Inheritance

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

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.
Attachments
callingERR.zgeproj
test
(1.98 KiB) Downloaded 468 times
iterationGAMES.com
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:)

@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 ) :wink:

K
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

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.
Attachments
callingERR_fixed.zgeproj
(2.19 KiB) Downloaded 542 times
Last edited by y offs et on Mon Aug 02, 2010 6:12 pm, edited 1 time in total.
"great expectations"
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

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.
Attachments
X.zgeproj
(479 Bytes) Downloaded 497 times
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

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;

Code: Select all

xy_holder[0]=CurrentModel.Position.x;
xy_holder[1]=CurrentModel.Position.y;

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.
Attachments
callingERR_fixed2.zgeproj
two models using the same behaviour!
(2.65 KiB) Downloaded 469 times
iterationGAMES.com
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

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.
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

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.
"great expectations"
Post Reply