> 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.