No Topic

ID:141270
 
Apr 30 2009, 3:00 pm
Code:
runtime error: Cannot modify null.Frozen.
proc name: DeathCheck (/mob/proc/DeathCheck)
  usr: Forerunnerz (/mob/create_character)
  src: Forerunnerz (/mob/create_character)
  call stack:
Forerunnerz (/mob/create_character): DeathCheck(null)
Forerunnerz (/mob/create_character): Punch()


Problem description: The following only happens to NPC's: When NPC's get deleted the "DeathCheck()" still checks if the enemy is frozen and sometimes if the enemy is dead or alive. How would I set it so if the enemy is dead before the proc, the proc doesn't activate. I tried "if(M)" but it also came with a null runtime error. Is it even possible to fix this?

Apr 30 2009, 7:57 pm
if(!M) return
Should actually work.
Please post the relevant code so we can see if it is being applied correctly?
May 1 2009, 8:11 am
In response to AJX
AJX wrote:
if(!M) return
Should actually work.
Please post the relevant code so we can see if it is being applied correctly?

I used a similar code. Here is the DeathCheck() proc. It's still getting the runtime error:

mob
    proc
        DeathCheck(mob/M)
            if(M.BP<=0)
                if(M)
                    M.BP=0
                    M.Refresh()
                    M<<"You were knocked out!"
                    src<<"You knocked out [M]!"
                    M.Frozen=1
                    sleep(70)
                    if(M.Frozen==1&&M.BP==0)
                        M.BP=1
                        M.Frozen=0
                        return
                else
                    return
May 1 2009, 9:07 am
In response to Forerunnerz
Well your Deathcheck is the other way around (src should be the one dying, argument supplied the killer)

You're if() checking for boolean (false/true) variables in an ugly way.
if(variable == 1)
//Change to
if(variable)

if(variable==0)
//change to
if(!variable)


And you're getting that runtime error because you're deleting M somewhere, and then trying to change its variables. An easy solution is like AJX said, add a
if(!M)return

after the sleep(70).
May 1 2009, 9:33 am
In response to Mysame
Mysame wrote:
And you're getting that runtime error because you're deleting M somewhere, and then trying to change its variables. An easy solution is like AJX said, add a
if(!M)return

after the sleep(70).

He's correct there. Your first check (if(M)) is being done and then you are sleeping for 7 seconds. If the M is deleted in those 7 seconds it will *NOT* go back in time and make that if() statement false. You need to do another if(M) check after sleep(), best if immediately after.
May 1 2009, 11:02 am
Maybe its best if you change this too.
mob
    proc
        DeathCheck(mob/M)
            if(M.BP<=0)
                if(M)

To this
mob
    proc
        DeathCheck(mob/M)
            if(M)
                if(M.BP<=0)

First checking to see if M is there instead of checking Mīs BP var.
May 1 2009, 11:48 am
In response to AJX
Thanks everyone. I used all your help. I changed all the "if(variable==0)"'s and the "if(variables==1)"s. They were just bad habits. I also fixed the if(M) to work now. Now my game is almost completely glitch free except for an overlay that won't delete after logging in. Any help on that? Don't wanna start a new thread.

src.overlays-=/obj/Kame

When I use my move, It creates a "Kame" and it deletes if you finish the move but if you glitch it by logging out while charging it, then when you log back in the /obj/Kame is still on you as an overlay and won't delete with my refresh proc below which is located in the Login code. Also, I even tried the refresh verb, it doesn't seem like it's deleting the overlay but all my variables are fixed. Here's the code:

        Refresh()
            src.Doing=0
            src.Delay=0
            src.Frozen=0
            src.ReadyK=0
            src.Resting=0
            src.Flying=0
            src.RDelay=0
            src.KBDelay=0
            src.ChargingK=0
            src.icon_state=""
            src.Strength=src.MSTR
            src.Speed=src.MSPE
            src.Defense=src.MDEF
            src.Reflexes=src.MREF
            src.Intelligence=src.MINT
            src.WT=0
            src.overlays-=/obj/Kame
            src.overlays-=/obj/Kame2
            src.overlays-=/obj/OKB
            src.overlays-=/obj/OKB
            usr.overlays-=/obj/OKB
            src.WT=0
            src.Liftup=0
            src.HM1=0
            winset(usr,"label6","text=\"Stored KI Energy: \"")
            winshow(usr,"default.SKE",0)
            if(src.BP>BPM)
                src.BP=src.BPM
            if(src.Ki>src.MKi)
                src.Ki=src.MKi
            sleep(20)
            src.Frozen = 0


May 1 2009, 4:35 pm
In response to Forerunnerz
The reason for this is when you save and load overlays/underlays when it is recreated you are given 'one' overlay that is really just a compilation of all of them. The only option for resetting this is deleting ALL overlays and starting again. This is why saving/loading overlays/underlays is ill advisable.
May 1 2009, 8:27 pm
In response to Forerunnerz
And just to mention here, in the past I've had problems saving when my Logout() was too large. All those variables, like frozen, resting, doing, delay, etc, just make them 'tmp' variables. These are temporary, and will NOT be saved. When you log in, they'll ALWYAS be the default value.

mob/var/Frozen = 0
// Changes to..
mob/var/tmp/Frozen = 0
May 2 2009, 12:38 am
In response to AJX
Well, that's not really accurate, but these theories about overlays have been circulating for a long while, meh (had nobody ever tested 'em?). IIRC I'm the one that even told you that, because I read it in the forum before. ;D

Well, as for the more correct description...
Basically after you load overlays they sometimes (not actually all of the time) seemingly don't keep track of the 'value' (or appearance) used to create them, and so you can't remove them by conventional methods (i.e. remove a similar/same appearance (through either icon/object/type...) from overlays). Regardless if this is the actual reason or not, they just can't be removed that way.
But the overlays are still separate and can in fact be removed separately by simply looping through the overlays list. I've gone into more detail about this post: [link]

This is why saving/loading overlays/underlays is ill advisable.

Also because that causes you to needlessly save extra icon data (which is already available in your game's RSC anyway), which takes up a lot of space (relatively to numbers/text, anyway) per every atom (with overlays) save as opposed to simply saving identifiers or indicators/flags to help reconstruct overlays later. Sometimes this identifier is already being saved anyway; e.g. equipped... equipment.
May 2 2009, 10:53 am
In response to Kaioken
Kaioken wrote:
Well, that's not really accurate, but these theories about overlays have been circulating for a long while, meh (had nobody ever tested 'em?). IIRC I'm the one that even told you that, because I read it in the forum before. ;D

Possibly. I just remember reading it in some other thread, and I felt like repeating it.