I've been wrestling with this bug (or some permutation of it) since yesterday. NEStalgia has a Bestiary system that stores information about all of the monsters a player has encountered, and up until now it has done so using a single painfully inefficient list of mob types and associated values. In trying to convert the old bestiary list over to a new system I encountered the problem with messed up sound(null) calls that instead call mob/New().

The good news is that I was able to work up a very simple demo that reproduces the bug. It's fairly self-explanatory, but let me know if you have any questions: http://silkgames.com/random/sound_bug_demo.zip
HOLY SHIT
A reproducible demo for this bug is huge, looking forward to seeing results!
so here's the fun bit. creating a sound before the all of this will prevent the bug.


world/New()
var/sound/S = sound()
if (!istype(S))
world.log << "HOLY JESUS! WHAT IS THAT? WHAT THE FUCK IS THAT?"


Add that to world/New() in the project silk games gave, and the issue stops.
In response to Silk Games
That's fantastic news. I'm on the case!
Lummox JR resolved issue with message:
Using text-to-type lookups for /mob types caused subsequent lookups, often on unrelated types (/sound being a common one), to fail in bizarre ways.
Wow. This bug has been around forever. I know I never touched this part of the code except to do some type correction. What a curious thing to find on the tail end of my BYONDiversary.

The problem lay in TextToType(), which keeps an associative list to handle repeated lookups--and this is why calling sound() before loading the savefile fixed it. If the associative list doesn't have a hit, the routine looks at all prototypes whose type string has a matching ID to the one being looked up.

When looking up a mob prototype, some additional logic was done to find the right one. There's some weird internal distinction between protomobs and other prototypes; protomobs have a separate regular prototype, so once the right prototype is found, then the protomob that goes with it has to be looked up. The loop that did this was reusing the very same argument var that was used for the string ID of the type path. Then when the proper protomob was determined, it went to add the value to the associative list--but the string ID had been mangled, and was now actually set to the protomob ID.

This also explains why only complex games end up having this issue; they're the ones that have a large number of protomobs, and you have to get to a decent number of them to start conflicting with regular type paths like /sound.
This is great!
I mean, I really don't have words for how good this is, so I guess the above (+this) will have to do.
Good lord, great find Silk! Oh, and I suppose Lummox did a thing worthy of notice. ;P
Great work everyone
Page: 1 2