I don't get any lag. However in your Shield task you do ascent(i in 0..65){ ObjRender_SetScaleXYZ(ielD, sc, sc, 0); } which just does the same thing 65 times.
As for the second thing, I've identified that what's happening is that you are calling CreatePlayerShotA1 in VaniBulletA1 and then are immediately checking its coordinates to set mx and my. This should be fine assuming that CreatePlayerShotA1 actually returns a valid object, but in this case it does not. In fact, it doesn't even return ID_INVALID (-1); it looks like if player shots are forbidden, CreatePlayerShotA1 doesn't return anything, which means the variable ParentShot isn't set to anything at all, leading to errors. That's mkm's mistake.
There's more to this though. When do you forbid player shots? On EV_PLAYER_SHOOTDOWN. Now you would think that VaniBulletA1 shouldn't be run if the player is dead, but that isn't the case; you check Obj_IsDeleted(ID), which is not a check for the player being dead. On top of this, even though your options get deleted when the player is supposed to die, your loop for this is:
while(!Obj_IsDeleted(Option)){
if(!yetAlive){
Obj_Delete(Option);
}
// stuff being run
yield;
}
So what's happening is that the player gets shot down, yetAlive is set to false in the event, this loop resumes, the option object still exists so it runs the loop, deletes the option because yetAlive is false, then still runs whatever was in the body of the loop, including your player shot logic. So even though the player is dead and shots are forbidden, VaniBulletA1 runs anyway and the above error happens.
There are a couple main things to fix; one is that when you delete your Option object you should end the task immediately with return or do something similar. The other is that even if you changed your condition for player shots to check if the player has died, the error will still occur if the player is ever alive and shots are forbidden. So the condition to shoot should include IsPermitPlayerShot() somewhere.