What is the correct term for a "script processing slot"?

For AI and campaign script related discussions and questions
Post Reply
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

What is the correct term for a "script processing slot"?

Post by aubergine »

The JS environment isn't threaded... instead, when an event is triggered, the associated event handler code runs but in a "blocking" fashion (the rest of Warzone is paused and only resumes after the event handler has finished processing).

If I understand correctly, in one of these processing slots, several events might be fired. I don't know if each script has it's own allocated processing slot schedule, or whether events are just queued up and then triggered in sequence in the relevant JS env associated with the player the event is for?

Anyway, I'm trying to think of a correct term for these processing slots, the windows of processing time allocated to scripts. Is there a proper technical term for them?

Also, is one player script processed at a time, or is it sort of random and queued events are triggered one after the other against the relevant player script?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: What is the correct term for a "script processing slot"?

Post by Per »

It is definitely not random. However, from the script writer's perspective, no particular order should be assumed, since it may change.

Script events are fired from the C++ whenever appropriate. They are not presently queued, nor sorted.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: What is the correct term for a "script processing slot"?

Post by aubergine »

So as soon as an event occurs in the C++ code, the JS for that player (if it has a listener for that event) is invoked?

Can gameTime increment between events? So, say I listen to eventAttackedUnthrottled() and a group of my droids gets plasmite dumped on them... Would all those eventAttackedUnthrottled() events occur at the same gameTime?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: What is the correct term for a "script processing slot"?

Post by Per »

aubergine wrote:So as soon as an event occurs in the C++ code, the JS for that player (if it has a listener for that event) is invoked?
Yes.
aubergine wrote:Can gameTime increment between events? So, say I listen to eventAttackedUnthrottled() and a group of my droids gets plasmite dumped on them... Would all those eventAttackedUnthrottled() events occur at the same gameTime?
For the moment, yes, but do not assume that going forward. I may one day add load balancing to events to spread them out over multiple frames.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: What is the correct term for a "script processing slot"?

Post by aubergine »

If we can get the objOnMap(id,type,player) function in the 3.1 branch, I can implement load balancing in JS.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
raycast
Trained
Trained
Posts: 131
Joined: 12 Sep 2012, 19:16

Re: What is the correct term for a "script processing slot"?

Post by raycast »

The following code might be a solution for "CPU hungry" AIs:

You schedule a callback to be invoked for each object.

The main game engine does the object loop, and invokes a callback function for each object once. Then, at the very end, a "completed" callback. The main game engine is allowed (and somewhat even encouraged) to spread out the callbacks over multiple frames.

From a JS perspective, it would be something like

foreachObjectAsynchronous(id, type, player, callback_foreach, callback_completed);

where the last two would be javascript functions. Commonly, callback_completed would be used to either restart the whole thing, or remove a lock, so it can be triggered again.

When the engine detects the AI takes too much time, it would increase a multiplier, and instead of iterating over all object every frame, iterate only over half of them, a third of them etc. There is some difficult stuff to do here: e.g. what if an object gets destroyed or created while the iteration is incomplete. But this can be solved.
User avatar
bendib
Regular
Regular
Posts: 1011
Joined: 29 Aug 2010, 05:22
Location: Imeuta
Contact:

Re: What is the correct term for a "script processing slot"?

Post by bendib »

Perhaps I'll move the JS engine to a thread if it's not in one already, for Legacy that is. The game UI shouldn't freeze solid because of an AI script. I'll also try to add threading to the scripts.
Also known as Subsentient.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: What is the correct term for a "script processing slot"?

Post by aubergine »

@raycast - I already have a rudimentary class called "GO" that does something very similar - I dump game objects in to it (of any kind) and then start iterating over them. The function processing the objects can store data on the GO object (which is just a glorified array) and if it runs out of time it will yield (not the JS yield tho - that's not available in current WZ JS env) and resume the iteration a bit later after giving WZ a chance to get some other stuff done, thus avoiding game lag. It's one of the reasons I've always been interested in functions like objFromId() and the proposed objExistsOnMap() (or whatever it will be called) as they allow me to check if a game object is still valid. I'm currently tweaking the way I allocate processing time -- I was using gameTime but I think I'm going to switch to using real-life time as that progresses at a more constant rate.

@bendib - I'm not sure that would solve anything, and in fact it might just make matters even more complicated.

@all - I should note that the JS environment has good performance (it does a very good job of optimising JS) and tasks rarely take more than a few milliseconds to complete. The main reason I'm working on spreading code over multiple processing slots is that there are a few crazy things I want to do which involve building and processing an array of about 65,000 objects -- it doesn't actually take that long, I just don't want it to cause game lag. Also, later in the game when players have lots of droids and defence structures, the cumulative arrays of game objects can get pretty big, especially on 10 player maps where there are 9 other AIs processing the same lists at the same time. That issue will be pretty much eradicated once the new enumRange() and enumArea() functions arrive.

So don't bust guts over threading and stuff like that, most AI's are not going to be quite as insane as mine.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
raycast
Trained
Trained
Posts: 131
Joined: 12 Sep 2012, 19:16

Re: What is the correct term for a "script processing slot"?

Post by raycast »

@bendib: Javascript isn't really about threading. That can screw up things badly. In particular, it will then need much more synchronization, and can cause various errors. Like you retreive an object, but by the time you want to query some property of it, it already no longer is on the map and was invalidated etc.

Just look at the various JS databases. Node.js, does it by now support multi-threading?

Starting threads is easy. Getting threading work right and reliably is a pain. In particular when you don't rely on Garbage collection to clean up after you.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: What is the correct term for a "script processing slot"?

Post by Per »

raycast wrote:The following code might be a solution for "CPU hungry" AIs:

You schedule a callback to be invoked for each object.
There is already the queue(function[, milliseconds[, object]]) function for precisely that purpose. Load balancing events automatically over multiple frames is on my TODO list.
User avatar
bendib
Regular
Regular
Posts: 1011
Joined: 29 Aug 2010, 05:22
Location: Imeuta
Contact:

Re: What is the correct term for a "script processing slot"?

Post by bendib »

raycast wrote:@bendib: Javascript isn't really about threading. That can screw up things badly. In particular, it will then need much more synchronization, and can cause various errors. Like you retreive an object, but by the time you want to query some property of it, it already no longer is on the map and was invalidated etc.
I had error reporting more in mind, rather than a hard lockup. Perhaps the game should pause like it does for bad pings to allow the game to catch up? I just am vehemently against the game bricking solid every time it encounters a boo-boo, something I have yet to eradicate from such simple matters as a bad lobby server refresh. Running a bunch of scripts in the master thread just smells, tastes, and feels like a bad idea. These are the things used for AIs and game setup scripting, and they shouldn't bring the game to it's knees so you can't even unlock your cursor. I am quite fast to admit I have yet to find a viable solution to this problem.
Also known as Subsentient.
Post Reply