ID:2036060
 
BYOND Version:510.1325
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 44.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: When a proc and a verb of different types share the same name, using the . or : operators to access those procs/verbs tends to fail in some cases, apparently favoring the verb definition.

Numbered Steps to Reproduce Problem:
1) Download the Call test demo.
2) Examine the code for errors, then compile and execute the demo.
3) Use the Bump mob test. Observe that the mob.test() call is successful.
4) Use the Bump item test. Observe that the item.test() call is not processed, despite code flow processing beyond the call.

Expected Results: For the verb or proc to be executed as defined, or for an unknown proc runtime error to be thrown.

Actual Results: In some cases, no proc/verb is executed when called using the . or : operators. (or I suspect, the other non-existent proc/verb is executed, but throws no error.)

Does the problem occur:
Every time? Or how often? In some cases. See demo.
In other games? Untested.
In other user accounts? Untested.
On other computers? Untested.

When does the problem NOT occur? The problem does not occur when same named procs are both defined the same way. The problem also does not occur if call()() is used, rather than the . or : operators.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown. This issue appears to be very old, appearing in BYOND 354.

Workarounds: Use call() or define same named procs as either proc or verb, not one of each.

This is a bug none the less, to sum it up for lummox:


When you have a var typed as a mob (or something else) and it really holds an obj (or something else) and you try to call a proc on the var that mob and obj both have separately defined (and the obj defines it as a verb) the proc will not run with no runtime or compile time errors.




That being said! Calling procs like this isn't advisable.

any time you have an istype, you should then type cast the variable to the proper type.

Calling /mob/test() on a obj is technically suppose to work if obj also has a test() method, but its bad programming, you should type cast P to an obj/item:

        Bump(mob/p)
if(istype(p))
world << "process1"
p.test() // calls correctly.
world << "process2"
if(istype(p,/obj/item))
var/obj/item/O = p
world << "process3"
//p.test() //This doesn't appear to ever be called correctly.
O.test() //This will get called
// call(p,"test")() // Using call() directly will have expected results.
world << "process4"