The DMM format allows several turfs to be added to the same location. DS loads the last one as the actual turf, and the rest are used to create underlays on that turf. I'm trying to take that turf, as loaded, and recreate the original DMM text. As far as I can tell, the information needed is unrecoverable.
If I could get the type path of the turf definition used to create the underlay, I could reconstitute the rest.
The only proper way I could think of doing this would be to put a type path variable on appearances, so you could find out what type of object the appearance is based on.
ID:2346000
 Feb 15 2018, 2:01 pm
|
|||||||
| |||||||
I agree completely.
I'm remaking my DMM reading / writing library; because this behavior is part of the DMM format, I want to be able to handle it. Even though my old DMM suite is unusable in any except the most basic cases, I frequently get questions about saving and loading maps from new developers who haven't yet learned not to stack turfs. Having heard these things for the last decade+ that the reading portion of the library has been around, I've concluded that a large portion of that target users will need this behavior. ---------------------- I've heard that SS13 uses its own tools to handle DMM files, and I'm curious about both what kind of tools you've developed, and the sorts of special cases they need to handle. If you have time to go into it, I'd love to hear about your experience. Do you have a tool for writing DMM files at runtime? Do you have a tool for loading DMM files? Are they (could they reasonably be edited to be) general purpose, or specific to SS13? I imagine you have to deal with a lot of cases where an /atom/movable needs be loaded with objects already in its contents. Was it a pain getting this to work, or am I wrong and you're doing this via a different method? Do you ever need to save icons into DMM files. If so, how'd you accomplish this? Were there any kinds of data that were particularly tricky to save or load? Lots of respect that you keep that code base going strong :) | |
Honestly you should just throw an exception if you encounter turf stacking and tell the developer to fix their shit.
| |
Do you have a tool for writing DMM files at runtime? Yes, but its not particularly well tested or supported. it was created once and used somewhat. Do you have a tool for loading DMM files? Yes, in fact most zlevels are not compiled in, we load them at runtime. Are they (could they reasonably be edited to be) general purpose, or specific to SS13? It uses ss13 frameworks, see below I imagine you have to deal with a lot of cases where an /atom/movable needs be loaded with objects already in its contents. Was it a pain getting this to work, or am I wrong and you're doing this via a different method? We handled this by moving all of our code away from New() and into Initialize(). During map load initialize is called only after everything is loaded in, other wise its called directly after New() Do you ever need to save icons into DMM files. If so, how'd you accomplish this? No. Were there any kinds of data that were particularly tricky to save or load? Not sure, I wasn't around when most the initial work was done with the map loader | |
MisterPerson wrote:
Honestly you should just throw an exception if you encounter turf stacking and tell the developer to fix their shit. If I were dealing with a professional programmer, yeah. One of the goals of BYOND was to teach programming to kids, and a lot of our new developers are kids who've never written code. The first page of the DM Guide, section 1.2, directs new users to go to the mapper and try it out. My experience has been that new devs use turf stacking heavily in their first projects. This will continue to be true so long as the editor, the guide, and the DMM format remain the way they are. If you want people to stick around, you've got to treat the newbies with kid gloves and a degree of hand-holding. | |
Basically I think what you'd need would be a way to get at the compiled map pops for each turf--currently that data is available, but not accessible to hard code.
However a harder part of your request would be converting the pop to text. Although the type path is easy, any modifications to vars would be harder, since those are compiled as init procs. Effectively you'd need a mini init proc disassembler built in. | |
What I'm looking for is a "close enough" solution that'll work for my library's users. Here's the use case I'm aiming for, what my library currently does, and how it currently fails:
1. The user creates a map with turf stacks, loads it (either via the library or by compiling it into the game), and saves it back to file. 2. The library saves turf underlays as a special type, /dmm_suite/underlay, with the necessary variables to reconstitute its appearance. 3. The user modifies their code, changing the original turf definitions to use different icons or states. 4. The underlays don't update. I understand that implementing yet another variable just for my use case isn't good for the design of the software as a whole, so any change will have to wait until you figure out a general solution. In the meantime, is there some esoteric aspect of DM that would do this, and I'm overlooking? | |
Cases where that's common use could either be moved so the higher turf layers are actually objs, or create map time helper objs that turn into turf overlays/underlays at runtime, since they could then save info on the turf with what types are over/underlayed