ID:2573596
 
Resolved
Another cause of map "repops" misbehaving on maps with many such objects was discovered and corrected.
BYOND Version:513
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 76.0
Applies to:Dream Daemon
Status: Resolved (513.1525)

This issue has been resolved.
Descriptive Problem Summary:
At least one mapped in object's mapped-in variable values are not applied.
Probably related to: http://www.byond.com/forum/post/2548837

Versions Tested
  • 513.1520


Numbered Steps to Reproduce Problem:
1) Compile and Run the demo program.
2) The demo code will run on login.

Code Snippet (if applicable) to Reproduce Problem:
Demo Program: https://www.dropbox.com/s/l7n3iihrfuay6jp/ NewMePlease2.zip?dl=0

/atom
var/testvar = "compiled"

// Run the check on login for convenience.
/mob/Login()
. = ..()
src << "Starting Search"
for(var/obj/A in world)
if(A.testvar != "mapped")
src << "[A] ([A.type]) (REF=\ref[A] at [A.x],[A.y],[A.z] has testvar=[A.testvar]"
src << "Finished Search"

Map tiles look like:
"b" = (/obj/circle/green{testvar = "mapped"},/obj/circle/red{testvar = "mapped"},/obj/square/orange{testvar = "mapped"},/turf/standard,/area)


Expected Results:
All those objects should have testvar = "mapped"

Actual Results:
On my test map, one object still had testvar = "compiled" by the time /mob/Login() was run.
The green circle (/obj/circle/green) (REF=[0x2010000] at 50,19,3 has testvar=compiled
I cannot help but notice the object's ref of 0x2010000 strongly suggests it was the 65,536th object on the map.

The problem occurs:
  • Every single time, and it is always the same object.
  • I only ran the demo project on Windows, but bug was originally discovered from an SS13 server running on Linux, so I'd say both.


Yes, I copied and pasted this bug report from the previous one. I even left in the New() checking code in the demo as a regression test for you.
Lummox JR resolved issue with message:
Another cause of map "repops" misbehaving on maps with many such objects was discovered and corrected.