ID:143543
 
xD you forgot to subtract the health!!

attack2(mob/defender)
var/damage = rand(1,5)//sets the damage variable to a random number between 1 and 5
defender << "You take [damage] damage!"
src << "You attack for [damage] damage!"
defender.health-=damage
if(defender.health <= 0)//if no health is left
src.death(defender)//death
if(!src.client)//if it's not human
sleep(10)
src.ai_random_wander()//wander
In response to Tubutas
that doesnt work
In response to Agrey123
ai_check_dist(mob/attacker,mob/defender)
if(attacker.client)
return
else
if(get_dist(attacker,defender) <= 1)//if the monster is one tile away from the player
attacker.attack2(defender)//attack!
else
return


replace that
I'm confused. How is it your code got much worse over an 11-hour period? Somebody obviously gave you some really terrible advice on what to do with your code, because it went from close to right, to totally wrong.

This was your code earlier:

mob
proc
DeathCheck(mob/M)
if (src.Hp <= 0)
world << "[src] dies at the hands of [M]!"
del(src) //delete whatever just died
src.Hp = 30
src.loc= locate(1,1,2)


Now it does have one obvious problem in that del(src) is being called before the other stuff, but that basically doesn't matter if you're just deleting the mob anyway. The main thing is, this is the right way to handle a deathcheck; src is the victim, and the killer is passed in as an argument. Here's what your code looks like now:

mob
proc
DeathCheck()
if (usr.health <= 0)
world << "[src] dies at the hands of [usr]!"
del(src) //delete whatever just died
usr.health = 30
usr.loc= locate(1,1,2)


You've got usr in a proc now, which is always bad, in place of having an argument which was the right thing to do. But worse, you're not even using src and usr consistently. Sometimes you treat src like the victim, other times usr. Go back to the first version, because it was the right design.

Then, there's this:

    verb
attack(mob/M as mob in oview(1)) //attack a mob within 1 tile of you
usr << "You attack [M]!" //send this message to the usr
oview() << "[usr] attacks [M]!" //send this message to everybody else
var/damage = rand(5,20) //assign a random # to a new variable
world << "[damage] damage!" //tell the damage to the world
M:health -= damage //take away the damage from M
M:DeathCheck()


The : operator has very limited usefulness and a newbie should never touch it at all, ever, for any reason. Always always find a way to use the . operator instead. In this case, M is already the right type (/mob), so just use . and be done with it.

            M.health = max(M.health - damage, 0)
M.DeathCheck(usr)


Notice I added an argument to DeathCheck() as well. Why? Because you need to go back to the earlier version of DeathCheck(), and that version takes the attacker as an argument.

Lummox JR
In response to Tubutas
Tubutas wrote:
xD you forgot to subtract the health!!

Nope, you just forgot to read the line where he subtracted the health. It's right there in his code.

But what's up with this?

if(defender.health <= 0)//if no health is left
src.death(defender)//death


That code fails. First of all, his deathcheck proc is called DeathCheck(), not death(), and it never hurts to keep it relevant to his code issues rather than just pulling other code out of the blue. Second, that's some bad blue to be pulling code out of, because you've got your death() backwards there. In any deathcheck proc, src must always be the victim; the killer, if needed, must always be sent as an argument. There is a very simple reason for that:

A death check is always about the mob who's dying.

That is, a death check does all the necessary cleanup, etc. on a dying mob, and handles issues like whether they drop items, whether and where they respawn, and so on. The most it needs to do with the killer is maybe send a message about who did the killing, and maybe add to the killer's experience/score and level them up. So the killer is really secondary information. In any proc src should always be the main focus of the action, and in a deathcheck that's the victim, always.

On a side note, you should always put a tab between your code and a // comment just so the comment is readable.

Lummox JR