Doom3world

So sometimes scripts, particular AI scripts, can become very large and slow. and even then they're not very powerful, and it becomes quite tedious to add a zillion script events. for these reasons (and possibly more) I decided to try to take some AI and throw it all into the SDK with no script object at all. This wasn't such a hard thing to do, but one real issue I came across was the waitFrame() and sys.wait() script events. they halt the execution of the script and let the game continue what it's doing, and resumes at a later time. the SDK can't just stop execution, or "resume" into a function somewhere after returtning. and we can't just call gameLocal.RunFrame() because that'll cause all kinds of problems and concerns (I won't go into detail with my endeavors there)

So here's my solution - a working waitFrame() macro which utilizes computed goto()s. all you have to do is call evalWaits() before anything else in a function, make all the variables you're going to use after the waitFrame() static so they retain their values (which is a bit ugly, I admit), and add two small private member variables.

Here is a proof of concept:

of course, I might have to make the entity not execute that particular function for that frame, or something, so it doesn't get executed during the RunFrame... but. yeah.

Thanks for sharing the idea!

Anyway I've a question: why don't you simply use the Think function, that is already called every frame?
I think that if you feel the need to wait in the SDK, you are doing something... "wrong": you could probably do the same thing with a function meant to be called every frame.

I know it could change how AI works a lot, but wouldn't the code be much more clear?

Btw, once I had to rewrite all weapon scripts for my mod: I had to turn every extra thread in functions called every frame (because ROE bullet time does not like threads in scriptobjects too much, so I had to remove them).
I was not that hard and I really felt that every problem can be handled in both ways.

you cant call think because it wont call think for every other entity, and all the other stuff that needs to get done duringa frame. the stuff that gameLocal.RunFrame() does. also calling the Think() might potentially execute the same function that called Think(), resulting in an infinitely deep function call loop. avoidable, and obvious when it happens, but still something to be concerned about.



to add to my top post for the waitFrame() thing, you'd also have to halt execution of the main AI function (which you'd create to replace UpdateAIScript() ) right after the function which called waitFrame(). to do that, you'll have to return and be able to resume where you left off after you return to the function that called waitFrame(). you'll have to skip executing the code you already executed at the beginning of the function which calls the waitFrame calling function... also to consider is return variables.

this is getting real messy.


everything you could do with this could be done with a simple float nextExecute = gameLocal.time + DELAY; sort if business, but I'm interested anyhow

I know, but this intrigues me

for a REALLY whacky idea, you could goto() one of the parent functions (maybe need to use asm for this being that the line is out of scope) instead of return;ing after the waitFrame(). before doing that you'd need to pop the local variables off the stack with asm and push them into a static linked list. then also pop off the function prelude and store it in a separete static linked list. restore the frame pointer to the stack pointer.

voila.

when the AI main function decides it's time to go back into the function that called waitFrame(), push the function prelude and the local variables back onto the stack. change the frame pointer back to original.

voila again.

this would solve the issue of worrying about return values for functions that call waitFrame() as well as the prevention of execution of the rest of parent functions.

you'd also need to push variables for parent functions of parent functions, which aren't really accessible. thats the only catch I see, but this is a wild idea.

do I sound crazy yet?


edit: I think I'm going to make a project of this and see how far I get - not for Doom3, but just the idea of "Deferred function execution."

It's really hard to understand everything you're talking about, but why didn't you just give a look at the Q4 AI (sdk)?
(Raven removed AI scripts and coded everything back into the SDK.)

that's incorrect, actually. Raven DID put a lot of the functionality back into the SDK, but there certainly are scripts in Quake 4. for example, the animation is all controled via script. I don't know what else, though. haven't touched it much.

Ho ok, i didn't looked much into it.