mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-30 03:22:41 +00:00
a3849062b8
## About The Pull Request [Design doc](https://hackmd.io/@shadowh4nd/r1P7atPjn) Adds a new supply role centered on short dungeon-esque runs with a focus on unifying the job with the fun part. Some virtual domains are combat related, some are silly, some focus on "objectives". Avatar health is linked to your physical presence and retries are limited. <details> <summary>Photos, WIP</summary> Net pod stasis  Server loaded  Server cooldown  the quantum console UI  Cyber police antag page  A safehouse  Domain info page, every domain gets this (and sometimes help text)  Me getting steamrolled in one of the missions  Ghost roles getting notified that server is kicking them out  Players enjoying the new combat missions  Players exploring some of the virtual maps  (Not part of the PR, but)  New bitrunner vendor  </details> ## Why It's Good For The Game Content, firstly, and moreso being supply department content. The framework that this implements is a great (preauthorized) replacement for two systems which are collecting dust: BEPIS and the gateway. They integrate into this system and it's a direct upgrade. This adds a way for the players on station to generate materials (if that remains). The nice part about it is that I can throw balance and believability to the wind, as unlike its unrelated predecessor VR or away missions, bitrunning entirely washes its hands of the map and mobs each reboot. It offers a very expandable map framework to add content and it's all fairly well documented. I'd like to add a feature that represents the idea that jobs don't have to be mundane and "external" jobs can stay tied to the main gameplay loop. ## Changelog jlsnow301, kinneb, mmmiracles, ical92, spockye 🆑 add: Adds Bitrunning to supply department- a semi-offstation role that rewards teamwork. add: Adds new machines to complement the job- net pod, quantum server, quantum consoles, and the nexacache vendor. add: Adds several new maps which can be loaded and unloaded at will. add: Some flair for the new bitrunning vendor. add: Adds a new antagonist for the virtual domain only. Short lived ghost role that fights bitrunners. del: Removes the BEPIS machine, moves its tech into the Bitrunning vendor. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com> Co-authored-by: Ical <wolfsgamingtips@gmail.com> Co-authored-by: spockye <79304582+spockye@users.noreply.github.com> Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@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.