Code in hit proc
Seems that code inside a monster's hit procedure is run before hitpoints are deducted from the monster. Is there a way to run code after the hitpoints are updated?
Nevermind, wait(30); seemed to do the trick. It's still a bit unreliable, though... And what's the logic in that 30? It didn't work if the wait was shorter than that.
Seems so, but why? Wait(1); is usually enough to let other scripts do their stuff first before continuing.
Actually, I don't think wait(1); is usually enough.
It should be. Taken from DinkC Reference:
"...So any wait(), even a wait(1), makes a script "yield the floor" to other active scripts to allow them time to finish or at least get to their own wait() points before this script is resumed."
So wait(); isn't just a delay, it pauses the script and lets other scripts run their stuff. Wait(1); usually solves quite a few problems with script execution, for example, in cutscenes with screenchanges and screen base scripts.
I can't figure out why wait(30); works in this case, and wait(1); doesn't. Basically, is wait(4); the same as four consecutive wait(1)s or not?
"...So any wait(), even a wait(1), makes a script "yield the floor" to other active scripts to allow them time to finish or at least get to their own wait() points before this script is resumed."
So wait(); isn't just a delay, it pauses the script and lets other scripts run their stuff. Wait(1); usually solves quite a few problems with script execution, for example, in cutscenes with screenchanges and screen base scripts.
I can't figure out why wait(30); works in this case, and wait(1); doesn't. Basically, is wait(4); the same as four consecutive wait(1)s or not?
Sorry, I'm pretty bad in DinkC. I can mae a good D-Mod. But I usually make them with pretty standard scripts.
Here's how I would imagine it: Wait(4) pauses the script for 4 thousands of a second and then gets back to it. Four wait(1)s pauses the script for a thousandth, gets back to it, pauses the script for a thousandth, gets back to it, pauses the script for a thousandth, gets back to it, pauses the script for a thousandth, gets back to it. Having lots of waits might show in the game's performance, similar to how loops with a very short amount of wait can slow the game down considerably (on a crappy machine, like my laptop).
The problem might be with some kind of internal timer, like with the shadow brain. If you kill the sprite the shadow is attached to, it takes a while before the shadow dies.
The problem might be with some kind of internal timer, like with the shadow brain. If you kill the sprite the shadow is attached to, it takes a while before the shadow dies.
I don't believe there are any internal timers like that.
Don't use wait(30). Use two wait(1)s. If that is not reliable, use three. (But I think 2 will do.)
4 wait(1)s is not the same as wait(4).
This is what wait does:
Do all other tasks in the que
IF the time is up, then return, otherwise wait until it is
You should be able to see from that that wait(0) could be used instead of wait(1).. You want to use wait to allow the other tasks to be executed, not so much to "wait".
I've got stuff very similar to what you want to do in my tutorial.
Don't use wait(30). Use two wait(1)s. If that is not reliable, use three. (But I think 2 will do.)
4 wait(1)s is not the same as wait(4).
This is what wait does:
Do all other tasks in the que
IF the time is up, then return, otherwise wait until it is
You should be able to see from that that wait(0) could be used instead of wait(1).. You want to use wait to allow the other tasks to be executed, not so much to "wait".
I've got stuff very similar to what you want to do in my tutorial.
Yeah, I thought so, but the 30 instead of 1 seemed a bit strange. Wait(1) (and wait(0)) had always worked before. Maybe I'll try to use two wait(1)s, thanks. 
