![[de]](/mwf/flags/de.png "Germany")
At the moment, the different layers of objects are implemented using bits in the so-called Category. (The only difference between a category bit and some random flag in C4Def is that Objects can overwrite them, so it's no surprise that the Category is a collection of flags that have almost nothing to do with each other.) While this works, the additional behaviors associated with each layer make the whole thing somewhat inflexible, and we could often use a bigger number of layers than the fifteen we have. (Five of these are behind the landscape and another five have a forced parallaxity of 0).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?
I need some clarification on your post before I can respond anything reasonable.> 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.
The first five categories indeed have in common that they also set the layer the object is in. The other categories, not so much. Especially the ones that just were removed.>> 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).
By "layers" you mean "z-order"? The term "layer" is already taken and shouldn't be used to avoid confusion.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.
The z-order is the total order of the objects, "Category-layers" only the broad one.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.
For the real layers in clonk (SetObjectLayer()). I used them in CR to create accessible Buildings. There they really unfold all their posibilitys, cause you then have more objects in the same layer e.g. the layer of the building. But yes, something like SetObjectLayer(this) is in most cases just used to disable objects.
You could as well just make all objects that are not in the currently visible layer disabled.
Ehm no! Not if there are other players around that are not in the same building.
SetContactDensity and Vehicle Material with a density between 25 and 50 I guess.
Like discussed in the CF - this breaks the Clonk-AI Not watching out for contacts density, and you can't move the house easily.
Even if layers aren't used a lot for other things: Why would you want to change it? The functionality is there. It is not more difficult to use than disabling objects (to disable, you write SetObjectLayer(this) instead of SetObjectDisabled(). To find non-disabled objects, you write Find_Layer(this) instead of Find_NotDisabled()). And in some rare cases, the ability to have a subset of objects in a layer comes in handy.Besides, the term "Disabled" is already taken for objects disabled by object status.
We could make disabled objects not show up in FindObjects. They wouldn't really be objects, but a simple method to create decoration that looks like an object.
That would be the same as having an implicit "Find_Layer(GetObjectLayer())" in FindObjects.Btw: The old CR-FindObject did have that implicit property.
See Sven. There was a thorough discussion about this in the bugtracker between me, CK and Isilkor. Read up here.
There are important differences between Layers and disabled objects. I agree that making FindObjects limited to the current Layer is problematic, but I think disabled objects are another matter. In particular, I see no important usecase for finding disabled objects, whereas the concept of layers requires that objects in the same layer find subsets of each other. But having scripts store all disabled objects in an array for future reference would work.
>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)
Yeah, a Clonk that can walk around isn't disabled. If you want him to walk around but not tumble from explosions or rocks (instead of simply not loosing life energy), the object layer stuff is handy, I'll grant that. But is it really worth all the complexity in every script?
>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
If you use layers for game related stuff (explosions) you are, yet again, not free to use them for object ordering (because having that animal behind your Clonk would maybe prevent it from getting hit by something).I would seperate drawing from game related stuff there
Objects that are adjacent in the drawing order should be adjacent in the game logic as well. For example, hitting Clonk with rocks that are behind buildings would feel very weird. So some properties of the Categories do make sense, the problem is that the Categories were abused for other stuff.
But the arrow (GUI element) you were pointing out earlier has nothing to do with the game logic.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
It has everything to do with game logic: Nothing on the GUI layer should interact with anything that happens in the game layers. That's very straightforward game logic that is directly tied to the placement of the objects in the layers. (Except if you want GUI elements that are behind game objects. I'm having a hard time imagining why one would want that.)
Thing is you would probably find reasons to have more than one GUI (or special effects) layer where you do not want any interaction with the game objects
What about GUI-Elements (like energy bars or something) attached to a normal object? Here a layer doesn't help and you would need a category (especially if a few elements overlap)...
> 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).
Okay, maybe. Good news is that you don't care whether that object is blasted or moved by solidmasks because it would be attached to the Clonk.
Okay, here's more detail about how I think this could work: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.
This seems quite limited and very specific though - do we need such a strict separation? Working with (object-script) ObjectOrder in more places might be more flexible than a fixed limitation in the engine.Besides, the shockwave could rather use a callback. So switching from engine-implementation to object implementation might be interesting here.
Limited in what way? If you mean the number of layers, I already wrote that 70 are probably the minimum. 4294967295 is the theoretical maximum, but I don't think we should use numbers that require counting the digits. We will need to standardize the layer numbers for categories of objects and name them so that object authors won't need to constantly look up which layers the objects use that they want to put a new object in between of, so specific is necessary.
>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
OK, after the clarification: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)
There's certainly a usecase for excluding objects from blastwaves. 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.
>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.)
ACK by the way. I share your concerns regarding the linking of ingame behaviour to the order of how objects are displayed. But when the category system is overhauled, we get the chance to get rid of that.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
