mirror of
https://github.com/yogstation13/Yogstation.git
synced 2025-02-26 09:04:50 +00:00
ffdb861fb8
* Code to doors.dm for airlocks with unrestricted sides * Code to airlock_electronics.dm supporting airlocks with unrestricted sides * Code to door_assembly.dm supporting airlocks with unrestricted sides * Adding buttons to airlock electronic gui for unrestricted direction access * Update airlock_electronics.dm typos in comments are still typos * Tgui support for arbitrary unrestricted access * Cleaner way of calling unrestricted_sides() Moved the call to unrestricted_sides() to run from allowed(), and added a recursive check for if the user is inside an object (like a mech). * Missed a test variable * Replaced a block of if statements with get_dir Re: SpaceManiac * Simplified XOR operation Re: SpaceManiac * Changes order from NESW to NSEW (for get_dir) Re: SpaceManiac * Re-built using changes to airlock_electronics.ract * Added unres overlays, fixes overlay/power actions Small lights that shine out to indicate open directions. They're not super pretty, but they aren't *that* horrible I think. Because it's a light, it acts as a weak light source. Also, all door overlays respond to power changes now, including area power loss. There was code in the overlay section for checking power states, but nothing to actually trigger it outside players opening the panel or something. This was broken before I made any changes. * Makes overlays respond to power outages The airlock overlay (bolt lights, etc) would not respond to the area power going out or coming back, even though it had code for it. This was broken before I added my code. * Makes the Airlock update overlays when built Long story short, the unres_sides variable wasn't getting set before the airlock spawned and did its first overlay update, meaning the unres indicators would be invisible until the door's state changed the first time. This makes the airlock run the update again just before the construction airlock object is removed. * overlays.dmi -- removing to replace I can't just edit the code of an image file, can I? * new overlay file with the four unres indicators * Set medical doors to use this feature Removed medical door buttons, and set the unres variable on Meta, Box, Delta, Pubby, and Omega. * Revert "Set medical doors to use this feature" This reverts commit 53122ce63240ff0660226c8d2c6ed7eb814ec054. * Updates medi-doors in maps let's try this again... * Did this tgui.js get overwritten? juggling too many testing build folders is hard * reverting momentarily * Re-adding tgui.js changes * pushing tgui.css too Didn't realize this file also got changed by the script * rebuilt the tgui.js file * repushing the unchanged tgui.js again I hope I'm not email-spamming people with this * .css too * Re-applying tgui.js changes * added mapping helpers little green arrows that set unres settings on airlocks and then poof * removal of comments unneeded code * Adding helpers to all maps Removed the var edit, as well * Changed airlock.dm to use defines Also removed an unneeded "src" from four lines. * New .js and .css file to fix RPD issue Boy I love tgui * Removing define defines Didn't know these were coded elsewhere. Neat. * Mapmerged again, as requested * Clean up maps
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.