In response to Spunky_Girl
If you type cast under Enemy2, then yes, you can access the verbs from Enemey1. Though, couldn't you just put the verb higher up in the tree if both mobs are going to have similar verb functions?
In response to Mega fart cannon
Mega fart cannon wrote:
Though, couldn't you just put the verb higher up in the tree if both mobs are going to have similar verb functions?

That wasn't my question, now was it? ;p
In response to GhostAnime
GhostAnime wrote:
The set command should not work in procs, they're only for verbs; the "set src in oview(1)" should have given you an error (I think, it's been a while).

Verbs and procs are very much identical; the main thing that's different with a verb is that it's automatically added to the verbs list of the atom it's defined under. Other than that, verbs and procs function the same way whenever called by a proc or when invoked by a player, which is the time verb arguments and src settings will take effect. So DM will let you use things like src settings in procs because they can always be added to a verbs list and then function as verbs.
(So, you can also call verbs just like you can procs, seeing as they're pretty much the same. :P Like with any proc call however usr's value won't be changed but passed on as it is though, so you'll want to set usr to the correct value right before calling the verb to pass it the correct one, or use another value (sometimes src is appropriate).)

Like what Spunky said, get_dist would be better for this thing anyways >_>

He already attempted to check if the object is in view(1) anyway, which is similar enough (or perhaps even considered slightly better). Talking about using if() of course, not set.
In response to Spunky_Girl
All functions have to be initiated by something. Either the world, or input from a client.

Enemy1 cannot magically call Enemy2's Talk function. You can call Enemy2's Talk function from one of Enemy1's functions though usr will not identify as Enemy1 (something has to call Enemy1's function that calls Enemy2's function).

usr is always either null (this would be something initiated by the world itself), or the mob that belongs to the ultimate source of all of the functions that lead up to the current function (a client typing a command that called a function that called a function that called a function).

mob
proc
// calls another mob's Talk function.
callTalk(mob/target,message)
target.Talk(message)

// display a message, announce usr.
Talk(message)
world << "[name]: [message]"
world << "(usr is [usr ? "[usr]." : "za warudo!"])"

world
// note that this doesn't mean just world functions.
// any function that is a result of something done by the world will have no usr.
// this means items created on map (from the map editor, that is) and stuff like that.
New()
..()
spawn(10) // so we can see the result
var/mob/mob1 = new
var/mob/mob2 = new
mob1.callTalk(mob2,"this is a test")

mob
verb
test()
var/mob/mob1 = new
var/mob/mob2 = new
mob1.callTalk(mob2,"this is a test")


Also, please note that src refers to the object that the function belongs to.

var/mob/x = new
x.somefunction()


src used in somefunction() will refer to x (who is the source of the function).
Page: 1 2