mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-07 15:32:47 +00:00
71b45e54ad
## About The Pull Request Fixes #76349 I didn't know that people needed to add any new traits to a global list so they can be easily read in View Variables, and was pretty shocked to find out many other people didn't know it was a thing. Let's make it a thing by testing it using a new CI Python Linter to check this. But oh no-  There were about 200+ missing traits. Alright, so let's do the following: * Move trait defines to their own dedicated folder in the `_DEFINES` folder. * Split up the traits mega-file into different files, for better organization. One for the macros, one for the sources, and a few for the "trait declarations" * Run the linter a load of times and add everything to the globalvars file, removing anything that's no longer used and figuring out where the best categorization of it is. also minor code improvements. also rename all of the ones that look weird. also fix list indentations * Also alphabetize the lists because it's easy * Move everything to a new `traits_by_type` list, while keeping the admin one the way it is for the time being while we figure out a better way to show that list to admins. * Profit ## Why It's Good For The Game Mapping trait injectors will now work for any type of trait. You shouldn't add any trait via this injector though, but you're no longer limited to coders remembering to add it to that critical list you needed. Lays the framework for a better view variables experience. This work is too lengthy to presently do, but hopefully we can get this done sooner rather than later. we will need a code-accessible way to view these traits for such a framework to be implemented, so let's just do that. Future steps are to break down the mega-declarations file into a folder full of separate files by typepath, but that requires a lot of auditing. Does need to happen one day though, there's a lot of mob traits mingled with datum traits and auuugh we gotta do this later this PR is already massive. there's probably ways to game this but this catches _my_ mistakes so good luck to everyone else (it should work for 99% of everyone) ## Changelog Nothing applicable to players. However, to mappers, the mapping trait injector should always be able to add any kind of trait (which is rather good for the times when you need it).
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.