ID:2049676
 
BYOND Version:509
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 44.0
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
After editing an existing map and saving it, there may exist duplicate models in the map file.

Numbered Steps to Reproduce Problem:
Edit map and save. Can't say how much editing is required or if it needs some specific editing.

Expected Results:
All models are unique.

Actual Results:
Existence of models that match existing models but with a different order.

Did the problem NOT occur in any earlier versions?
Hard to say when it started happening, but our maps have dozens of duplicate models in them which surely accumulated over time.
--

I was messing around and I noticed that one of our maps had a model that was the exact same as another existing model, just with a different order. Thinking it was a result of the old map merger tool we used at /tg/station, I wrote a script to detect and correct any existing duplicate models and fixed that map file.

On a hunch, I decided to edit that clean file with DM, save it and keep it in that format and have the script take a look at it. It detected one duplicate model.

The extent of my edit was randomly spraying an object around the map and then do the same with a turf type. The turf type was '/turf/simulated/floor/noslip' and that isn't normally mapped, so I know that the duplicate model was a result of this new edit and did not exist before that:

"ayg" = (/obj/machinery/atmospherics/pipe/simple/scrubbers/hidden{dir = 4},/obj/machinery/atmospherics/pipe/simple/supply/hidden,/ turf/simulated/floor/noslip,/area/crew_quarters/sleep)

"auN" = (/obj/machinery/atmospherics/pipe/simple/supply/hidden,/obj/ machinery/atmospherics/pipe/simple/scrubbers/hidden{dir = 4},/turf/simulated/floor/noslip,/area/crew_quarters/sleep)

As you can see it's the same model with a different order and this was written by Dream Maker itself. I assume models are supposed to be all unique, regardless of order?
After some more testing, I figured this happens because objects are placed with different orders and so it must be intended behavior.

I'd still appreciate a confirmation that it is intended.
it shouldn't be intended.

Depending on initialization order of the objects on the same map tile sounds like a recipe for failure.

and shortening the amount of tile definitions should always be a target.
It is intended. Movable atoms are layered in the order that they are placed in the tile, more or less.

Although, a nice compromise would be to sort movable atom order in the pop by compile-time plane/layer variables. This would help reduce identical but reordered pops.

Where the layer is the same, insertion order should dictate the pops.

That way the existing intended behavior is still possible, but optimization is also possible for objects using specified layers.
layers support floats, we generally try to use this on ss13 rather then map order.
FLOAT_LAYER really only applies to overlays and underlays. It doesn't apply in this case:

"ayg" = (/obj/machinery/atmospherics/pipe/simple/scrubbers/hidden{dir = 4},/obj/machinery/atmospherics/pipe/simple/supply/hidden,/ turf/simulated/floor/noslip,/area/crew_quarters/sleep)

"auN" = (/obj/machinery/atmospherics/pipe/simple/supply/hidden,/obj/ machinery/atmospherics/pipe/simple/scrubbers/hidden{dir = 4},/turf/simulated/floor/noslip,/area/crew_quarters/sleep)


That's because the prototypes in this case are on-map objects, not overlays.
i said float layers, not FLOAT_LAYER

as in floating point