Project Tree improvements

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
VilleK
Site Admin
Posts: 2355
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

I'll remove it for next build then :). It is a good idea but obviously needs some more attention to get right so better put it on hold for now.
User avatar
rrTea
Posts: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

This has nothing to do with the previous part of the thread but it still falls under "Project tree readability" so here goes...

Am I the only one who finds the order of certain Project Tree entries inconsistent / confusing? For example I always somehow expect Model's OnSpawn entry to be near the top, just like main "OnLoaded" is.

Similarly, every time I want to access "OnRemove" of a Model, I instinctively tend to look at the bottom of its Project Tree sublist (it's probably the last thing the Model will do, so it'd make sense for OnRemove to be there). Main program's "OnClose" (in my eyes the equivalent to "OnRemove" but for the whole program) on the other hand is in the middle...

...and to make it a bit more confusing, individual States of the model have the order reshuffled again, for example Model's "Definition" is on top of the sublist, while State's "Definitions" are second from bottom. Shouldn't "Definitions" be called "Content" anyway like in the main program Project Tree entry?

I'm not saying everything should match 1:1 to everything else, but maybe it'd be nice if at least Model and States had a similarly listed Project Tree entries?

(The ideal solution would be to have everything mapped 1:1, and the lower part of the Project Tree just reserved for "Content", but that'd probably be wrong...)
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

rrTea wrote:Am I the only one who finds the order of certain Project Tree entries inconsistent / confusing?
rrTea, for sure you are not the only one, but the others somehow get used to the current not so logical ordering of sections. Your proposal makes sense - sections ordered by lifecycle, e.g.:

ZAppliation
- OnLoaded
- States
- OnRender
- OnBeginRenderPass
- OnUpdate
- OnClose
- Lights
- Content

AppState
- Definitions
- OnStart
- OnRender
- OnUpdate
- OnLeave

Model
- Definitions
- OnSpawn
- States
- OnRender
- OnUpdate
- OnCollision
- OnRemove

Remarks:
1. I think Definitions is semantically different than Content, therefore, I used the original names.
2. Ville, is the Lights section really needed? Cannot be lights put to the Content section?
User avatar
Kjell
Posts: 1915
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi guys,

Hmm .. I'd keep all events ( everything starting with "On" ) grouped together and follow the order in which events are executed.

Code: Select all

ZApplication
- States
- OnLoaded				(Create)
- OnUpdate				(Update)
- OnBeginRenderPass
- OnRender				(Render)
- OnClose 				(Delete)
- Content

AppState
- OnStart 				(Create)
- OnUpdate				(Update)
- OnRender				(Render)
- OnLeave 				(Delete)
- Content

Model
- States
- OnSpawn 				(Create)
- OnUpdate				(Update)
- OnCollision
- OnRender				(Render)
- OnRemove				(Delete)
- Definitions

ModelState
- OnStart 				(Create)
- OnUpdate				(Update)
- OnCollision
- OnRender				(Render)
- OnLeave 				(Delete)
But as long as it's logical in some way i don't really mind ( which isn't the case right now ).
Rado1 wrote:I think Definitions is semantically different than Content, therefore, I used the original names.
The Definitions node of AppState should be called Content instead .. I actually talked to Ville about this a couple of months ago.

+ Not sure why ModelState has a Definitions node as well ( accidental inheritance? ).

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

Post by VilleK »

Good suggestion. This can be changed without breaking backwards compatibility. Can we agree on one of the suggested orders?
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

I'm fine with suggestion of Kjell with unified/simplified names, but instead of Delete I would prefer Destroy (as antonym to Create) and Model.Definitions can be Model.Content.
User avatar
Kjell
Posts: 1915
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi Rado1,
Rado1 wrote:I'm fine with suggestion of Kjell with unified/simplified names, but instead of Delete I would prefer Destroy (as antonym to Create)
I only listed the events like that to make it easier to compare the order between the different component .. not as a suggestion to rename them :wink:
Rado1 wrote:Model.Definitions can be Model.Content.
Did you mean AppState.Definitions instead of Model.Definitions? Since i do think Model.Definitions should stay that way.

K
User avatar
rrTea
Posts: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

Kjell wrote:But as long as it's logical in some way i don't really mind
Same here :) Obviously there will be some exceptions but hey.

Kjell wrote:+ Not sure why ModelState has a Definitions node as well ( accidental inheritance? ).
I actually occasionally use those for storing some Model state-specific values etc... Maybe it's just my weird habit.


(Maybe in a distant future it'd work well to have the lower part of the Project Tree reserved for "Content / Definition" field that appears when the App / Model / ModelState is selected / clicked on, similar to how "Properties" appear right now. This'd remove the currently necessary requirement to have the App branch end with "Content"... One problem I see with this is that the number of Content entries can vary a lot - the main App will have many entries in Content while a Model can have only a few... and a State almost nothing...)
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

Kjell wrote:
Rado1 wrote:Model.Definitions can be Model.Content.
Did you mean AppState.Definitions instead of Model.Definitions? Since i do think Model.Definitions should stay that way.
Kjell, I meant all Definitions renamed to Content; AppState.Content, Model.Content... but that's maybe not a good idea, I'm fine with Definitions sections as they are now.
Last edited by Rado1 on Wed Dec 24, 2014 2:49 pm, edited 1 time in total.
User avatar
Kjell
Posts: 1915
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi Rado1,
Rado1 wrote:I meant all Definitions rename to Content; AppState.Content, Model.Content... but that's maybe not a good idea, I'm fine with Definitions sections as they are now.
I just think it's beneficial to indicate there's a clear distinction between Model.Definitions and App.Content ( and AppState.Content ) as Definitions get allocated for each individual clone, whereas for Content there's no such feature.

K
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

Kjell wrote:I just think it's beneficial to indicate there's a clear distinction between Model.Definitions and App.Content ( and AppState.Content ) as Definitions get allocated for each individual clone, whereas for Content there's no such feature.
I agree.
User avatar
VilleK
Site Admin
Posts: 2355
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

I've updated the order of the property lists now (all except ModelState.OnCollision because AppState and ModelState share the same parent class so I could not alter it). Beta updated.
User avatar
Rado1
Posts: 775
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 »

By the latest change I got errors in my projects because ZExpressions in application states do not recognize variables defined in ZLibrary placed in OnLoaded section.
User avatar
VilleK
Site Admin
Posts: 2355
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Ah. So this change isn't totally backwards compatible after all. I've moved OnLoaded back to top again. Any other problems?
User avatar
rrTea
Posts: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

Looks better. There are a few little things I found surprising, nothing major but for example the Model and ModelStates don't have the same order of sublists (ModelState has OnCollision as last entry for example - due to the structural similarity of Model / ModelState I'd expect sublists of both to be almost identical), and if I understood correctly the content / code of ModelStates are executed after the main Model events, so I would expect States to be after OnUpdate / OnRender / OnCollision but Before OnRemove.

But this is just a minor observation really. It does make more sense than before so definitely an improvement.
Post Reply