Scripting improvements in ZGE 2.0 beta

[VilleK]

I'm updating the compiler for the 2.0 release. Here are the updates so far:

1. Advanced expressions and assignments.

Previously you could only use expressions such as "[component].[property]". Now you can use more advanced expressions so for instance this is possible:

(Um1 is a UseMaterial component)
//Set the red component of the material
Um1.Material.Color.R=1;

Notice that "Material" is a property referring to another component.

You can also assign component references to another component:

//Use different materials
if(something)
Um1.Material=Material1;
else
Um1.Material=Material2;


2. "CurrentModel" behaves like it should.

Referring to CurrentModel in expressions now always refer to the model currently executing. This means you can now use "CurrentModel" in ZLibrary-functions or components called with CallComponent.


3. New datatype "model".

Model is now a built-in datatype.

//Use as a local variable
model m=CurrentModel;
m.Position.x=2;

//Use as parameter to ZLibrary functions
void UpdatePosition(model m) {
m.Position.X += 0.1 * App.DeltaTime;
}


4. New built-in function

//"createModel" works like SpawnModel (clone)
for(int i=0; i<10; i++) {
model m = createModel(Model1);
m.Position.X = random(0,5);
}


5. NOTE

I have made significant changes to the compiler code so there are probably bugs lurking around. Please be aware of this and report anything you may find!

Also note that with the new expressions you must be careful not referring to null values:

//Error: m is not assigned
model m;
m.position.x=1;

This will give you a null-pointer message in the log-window. In runtime you will get an access violation instead.


6. Model.CollidedWith property instead of App.CollisionCategory

Introducing two new properties that replace App.CollisionCategory.
- Model.ClassId : An integer that is unique for this model.
- Model.CollidedWith : In OnCollision this property is set to the model that the current model has collided with.

When an collision occurs and OnCollision on a model executes, previously you would do things like: "app.collidedCategory==4" to test which kind of model collision occurs with.

The new syntax is

"CurrentModel.CollidedWith.Category==4"

or using ClassId:

"CurrentModel.CollidedWith.ClassId==PowerUpModel.ClassId"

Code: Select all

switch(CurrentModel.CollidedWith.ClassId) {
  case EnemyModel.ClassId : 
     //...
  case PlayerShotModel.ClassId : 
     //...
}

The benefit of the new style is that it is easier to detect against a specific model (not just the category) and also you get hold of all the other properties (position etc) of the model that was collision occurred with.


7. DefineArray-component and DefineVariable support the new Model data type.

You can now store references to models in variables and arrays.

NOTE: if you store models in a array and the models are removed (using removemodel) the array element will point to an invalid model reference and trying to use that value will result in undefined errors.


8. Access to defined variables in other models.

You can now access defined variables in other components. This means lots of new possibilities for inter-model communications.

An example:

PlayerModel
-- Definitions
-----DefineVariable PlayerLives
-----DefineVariable PlayerScore

EnemyModel
-- Definitions
-----DefineVariable EnemyLife

Code: Select all

model m = PlayerModel;
m.PlayerLives-=1;

m=EnemyModel;
m.EnemyLife-=1;

NOTE 1: that you must make sure that the variable exists in the model otherwise you will get a "Defined var mismatch" error in the designer and undefined behavior in runtime. You can use the new ClassId-property to make sure the model is of the kind you expect it to be.

Code: Select all

m=PlayerModel;
m.EnemyLife=42; //ERROR: enemylife is not defined in playermodel

NOTE 2: variables are tied on relative position in Definitions-list. If you have two different enemy-models, Enemy1Model and Enemy2Model, you can define variables such as KillScore and Hitpoints in both models and they can be updated using the same code (in a zlibrary for instance) as long as they have the same relative position in respective models Definitions-list.

NOTE 3: it only works with variables defined directly under Model.Definitions. They can not be defined inside a sub-group or in a ModelState.Definitions. It should work with all kinds of components (mesh, material etc) although I have yet only tested it with DefineVariable.


9. New built-in function: trace

This function makes it easy to trace out values in the designer log window. Useful for debugging.

Code: Select all

if(score>100)
  trace("score is now: " + intToStr(score));

10. Null-values

You can test model variables and component references for null values. Null means it is not assigned to a value.

Code: Select all

Model m;
...
if(m==null)  //Test a local variable
  m=createModel(PlayerModel);

if(ModelArray[0]==null)  //Test a DefineArray of model type
  ModelArray[0] = CurrentModel;

ModelArray[1]=null; //Assign a null value

if(Um1.Material==null)  //Test a component reference property (Um1 is a UseMaterial component)
  Um1.Material=Material1;

[jph_wacheski]

Wow, all that looks quite tasty,. Unfortunatly I am too busy rushing to get the arcade machines done for the deadline. So I will not be able to test till probably soonest next week. But I shall return eventualy, and help shake loose any bugs,. .

[Rado1]

Great! Great! Great! Let's do some testing... and also refactoring the current ZGE code

[Lupo]

Amaziiing!!!


I'm just migrating to use model.collidedwith ...
and testing ...

[Lupo]

Hi,

I refactored the code collission in a couple of projects and worked perfectly!

As a side note, I was assigning a couple o enemies the same "code category", and then doing some conditions on the bullets collission, now I have to take into account that each enemy has a different ID...

great work ville!