Beta release 3.1b

[Rado1]

One low-prio improvement: vec*/mat4 types can be highlighted in expression editor. Maybe also other component-based types. If possible all available types of variables.

[Rado1]

Observation: RenderSetColor.Color = vector3(1,1,1); gives syntax error "Invalid conversion: ((float)vector3(1,1,1))". Would it be possible to assign also vec3 values to such properties? The possibility to assign also float values can be preserved; but not necessarily.

[VilleK]

Small update:
- Assigns between arrays and properties improved ("RenderSetColor.Color = vector3(1,1,1)", "vec3 foo = App.CameraPosition;" etc). Let me know if any problems remain.
- F5 (refresh) when a ZExpression is selected in project tree will execute that expression. Should work with other components too.

http://www.zgameeditor.org/files/ZGameEditor_beta.zip

[Kjell]

Hi Ville,

F5 (refresh) when a ZExpression is selected in project tree will execute that expression. Should work with other components too.

Thanks a bundle! Tested & working ( even in combination with disabled components ) with ZExpression / SpawnModel / PlaySound etc Would be nice if it would work with the Group component as well, but no biggie.

Two minor issues, when selecting multiple components only the last is executed, and WebOpen only seems to work twice ( and stops working after that ).

K

[VilleK]

Update:
- "Property references" changed. Previously properties such as RenderText.TextFloatRef and AnimatorSimple.Target could only hold a simple [componentname].[property] syntax. Now they can contain whole expresssions:

App.FpsCounter
2 * App.FpsCounter
myFunction()
globalVariableDefinedInLibrary

etc.

AnimatorSimple.Target must have a so called "lvalue", i.e. something that can be put on the left side of an assignment.

Editing these properties now bring up the code editor so you get auto-suggestions etc also.

This is more generic and cleans up the code inside ZGE. Let me know if it breaks something. (previous beta can be downloaded here if you need to go back)

http://www.zgameeditor.org/files/ZGameEditor_beta.zip

[Kjell]

"Property references" changed. Now they can contain whole expresssions

Not a big fan of this. Now, next to components containing properties using "regular" expressions ( such as RenderText.RenderCharExpression and RenderParticles.OnEmitExpression ) and expressions that explicitly return a value ( such as Repeat.WhileExp and Condition.Expression ), there's a yet another variant using a different syntax ( no return keyword used ). Aside from ZExpression, ZLibrary, ZExternalLibrary, Shader.Sources, MeshExpression / BitmapExpression / SampleExpression which are have their own conventions as well of course.

In fact, i'd rather see properties like RenderText.TextFloatRef ( and RenderText.TextArray ) being removed altogether as they were workarounds from the days when Strings weren't supported by the scripting language yet.

Just my 2 cents .. feel free to disagree

K

[VilleK]

Kjell,

In this case, since the syntax already was "componentname.propetyname", I merely improved it by allowing full expressions while maintaining backward compatibility.

I agree too many variations of syntax is confusing. I haven't fully decided what I would do if I could ignore backward compatibility. Having to type "return this.Iteration<10;" when only the actual expression would suffice feels cumbersome but the "return" syntax has the important advantage that it allows full statements (i.e. declare local vars, make calculations, issue commands etc before the return).

Imo RenderText should only have Text and TextExpression properties. So Text could be PLAYER ONE etc. and TextExpression "SCORE: " + intToStr(score). Should cover most cases.

Anyway, I only made this change because Rado1 pointed out that global vars declared in libraries could not be used in property-references. This is fixed now, and I also could simplify the engine by using expressions everywhere instead of a dedicated type for property-references.

[Rado1]

In general, I personally prefer to have expression properties (maybe everywhere where possible). This style of programming can increase encapsulation and flexibility/simplicity of code, e.g., RenderText itself specifies what to display. Other properties such as TextFloatRef, TextArray and FloatMultiply can be omitted if backward compatibility is not needed. I really appreciate this change mainly in the case of TextFloatRef which did not work for global variables declared in ZLibrary and all referred variables had to be floats, even if the values were just integers, etc.

