mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-10 17:52:36 +00:00
a47835a04f
## About The Pull Request Turns the surface z-level of icebox into a 1x3 area, effectively adding 2 wilderness new z-levels surrounding the station Because it's not always clear to other people what I'm talking about, this is what I mean with making the surface level a 3x3 z-level The wilderness z-levels are gridlinked, instead of crosslinked, which just means the connections are consistent and not randomized. If you keep going right, you will always end up where you started again, eventually. This also removes the black border around the surface icebox z-level (cause you can just go there now) **Wilderness levels** I've added some Z-level templates that can be generated. They're incredibly basic, but all can spawn runes on them as well. - Snow planes (5x) - Ice planes (1x) - Forest planes (1x) - Mountain planes (1x) I've also tweaked surface generation quite a bit. It being completely covered in bones always felt weird, and the intersparsed rocks and chasms never sat right with me. The default overworldgen is now more like the Forested trait, but with more sparse trees. All of this is modular btw. You can increase the amount of z-levels, make any space z-level be unrandomized gridlinked or add your own wilderness z-levels (either to your own map or icebox) ## Why It's Good For The Game Icebox exploration is kind of depressing. We have this unique setting, but we can't really go anywhere? You can go down and find that one pool, which is about the peak of exploration of icebox. Now you can literally explore the entire round and get incredibly lost! It's also a great opportunity for mappers! (Especially since the templates I made were made rather quickly as I wasn't sure if this had merit). 2 extra z-levels isn't a lot, but it'll let us further develop planetary wilderness z-levels further without impacting load times that much. Maybe 3x3 icebox can be real in the future, but for now 1x3 icebox will have to do
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.