It wont damage!

Page: 1 2 3 4 5 6
ID:145853
 
Nov 21 2005, 9:31 am (Edited on Nov 21 2005, 5:34 pm)
Code:
Attack(mob/m as mob in oview(range))
            set category = "Commands"
            if(isnull(m))
                return
            var/mob/t = src
            var/hit = (rand(t.speed * 10)) - (rand(m.speed * 10))
            var/dmg = t.mindmg
            if(hit > 0)
                switch(t.physelem)
                    if("war")
                        dmg += round((rand(t.attack * t.war)) + (t.attack * t.war / 2))
                        switch(m.baselem)
                            if("dragon")
                                dmg -= round((rand(m.defense * m.dragon)) + (m.defense * m.dragon / 2))
                    if("wind")
                        dmg += round((rand(t.attack * t.wind)) + (t.attack * t.wind / 2))
                        switch(m.baselem)
                            if("dragon")
                                dmg -= round((rand(m.defense * m.dragon)) + (m.defense * m.dragon / 2))
                    if("mystic")
                        dmg += round((rand(t.attack * t.mystic)) + (t.attack * t.mystic / 2))
                        switch(m.baselem)
                            if("dragon")
                                dmg -= round((rand(m.defense * m.dragon)) + (m.defense * m.dragon / 2))
                    if("dark")
                        dmg += round((rand(t.attack * t.dark)) + (t.attack * t.dark / 2))
                        switch(m.baselem)
                            if("dragon")
                                dmg -= round((rand(m.defense * m.dragon)) + (m.defense * m.dragon / 2))
                if(dmg < t.mindmg)
                    dmg = t.mindmg
                DeathCheck(t,m)


Problem description:

Stated. Based on the base element, it's supposed to damage the player.
Nov 21 2005, 9:33 am
Change 1 already found:

Attack(mob/m as mob in oview(src.range))
Nov 21 2005, 9:37 am
In response to Developous
Problem found. I was missing the damage alltogether!
Nov 21 2005, 10:39 am
Instead of using so many switch statments, wouldn't it be easier just to use a list?

dmg += round((rand(t.attack * t.elems[physelem])) + (t.attack * t.elems[physelem] / 2))

dmg -= round((rand(m.defense * m.elems[baselem])) + (m.defense * m.elems[baselem] / 2))


Something around that.
Nov 21 2005, 2:22 pm
Your DeathCheck() proc is wrong. You're passing it two arguments instead of one. Namely, you're passing it as DeathCheck(killer,victim).

You don't have to pass the victim to DeathCheck(), because it should already know the victim. The victim is src, or else it's wrong. So you should be calling m.DeathCheck(t), and you need to fix your DeathCheck() proc.

Lummox JR
Nov 21 2005, 5:07 pm
In response to Lummox JR
I just preferr it with double values. Could be useful in the long run, especially knowing the combos thereof involving src and usr for that.
Nov 21 2005, 5:11 pm
In response to Dever
Dever wrote:
Instead of using so many switch statments, wouldn't it be easier just to use a list?

dmg += round((rand(t.attack * t.elems[physelem])) + (t.attack * t.elems[physelem] / 2))

dmg -= round((rand(m.defense * m.elems[baselem])) + (m.defense * m.elems[baselem] / 2))


Something around that.

Good idea. I haven't really learned lists yet, though. I will get to that when I have made most the necessarry upgrades.
Nov 21 2005, 5:19 pm
In response to Developous
Developous wrote:
I just preferr it with double values. Could be useful in the long run, especially knowing the combos thereof involving src and usr for that.

It would be useless because src would be the same as the mob/t you defined to be set as src. You'd basically be passing an argument which you already have access to.

~~> Unknown Person
Nov 21 2005, 5:32 pm
In response to Unknown Person
Unknown Person wrote:
Developous wrote:
I just preferr it with double values. Could be useful in the long run, especially knowing the combos thereof involving src and usr for that.

It would be useless because src would be the same as the mob/t you defined to be set as src. You'd basically be passing an argument which you already have access to.

~~> Unknown Person

fact, but I simply cannot help make double values. No fret. Double values, double trouble! TO each his own.

Um, there is another problem. Exp and gold values are not set, but it would look like they are.

DeathCheck(mob/m as mob, mob/t as mob)
            if(t.hp <= 0)
                m.gold += t.goldval
                m.exp += t.expval
                if(t.humv == "yes")
                    t.hp = t.hcp
                    switch(t.starter)
                        if(1)
                            t.loc = locate(/area/startup)
                        if(2)
                            t.loc = locate(/area/spawn2)
                else
                    del(t)
                LevelUp(m)
