"undefined map symbol" error on a seemingly correct map file

ID:2340796
 
Jan 27 2018, 8:23 am (Edited on Jan 27 2018, 5:33 pm)
BYOND Version:512.1405
Operating System:Windows 10 Enterprise 64-bit
Web Browser:Firefox 58.0
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
As a follow-up to (http://www.byond.com/forum/?post=2338657).
I am unable to compile the following project:
https://github.com/DamianX/vgstation13/archive/ e3b09768ab409c34b30b2850c1e55ac884eecd05.zip
The error is the following:

maps\tgstation.dmm:12900:error: undefined map symbol: "bBC"

However, bBC seems to be correctly defined:

"bBC" = (/obj/structure/table/reinforced,/obj/item/weapon/folder/white,/obj/item/weapon/pen,/obj/item/device/flashlight/lamp/green{on = 0; pixel_x = -3; pixel_y = 8},/turf/simulated/floor{dir = 1; icon_state = "whitegreen"},/area/medical/medbay)


Numbered Steps to Reproduce Problem:
- Open project in Dream Maker
- Build

Expected Results:
Successful compilation

Actual Results:
maps\tgstation.dmm:12900:error: undefined map symbol: "bBC"

Does the problem occur:
Every time? Or how often? Yes, every time.
In other games? Does not apply.
In other user accounts? Does not apply.
On other computers? Yes, tested both on Travis CI and my Windows machine.

When does the problem NOT occur?
Similar maps in the same project like 'test_tiny.dmm' compile correctly.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? The problem started with 512. 511 compiles and works correctly.

Workarounds:
I replaced every occurrence of "bBC" in the map's levels with "aaa" and deleted the "bBC" definition. This caused other errors of the same nature to show up:

maps\tgstation.dmm:12930:error: undefined map symbol: "cvu"

I kept repeating this process of search/replace/delete until the map compiled.
After this, the project compiles and everything seems to be working.
However, this is not an acceptable solution as I had to delete important parts of the map.

I have published a version of the project adopting this "workaround" here:
https://github.com/DamianX/vgstation13/archive/ 6560222ace90e7956ad6c7bb84f1a101e28f9777.zip
Jan 27 2018, 5:30 pm
I don't really play with the map much, but is there a space between 'lamp/' and 'green'?
Jan 27 2018, 5:32 pm
Nope, not sure how that got there. I will edit the OP.
Jan 27 2018, 8:41 pm
Huh. Now that's quite interesting. So the bug I fixed was only triggering because of another bug?
Jan 29 2018, 2:45 pm
One thing I'm seeing in your map file is that there are some bogus symbols included. The "highest" symbol allowed currently is "ymo" in the base-52 counting scheme it uses. You have 18 symbols beyond that number. 10 more are legal but appear to have been manually set.

"bBC" is 4136 numerically, which is "zNS" if you add 65536--which happens to be one of the bogus symbols in your map file.

A proper fix on my end here requires making some big changes to the parser, specifically that I should allow for broken symbols and handle them specially when they're added to the map. Right now the routine that reads the symbol name as a numerical number doesn't have a way to handle overflow, so what I would need to do is allow for such overflow and return a result anyway even when it's bogus, check to see if said result is bogus, and in that case assign the symbol a dummy number that may need to be replaced later--and then handle changing things around when another legit symbol is loaded into the slot it was assigned.

In other words, quite a few changes would have to go on there and a number of them would be, IMO, bug magnets. To be honest I'm not sure the effort is warranted when the fault lies entirely with whoever manually added bogus symbols to the map. This is something you should be able to fix quickly on your end by replacing the bogus symbols with reasonable ones.
Jan 29 2018, 4:09 pm
This is likely the fault of the map merging system almost every ss13 server uses to keep diffs low by keeping keys from getting changed around. We didn't know about this limitation and new keys just keep getting added to the end, reusing unused keys from earlier in the set wouldn't happen until it hit zzz or the number of keys became small enough to revert to 2 character keys.

I doubt this map actually has more than 65536 keys.

Jan 29 2018, 10:17 pm (Edited on Jan 29 2018, 10:47 pm)
Hmm, should have taken into consideration the possibility that things would stop near 65536 (ymo being 65534). I can fix this tools-side to prevent generating the bogus keys.
Jan 29 2018, 10:40 pm
In response to MrStonedOne
MrStonedOne wrote:
I doubt this map actually has more than 65536 keys.

No indeed; it has something like 20% of that.