Projectile Bump damage

ID:1978045
 
Nov 5 2015, 1:51 am
(See the best response by Kozuma3.)
Code:
    Bump(mob/M)
        if(istype(M,/turf/))
            var/turf/T = M
            if(T.density)
                del src
        else if(istype(M,/obj/))
            del src
        if(src.owner ==M)
            return
        else
            var/damage = src.Nin 
            M.Health-=damage
            s_damage(M,damage, "orange")
            world << "You hit <b>[M]</b> for <font color=red>[damage]</font color=red> with [name]!"
            del src
            M:deathcheck()


Problem description: It doesn't do any copile problems and it works just fine but the problem is that it uses the src.Nin default value (mob/var) and not the current Nin that the mob has in the game..

Example: the current mob/var/Nin = 500
I made a verb that increases your src.Nin by +30
After doing this the damage the projectile deals is still 500.. instead of 530
Tried using usr.Nin instead of src.Nin but it gives an In game error and says Cannot read usr=0 or something like that..
Also tried doing a proc for the damage but nothing =/ Any help would be appreciated

Nov 5 2015, 3:13 am
var/damage = owner.Nin
src would be the object itself while owner.Nin is the object's owner's variable of Nin
Nov 5 2015, 3:33 am
Verbs.dm:111:error: owner.Nin: undefined var

Is it maybe because the var/owner is null?

obj
    projectile
    parent_type = /mob
    var/owner = null

Nov 5 2015, 3:39 am
Is Nin defined under /mob?
Do you set owner?
Nov 5 2015, 3:46 am
Yes Nin is defined under /mob
Nov 5 2015, 3:47 am
In response to Kakarot06
Kakarot06 wrote:
obj
>   projectile
>   parent_type = /mob
>   var/owner = null
>


Change it to

obj
    projectile
    parent_type = /mob
    var/mob/owner = null


Nov 5 2015, 3:52 am
Copile went well but in game runtime error happened:
runtime error: Cannot read null.Nin
Nov 5 2015, 3:52 am
In response to Kakarot06
Kakarot06 wrote:
Copile went well but in game runtime error happened:
runtime error: Cannot read null.Nin

What was the error output?
Do you have it on debug, and if so what line?
Nov 5 2015, 3:56 am
Fire Blast (/obj/projectile): Bump(Thief (/mob/NPC/Thief))
Fire Blast (/obj/projectile): Move(the grass (77,34,1) (/turf/grass), 1)
runtime error: Cannot read null.Nin
proc name: Bump (/obj/Bump)
usr: 0
src: Fire Blast (/obj/projectile)
call stack:
Nov 5 2015, 3:57 am
Best response
You're not setting the owner, when the projectile is created you need to set its owner to the creator mob.
Nov 5 2015, 4:04 am
Done! Thank you very much!
Nov 5 2015, 4:04 am
You're welcome!
Nov 5 2015, 10:45 am
One thing I strongly recommend is taking all of that damage-dealing code out of the projectile and moving it somewhere else, because I very much doubt it's the only place you're doing that.

Instead, you should consider something like this:

mob/proc/TakeDamage(mob/attacker, damage, weapon, clr="orange")
    Health -= damage
    s_damage(src, damage, clr)
    attacker << "You hit <b>[src]</b> for <font color=red>[damage]</font>[weapon ? " with [weapon]" : ""]!"
    deathcheck(attacker)    // pass attacker as an argument in case it's meaningful to the deathcheck

So your projectile would call M.TakeDamage(owner,Nin,src,"orange") to accomplish this.

I fixed your HTML too; including attributes in a closing tag is a no-no.
Nov 5 2015, 4:12 pm
Done why you strongly recommend it though?
and thanks
Nov 5 2015, 4:18 pm
In response to Kakarot06
Kakarot06 wrote:
Done why you strongly recommend it though?
and thanks

Let's say you have your projectile doing damage. You have all that code in the Bump(). What happens when you add a melee attack? You have to re-write all that code just to be able to add melee. If you put all that code in a proc, and call it in Bump(), you can re-use it on all sorts of things, such as melee, without having to re-invent your wheel.
Nov 5 2015, 4:20 pm
In response to Kakarot06
Kakarot06 wrote:
Done why you strongly recommend it though?

There's a programming design principle called separation of concerns, that basically something should not try and do too much all at once. I briefly give an example of why you'd want to do that here.
Nov 5 2015, 4:36 pm
In response to Kakarot06
To add on to what Rushnut and Pop said, basically the reason to do this is that you don't want to have to have the exact same code, or tiny variations on it, repeated all over the place. Doing so has the following disadvantages:

- It bloats your code.
- It's very hard to maintain; making changes to the way damage is handled would be much more difficult.
- Copy-paste errors are hard to spot and the source of much hair-pulling.

It has the following advantages:

- No proc call overhead

The latter advantage can sometimes be gained, at the cost of compiled code bloat and higher compilation time, with a #define macro, but for simplicity's sake you should just use a proc here.

The disadvantages far outweigh the advantages, so it's best to stick code like this that you'll use a lot into its own proc.
Nov 5 2015, 4:45 pm
I see thanks you all