I think I like your second suggestion better. At the very top of each UDF, it could just establish the next entry point in the queue. Then if there is an early exit (such as dead or disabled) I don't have to worry about looping through setting up the next queue entry in the parent quest script.

If an actor is marked as invalid or to be deleted, the UDF will just be skipped an the actor will naturally get dropped off the list.

I'm still not sure what to do about dead actors though. Once an actor is dead, most of the UDFs and scripting would be ignored, and I'd hate for there to be constantly queued up items that are unnecessary. But I also have to take into account the possibility of an actor being resurrected.

I suppose I could have two queues: one for dead, one for not-dead. Whenever there is an "on death" event, the dead actor would be added to the dead queue. There is only one UDF for the dead queue, and it's only 30 lines of code that needs to be updated every .1 seconds. The live queue will naturally filter itself out because there would be an early return if "get dead" is true.

saebel, from what you mentioned in post #22:

If you only care about high processing actors, I do not see any reason to add/keep the other actors in the queue.

When you check the high actors (every 5 seconds, maybe?) you could adjust the queue, adding the new ones and removing the missing ones.

Or, maybe better, you could, then, rebuild the whole queue from scratch with the actual, current high actors.

(not really sure about the above, since you did mention other processes with larger intervals)

From the following posts, I like snazzyCM;s suggestion and your idea of the UDF returning the timeframe of the next check. This way you keep all the queue handling in one place, which seems a good practice. You may use a return = 0 to say that the actor should not be put back in the queue (maybe a -1 to add him to the dead queue, in case you adopt it).

The larger intervals do become problematic.

However, I do feel as though I am almost at a solution. It's just barely out of my reach.

If I come up with something snazzy (forgive the pun), I'll be sure to post it here.

One thought I just had was to have three queues:

- Active High Processing

- Dead High Processing

- All others / back burner

If an actor is not high processing, they will be added to the "back burner" queue (if not already on it) and filtered out of the active queue. It's just a matter of checking it every so often to see if any of them are back to high processing. In theory that could be done whenever the system looks for new actors. Whenever an actor gets bounced back into the active queue, then all of the UDFs would run once, and then be added to the active queue accordingly.

Either that or go with the other suggestion which just refreshes the entire high-processing actor list and just automatically reset all timers. But with the longer interval checks, there is the potential issue of gaps where either new people are skipped or longer interval processes get skipped. I would probably have to do a comparison of the existing queue with new list, and that could be a bit of a pain since the actor refs are buried a few layers deep in the queue array.

Anyway, I will need to work on this some more. Thanks very much to everyone for the ideas and feedback. I think I have a solid grasp of the various suggestions, and now it's just a matter of experimenting with them to see if I can come up with something that will work.

???

So far this thread is full of snazzier coders than myself, so I wouldn't be surprised if you did.

?

For what it's worth, the multi-queue approach sounds fine to me, specially if you adopt the first ideas suggested by QQuix. You could keep the high-processing queues running in GameMode and the backburner exclusively in MenuMode, for example.

?

I admit I even learned a couple of things in the process, so I'll gladly try to keep joining these discussions as long as you continue to be open to suggestions.

Generally speaking, I'm usually open to suggestions. Whether I use them or not is entirely different matter.

I am especially open to techniques that can improve performance. Design/formula/feature suggestions depend on whether or not the suggestion falls in line with the vision of the mod and makes it better or not.

There is a long list of folks who have my thanks in the credits, and their suggestions/assistance are one of the main reasons why I consider SDR to be as good as it has been and will be.

Edited my post, thanks.