[Kjell]

Hi guys,

Obviously a "hack", but you can already set the Text property of a RenderText component from itself using the RenderCharExpression property ( if you really want to )* For instance ..

Code: Select all

ZZDC<?xml version="1.0" encoding="iso-8859-1" ?>
<RenderText Text=" " RenderCharExpression="if(!CharI)Text = intToStr(App.FpsCounter);"/>

*Of course for this to work the DrawText.Text property needs to contain at least one character.

K

[Imerion]

I just tried out the Model Inheritance, but I can't seem to make it work.
I have a set-up where one model, called PlayerShip, spawns two EngineFlare models from it's OnSpawn-list. These two EngineFlare models have BaseModel set to PlayerShip. Somehow this crashes my game when I try to run it, regardless of whether I run it in the editor or if I build it first. Could it be a bug, or am I doing something wrong?

Edit : It woks if I spawn the EngineFlare models from another place, so perhaps the problem lies with them coming from the OnSpawn list?

[Kjell]

Hi Imerion,

I just tried out the Model Inheritance, but I can't seem to make it work.

Perhaps you've mistaken inheritance for hierarchical parent-child relationship used in 3D modeling applications ( Maya / Softimage / Blender etc )?

I have a set-up where one model, called PlayerShip, spawns two EngineFlare models from it's OnSpawn-list. These two EngineFlare models have BaseModel set to PlayerShip. Somehow this crashes my game when I try to run it, regardless of whether I run it in the editor or if I build it first.

The reason why it crashes is because you've created a endless loop. Every EngineFlare you spawn causes another two to be spawn ( since that behavior is inherited from its BaseModel ) ..

What are you trying to do exactly?

K

[Imerion]

Ah, I get it. Everything in every list gets included? So does that mean my models, now spawned from AppState Level1 OnStart, include the renders and everything from my PlayerShip model too?

I was trying to make it so I can access every part of PlayerShip from each of the EngineFlare models. So I can do things like "CurrentModel.Position.Y = PlayerShip.Position.Y;" or have a variable called ShipBoost included in the Definitions of PlayerShip be readable from the EngineFlare models too.

But I may have missunderstood the system. I think I have a better idea now though.

Edit again : Realized this "CurrentModel.Position.Y = PlayerShip.Position.Y;" works already without inheritance. Scratch that.

[Kjell]

Hi Imerion,

Do keep in mind that you can only directly access a model like that when it's been spawned as a reference ( and thus only a single instance can exist ).

In case you need multiple instances / clones, you could for instance add a local variable ( by putting it in the Definitions node ) to the child model .. and set it to the respective parent just before spawning a clone. Attached is a example.

K

[Kjell]

Hi guys,

Perhaps a bit late, but wouldn't it make more sense to use all lowercase for the Camera / Mesh / Sound etc. variable types? The Model type ( available since 3.0 ) is all lowercase as well.

The current situation is not very convenient in combination with the naming convention ( as used in the examples & tutorials ) either. When you for instance only use a single Camera component in your project, you might want to name it "Camera" .. but then you can't use it in scripts, as it collides with the Camera type keyword. Of course you could use ( all lowercase ) "camera" in your scripts to refer to the Camera component ( since ZGE is case-insensitive ), but that's less than ideal / confusing.

K

[Rado1]

When you for instance only use a single Camera component in your project, you might want to name it "Camera" ..

Kjell, this is a good example of incorrect naming. You should not use the same name for different things in the same namespace; e.g., name of a type and name of a variable.

Learned from good practices of OO languages, I rather prefer to use upper camel case for types and lower camel case for local variables. Usually, I also use upper camel case also for global variables; but that's matter of style.

Anyway, I agree with Kjell that having names for types as "model" and "Camera" is not consistent. I would prefer to have "Model". Also because ZGE uses upper camel case for all component types in project tree and Add Component dialog. Of course, renaming the "model" type in expressions to "Model" would be backward incompatible.