mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-30 03:22:41 +00:00
5d9488cd2a
## About The Pull Request Yello! This one is reasonably quick, tho I did some fixes too This is the big one, fixes the buildmode tool sometimes locking disabled for the whole round. We do this by replacing the static var on buildmode with global var and a global proc This keeps a harddel on the buildmode datum from permalocking is_running to TRUE Also makes flipping the var BACK if something breaks significantly easier for admins, so that's nice Alright, smaller things now Fixes lists of numbers failing to encoded improperly This was fixed on shiptest, we failed to actually port their most recent revision Fixes the shuttle flag not actually working because it used istype instead of ispath Changes obj_blacklist to a typecache for optimization's sake Renames/moves some vars around to prevent weird double typing things Removes a checktick in key gen, it's just costing more time then it would save in overtime Properly handles lists. We were only doing var encoding one layer deep, need to do it alll the way down Alright, now the optimizations This proc is fucking HOT, and it's for really dumb reasons This is a text gen proc, and it makes the mistake of generating text and concatinating it with MORE text. This is HORRIFICALLY EXPENSIVE because byond caches strings (can only be one of each) and string churn fucks up that caching system something fierce Moving from strings to lists of strings we join at the end takes us from like idk 100 seconds to save bare metastation to like 1.5 This is applied basically everywhere for obvious reasons While I'm here, storing keys in a flat list and then using find to find them, then using that index to lookup into another flat list is a bit silly. Let's just make it an assoc list. Faster lookup, cleaner. Oh also rather then iterating over all the vars on an object, let's iterate over just the ones we care about yeah? Let's see... no sense genning a key we'll never use, and having suffixes be often non existent is silly just embrace the slight mess. That's it I think, this takes us from 100 seconds to save metastation to 2.5 seconds to save ALL of metastation (I removed the vars limiter so I could make sure var saving didn't fuck me up) ## Why It's Good For The Game Cleans up some issues that we failed to port the fixes for, MASSIVELY optimizes this (so it can finish in like 5/10 seconds and not 300!) and ensures admins can always use the thing and don't risk dropping their pet buildastation to the void. Worth noting, this tool really should not be used for station mapping outside an event context. It produces sorta buggy var edits, and WILL fail to pull over context for shit. Please don't use it as such Profiles (csv files I promise) [Before](https://github.com/tgstation/tgstation/files/13853313/profiler.json) [After](https://github.com/tgstation/tgstation/files/13853271/profiler.json) I'd include my line by lines but I don't know how much you'd get out of them. Here's an image tho  ## Changelog 🆑 fix: The map saving tool will no longer lock up and prevent all further action at random fix: Map saving now takes on the order of seconds, not minutes fix: Fixes an issue with lists that caused strongdmm to report saved maps as broken /🆑
The code in this module originally evolved from dmm_suite and has since been specialized for SS13 and otherwise tweaked to fit /tg/station's needs. dmm_suite version 1.0 Released January 30th, 2011. NOTE: Map saving functionality removed defines the object /dmm_suite - Provides the proc load_map() - Loads the specified map file onto the specified z-level. - provides the proc write_map() - Returns a text string of the map in dmm format ready for output to a file. - provides the proc save_map() - Returns a .dmm file if map is saved - Returns FALSE if map fails to save The dmm_suite provides saving and loading of map files in BYOND's native DMM map format. It approximates the map saving and loading processes of the Dream Maker and Dream Seeker programs so as to allow editing, saving, and loading of maps at runtime. ------------------------ To save a map at runtime, create an instance of /dmm_suite, and then call write_map(), which accepts three arguments: - A turf representing one corner of a three dimensional grid (Required). - Another turf representing the other corner of the same grid (Required). - Any, or a combination, of several bit flags (Optional, see documentation). The order in which the turfs are supplied does not matter, the /dmm_writer will determine the grid containing both, in much the same way as DM's block() function. write_map() will then return a string representing the saved map in dmm format; this string can then be saved to a file, or used for any other purose. ------------------------ To load a map at runtime, create an instance of /dmm_suite, and then call load_map(), which accepts two arguments: - A .dmm file to load (Required). - A number representing the z-level on which to start loading the map (Optional). The /dmm_suite will load the map file starting on the specified z-level. If no z-level was specified, world.maxz will be increased so as to fit the map. Note that if you wish to load a map onto a z-level that already has objects on it, you will have to handle the removal of those objects. Otherwise the new map will simply load the new objects on top of the old ones. Also note that all type paths specified in the .dmm file must exist in the world's code, and that the /dmm_reader trusts that files to be loaded are in fact valid .dmm files. Errors in the .dmm format will cause runtime errors.