ID:2330729
 
BYOND Version:511
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 57.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Compiling the project and attempting to run it in DD results in an error in DD:
BYOND Error: corrupt map data in world file
while encountering no errors at compiletime, but each map compiles and runs fine in different combinations, indicating there's no actual corruption in the DMM files.

Numbered Steps to Reproduce Problem:
1) Compile project
2) Attempt to start project in DD

Code Snippet (if applicable) to Reproduce Problem:
N/A

Expected Results:
Project runs normally

Actual Results:
DD refuses to run project with above-mentioned error

Does the problem occur:
Every time? Or how often? - Every time.
In other games? - No.
In other user accounts? - Yes.
On other computers? - Yes.

When does the problem NOT occur?
If I remove any of the maps in the project, it will start fine. It sounds very similar to the issue here: http://www.byond.com/forum/?post=2148278 where no actual root cause was ever discovered. Unfortunately I'll need to actually know the cause if I'm going to work around or fix the issue.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Occurs in 511 final, and two 512 betas I tested.

Workarounds:
See above. Removing any map (except the '10' map below) causes DD to load the project fine.

-----
My comments/thoughts:
I was initially under the impression that this was based on some kind of limit in either 'turf pop' count (as the other thread called them), aka the definitions at the top of DMM files, or simply in total turfs. However the maps are only 128x128 and there are only 13 of them, so it doesn't seem to meet the limit mentioned in the other thread for turfs.

So maybe total limit in 'turf pops', but none of the single maps are over the limit? The other thread didn't seem to specify what the backend 'total' sum limit of these would be. It would be helpful to know. The total number of pops for each DMM file are...

5705 + 10 + 5541 + 127 + 489 + 1536 + 1082 + 262 + 62 = 14,814


That's less than the 65k mentioned in the other thread for even a single map's limit. If it's relevant, the reason there's 13 maps and 9 totals is because the first and third DMM each have three z-levels internally using the Byond z-level thing.

I don't really think it's actual DMM file corruption since like I said, each DMM will compile and run fine, but just not all at the same time. I also tried removing a map with a very small turfpop count (the 10) and I still get the corrupt world data error, sort of indicating it does have something to do with that. Removing the 262 popcount one results in it working fine. So, 14,814 is too many, 14,552 is fine, if it's really that.
Out of frustration I'm narrowing it down.

The limit is between 14,787 and 14,802
The limit is within 5 pops of 14,787
The limit is 14,787, however the plot has thickened.

I performed all my testing in the final map with 62 pops, reducing it to 35 (lucky first guess, as that's 14,787), and trying various other numbers (50: fail, 40: fail, 36: fail, 35 again: works again).

I then left it at 35 pops on that map, for the sum total of 14,787, and created a new pop in another map by adding a random item and verifying the count increased (the 262 map increased to 263, for a total of 14,788). And THIS starts fine. I then created three more new pops, bringing it up to 14,791, and this ALSO starts fine. These four I added at the end are totally unique: no other map shares those turf item combinations.

Why would this happen, in that case? I had briefly assumed that the turf/item combos I had created were not unique and the problem was in the compiling backend when it merges the DMMs but that appears to not be the case since those 4 are totally unique.
For funzies, I copied every map into a single 13-level DMM. This also fails to start, but ends up with 14,804 pops. This appears to be far shy of the 65K per-dmm limit in the other thread.