ID:2378173

Resolved
 The vis_contents and vis_locs lists were null for the turf with ref 0x100FFFF. This turf also did not act correctly with the parser or several parts of the interface, going way back; those issues have also been corrected.
 BYOND Version: 512.1427 Operating System: Windows 7 Ultimate 64-bit Web Browser: Firefox 60.0 Applies to: Dream Daemon
 Status: Resolved (512.1428) This issue has been resolved.
Descriptive Problem Summary:

The 65,535th turf, that is the turf with ref "[0x100ffff]", has null vis_contents. This was discovered with turf (1, 3, 2) in a 255x255x3 world, but manifests on any other map size which has more than 65,535 turfs.

Other bugginess manifests on this turf, such as some right-click verbs but not others not triggering when activated in the context menu, but null vis_contents is the most obvious.

Attempting to manipulate the vis_contents of this turf in any way throws a "special list may not be cut" runtime.

Note that "[0x101ffff]" is NOT bugged. Only this exact turf is bugged.

Working verbs:
/client/proc/callproc_datum(datum/A as null|area|mob|obj|turf)
/mob/verb/examinate(atom/A as mob|obj|turf in view())
/mob/verb/pointed(atom/A as mob|obj|turf in view())

Broken verbs:
/client/proc/jumptoturf(turf/T in world)
/client/proc/debug_variables(datum/D in world)

Probably "in world" is the problem.

Code Snippet (if applicable) to Reproduce Problem:
/world    maxx = 255    maxy = 255    maxz = 3/client/New()    ..()    var/turf/T = locate("$0x100ffff$")    src << "\ref[T] ([T.x],[T.y],[T.z]) bugged=[isnull(T.vis_contents)]"


Expected Results:
[0x100ffff] (1, 3, 2) bugged=0

Actual Results:
[0x100ffff] (1, 3, 2) bugged=1

Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes, exhibited in a test project.
In other user accounts? Unknown.
On other computers? Unknown.

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.)

Not tested in any earlier versions, but the nature of the bug makes me suspect it is very old. I'm counting this as a beta bug because the test case requires beta.

Workarounds:
None known.

 <-> Jun 21 2018, 7:34 am To be clear: further turfs after this one seemingly work fine, is it only the 65,535th turf that is bugged.
 <-> Jun 21 2018, 8:38 am This is likely to be an easy fix if I can isolate where the NONE check is being made. (0xFFFF = NONE and that's considered sacred by most types except turfs and their derivatives. When BYOND updated from 2-byte limits to 4-byte, NONE had to stay, but turfs aren't supposed to use it at all.) Can you shoot me a demo project?
 <-> Jun 21 2018, 8:44 am Actually forget the demo project. I think I found it. Ref2Value() does a type check and ignores NONE for certain types, or otherwise converts to null. REF_LIST_TURF_VISCONTENTS and REF_LIST_TURF_VISLOCS were never added to the list.  No wait, please do get me a demo, because I want to fix the other issues like right clicks and that will be a lot easier to track down with a demo.
 <-> Jun 21 2018, 1:19 pm Here's a demo project: https://wombat.platymuus.com/dl/demo.zip On spawn the mob is moved to the bugged turf and a message is printed. The CheckLocal verb is usable on any turf but targets the mob's loc by default. It is usable on the bugged turf in the right-click menu. The CheckWorld verb is also usable on any turf but targets (1,1,1) by default. It is NOT usable on the bugged turf. Clicking it in the right-click menu does nothing.
 <-> Jun 21 2018, 1:53 pm That link is broken.
 <-> Jun 21 2018, 2:05 pm Sorry, should have copy-pasted instead of failing to type from memory: https://wombat.platymuus.com/dl/minimal.zip
 <-> Jun 22 2018, 10:08 am Lummox JR resolved issue with message: The vis_contents and vis_locs lists were null for the turf with ref 0x100FFFF. This turf also did not act correctly with the parser or several parts of the interface, going way back; those issues have also been corrected.