Nov 21 2005, 5:40 pm
In response to Developous
Developous wrote:
I just preferr it with double values.

That's ridiculous. You're passing the proc information that's not only completely redundant, but likely to make you dependent on it. Keep doing that and you'll never be a better developer, which is to say, you'll never escape mediocrity and simple code problems you could so easily avoid.

Could be useful in the long run, especially knowing the combos thereof involving src and usr for that.

How is an extra copy of the same data at all useful? You already know it; being told it twice won't help you. It's not like passing an argument for usr which is basically just safety: usr is unreliable outside of procs. src is not.

Lummox JR
Nov 21 2005, 5:50 pm
In response to Developous
Developous wrote:
fact, but I simply cannot help make double values.

Translation: I know I'm doing something wrong but don't intend to do better.

That being the case, why are you seeking help at all? Your quest to debug your code is useless if you're unwilling to learn anything.

No fret. Double values, double trouble! TO each his own.

This isn't a matter for opinion. Passing a proc its own src as an argument is asinine. It tells the proc nothing, and only presents you with a var to rely on that will be difficult to ever remove from your code later, while also offering a nice fat target for runtime errors and bugs.

There are multiple ways to do a lot of things. This isn't one of those things.

LevelUp(m)

For the same reasons, this is wrong too. A levelup proc needs absolutely no arguments. src is all it needs.

Lummox JR
Nov 21 2005, 6:04 pm
In response to Lummox JR
Almost like passing usr even when its already passed to the proc? ..Lummox.
Nov 21 2005, 6:11 pm
In response to Dever
Dever wrote:
Almost like passing usr even when its already passed to the proc? ..Lummox.

Dude, I addressed that in the other post. usr is unreliable because you have to make an assumption about how the proc was called. src on the other hand is always reliable. Passing an argument to avoid usr is robust design; passing an argument to get in the way of using src is folly.

The rule isn't more vars = good. That's just the assumption of a lousy programmer. If you actually analyze the difference between passing something or not, it's obvious why in one situation it's good, and another it's bad.

Lummox JR
Nov 21 2005, 6:14 pm
In response to Lummox JR
I don't believe in robust design. I believe in effiency.
I code everthing to work perfectly and effiently for the current situation of the program. If it ever comes up in the future and needs to be changed, then I will change for that situation. Having procs written to work in multiply situations lowers its effiency and performance.
If you know that usr needs to be used, and know how its going to work, then using it in that situation is completely valid.
Nov 21 2005, 6:23 pm
In response to Dever
That's like doing this:
/********************/ //Code A
turf/grass/Entered()
  usr<<"Hello!"
/********************/
/********************/ //Code B
turf/grass/Entered(mob/M)
  M<<"Hello!"
/********************/
//or
/********************/ //Code A
mob/NPC/Bump()
  usr<<"Hello!"
/********************/
/********************/ //Code B
mob/NPC/Bump(atom/movable/M)
  if(ismob(M))
    var/mob/m=M
    m<<"Hello!"
/********************/


Both code snippets (Code 'A' and 'B') work fine. But using 'usr' can cause problems in the near future. So, arguments and 'src' usually are the best to use, because we won't know what 'usr' when a proc is called.
Nov 21 2005, 6:26 pm
In response to Mega fart cannon
"because we won't know what 'usr' when a proc is called."

I do know.
Nov 21 2005, 6:30 pm
In response to Dever
Dever wrote:
I don't believe in robust design. I believe in effiency.

Robust coding is a step towards effiency.

I code everthing to work perfectly and effiently for the current situation of the program. If it ever comes up in the future and needs to be changed, then I will change for that situation. Having procs written to work in multiply situations lowers its effiency and performance.

So what you're saying is, 1 proc doing 3 things, is less effient (sp?) than 3 procs doing 1 thing?

If you know that usr needs to be used, and know how its going to work, then using it in that situation is completely valid.

I totally agree.
Nov 21 2005, 6:34 pm
In response to Mega fart cannon
'So what you're saying is, 1 proc doing 3 things, is less effient (sp?) than 3 procs doing 1 thing?'

I did not say a proc doing multiple functions, but a proc wokring in mutliple situations. If you know the current situation of how its being used, then code that way.
Nov 21 2005, 7:11 pm
In response to Dever
By "we", he doesn't mean you or anyone for that matter. What he means is, your program won't know.

What if an NPC decided to enter that turf/bump into that mob? There's no usr in that situation. So you'd get an error.
Nov 21 2005, 7:13 pm
In response to DeathAwaitsU
What if I know an NPC won't? If there is such an NPC, and if it possible for him to do so, then I will code it that situation.
Page: 1 2 3 4 5 6