ID:1588517
 
Not a bug
BYOND Version:506
Operating System:Windows 8 Pro 64-bit
Web Browser:Chrome 35.0.1916.114
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
I was helping somebody in the Developer Help forums and ran into a small issue, I found a work around so it wasn't bad.

Anyway, the game runs the delete command before it runs a command or two before it.

Numbered Steps to Reproduce Problem:
Use this code and compile it and see.

Code Snippet (if applicable) to Reproduce Problem:

 proc
Null_Projectile(atom/A)//obj/A) -- if it's going to effect this object, why bother with the arguments in (), I changed it to be whoever it collided with so you can
//A.icon = null -- replaced with below
//A.loc = null -- replaced with below
src.icon=null
src.loc=null
if(A)
A.overlays += image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
sleep(5)
A.overlays -= image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
del(src) //deletes it from existence to prevent stockpile of objects in the world.


Expected Results:
I expect it to remove the overlays on "A" before the delete command is ran.

Actual Results:
The overlays are applied but are not removed.
Does the problem occur:
Every time? Or how often? Everytime.
In other games? Dunno.
In other user accounts? Yep.
On other computers? Surely.

When does the problem NOT occur?
The problem doesn't occur when I use a sleep() statement like so:

 proc
Null_Projectile(atom/A)//obj/A) -- if it's going to effect this object, why bother with the arguments in (), I changed it to be whoever it collided with so you can
//A.icon = null -- replaced with below
//A.loc = null -- replaced with below
src.icon=null
src.loc=null
if(A)
A.overlays += image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
sleep(5)
A.overlays -= image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
sleep(10)
del(src) //deletes it from existence to prevent stockpile of objects in the world.


Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
As stated above, the sleep() command.

 proc
Null_Projectile(atom/A)//obj/A) -- if it's going to effect this object, why bother with the arguments in (), I changed it to be whoever it collided with so you can
//A.icon = null -- replaced with below
//A.loc = null -- replaced with below
src.icon=null
src.loc=null
if(A)
A.overlays += image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
sleep(5)
A.overlays -= image('Explosion.dmi',icon_state="",layer=EFFECTS_LAYER)
sleep(10)
del(src) //deletes it from existence to prevent stockpile of objects in the world.

I wouldn't be so quick to call this a bug; it's very likely that something else is triggering the delete. Two successive calls to Null_Projectile(), one of which had A=null, would be enough to trigger the issue. I strongly suspect this is a code problem. You'll have to include some debugging output to tell when Null_Projectile is called and when del(src) is called.

For efficiency's sake I strongly recommend storing the result of the image() call in a var and just reusing it. Calling image() twice for something only used as an overlay is a waste. In fact if it comes up often, better to cache the image--or even just cache the Appearance, which you can get by adding it to an overlays list and grabbing the value that actually got added.

Another efficiency improvement is to move the projectile to a null location instead of calling del(src).
^ overall, I agree with the whole image and such.

I create a new datum for overlay effects and such that are already made and are just waiting to be applied to players so there won't be useless junk around everywere xD

From the looks from Debugging, Null_Projectile was being called twice, I guess I overlooked the code and didn't see where the other one was placed.

Thanks for clearing that up :)
Stephen001 resolved issue (Not a bug)