ID:140679
 
Code:
    if(usr.hp<=0)
usr<<"You have died"
usr.hp = usr.hpmax
del(usr)


Problem description:
this is part of my deathcheck proc (del part)and it always deletes the user, even when its maximum hp. do i really suck dat bad?

EDIT: or maybe its just my meds, ive been taking some stuff thats spose' tuh make me not think straight as a side effect
Gigimoi wrote:
Code:
>   if(usr.hp<=0)
> usr<<"You have died"
> usr.hp = usr.hpmax
> del(usr)
>

Problem description:
this is part of my deathcheck proc (del part)and it always deletes the user, even when its maximum hp. do i really suck dat bad?


I'm really not seeing what you are asking. The coding I'm looking at will delete the usr regardless. If you want them to just respawn with max hp then don't call del() just change their location to a spawn point or what not.
Since you're calling del(usr), usr will always be deleted regardless of any other circumstances. But since this is in a proc, you shouldn't be using usr at all.

Lummox JR
In response to THESINKING
if(src.hp<=0)
src.loc=locate(1,1,1)//or any other loc
src<<"Some wording"

You could also add something in there like src.Dead=1 if you need to recognize that the src is dead.
In response to Lummox JR
oh.... well im retarded..... again, must be meds.......
In response to Drehdog7
ive got auto repop so.....
In response to Gigimoi
    if(usr.hp<=0) // okay, if the user's HP is less than or equal to 0.
usr<<"You have died" // he dies.
usr.hp = usr.hpmax // set his hp back to max hp.
del(usr) // delete him from the world.


I commented what you were trying to do. Hopefully this enlights you on what you did wrong. :)

Remember!! Never use usr in proc's!! Use src.

Here's a version of a deathcheck proc I just scrapped up.

mob/proc/DeathCheck(mob/M)
if(!M.client) // if it's not the player.
if(src.hp<=0)
src<<"You have died"
del(src)
else
if(src.hp<=0)
src<<"You have died"
src.loc=locate(x,y,z) // send him to the start location
In response to Stereo
Wouldn't using hp<1 use less processing power than <=0 ?
In response to Mista-mage123
It's practically the same.
In response to Stephen001
<=o is two seperate expressions, is it not?

It would be easier on the CPU to only use one expression, less than. Wouldn't it?
In response to Mista-mage123
I don't see why it wouldn't be implemented as one expression. The difference is still trivial though. If you want to talk efficient, reduce the amount of looping / repeated processing of data in a given piece of code.
In response to Mista-mage123
Mista-mage123 wrote:
Wouldn't using hp<1 use less processing power than <=0 ?

Most likely not (they are both one opcode), and they are not equivalent expressions anyway.
In response to Mista-mage123
Mista-mage123 wrote:
<=o is two seperate expressions, is it not?

It is not. At the bytecode level, both < and <= use a single instruction. At the machine code level, that is also usually the case for most processors.

Lummox JR
In response to Stephen001
my meds have warn off for now but i have to take them every day......
In response to Stereo
Stereo wrote:
> mob/proc/DeathCheck(mob/M)
> if(!M.client) // if it's not the player.
> if(src.hp<=0)
> src<<"You have died"
> del(src)
> else
> if(src.hp<=0)
> src<<"You have died"
> src.loc=locate(x,y,z) // send him to the start location
>


You don't need to make it a mob/proc if you define the mob inside the proc arguements
Or the way around

proc/DeathCheck(mob/M)
In response to Nielz
The proc is an object proc on purpose because there are reasons and incentives to do it.
An object proc is different from a global proc in that the proc depends on its source existing (and of course being of the right type) in order to be called as well as continue its execution, the proc's main purpose is doing something with that one object, and the proc can be overridden to do different things when called on different subtypes.
As you've probably noticed, people don't go about just making all of their procs global procs just because they can almost always do so.
DeathCheck() should be a /mob proc because it specifically operates on its source object, which is a mob. Of course, if the mobs that could die and fight were under a specific subtype (which is comparatively better design), such as /mob/fighter, then you would've had /mob/fighter/proc/DeathCheck instead.
In response to Kaioken
Alright then, but, if it is a mob proc that only processes its src, then it isn't needed to define a mob as an arguement in the brackers, right?

Because what Stereo did, seemed a bit odd to me:

mob/proc/DeathCheck(mob/M)
if(!M.client) // using M
if(src.hp<=0) // using src, which == probably M in a deathcheck


And something like src.DeathCheck(src) or mob.DeatCheck(same_mob) seems a bit useless to me
In response to Nielz
Nielz wrote:
Alright then, but, if it is a mob proc that only processes its src, then it isn't needed to define a mob as an arguement in the brackers, right?

It could be needed. Arguments are for passing information; a mob could be a needed piece of information. In a DeathCheck() proc, you'd typically pass the attacker (potential killer) mob as an argument, since the proc needs to know it.

Because what Stereo did, seemed a bit odd to me:

Ah, because it is. His usage of the argument is wrong, and he's even mixing it and src together, when all he needs to use there is src. He doesn't need that argument (but the proc should be an object proc).

And something like src.DeathCheck(src) or mob.DeatCheck(same_mob) seems a bit useless to me

Yes, of course that's not right. A typical proper DeathCheck() and calling it would look like in the example here: [link] (it also happens to give an example of overriding DeathCheck() for a subtype).
In response to Kaioken
I see, thanks for explaining