Another safe and efficient way to go is to use user-defined events and have them delay a SignalEvent call to repeat themselves. They are easy to centralize and manage from a single script or two so you can limit the number of additional scripts you have to add to your module like you will eventually get by using delayed ExecuteScript calls all the time...plus Events evoke a context switch too so you won't end up with a memory leak after lots and lots of repetitions like a delayed function can cause. They allow for some added flexibility in implementing your pseudo-hbs as well. For example, if you have a group of phbs that are related and can all be running at the same time, you can create a specific object like a creature or placeable to receive the events and thus operate them. Then, should you ever want to shut them all down at once, all you have to do is destroy the object. The only drawbacks really are that PCs can't be used to run them (a biggie sometimes), and that you have to use local variables to pass data to them...but, of course, you have to do that with executed scripts also. Only delayed functions make it easy to pass data along. If you need to pass something that cannot be stored in a local variable (e.g. an effect), you're stuck with functions. You just can't allow them to run too many times between shutdowns is all..."too many times" being largely dependent on how much data you pass along.
In this instance however, I wouldn't concern myself too much with efficiency or memory leaks building up since whatever method you go with it isn't very likely to ever repeat more than 10 times. For that problem to manifest here, the implementation you use for OnDying would have to allow for bleeding to potentially go on for hundreds of rounds without the guy ever dying or healing...probably not a system most people would use.
Modifié par Axe_Murderer, 12 août 2011 - 09:51 .