Have the Map-editor save items in the JSON in the same order they were created.

[Chrisdashezz]

The original poster is Desertshadow.

Placing objects in MapEditor appends to the end of the list. This causes chronological order (oldest on top -> newest on bottom) during a mapping session.

Saving in MapEditor stores that list in a JSON file, under data[]. But the order is scrambled/destroyed.

You can make a pseudo prefab, by selecting A, B, and C in the list with Shift + LMB during chronological order. But when A, B, and
C are spread out in random locations across 3000 objects, the pseudo prefab requires manually selecting each object in the world.

[Powback]

Fixed on branch live-ebx (commit 5c45106), leaving this open until it's confirmed on someone else's save.

Root cause was two compounding things, not just the pairs() walk:

1. table.sort in Lua is not stable. ProjectManager:SaveProjectCoroutine sorts the save array by timeStamp, so any objects sharing a stamp came out in an arbitrary — and differently arbitrary each run — order. That's the reshuffle.
2. Timestamps collide. They come from SharedUtils:GetTimeMS() at millisecond resolution, so bulk operations (Copy/Paste, Duplicate, a project load) stamp many objects identically.

Changes:

• GameObjectManager:NextTimeStamp() issues strictly increasing stamps (bump by one when the clock hasn't advanced), so new saves can't contain collisions.
• The save comparator is now a total order (tie-break on guid, or 0 guard for a missing stamp), so the result is deterministic even for existing saves that still contain collisions.
• CreateAndExecuteImitationCommands iterates with ipairs, not pairs — command order is the order the tree ends up showing.
• SAVE_VERSION 0.1.3 + RespaceDuplicateTimestamps: upgrading an older save freezes its current (timeStamp, guid) order into unique stamps once, so a collision-ridden file becomes permanently stable. No-op for files that are already clean.

Re the options discussed above: this is essentially option 1, but note the timestamp mechanism was already ~90% present on the Gameface branch (sorting, m_GUID_To_Timestamps persistence, and a migration path all existed) — it just couldn't work with colliding stamps and a non-stable sort. No schema change, no file-size increase, and m_GameObjects is untouched, so option 2's intermediate table wasn't needed.

Verified with a Lua unit test of the comparator (same set, shuffled input → identical output; re-spacing stays unique and order-preserving) and an end-to-end check that saves, reads the project row back out of mod.db, and asserts the persisted timestamps are unique and ascending. Honest limitation: I could not reproduce a natural same-millisecond collision in-game (the duplicate path round-trips through the server and spreads across ms), so the collision handling itself is covered by the unit test rather than the e2e.

[Powback]

discord discussion was also considered