Using call(ref, path/to/proc/myProc) doesn't always call the latest override for path/to/proc/myProc.
Numbered Steps to Reproduce Problem:
1. Have a datum and proc you want to call()()
2. Override the proc within the same datum type
3. call(datum, yourProcPath)()
4. The latest override might not get called
Code Snippet (if applicable) to Reproduce Problem:
testDatum
proc
MyProc()
world << "called from MyProc"
testDatum
MyProc()
world << "called from MyProc override" // actually this one gets called
testDatum/MyProc()
world << "called from MyProc override 2" // doesn't get called
mob/verb/TestCall()
var/testDatum/D = new()
D.MyProc()
call(D, /testDatum/MyProc)()
Expected Results:
The latest override for the proc gets called. ("called from MyProc override 2" in the example)
Actual Results:
The first or one of the other overrides gets called ("called from MyProc override" in the example)
Does the problem occur:
Every time? Or how often? Yes
In other games? Yes
In other user accounts? Yes
On other computers? Yes
When does the problem NOT occur?
When calling by name or just calling directly as a member.
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.)
Doesn't happen in 514 because 515 brought new behavior to call()() with proc references.
Workarounds:
call(datum, "MyProc")() or call(datum, datum::MyProc():name)()// call by name
At present, /testDatum/proc/MyProc unambiguously refers to the original proc definition. /testDatum/MyProc refers to the first override found, and is not terribly useful.
Also—and this is the bad part—the current behavior means that when the 1st override is called, ..() will call the exact same proc again, with a subsequent ..() call calling the original. This is something that can potentially be fixed with an overhaul to how ..() operates, but that's a future plan and beyond the scope of this bug report. Calling the original proc via call() also does this, where ..() will call the next-to-last override and so on.
I found I can alter the node lookup behavior in the compiler so that /testDatum/proc/MyProc and /testDatum/MyProc both point to the last override. However, in a situation where there are no overrides at all, /testDatum/MyProc is considered an undefined type path, and that's insanely difficult to change. Additionally, it's unclear how altering the node lookup in this way impacts other behaviors in the code, so I'm not that thrilled with it.
Altering /testDatum/MyProc lookup alone would make some degree of sense, but it doesn't address the problem when call() looks up /testDatum/proc/MyProc and ..() gets called.
Ultimately, I believe the only solution here is for the :: operator to be used as in /testDatum::MyProc(), because it will produce the intended result. I'll edit the list of breaking changes to reflect this.