mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-30 03:22:41 +00:00
About The Pull Request Hello once more! As we near summer, I continued to reminisce on several PRs done throughout last year! One of them was the controversial, but rather positive Tilening V1, as done by me and Twaticus a while back (#58932), and felt I could've done a better job with how it was presented. And thus, thanks to @Fikou encouraging me with a very interesting find of a previous tile resprite attempt, I've successfully done it! Ladies and Gentlemen, I present to you all, Tilening Version Two! image Now this isn't your run of the mill tile resprite. While I did improve the appearance of several tiles I haven't touched last time (including the showroom/freezer tiles now), I decided to do something special that most mappers shall appreciate! Don't you hate it when of all damaged states, there's only ones for grey tiles when we have white, black, terracotta and a bunch of other materials? Don't you wish they were overlays instead? Well golly gee do I have good news for you! image image After painstakingly spending at least several hours trying to learn enough code to pull it off, I have successfully made it so most tiles display transparent versions of damage overlays over them! This means mappers can express their creativity that much better! And thanks to how the code is written, its super easy to snowflake certain tile types to make them use unique damaged states (looking at you wooden tiles), so fret not in that aspect. Credits to: @WJohn For actually making those damaged overlays! Wouldn't've done the PR if it wasn't for you. @dragomagol, @RigglePrime and @LemonInTheDark for helping me out in a VC at 10 PM to 12 AM troubleshooting the code to make this improvement work! Why It's Good For The Game The shading is done better as compared to last time, making them feel more cubical and less like a pancake when seen from above! This PR also makes it so that we never ever have to touch damaged tiles ever again potentially, saving up some RSC regarding icons. However, due to how damaged tiles are currently mapped in, rather than overlayed as I envision in the future, it'll require a PR by San to be merged later that should make it safe to remove these icons. Changelog cl PositiveEntropy, WJohnston, Dragomagol, LemonInTheDark, Riggle imageadd: Resprites most variety of tiles into a better shaded version! code: Damaged floors are now damaged overlays, meaning that most tiles should properly display a damaged state! /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.