mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-31 03:52:31 +00:00
0e904f7032
About The Pull Request Alternative to #65354 Ok so like, there was a lot of not floor types on /floor. They didn't actually want any of their parent type's functionality, except maybe reacting to breaking (which was easy to move down) and some other minor stuff. Part of what we don't want them to have is "plateable" logic. I should not be able to put floor tiles on the snow and be fine. It's dumb. Instead, I've moved all non floor types down to a new type, called /misc. It holds very little logic. Mostly allowing pipes and wires and preventing blob stuff. It also supports lattice based construction, which is one of the major changes here. I think it makes more sense, and it fixes an assumption in shuttle code that assumed you couldn't place "a new tile" by just hitting some snow with a floor tile. Oh and lattices don't smooth with asteroid tiles anymore, this looks nicer I think. Moving on to commits, and minor changes Changes clf3 to try and burn any turfs it's exposed to, instead of just floors Moves break_tile down to the turf definition, alongside burn_tile If you're in basic buildmode and click on anything that's not handled in a targeted way, you just build plating FUNCTION CHANGE: you can't use cult pylons to convert misc tiles over anymore Generalizes building floors on top of something into two helper procs on /turf/open, reducing copypasta Adds a new turf flag, IS_SOLID, that describes if a turf is tangible or not. Uses this alongside a carpet and open check to replace plating and floor checks in carpet code. This does mean that non iron tiles can be carpeted, but I think that's fine Moves the /floor update_icon -> update_visuals call to /open This change is horrificly old, dating back to8e112f6but that commit describes nothing about why it was done. Choosing to believe it was a newfriend mistake. Uncomfortable nuking it though, because of just how old it is. Moving down instead Create a buildable "misc" type off open, moves /dirt onto it Basically, we want a type we can use to make something support construction, since that can be a messy bit of logic. Also enough structure to set things up sanely. I'm planning on moving most misc turfs onto it, if only because constructing on a dirt tile with rods should be possible, and the same applies to most things Murders captain planet, disentangles /turf/open/floor/grass/snow/basalt Adds a diggable component that applies the behavior of "digging" something out from a turf. Uses it to free the above pain typepath into something a bit more sensible The typepaths that aren't actually used by floor tiles are moved onto /misc The others are given names that better describe them, and kept in fancy_floor Oh and snowshoes don't work on basalt anymore, sorry Snowed over platings now actually have broken/burned icon states, fixing black holes to nowhere Misc turfs no longer smooth as floors, so lattices will ignore them Placing a lattice will no longer scrape the tile it's on Ok this is a really old one. I believe this logic is a holdover from kor's baseturf pr (97990c9) It used to be that turfs didn't have a concept of "beneath" and instead just decided what should be under them by induction. This logic of "if it's being latticed scapeaway to space" made sense then, but has since been somewhat distorted We do want to scape away on lattice spawn sometimes, mostly when we're being destroyed, but not always. We especially don't want to scape away if someone is just placing a rod, that's dumb. Adds a path updating script for this change I've done my best to find all the errors this repathing will pull out, but I may have missed some. I'm sorry. Why It's Good For The Game Very old code made better, more consistent turfs for lavaland and icebox, better visuals, minor fix to snowed plating, demon banishment in lattice placement, fixes the icebox mining shuttle not being repairable Changelog cl add: Rather then being tileable with just floor tiles, lavaland turfs, asteroid and snow (among other things) now support lattice -> floor tile construction fix: Because of the above, you can now properly fix the icebox mining shuttle refactor: Non floor turfs are no longer typed as floor. This may break things, please yell at me if it does /cl
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.