ZGameEditor forum

Very cool, that works quite well, but is also limited with the currentModel issue. See attached; that draw event is fine, and then the behaviour involks CurrentModel in the expression and fails,. if CurrentModel can be made to point at the executing model then this will be a very usefull time saving organisation feature.

@Ville - Fantastic!

@jph - Instead of using CurrentModel, you could write any CurrentModel values you want to use to a global array, then do your component call, and finally use any values that got set by the call from the array again. It's a workaround, but one that you probably got used to by now ( returning custom data types from functions )

K

Poking around and stumbling as I am want to do, I stumbled upon this strange solution to JPH's demo, which will surely provoke discussion.

The cool part is, as long as ModelState1 is never called, and thus forced to calculate itself, it works simply as a component holder on every list property. I've tried them all.

EDIT - @Villek - You're right - All those modelstates unnecessary. Changed to use definitions for posterity.

Ville: The CallComponent works well, except of the CurrentModel issue. Great!

y offs et: Nice fix of this particular case, but will not work in cases when components are called from different models.

Therefore, I would suggest to fix CurrentModel to behave as a function being aware of its calling context. Is it possible, Ville?

There is also the problem with recursive calls from models; ZGE crashes in runtime. See/run the attached file.

Yeah, y offs et you could just move the controller into the model's update and have it 'work' ,. however the thing that makes the new component usefull is calling complex routines in a general way and likely from a different model,. I changed it so it is working as Kjell suggests,. this would be usefull if the routine is complex or you have many models using that same bit and you want to be able to tweek them all at once while keeping them the same,. you just need to do the additional work of sending the data to the array;

Yes, I agree with Rado1 if this could be built in, so the currentModel is used in the correct the context, this would be even better,. but even as is it is quite usefull,. if it stays this way, decent documentation explaing it would be needed.

So it turns out CallComponent can be useful for defining component-"subroutines" that are placed in groups in a model Definitions-section, good idea!

CurrentModel should definitely be changed but it requires work on the type-system because currently a function (or a variable) cannot hold a model reference.

Recursion needs to be used like a normal recursive function: the recursive call has to be made within some kind of logic (Condition) so it won't make infinite recursion. I can try to detect this in design-time but the user needs to be careful too. There are already other recursive functionality in ZGE where care needs to be taken: zlibrary-functions, MeshLoad/BitmapLoad, MeshLoop.

The Model's list tree items are executed as first, then ModelState's list tree items.

I've thought about this in the past. Wouldn't it be better to have a Model component do this?

Before it begins execution of it's list tree,
1) check for ModelState children, and
2) if true, check if children active, and
3) if true, execute the dual onUpdate, onRender, and onCollision lists in a parent - child order.