This behavior actually is an editor feature: the editor moves all multi-part objects on top of single-part objects. (Not doing so when inserting it at edit time but only at map loading/undo/redo time probably is a bug, though.)
The reason for this behavior probably was: at some past time the only multi-part objects probably were monsters. The server moves monsters on top of other objects when the monster moves. I think the editor moves multi-part objects to top to simulate this behavior.
Today this assumption is not true anymore since many multi-part objects are immobile/non-monsters. Therefore this behavior probably is not correct anymore.
To fix this issue:
In map files only the head parts of multi-part objects are saved. Therefore the z-order of tail parts cannot be specified in map files (or by the editor).
I did some quick tests with a current server to find out how it (re-)orders multi-part objects:
- It seems that the server puts (automatically generated) tail-parts *below* all existing objects when loading a map.
- For some reason the server seems to reorder objects; this is somehow based on the "no_pick" flag.
See the attached map "xxx": the left chocolate on the bottom left table should be *below* the table according to the map file but the server displays it *on top* of the table.
The top left table uses the same objects and the same ordering in the map file, except that the chocolate has "no_pick 1" set. This time the server displays the chocolate correctly below the table.
That said:
a) What is the correct behavior when loading multi-part objects from a map file? I.e., is the server correct in that it inserts the tail parts *below* all existing objects? And is this always the case, or depends it on some object attributes?
b) Why does the no_pick attribute matter for z-ordering? How should the editor behave?
c) Are there more attributes and/or rules that matter for z-ordering?
File Added: xxx
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=707817
Originator: NO
This behavior actually is an editor feature: the editor moves all multi-part objects on top of single-part objects. (Not doing so when inserting it at edit time but only at map loading/undo/redo time probably is a bug, though.)
The reason for this behavior probably was: at some past time the only multi-part objects probably were monsters. The server moves monsters on top of other objects when the monster moves. I think the editor moves multi-part objects to top to simulate this behavior.
Today this assumption is not true anymore since many multi-part objects are immobile/non-monsters. Therefore this behavior probably is not correct anymore.
To fix this issue:
In map files only the head parts of multi-part objects are saved. Therefore the z-order of tail parts cannot be specified in map files (or by the editor).
I did some quick tests with a current server to find out how it (re-)orders multi-part objects:
- It seems that the server puts (automatically generated) tail-parts *below* all existing objects when loading a map.
- For some reason the server seems to reorder objects; this is somehow based on the "no_pick" flag.
See the attached map "xxx": the left chocolate on the bottom left table should be *below* the table according to the map file but the server displays it *on top* of the table.
The top left table uses the same objects and the same ordering in the map file, except that the chocolate has "no_pick 1" set. This time the server displays the chocolate correctly below the table.
That said:
a) What is the correct behavior when loading multi-part objects from a map file? I.e., is the server correct in that it inserts the tail parts *below* all existing objects? And is this always the case, or depends it on some object attributes?
b) Why does the no_pick attribute matter for z-ordering? How should the editor behave?
c) Are there more attributes and/or rules that matter for z-ordering?
File Added: xxx
Crossfire map file to demonstrate z-order issues.
Partly fixed in r8935. Now Gridarta does not anymore move multi-square objects to top when loading map files.