ID:34372
 
Keywords: dmbformat, java, mapsub, ss13
MapSub is a program I wrote to allow editing of maps for Space Station 13. We're in a slightly odd situation with SS13; a perfectly good set of map maker files are available, but the author has moved on to a new project and is no longer interested in compiling maps for the game.

MapSub works by, in effect, converting a Dream Maker DMP file into the same format as a compiled map, then inserting that data into the original SS13 DMB file. It's a fairly complex task, involving rewriting a large portion of the DMB's data structures, but it seems to work OK, and now anyone, with a bit of effort, can create or modify a map for SS13. I hope to see some creative layouts soon.

One particular difficulty is instances; that's what you get when you add an atom to the map, and then change its variables. For example, SS13 has a security camera object, /obj/machinery/camera, by which players can view remote parts of the station. Adding an atom to the map is pretty easy, you just need to know its index number (atom number 32, in this case), but complications arise because each camera needs two variables set: its direction, dir, and a unique name tag for the camera, called c_tag.

If you open up a DMP file in a text editor, you'll see the values of the instance variables after each atom name in braces, for example:
/obj/machinery/camera{dir = 4; c_tag = "Northern Airlock" }
You'll see this format for any atom in the map which doesn't use the default variable values.

The difficulty arises because each of these instance initializations is turned, by the DM compiler, into a tiny, unnamed procedure in the final DMB file. The procedures are executed as the map loads, and set the atoms variables to their desired values. What this means is, if I want to be able to add new instances to a map (and MapSub would be much less useful if it couldn't), then the program must create an initialization procedure for each new instance.

In effect, that means compiling and inserting new DM bytecode into the DMB file; a fairly scary idea, particularly if you're working only with information you've reverse-engineered from the format. Fortunately, setting a variable is one of the simplest procedures: a push of the value (integer, float, or string index) on to the stack, then a pop of that value into the variable. (I'll have a lot more to say about how I think the DM bytecode works in a future post.)

So, MapSub must interpret the DMP format, convert the data into the same format used internally in the DMB file, identify each new instance and build the bytecode to initialize it, then insert that code into the DMB and make sure its referenced correctly. Not to mention decode the string table, append any new strings used, and then re-encode it. Frankly, I'm half-amazed that it works at all, but so far there seems to be no major bugs.

MapSub is written in Java, which has good and bad points. One constant problem is its lack of unsigned data types, a terrible pain when working with file formats (such as DMB) that use unsigned values. There are workarounds, but it's easy to miss a case, and I suspect MapSub will start throwing up bugs if anyone ever starts using, say, more that 32767 different objects. The other disadvantage is the need to download the Java Runtime Environment to run the program. A pity, but on the other hand, half the Windows programs nowadays seem to need some variant of the .NET framework, and it's a chore you only need to do once.

One big benefit of Java is its excellent Collections framework; things like extensible lists, associative maps, and so on. MapSub makes extensive use of these for all the data re-jigging it needs to do. C++ has the STL, which can do all the same stuff, but I find Java's versions rather easier to use.
Decompilers, resource extractors, binary splicers.. when will the madness end?

Very impressive work. I'm looking forward to seeing this evolve.
That is impressive. =O

Anyone else notice that all these programs have been written to be used on Space Station 13?

Slurm wrote his Decompiler for SS13 to fix a couple of bugs. And Hobnob wrote this to make use of custom maps.

Is the game really that impressive? >.>
I'm assuming that, minus all the bugs and the fact that the person who made it has quit working on it, it is.
I'm impressed, especially after reading the code behind it.

Nice work!
Since I couldn't find any other way to contact you, I'll leave a comment here:

Can you use the "decompiler" you created on my old game Stick World (http://games.byond.com/hub/Zaole/StickWorld) and send me the messy code?

I lost the code a long time ago and I'd really appreciate if you could do this for me.

You can email me at netsniffer @ yahoo.com
When I run I get a blank screen. Help?
When I try to run the screen never shows up. I give it permission to get the motd, the admins, etc, and it freezes.
Assuming you're seeing no errors during the compile process, make sure all the required areas mentioned in the map maker files' "areas.dm" are placed properly. Especially /area/start. Those are referenced internally in the SS13 code, and could cause a crash/freeze if they aren't present.
Dear Hobnob. Where can I get the host files for your updated SS13? I love the things you've done, such as restoring connectors, adding a chapel w/ space burial, meteors that damage floors and such. I run a RP-enforced server, and would love to be able to get my hands on the host flies for your version. It's quite nice. Thanks!

MSN: [email protected]
It looks like the time has come for me to slip out of the community's updates.

I'm not going to go that easily, though!

Eee hee hee!