Most turf keys in associative lists will lose non-constant values if world.maxx or world.maxy are increased.
Numbered Steps to Reproduce Problem:
1. Obtain a reference to a turf located anywhere but the topmost row of the first z-level.
2. Create a list with that turf as a key for a non-constant value, like a datum or a list.
3. Increase world.maxx or world.maxy.
4. Check the list and see that the non-constant value is gone, but the key still exists.
Code Snippet (if applicable) to Reproduce Problem:
world{maxx=1;maxy=2;maxz=1};
/world/New()
var/turf/T = locate(1,2,1)
var/list/L = list((T) = (new /datum))
world.log << json_encode(L)
world.maxx++
world.maxy++
world.log << json_encode(L)
Expected Results:
Output should be:
{"turf":"/datum"}
{"turf":"/datum"}
Actual Results:
Output is:
{"turf":"/datum"}
{"turf":null}
Does the problem occur:
Every time? Or how often?
Whenever someone has a turf as a key for a non-constant value in a list, and resizes the world in a way that requires turfs to be added before it.
In other games?
If they do that, yes.
In other user accounts?
Yes.
On other computers?
Yes.
When does the problem NOT occur?
When the turf is on the first row of the first z-level.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Occurs in 514 and 515, likely occurred earlier as well.
Workarounds:
Don't make a list with turf keys and non-constant values, make sure the turf refs are on the first row of the first z-level, or don't change maxx and maxy.
I've been looking at the code for associative list trees, and because the key in the tree item isn't refcounted, the garbage collector can't just call the function it normally would to make the reference change. I'm gonna have to make some internal changes to the garbage collector to make this work.