Frozen Screen(?)

ID:139807
 
Aug 21 2010, 12:03 pm
Problem description:
It's not a code problem, at least it might not be.... The world suddenly freezes when I continuously spam the Battle Macro on a nearby wall during a test. The purpose of the test, was to ensure that the wall did indeed take damage from the verb and at some point, changed its state to a damaged wall. The problem here, is that before I can destroy the wall enough to the point where it changes its icon state, the game either freezes and I can no longer close except by Task Manager or no matter how much I try, the damage isn't dealt to the wall nor does it show up using the s_damage library, as if it completely skips the override Bump() somehow. I've no clue what this problem is or how to get pass it, if its a bug through the method of code I used in the Bump() / Battle Macro or if its just my computer itself.

I welcome any input on helping me solve this problem and if needed, I may later put up the code of the Battle Macro and override Bump() or further explain the problem as best as I can. Thanks in advance.
Aug 21 2010, 12:13 pm
It's a code problem.

There is a problem in your code.

Also s_damage is rather poorly made in that it uses up way more processing power than is needed, but I'm not aware of any library that fixes that.
Aug 21 2010, 12:20 pm (Edited on Aug 21 2010, 12:25 pm)
In response to Garthor
Well, here's the code:

Battle Macro:
    LightStrikeA()
        if(usr.Request != "")
            if(usr.Request == "A")
                usr.Request = ""
                usr.LightStrikeA()
            else
                usr << 'Failure.wav'
                return
        else
            usr.Macro = "A"
            usr.Combo += "A"
            usr.Stance = "[usr.Macro]-Strike"
            usr.ShowCombo()
            usr.Timer += 9
            usr.Force += round((usr.Strength+usr.Fighting_Prowess)*rand(1.3,1.5))
            flick("[usr.Light_StrikeA]",usr)
            for(var/atom/A in get_step(usr,usr.dir))
                usr.Bump()
            spawn(usr.Timer)
            usr.Macro = ""
            usr.Combo.Cut()
            usr.Stance = ""


Bump():
Bump()
        for(var/atom/A in get_step(src,src.dir))
            if(ismob(A)==1)
                if(src.Stance == "[src.Macro]-Strike" || src.Stance == "Technique")
                    if(A.Fightable)
                        src.Bump_Attack(A)
            if(isobj(A)==1)
                if(src.Stance == "[src.Macro]-Strike" || src.Stance == "Technique")
                    if(A.Fightable)
                        src.Bump_Object(A)
            else
                return


Bump_Object():
Bump_Object(obj/O)
        var/mob/Damage = round(src.Force)
        var/mob/Choice = pick(prob(src.Fighting_Prowess*0.35+src.Intelligence*0.3+src.Skill*0.35); "goldenrod", prob(O.HP); "darkred")
        if(Choice == "goldenrod")
            Damage = round(Damage*rand(2.1,2.4))
        else
            Damage = Damage
        s_damage(O,Damage,Choice)
        O.HP -= round(Damage)
        if(O.HP <= 0)
            O.HP = 0
            O.icon_state = "Destroyed [O.icon_state]"
            O.Fightable = 0


Well? See anything wrong?

Edit: I've just noticed in the Source Folder a .rsc file called, "buggy" so now I'm doubting its a code problem even more now.
Aug 21 2010, 12:34 pm
In response to YoukoSieg
You aren't using spawn() correctly. Anything that should be spawned off has to be indented past the spawn() statement.

Your use of Bump() is horribly, amazingly, unbelievably wrong. Like, super-duper-woah. For starters, you are calling Bump_Attack() N2 times: you call Bump() once for each object, and then Bump() calls Bump_Attack() once for each object.

Defining those variables as var/mob/Damage is wrong. They aren't mobs. Why are you calling them mobs?

The pick() you have there is really quite nonsensical, but that's more of a design issue.

Your use of rand() in Bump_Object() (and LightStrikeA() now that I look at it) is wrong. rand() will only give integers, so rand(2.1,2.4) is just invalid usage. The line "Damage = Damage" is also particularly stupid.

I don't see anything that would cause a total crash, though, unless it's in one of the other procs (like ShowCombo()) or s_damage is just REALLY acting up.
Aug 21 2010, 12:51 pm (Edited on Aug 21 2010, 1:08 pm)
In response to Garthor
Erh... Jheez... Thanks for your input I guess... This was really only code I threw together a little earlier today, of course they'd be ton of errors and I'm aware of half the things you pointed out, which I know for a fact have nothing to do with the crash. They're merely coded that way as I was testing out a few things before. The ShowCombo() wouldn't be able to cause it neither as all it does is show what Macros are pressed in a small image around the mob, but if you still insist on seeing it:

    ShowCombo()
        set src in usr.client.screen
        var/image/Icon = image('Misc.dmi',src,src.Macro)
        Icon.pixel_y = -25
        Icon.pixel_x = 25
        src.ComboIcon += Icon
        src.client.images += Icon
        src.client.images -= Icon
        del Icon


I also really doubt its caused from s_damage as I've tried using s_damage in another version of the source, a much older version, and it worked without a hitch. At any rate, thanks... I guess...

Edit: As a heads up, this too was made earlier today for testing purposes however, like I said, it should have no influence on a crash...
Aug 21 2010, 1:30 pm
In response to YoukoSieg
 
        src.client.images += Icon
        src.client.images -= Icon


I really, really, really don't understand why you keep on having things like this and the "Damage = Damage" line.
Aug 21 2010, 1:35 pm
In response to Garthor
Again, the code was used in earlier testing for my own curiosity not to mention its beside the point.... I wanted to see how much delay there was between the two lines and other certain things. Similar thing with the "Damage = Damage" line. Bottom line, its got nothing to do with the topic.

So, is there any other reasons you can think of for the crash?
Aug 21 2010, 1:49 pm
In response to YoukoSieg
I'm gonna stick with s_damage being the culprit. Try disabling the call to it and seeing if it still crashes.

Also, I just noticed the "else return" bit in your Bump() proc. That shouldn't be there.
Aug 21 2010, 1:58 pm
In response to Garthor
Hmmm, oddly enough, I just tried it without the s_damage call 'n' it worked without a hitch... Thanks anyway.
Aug 21 2010, 2:14 pm
In response to YoukoSieg
Why yes, it is incredibly odd that disabling what I suspected to be the problem results in the problem going way.

What a world, what a world...

I posed a quick fix for s_damage at ID:716166
Aug 21 2010, 2:26 pm
In response to Garthor
Ya' know, I did say earlier that I've used s_damage in a older version of the source and it HAS worked. Which is why I find it odd that s_damage is the problem.... So there's no need to be sarcastic like that.

Either way, thanks for your help.