ID:2091233
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Basically taking an existing, mapless DMB and running it with a set of DMM files, specified at server startup time.

We're using a bunch of clobbered together code that piles a new set of map files into a DMB at Goonstation to cut compile times down (takes a second to insert a new map vs a 3-5 minute recompile). It'd be really nice to have this as official functionality since our tool is kinda screwy (doesn't clone varedited turf types, the DMM parser is super shoddy, it doesn't work with 510 DMBs yet, etc).
This would be super neat, not just for Goon but for any SS13 codebase that currently runs or intends to switch to running a multi-map setup. Bay is potentially in the second set of servers there, we have a swappable-maps-on-compilation system already but we don't run it on the live server (yet!)
See, i just compile the new dmb when i need it, mostly during the shuttle ride back to centcom.

Then i don't have to care about compile times. =P
In response to MrStonedOne
MrStonedOne wrote:
See, i just compile the new dmb when i need it, mostly during the shuttle ride back to centcom.

Then i don't have to care about compile times. =P

It's pretty convenient when mapping though, or if you simply have 4 different maps and want your CI system to test them all without grinding the server to a halt.
Giving this a friendly bump, any chance we could get this in 512?
This seems like a really useful feature, I wasn't aware that a lot of SS13 servers recompile to do map swaps.
Personally, I'd rather figure out a good native map saving/loading scheme that would include a .dmm parser as a side thing. (.dmm isn't a viable save format because there are some situations it can't handle.)

Tom always wanted a native way to save and load maps; it just never really came together.
Oh man, a native DMM or really any native loader to mass load/save turfs, objects and other things from a file format would be really neat.

as all the current 'in-code' ones are quite ever so slow and filled with edge cases.
Much of the slowness may be unavoidable, except that I think a native save/load could save appearances as a batch and simply refer to them by number, thus handling most of the cases.

Of course any New/init procs called by a turf will obviously be a factor in any map load, so those should always be eliminated if possible.
If you DO make it loadable from some other format, PLEASE make sure there's a proc that gets called for import and export (like Python's pickle's __getstate__ and __setstate__) so we can sanely store custom datums and such, and to remove redundant data.
In response to PJB3005
I'm not familiar with those functions, so can you elaborate on what you mean?
In response to Lummox JR
Similar to how /datum/Read and /datum/Write work for datums in savefiles, essentially the ability to override the save/load procedures if needed.