mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-31 03:52:31 +00:00
4a274a6e4b
* Makes condiments their own subtype, fixes geese, prepares for merging * Fixes geese checking drink type instead of edible foodtype to eat gross food. * Renames foodtype var on drinks to drink_types to prevent above from happening again because it KEEPS HAPPENING. DRINKS AREN'T FOOD! * Makes Condiments their own subtype of reagent_containers because they don't make any use of being a subtype of food, at all. * Starts moving things from food to /food/drink subtype in preparation for merging /food/drink with /drink * fully removes Food subtype * /reagent_containers/drinks are now /reagent_containers/cup - This is so it's no longer confused with eachother. * /food/drinks is now /reagent_containers/cup/drinks, so we can keep their special abilities. * Fixes a LOT of errors with food, which are STILL checking the reagent_containers, despite ACTUAL food being refactored away from it a long time ago. This doesn't compile yet, but I do want to make sure my progress is well tracked. * remove copypaste code, changes soda cans * Removes most copy paste code between the two drinks, moving most stuff to parent whenever needed. * Made soda cans their own subtype since they didn't share anything with glass bottles anyways. * Fixes more problems with food/drinks, especially with geese. Geese really were just broken this whole time and no one said a word... * Removes a snowflake signal, now that both drink types share a common one. * Adds everything to the .dme Currently my goal is to get this all compiling, then remove isGlass var by making glass be all glass ones only. * Moves all icons into a single drinks dmi I'm not that great at icon stuff, hopefully I didn't forget/break anything. * Turns juices into their own subtype This allows us to let them check for type in molotov, to both get rid of a use of isGlass, and so non-glass non-cartons don't show up as 'carton'. * fixes compile issues, adds updatepaths * a better updatepaths * updates the damn maps now * properly names the updatepath * how did that get there * i suck at handling merge conflicts * how am i this bad * code improvement and soda fix * more fixes * Don't be a timer Ports from old food bottles to trans the reagents, rather than add a timer to. * Merge conflicts and fixes bottle smashing * Bottle smashing is now consistently functional regardless of how much liquid they have in them, when before it would spill first, then smash on the second hit. * runs updatepaths again
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.