How does BYOND order procs when compiling? Lets say I have this code.
mob/Login()
..()
src << "I am login 1!"
mob/Login()
src << "I am login 2!"
..()
mob/pc/Login()
..()
src << " I am login 3! (pc)"
mob/pc/thief/Login()
src << " I am login 4! (pc/thief)"
..()
Now, in what order are they all called, especially in relation to the base true parent proc? I'm sure I could figure this all out with a test world (which I am going to boot up next), I'm just wondering about the logic behind it all. I know that libraries often add things to the predefined procs, are libraries counted before or after the source code? Bleh, confusing.
~Polatrite~
ID:135853
 Jan 21 2004, 6:29 pm
|
|
Don't really see how this needs documentation. It's compiled in order of hierarchy, and in order of appearance at similar levels of hierarchy.
A child procedure runs its code; when it encounters ..(), it inserts the code from the parent procedure. Thus, a complicated chain of statement; ..(); return would show the current nodes' statements, then the parents' statements, and so on. | |
Running my previous example, the output is...
I am login 4! (pc/thief)
I am login 2!
I am login 1!
I am login 3! (pc)
Procs 2 and 4 execute commands before the parent call. However, /mob/pc/thief was excuted first. That's because it's the mob's main type. After that, /mob's proc was excuted (because no /mob/pc Login existed).
After it finishes excuting the source code before the parent procs, based on type threading backwards, it beings the opposite -- threading foward through types executing the rest of the mob Login code AFTER the parent proc call, ..() .
Also, in cases where there are multiple iterations of the proc for the same mob type (/mob/pc has two Login definitions, for example), while it is "threading backwards" in terms of mob type, it is also threading backwards in terms of organization in the code. Therefore code that is at line number 80 will execute before code a line number 30, when threading backwards. However, when threading fowards (again, reading data after the parent proc call ..(), it would read line 30 before 80.
Since this undoubtidly makes no sense to anyone but me, try the following example for a better understanding. This works standalone in a new environment.
mob/Login()
..()
src << "I am login 5! (threading fowards)"
mob/Login()
src << "I am login 4! (threading backwards)"
..()
mob/pc/Login()
src << " I am login 3! (pc, threading backwards)"
..()
src << " I am login 6! (pc, threading fowards)"
mob/pc/thief/Login()
src << " I am login 2! (pc/thief, threading backwards)"
..()
mob/pc/thief/Login()
src << " I am login 1! (pc/thief, threading backwards)"
..()
src << " I am login 7! (pc/thief, threading fowards)"
mob/pc/thief/Login()
..()
src << " I am login 8! (pc/thief, threading fowards)"
world/mob = /mob/pc/thief
Just a little data for the curious developer that hasn't been documented, nor covered, as far as I'm aware.
~Polatrite~