mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-02 21:11:57 +00:00
abc0820466
## About The Pull Request This standardizes fugitive hunter IDs, making all hunter packs use the same subtype and giving them to hunters who would spawn with no ID at all. The badass flaming ID color that the OG Bounty Hunter team got are now the standard for fugitive hunter IDs. Additionally, these IDs now come with a radical skull trim. (Spacepol Officers don't get the badass flaming skull ID, and instead get a more modest Police Officer ID). **These IDs come with access, too. Airlocks, bolt buttons, shuttle controls, and shutters on all of the hunter shuttles now require a hunter's ID to operate.** While I was in the area doing mapping stuff to get the accesses in place, I made a few other very minor changes to the shuttles. These include: - The Bounty Hunter shuttle now has an oxygen dispenser. Two walls have been moved to make space. - The Russian Hunter shuttle now gets enough oxygen tanks to share with everyone. - The Psyker Hunter spawners now have proper spawner menu text. This was due to duplicate-but-not-really subtypes existing, and me mistakenly putting the wrong ones there in a previous PR. - The cut ai wire helpers from the Russian/Psyker shuttles have been extended to the Bounty/Spacepol shuttles. - Every hunter shuttle now has a shuttle pinpointer on it somewhere, and is no longer exclusive to a single Bounty Hunter's loadout. ## Why It's Good For The Game Some of the hunter IDs would spawn without trims or coloration, and some hunters wouldn't spawn with IDs at all. Now, everyone gets a credible, cool-looking ID that lets everyone know what you're here to do at a glance. One of these is a crazed larper with an unregistered firearm, the other is a certified bounty hunter. As for the hunter access, it's pretty nonsensical that anyone can just walk into the hunter ship and set up shop. At least the pirates get turrets! Not to mention, it's hard to balance or give hunters new equipment in good conscience when their entire domain is public-access and anything they can't carry is considered forfeit to the crew. Now it can be used as a base of operations, storage area, etc. more securely. Locking down the shuttle with accesses isn't going to stop a determined gamer with a toolset, but it'll at least make it more interesting and an actual risk. If the fugitives want to try and loot/hijack the shuttle, it will require the effort of taking down one of their hunters first. While hunters stand out for the differences/imbalances between each group, I don't see the shuttle pinpointer as something that contributes positively to the OG bounty hunter's uniqueness. There's no reason why the other hunters shouldn't also be able to track their ship.
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.