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,
ID:2091233
May 29 2016, 7:50 am (Edited on May 29 2016, 8:21 am)
|
|||||||
| |||||||
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, |
May 29 2016, 9:52 am
|
|
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. 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. |
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.
|