mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-14 03:32:00 +00:00
5e2d5210ae
* Abusing Generosity - Unrestricted Airlock Access Flip (#68096) * Abusing Generosity - Unrestricted Airlock Access Flip Hey there, We now have a lot of unrestricted access helpers on airlocks, which are neato. However, while spitballing ideas in regards to this a few months ago, someone suggested to make it such that you can use the airlock wires to "flip" the directional way. I decided to sit down and code it in today. The high details are this: You can only do it if the airlock has a directional Request-to-Exit sensor (which is just a thing I made up, you can't get this in-game outside of mapping it in via a directional helper). You can tell if a door has it the same way you can tell if any door is a directional door, or you can simply just check to see if the Unrestricted Access Display is "on" in any capcity (the airlock will not have the sensor if the display is off). It's effectively a dud without the "sensor". However, if it does have it, you can either pulse it (to switch the direction by 180 degrees) or cut the wire (to disable the direction entirely). When you mend the wire though, it'll activate to a random direction (could even be inside a wall). You can keep cutting and mending until you get what you want, though. If it gets stuck in a wall though... shouldn't have cut it. While in the area, I alphabetized a bunch of lists, added a new color of airlock wire, and probably some other stuff. * Adds this behavior to building new airlocks I also renamed it to "sensor" so it's a bit clearer across all the potential contexts. It does seem to handle setting multiple directions on creating a new mapload, cutting/pulsing will condense the nice multi-directional stuff into one direction (i am okay with this). Co-authored-by: spookydonut <github@ spooksoftware.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com> * Abusing Generosity - Unrestricted Airlock Access Flip Co-authored-by: san7890 <the@san7890.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
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.