> Here is a compromise between yours and Günthers argumentation. What do you two think of this.:

Sorry, that's not a compromise at all. We are all agreed that stuff like does-grow or the shape of the fire effect shouldn't depend on the object's position. How the engine derives a default position for object definitions that don't specify one isn't very important as one can always simply add that should the engine choose poorly.

> (Trees in front of animals & objects and trees behind structures should probably have the same behaviour.)

No, they shouldn't. Well, it doesn't matter for the two examples of position-based behavior (blastwaves and solidmasks) for trees, so let's take a car as an example. Cars are transported by solidmasks, at least by those attached to lifts. (No reason all solidmasks need to behave the same.) Buildings are not. I think it would look extremely weird if cars behind buildings were lifted by these solidmasks. There's a building in the way! A lift shouldn't be able to reach through the solid building and mess with the background objects!

I tried to think of other examples of position-based behavior in the engine, and remembered the hittest (Clonks vs. rocks). Again it would be just as weird to have a rock behind a building hit a Clonk in front of it as it would be for a rock ten Clonks away to hit the Clonk. Essentially, the engine would test (a.x, a.wdt) overlaps (b.x, b.wdt) and (a.y, a.hgt) overlaps (b.y, b.hgt) and (a.z, a.depth) overlaps (b.z, b.depth). The fact that the z test doesn't work properly at the moment doesn't mean that it shouldn't be there at all, it means that it should be made to work properly.

The freeze is over and various other projects are more or less done. It's time to wrap this up.

As usual, the most difficult thing is the script API. I've tentatively called the thing "Z", since that's what it is. One small problem is that we already have a Z position: Parallaxity. The new Z position would be a mere stacking order in the infinitely thin plane given by the parallaxity. Or, well, the layer in the plane, but using that word would require renaming that other "layer" feature. Anyway, I'd like to design a coherent API for both. Ideally including the feature request of the X/Y position of parallax objects being useful instead of the projected position on the landscape plane when the camera is at 0/0. That'd require dealing with infinitely far away objects (like the HUD...) separately, which is probably a good idea anyway. So, further feature requests? API suggestions?

There's a first patch on bitbucket. The category-replacing thingie is called "Plane" for now. Suggestions for better numbers for the inferred-from-category-planes are welcome. Here's a list of the remaining usages of "SortLimit" categories:
- C4Command::Build:
  // Worker ist structure or static back: internal target build only (old stuff)
  // Activate internal vehicles
- C4GameObjects::Load: // staticback must not have speed
- StaticBack have different behaviour with regards to "layer bounds"
- StaticBack don't move
- StaticBack can't be grabbed
- Only StaticBack can be chopped
- Only StaticBack and Alive Living can grow
- // Material check (if rule set or any other than structure or castle-part)
  bool fNeedMaterial = (Game.Rules & C4RULE_ConstructionNeedsMaterial) || !(Category & (C4D_Structure|C4D_StaticBack));
- StaticBack don't do gravity
- "// Woa, structures can build without target"
- bool IsMoveableBySolidMask()
  {
    C4PropList* pActionDef = GetAction();
    return (Status == C4OS_NORMAL)
           && !(Category & (C4D_StaticBack | C4D_Structure))
           && !Contained
           && ((~Category & C4D_Vehicle) || (OCF & OCF_Grab))
           && (!pActionDef || pActionDef->GetPropertyP(P_Procedure) != DFA_FLOAT)
           ;
  }
- StaticBack are not sorted by their definition
-   // Regular objects: Try to find a new, suitable owner from the same team
    // Ignore StaticBack, because this would not be backwards compatible with many internal objects such as team account
    // Do not ignore flags which might be StaticBack if being attached to castle parts
- Structure is created using CreateConstruction instead of CreateObject on drag'n'drop into a editor viewport
- // Structures dig free snow
- C4Object::DoCon:
  // even rotated buildings need to be moved upwards
  // but by con difference, because with keep-bottom-method, they might still be sinking
  // besides, moving the building up may often stabilize it
-   // set default fire modes
  DWORD dwCat = pObj->Category;
  if (dwCat & (C4D_Living | C4D_StaticBack)) // Tiere, Bäume
    iFireMode = C4Fx_FireMode_LivingVeg;
  else if (dwCat & (C4D_Structure | C4D_Vehicle)) // Gebäude und Fahrzeuge sind unten meist kantig
    iFireMode = C4Fx_FireMode_StructVeh;
  else
    iFireMode = C4Fx_FireMode_Object;
- // Shock wave hit (if in level range, living, object and vehicle only. No structures/StatickBack, as this would mess up castles, elevators, etc.!)
  if (cObj->Category & (C4D_Living | C4D_Object | C4D_Vehicle))
  // vehicles and floating objects only if grab+pushable (no throne, no tower entrances...)
    // living takes additional dmg from blasts
    cObj->Fling( itofix(Sign(cObj->GetX()-tx+Rnd3())*(level-Abs(tx-cObj->GetX()))) / BoundBy<int32_t>(cObj->Mass/10, 4, (cObj->Category & C4D_Living) ? 8 : 20), itofix(-level+Abs(ty-cObj->GetY())) / BoundBy<int32_t>(cObj->Mass/10, 4, (cObj->Category & C4D_Living) ? 8 : 20), true );
    if (cObj->Category & C4D_Object)
      // tracing indirect killers
      cObj->Controller = iCausedBy;
- C4Game::ShakeObjects only affects Living
- C4Object::Init: if (Category & C4D_Living) Alive=1;
-   // OCF_Inflammable: Is not burning and is inflammable
    // Is not a dead living
-  if (Category & C4D_Living)
  {
    OCF|=OCF_Living;
    if (Alive) OCF|=OCF_Alive;
  }
- C4Object::AssignDeath:
  // ensure objects that won't be affected by dead-plrview-decay are handled properly
  if (!pPlr || !(Category & C4D_Living) || !pPlr->FoWViewObjs.IsContained(this))
    SetPlrViewRange(0);
-  // Dead living don't burn
-  // Assume that the new container controls this object, if it cannot control itself (i.e.: Alive)
  // So it can be traced back who caused the damage, if a projectile hits its target
  if (!(Alive && (Category & C4D_Living)))
    Controller = pTarget->Controller;
- // Script context functions of target
  // No dead livings
- // Context functions of the menu clonk itself (if not same as target)
  // No dead livings
- // decay of dead viewtargets
- // Only hit if target is alive and projectile is an object

I've pushed to hg.openclonk.org. With that, I'm probably done with large-scale refactoring of the engine code for this release. Now it is time for bugfixes and game content.