ID:273248
 
I know I probably slaughtered this snippet, but anyways; the overlays are setting to null, but it won't add the original overlays back onto the mob prior to the spirit gun charge completion.

                if(usr.Check_User(T)) return
if(usr.Check_Direction(1)) return
usr.frozen = 1
usr.icon_state = "Spirit Gun Charge"
var/overlays = usr.overlays//here
if(usr.dir == SOUTH) usr.overlays += new/obj/Battle/Spirit_Gun_Charge_South
if(usr.dir == NORTH) usr.overlays += new/obj/Battle/Spirit_Gun_Charge_North
if(usr.dir == EAST) usr.overlays += new/obj/Battle/Spirit_Gun_Charge_East
if(usr.dir == WEST) usr.overlays += new/obj/Battle/Spirit_Gun_Charge_West
sleep(24)
usr.overlays = null//here
usr.overlays += overlays//here
usr.icon_state = "Spirit Gun Shoot"
spawn(4) usr.icon_state = ""
usr.frozen = 0
if(usr.isHuman) usr.spirit_energy-=rand(2,6)
if(usr.isDemon) usr.demon_energy-=rand(2,6)
view(usr)<<output("[usr]: Spirit Gun!","Combat")
var/obj/Battle/Blast/Spirit_Gun/B = new(null,usr)
walk(B,B.dir,B.delay)
usr.Cool_Down(T,T.initial_cooldown)
else return
There's no need to have the new there. You're just adding the object to your overlays. Also it'd be wise not to overuse usr so much, but instead to use src. I know that'd be a lot of code editing on your part though...
In response to Fugsnarf
Thanks for the uplift. Anyways, are you saying I should simply do

src.overlays += /obj/Battle/Spirit_Gun_Charge
In response to Dark Prince X
Yes.
In response to Fugsnarf
It can be a problem because of the New Update? the Isometric and that?
Dark Prince X wrote:
the overlays are setting to null, but it won't add the original overlays back onto the mob prior to the spirit gun charge completion.

(I don't think you meant "prior to" there.)

This fails because setting a built-in list's var to a different value doesn't actually affect the var's value, like it does with normal vars. Instead, it always affects the list itself instead. In other words, these vars are actually read-only (but misleadingly allow to attempt to modify them) and their values are static.
Setting a built-in list var to any value other than a list simply results in the special list being cleared (same effect of List.Cut()). Setting one to a list causes the special list to be cleared and then adds the other list's contents into it.

To conclude, this approach would work with objects stored in normal vars, but it can't work with those stored in special (namely, read-only) vars. To simulate the same results in those cases, you'd need to store a copy of the special list before you inevitably clear it, then use that copy to restore the old list contents.
In response to Revolution Naruto
..No
In response to Kaioken
Thank you.