Handling of unique is special. If the entire map is marked as unique - pretty simple, the entire map gets saved out. If the floor is marked as unique (FLAG_UNIQUE and FLAG_IS_FLOOR), then the floor and all objects above it are saved on the unique map. If just an object is marked as unique, then only that object is saved out. This is sort of necessary - otherwise, if a player had a unique object (say old apartment key), you don't want them dropping it someplace and now making that entier space unique. So the correct approach here is to make the floor space unique, and not the table, because that doesn't work. The reason the stacking 'changed' is the way the loading/saving happens. When unique objects are saved, they get saved to a different file. So when it comes to load the map, it loads all the original objects either from the temp map or original map. It then loads up the objects marked as unique. For floors, it does some extra processing and remove the old (original) objects on that space before loading the new ones. But for objects that are only marked as 'unique', those get loaded last and put on top of the other objects on the space. There only real possible fix to this is to add some information during save, like 'stacking order'. So when a space is saved it, it would number the stacking order 0, 1, 2, 3, ... When it goes to load them, it may load objects from the original maps at level 0, 1, 3. It then loads the object from the unique map, sees it order is 2, and inserts in the right place. However, thi is a lot of work for not a lot of gain - there aren't tons of unique objects in the game, and having them go to the top probably isn't that big a deal - when you drop objects, due to merging, the stacking order can change there anyways. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel