Every atom shows every possible verb in the right-click menu. If the verb is not valid for that atom, clicking it fills the input bar with "VerbName atomname.0xffffffff".
Atoms which did not have verbs, including areas, now have all verbs. Atoms with mouse_opacity = 0 correctly do not appear. In SS13 a spurious unnamed atom on which no verbs are valid appears, probably an artifact of one of our systems.
Procs which have been added and then removed from client.verbs are not removed from this megalist.
This is the same repro case as the turf@0x100ffff bug, but it also illustrates this problem: https://wombat.platymuus.com/dl/minimal.zip
I have received confirmation that this is a Dream Seeker issue; the problem manifests with a 1428 client on a 1427 server.
Expected Results:
The right-click menu for an atom only shows verbs for which it is valid as src or the first argument.
In the test case, this means only the turfs show up in the right-click menu.
Actual Results:
Every verb shows for every atom.
In the test case, right-clicking the mob shows the mob, the turf, and the area in the right-click menu, each with both verbs, which should only be valid for turfs.
The output control prints, on clicking one of the verbs:
Sorry, the following is not valid: area.0xffffffff usage: CheckLocal turf
Does the problem occur:
Every time? Or how often? Yes.
In other games? Yes, appears in a minimal repro.
In other user accounts? Unknown.
On other computers? Unknown.
When does the problem NOT occur?
Presumably if there are no verbs at all.
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.)
The bug is new in 1428.
Workarounds:
None known.
I found a few places that escaped my earlier changes where I was changing a bunch of NONE instances to a new NO_DOTCOUNT value in the parser. Apparently that's what did it.
Pushing out a new release momentarily.