ID:2103619
 
BYOND Version:510
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 46.0
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: This is a somewhat situational issue that few are likely to encounter, but I might as well report it anyway just so that it is known. When one removes an existing atom type, recompiles, and then opens up a map file that formerly contained an atom of that type, Dream Maker allows you to choose if you would like to replace that type path with another one on the map, or if you would like to delete all references on the map file. This is normally an excellent way to deal with changing a type path. However... If there are a lot of type paths that need changing... Byond will get overloaded. It gets locked up doing only this task, and fails to respond to the operating system. Windows 7, being how it is, shuts down the program immediately. So if you have made a lot of edits to types there is very little you can do using DM to access the map file, since any attempt to open it will just trigger this crashing. Now, obviously a lot of reference changing is a big task, so it is unreasonable to expect that it does this without slowing the computer... But it probably shouldn't fail to respond to the operating system to the extent where everything crashes. A normal computer should be able to do this, given enough time. I suspect this could be fixed if the code that restored map references kept the program responding to the operating system while it did it's thing.

Numbered Steps to Reproduce Problem:
1. Compile something with a lot of types.
2. Scatter all those on a big map file.
3. Delete / change a significant number of these types.
4. Recompile.
5. Attempt to open the map file.

(A code snippet is not applicable, this is an issue with the DM interface)

Expected Results: The expected result is that DM replaces the references from the map file as instructed without crashing.

Actual Results: The actual result is that it fails to respond and windows kills the process.

Does the problem occur:
Every time? Or how often? In these specific circumstances, it has so far happened every time I try to open the file.
In other games? Any DM based game with enough types would probably trigger this, but I honestly have not tested it with any other code than a custom build of ss13.
In other user accounts? This issue functions independently from accounts.
On other computers? Not tested; I do not have another computer on hand at the moment with which to try. I would if I could though, this is probably worth checking out. I bet this isn't an issue on a faster computer.

When does the problem NOT occur? When there aren't very many references to change. I have used the reference changing interface on the map files before successfully, it just got completely overloaded this time.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? This problem is occurring on version 510, I download older versions and update this accordingly.

Workarounds:

One thing I tried that is not a functional workaround is just re-adding dummy types for the missing paths. I think the reason why this didn't work is because the map contains instances of each type with variables set to certain things, and these dummy types still lack those variables.

I think that each time it crashes it finishes a small fraction of the task before the process is killed. Maybe if this is repeated enough the problem is resolved.

Alternatively, going through the dmm file with a text editor and manually altering the references should work. The problem with this is... There is inherently a very large amount of references to change with this problem, so doing it manually would be problematic.

Probably the best workaround I can think of is just to write a python script to parse the dmm file and remove all these references according to the syntax of the file. I highly doubt a lightweight python program would crash reading through this. This is what I am probably going to do.
UPDATE: Okay so after a fair amount of debugging, it has been determined that the number of references has nothing to do with it. All but five references were removed from the map and it still was able to crash things.
This almost certainly relates to the variables assigned to particular map instances, not the number of instances.

So those five references could be deleted manually by opening the dmm file in a text editor. But eliminating all but that five to find this out was... Complicated. We used an older version of the code that was before the types had been changed, modified most of the map in this case, and then manually removed those last five.