I'd like to replace this with simple numbered layers. The problem are the additional behaviors every layer has. Just as one example, blastwaves do not move vehicles that cannot be not grabbed. The comment in the engine gives thrones and tower entrances as examples for this. I'm not sure why those are not in the staticback or structure layer (which are not blasted at all), but the reason is probably some other additional behavior of those categories. And there are enough of them that it isn't feasible to replace them all in one go.
So here's a tentative plan to go forward:
- Switch the internal representation in the engine to numbered layers, and map the old categories to them, with extra layers in between
- Add a feature to set the layer independently of the category
- Make the engine compare layers instead of categories where that makes sense. The blastwave example might continue to not blast objects in the background, but it might also make more sense to cap off the blast speed above a certain mass instead.
- Provide alternatives for the additional behaviors, like the no-gravity-feature StaticBack has.
- Deprecate the old categories and switch the objects over one by one
Comments?
> Category is a collection of flags that have almost nothing to do with each other.
At least the first few categories do fit very well in categories: objects, vehicles, structures, static backround objects. So what do you mean, in what way don't they have anything to do with each other?
>can overwrite them
You mean with SetCategory()?
> additional behaviors associated with each layer make the whole thing somewhat inflexible
In what way? Why is that inflexible? Example?
>we could often use a bigger number of layers than the fifteen we have
For what? Examples?
Also:
Is the only thing a layer does to place the objects in front of each other (Something like a Z-depth)? Thinking of Find_Category(), I previously assumed that the objects list are sorted by category to allow faster access.
>> can overwrite them
> You mean with SetCategory()?
Yes.
> In what way? Why is that inflexible? Example?
Why does an object have to be in a certain layer in order to grow? Why do earthquakes only affect one layer? Why doesn't the gravity affect the first layer before the landscape?
>For what? Examples?
Indicator objects that are in front of all C4D_Objects, but are not forced to be parallax. Big animals that are always behind Clonks. Properly splitting castles and trees in two layers. Everything SetObjectOrder, ResortObjects and Resort is currently used for.
As the core of the Category/Layer implementation goes back to Clonk 4, I can only speculate about the reasons, but I do not think that faster access was a consideration. The object list is ordered in the order the objects are drawn, first by layer (as implied by the category), then by age of the object definitions oldest object (I think).
I am definitely in favor of this, and had actually planned to do it myself some day. The multitude of special properties associated with categories is a common source of limitations when you're designing objects.
I wonder whether we shouldn't just remove the layer feature and replace it with an option to disable objects. Isn't that the only usecase the layers are actually used for?
Well, perhaps we can move the current category to "Behaviorflags" or something and reuse the term.
Besides, the term "Disabled" is already taken for objects disabled by object status.
Btw: The old CR-FindObject did have that implicit property.
>I see no important usecase for finding disabled objects
Well, I do. One use of layers for me was to make the player's Clonk invulnerable for a few seconds when he respawns. Protecting him from an instant death by spawning for example in an explosion.
While said Clonk is invulnerable to other objects, he is still meant to be found by FindObject(Find_OCF(OCF_CrewMember)) when you want to apply certain effects to all the Clonks in the game (since he is not disabled after all - he can still walk around and cast stuff)
>But is it really worth all the complexity in every script?
I don't think adding a GetLayer check where you need it is too much hassle. Sven even suggested having FindLayer(mylayer) implicit for FindObject - I don't really know whether I like that yet but it is better than completely removing layers.
>I wonder whether we shouldn't just remove the layer feature and replace it with an option to disable objects. Isn't that the only usecase the layers are actually used for?
They were used. In races for example where you could terajump yourself without affecting your opponents. They are useful as they are
I would seperate drawing from game related stuff there
And if objects relied on something layer related ("I can hit everything in my two adjacent layers") you could once again not freely assign layers to GUI elements fearing it might have another effect.
And if the objects do not rely on something layer related as the single condition ("Has to be in my adjacent layers AND has to be movable") you could as well just throw the layer part out
> Except if you want GUI elements that are behind game objects. I'm having a hard time imagining why one would want that.
You might want to use an underlaid disc as a marker for recently selected clonks (instead of brackets or an arrow).
We have a bunch of layers, let's say 70, ordered like this:
(-10)-(-1): Background objects
0: The landscape. No object has this layer so we can use the zero as a layer-not-yet-set marker
1-5: Deco objects.
6: Castles
7-9: Stuff in castles
10: Buildings
11-15: Stuff in front of buildings
16-19: Stuff behind vehicles
20: vehicles
21-25: Stuff in front of vehicles
26: Stuff behind large animals
27: The Dragon (and other large animals)
28: Stuff in front of The Dragon
29: Stuff behind animals
30: Clonks
31: Stuff in front of Clonks (old-style shields would be an example)
32: Stuff behind small animals
33: Small animals - Wipfs and anything else that's smaller than a Clonk
34-35: Stuff in front of animals
36-39: Stuff behind objects
40: Flints, rocks, and similar stuff
41-45: Stuff in front of objects
46-49: The empty space between the game and the GUI
50-59: GUI objects
All numbers subject to change, of course. We will have to strike a balance between reserving enough layers for unforeseen uses and small, easy-to-remember numbers. 70 layers is probably on the lower end.
With this design, the blastwave example could move objects in layers 9 to 45. (Assuming that moving buildings a little bit is okay. If not, 16-49.) If something unforeseen comes along and requires a game object to escape explosions to the front, it could use the empty space, but a don't-blast-me opt-out query might work better.
Besides, the shockwave could rather use a callback. So switching from engine-implementation to object implementation might be interesting here.
>With this design, the blastwave example could move objects in layers 9 to 45.
So it WOULD hit the GUI element serving as a marker around a certain vehicle (that is behind of f.e. Clonks)? I don't like that.
I say: Use such a layer system for drawing and ordering objects as the sole purpose
Just to distinguish from Object layers, this ordering should probably be called Z-ordering or similar. Yeah, I think it makes sense to purge the categories by seperating the z-order from being bound to certain game mechanics. That's why I am doubting if binding game mechanics on to certain ranges of z-orders is such a wise idea. I'd like to see those properties of which you mentioned a few to be swapped into defcore-properties.
However, I don't have an overview of what all this special-category-behaviour consists of so this suggestion just comes from what the data I have.
Another note: Because of the upcoming feature freeze (after update system is implemented + probably another important thing that will pop up in the last minute), I'd refrain from opening another construction site for this release. Your suggestion for an implementation will probably only get interesting for the works on the release with castles (2nd or 3rd).
> Just to distinguish from Object layers, this ordering should probably be called Z-ordering or similar.
A hyphenated name is impossible, though. I've considered simply "z" because that's what it is (well, apart from the other z that is called Parallaxity). But z is an awfully short name.
> That's why I am doubting if binding game mechanics on to certain ranges of z-orders is such a wise idea.
Well, we need something. Using the layer isn't in of itself worse than using x and y. It's only that various other stuff that had nothing to do with the position was also triggered off those categories that created this mess. If we refrain from doing that and only use the layer for stuff where the position of the object should matter, we should be fine. That's one reason I mentioned explosions: It just makes sense that explosions affect a certain area. On the other hand, it certainly doesn't make sense to make gravity depend on the position of an object. At least in the small confines of a Clonk landscape ;-)
> However, I don't have an overview of what all this special-category-behaviour consists of so this suggestion just comes from what the data I have.
The problem is, the list of stuff that depends on the category defies summaries. I'd encourage you to do a search in the engine for C4D_StaticBack and the other categories and take a look at a few results that check whether a Category has that flag. There are often comments or self-documenting function names in the vicinity explaining the reason for the check: "staticback must not have speed", "Must be static back: this excludes trees that have already been chopped", "IsMoveableBySolidMask", "living takes additional dmg from blasts", etc. Compiling a complete picture would be a waste of time, though :-)
And yes, I don't plan on pushing this before the release.
>That's one reason I mentioned explosions: It just makes sense that explosions affect a certain area.
Sure, but if you use the layers like that you would need yet another possibility to say for example "hey, I am a GUI object, don't touch me". And therefore it would not make everythinge easier (as it is intended to - since the current category approach actually "works" as well until you want to do certain things).
PS: I mean the whole flaw in the category system at the moment is that the order of objects is always linked to ingame behavior (You want an objects behind Clonks but not static back? Too bad, it's me. Categories.). And I think _that_ is what we should get rid of. Not just introducing more "categories" that actually do the same (but you notice it later since you have more now)
>But unless there's a usecase for GUI elements being hit, excluding them on the basis of them being too far away on the z axis makes sense.
And what about that GUI element that I mentioned earlier? The marker around the vehicle that has to be behind Clonks but in front of vehicles?
I am pretty sure something like that would neither be rare not the only case where you need different behavior.
I don't think just adding more categories would solve the issues we have with categories at the moment.
I stand by my point
PS: I mean the whole flaw in the category system at the moment is that the order of objects is always linked to ingame behavior (You want an objects behind Clonks but not static back? Too bad, it's me. Categories.). And I think _that_ is what we should get rid of. Not just introducing more "categories" that actually do the same (but you notice it later since you have more now)
> And what about that GUI element that I mentioned earlier?
http://forum.openclonk.org/topic_show.pl?pid=10373#pid10373
The flaw of the categorization system is not that various behaviors were based on the z position, but that the z position was tied together with behaviors that it shouldn't have been tied with. In some cases, we really want to affect a certain area. There's not many, but there are some. I can think of two at the moment: Blastwaves and Solidmasks. Notice how these already affect a certain area in x and y dimensions. That's a good indicator that also using the z dimension is useful. It wouldn't make sense to blast objects behind the landscape or on the GUI layer. Just like it doesn't make sense to blast contained objects. We don't want to add func IsBlastable() { return !Contained; } to half of the objects, or func IsBlastable() { return false; } to all GUI objects. We might want to add a function like this to the exceptions to the rule, but that doesn't eliminate the need for sensible defaults. And in these two cases, using the z position is a lot more sensible than using a crude approximation of it with categories.
(Take a look at the IsMoveableBySolidMask function: Everything that's behind the Vehicle (Buildings and Staticbacks and some Vehicles) doesn't move, everything that is before it (really just GUI objects, which are targeted by the StaticBack exclusion) doesn't either. I'm not sure why the DFA_FLOAT term is there, maybe to solve some problem with two airships interacting badly.)
Most of the other category effects are not about the position of the object, and certainly shouldn't be tied to the z position. But in order to be able to write objects that do not use these special effects the categories offer, we need to fix the cases where the z position is needed to use the z position.
>http://forum.openclonk.org/topic_show.pl?pid=10373#pid10373
http://forum.openclonk.org/topic_show.pl?pid=10379#pid10379
With the current category system you can do nearly everything. Only in some special cases you have trouble achieving what you want.
Your solution would not change much about that I guess (you would still have unsolvable special cases while just having a lot more categories to care about - you would even still need SetObjectOrder: What if you have two dragons that are need to be in a specific order - what if we introduce another object that needs to be in front of dragons but behind the stuff behind animals (..while behaving like a rock)?)
> What if you have two dragons that are need to be in a specific order
You put them into different layers. Duh.
> what if we introduce another object that needs to be in front of dragons but behind the stuff behind animals (..while behaving like a rock)?)
You put them into the layer for stuff in front of Dragons, and give them C4D_Object. But I don't buy that we need that fine-grained control. Most objects work fine both before and after similar objects. It's just a few exceptions that need to be taken care of. We'll make sure that there are enough layers for these and it'll be fine.
>You put them into different layers. Duh.
Not possible if you follow your list. Only layer 27 is for "the dragon".
>But I don't buy that we need that fine-grained control. Most objects work fine both before and after similar objects.
But that fine-grained control for some very special corner cases is exactly the reason behind the request to scrap categories lnked to drawing order.
>>You put them into different layers. Duh.
> Not possible if you follow your list. Only layer 27 is for "the dragon".
There's layer 26 for stuff behind dragons. Stuff includes dragons :-)
>> But I don't buy that we need that fine-grained control. Most objects work fine both before and after similar objects.
> But that fine-grained control for some very special corner cases is exactly the reason behind the request to scrap categories lnked to drawing order.
Well, I'm separating the z-position from miscellaneous stuff like does-grow that shouldn't have been tied with it. The drawing position is just a result from the ingame position. For fine-grained control of special cases there'll be plenty of room between the z-positions used by the standard objects. Apparently that means more room for dragons. That's fine, I like dragons. ;-) The engine will probably only impose two hardcoded z positions: The landscape at 0 and global particles at a yet-to-be determined number between 6 and 2147483646. As I wrote above: We will have to strike a balance between reserving enough layers for unforeseen uses and small, easy-to-remember numbers. Suggestions welcome.
>There's layer 26 for stuff behind dragons. Stuff includes dragons :-)
Fails if you have three dragons then..
>Well, I'm separating the z-position from miscellaneous stuff like does-grow that shouldn't have been tied with it.
But you leave other stuff tied to it that leads to the same problem. I don't get the idea behind that.
You could as well just use the current category system and make everything you don't want tied to anything a property. You would still have some stuff that you could just not do with C4Script then, - but, well, if you want to keep those impossible things anyway (at least I could use SetObjectOrder more reliably, because everything would be more or less the same category)..
> >There's layer 26 for stuff behind dragons. Stuff includes dragons :-)
> Fails if you have three dragons then..
While I like dragons, there's such a thing as too much dragons. That many dragons would surely destroy all vehicles, making further layers available ;-)
Seriously, any better suggestions for the z-position of global particles and the default z-position for objects which don't specify one?
> But you leave other stuff tied to it that leads to the same problem. I don't get the idea behind that.
Simple: I don't believe that it will lead to the same problems. I think that it is a good idea to tie an object's position in the game to the object's position on the screen.
> You would still have some stuff that you could just not do with C4Script then
There is lots and lots and lots of stuff you can't do with C4Script. While it is fun to do things with the Clonk engine that it wasn't designed for, the engine has to first cater to the game we are making, and make it simple to create content for it. That implies that we should keep things simple if possible. What's simpler than a distance check to limit an effects range?
>Seriously, any better suggestions for the z-position of global particles and the default z-position for objects which don't specify one?
Well, if the layers would only affect the order on the screen you could more or use the surrounding layers without having to fear that your dragon behaves differently. But I think you know my opinion about that by now
>What's simpler than a distance check to limit an effects range?
Uh. Having categories like "object", "vehicle", "animal" which imply the behavior is actually quite simple and straight forward imo. Some addition to that, being able to sort your objects on the screen, would make it perfect without making it more complicated (if you don't want to specify the order it would just default. But you could still change it ingame without changing the behavior of the object.)
Here is a compromise between yours and Günthers argumentation. What do you two think of this.:
The (major part of) the behavior that is linked to object order can be put into seperate definition properties (DefCore) or script, some can even be dropped without replacement whenever this behaviour can be reached already with other means.
If object order (currently: "category") is not specified in the DefCore, it defaults to whatever seems appropiate when looking at the other (new and old) properties.
The object order of an object with NoMovement=1 (or similar) will default to an object order similar to C4D_StaticBack. Similarily, an object with CanBeConstructed=1 will have the object order of structures, Grab!=0 of vehicles, CanBeChopped=1 slightly behind structuresetc. Find_ObjectOrderRange or similar will not exist but something like Find_DefCoreProperty.
Thus, the logic that Günther tried to give as an example for what-goes-where can be taken from the objects properties by default. Still, the object order can be changed during the game (or in the defcore) without that the behaviour of the object changes. (Trees in front of animals & objects and trees behind structures should probably have the same behaviour.)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill