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 » Sun Aug 01, 2010 12:42 pm

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 228 times
iterationGAMES.com

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Sun Aug 01, 2010 4:03 pm

:)

@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 » Mon Aug 02, 2010 2:28 am

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 286 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: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Mon Aug 02, 2010 12:53 pm

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 239 times

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

Post by jph_wacheski » Mon Aug 02, 2010 1:27 pm

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 225 times
iterationGAMES.com

User avatar
VilleK
Site Admin
Posts: 2052
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon Aug 02, 2010 1:32 pm

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 » Tue Aug 03, 2010 3:45 pm

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