mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-12 02:32:10 +00:00
1aade91a18
This unit test detects all turfs & other movables that aren't in a lit area (ie area/space/nearspace) on station zlevels The grep detects movables placed on shuttles that do not have the correct area assigned, which caused those atoms to break off of the shuttle & literally get launched into random parts of space (usually on station z-levels; the only reason I found this issue was cause the unit test was detecting random shit ending up on station maps lol) Minor fix for the mapload_space_verification unit test - it was falsely detecting turfs that shuttle grids (that were template_noop) were parked ontop of, which aren't effected by the shuttle in any way. This allowed the following fix Fixed a number of shuttles having atoms in /area/template_noop areas. Atoms in these areas are treated as not actually part of the shuttle itself & were launched off into random space tiles across all z-levels via dump_in_space(). Corrected those grids to have the correct area, and as such, shuttles now stay together properly. 🆑 ShizCalev fix: Fixed a number of shuttles having parts (such as lattices) completely disappearing. fix: Fixed the ceilings above shuttles on station maps being full-bright. fix: Fixed lattices sometimes appearing at random locations in space on station maps. fix: Cleaned up a number of accidentally placed objects in space across all station maps. fix: Fixed a false positive with the mapload_space_verification unit test failing on turfs that weren't actually part of shuttles. code: Added a unit test that automatically finds all base space turfs with objects on them, as well as non-space turfs that are set to space areas (meaning that these squares weren't lit properly.) /🆑 Shuttle Ceiling Fix: Before  Fixed  Shuttle Fix: Before  Fixed (look at the lattices in the middle. the stuff in the shuttle are randomized / not part of this) 
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.