Now that's better!

ID:115842
 
Jul 13 2011, 8:51 am
Gonna get this out of the way immediately...

Disclaimer: This isn't necessarily a better way to do things. It's all strictly my own opinion. I just needed a catchy title folks ;p...


Now onto the post!


Alright, I'd say about 75% of everything I've learned programming wise was more or less because of epiphanies. Well, literally just now I had one.

For years I've created a central death control system as followed:

mob/proc/Death()
 if(src.key)
  src.deaths++
  return ..()
 if(istype(src,/mob/Monster/))
  del(src)
 if(istype(src,/mob/Turret/))
  del(src)
 ..()


Now, as far as I'm concerned this way is pretty decent and works alright(note that I didn't take into consideration the one killing because I felt it wasn't necessary).

However, I today realized there is a different [arguably better] way...

It plays off the fancy smancy ..() function.

If you are not formilar with the ..() function. More or less what it does is causes the proc/verb to do it's parent function.

Any who... Here is how I now think a Death proc should be made...

world/mob = /mob/Player/ //Set the clients default mob to mob/Player

mob/proc/Death()
 ..()

mob/Player
 Death()
  src.deaths++
  ..()

mob/Monster
 Death()
  del(src)

mob/Turret
 Death()
  del(src)



I don't know. Just to me this little feature seems like it could potential help save a lot of unneeded checking...

It also turns out that it gets a little more indef than just this.

Say for instance your path doesn't contain one item but several. It actually goes down the tree from top to bottom. Here is my script I used to test.

mob/Player

world/mob = /mob/Player/

mob/proc/Test()
    src << "Root"
    ..()

mob/Test()
    src << "mob base"
    return ..()

mob/Player/Test()
    src << "player base"
    ..()

mob/verb/TestThisProc()
    src.Test()


It displays player base then mob base then root base... As state, I just really thought this was neat and practical..


Lastly, an even closer look at how this could all help you... You can also use . to control the ..()'s return value.. Yet another example...

mob/proc/TestProc()
 .="root value"
 ..()

mob/Player/TestProc()
 var/parent_return = ..()
 src << parent_return



Honestly, I can't really think of anything too too good for this at the moment. However, I am very sure I will take advantage of this system in the future..
Jul 13 2011, 9:03 am
You're abusing the ..() procedure.
Jul 13 2011, 9:07 am
Darker Legends wrote:
You're abusing the ..() procedure.

He's displaying the variety of uses for its function, so.
Jul 13 2011, 10:21 am
Lmao Zane
Jul 13 2011, 10:26 am
Say for instance your path doesn't contain one item but several. It actually goes down the tree from top to bottom.

You can even have multiple definitions of the same proc at the same level and use ..() to call the other instances at the same level. For example:

mob/proc/test()
    world << "a"

// later in the code
mob/test()
    ..()
    world << "b"


That'll output a and b. If you take out the call to ..() it'll just output b.

I use ..() a lot in my libraries. The library defines the default behavior for each movement proc. You can override these proc in your own code and call ..() to run the instance of the proc defined in the library (which is the default behavior).
Jul 13 2011, 11:12 am
Maybe you should read the DM reference. They cover this, and a lot of other useful things.
Jul 13 2011, 11:51 am
Suicide Shifter wrote:
Maybe you should read the DM reference. They cover this, and a lot of other useful things.

The reference tells you that things like this exist but they don't always tell you how useful it can be. It's easy to disregard a feature when you don't see why it'd be useful.

Also, you probably don't need to call ..() in the proc's definition. I don't think it's possible that ..() will ever do anything there because if you're defining the proc, it doesn't have a parent to call.
Jul 13 2011, 12:42 pm
Yeah, Forum_account, I don't think it will do anything either. Sometimes I do it anyways, though. Not sure why. And I use this quite a bit in my game. It is very useful in some situations.
Jul 13 2011, 1:44 pm
Yeah I knew that Forum_account. Felt I should had probably displayed a mob/Move() proc example that displays if you moved or not...

mob/Move()
 if(..()){src << "Step successful."}


Also Forum_account, Idk why, but I for some reason thought if ..() wasn't called then it wouldn't return to the initial proc. So thanks for pointing that out =)!

You guys gotta understand. I'm no good at programming.. I learn as I go and am too lazy to read a dang thing that isn't inside the Help On section of the Dream Maker :p