This article is geared towards more advanced scripting when you also must take into extreme consideration the performance and execution priorities of the ArmA2 engine. Great examples of these circumstances are: missile guidance, "player visible" activities, real-time issues (voice/munitions guidance), and other actual areas within the game that really do require real-time updating and visibility.
Mainly, you run into these kinds of issues when you are working on something that is extremely visible and evident to the player either during its entire execution, or requires immediate feedback to the user. In these areas, using regular ArmA2 scripting *IS NOT APPROPRIATE*. Why do you ask?
When it comes to general ArmA2 scripting and performance, you will never notice performant bugs or issues in normal testing, or even on most normal servers and gameplay. This is because most of these issues only become evident and extremely problamatic in a few rather common scenarios:
1. Low Server FPS
2. Low Client FPS
3. "Broken" missions or addons (extremely script usage, to be explained later)
4. Large amounts of scripts
In all of the above scenarios, you'll notice that suddenly things either don't perform correctly, on time, or just generally "lag". This is mainly due to the script scheduler within ArmA2. That is to say - this is due to the fact that A2 prioritizes what runs and what does, and generally tries to give a fair share of time to everything running, regardless of what its doing. Because of this, you run into some extremely easy-to-notice evidence of performance issues on servers, addons, and missions in general:
1. Bouncy AI
2. Unresponsive user actions
3. Delayed action response
4. In-game watch delay
All of the above are indicative of either lag, incorrect performance, or other issues regarding running scripts within A2. Now - on to the juicy stuff. Lets figure out WHY exactly things slow down in A2 so quickly. And oddly enough, it is not because of AI usually - it is usually because of other reasons.
When originally looking into A2 performance issues, I ran into the massive roadblock working on ACRE. The main issue we ran into is that we (the ACRE devs) suddenly hit a massive problem. Because of the nature of our addon - voice communications - any possible delays, lags, or bugs were extremely and immediately evident. The instant any sort of lag or delay hit, people would notice it ten fold in comparison to any other addon in existence. This was extremely evident in our predecessor - a2ts - and was also really obvious in our early versions.
What this led us to discover, however, is that there are certain characteristics to the A2 scripting engine. There are places you can run code immediately, really quickly, really slowly, and everything in between. Designing things that MUST perform correctly means that considering all of these things is CRITICAL. Within the ArmA2 scripting environment, you are basically dealing with a whole new level of multithreading and pooling, which suddenly completely ruins any of your assumptions of code execution you ever had.
Finally, moving on to the guts of this overview, I would like to begin with an initial preface. Please forget everything you think you know about ArmA2, Programming or the real world. Things perform differently in A2, and here are the considerations you must take in place when dealing with multi-player addons or performance-critical addons.
The ArmA2 scheduler is the number one problem anyone new to scripting, or extremely experienced with scripting, will run into when attempting to perform time critical operations within the game. First, lets describe this exactly. A scheduler is basically a component of an application that determines when, how long, and how much things execute. In regards to A2, this is the actual portion of A2 that determines what scripts run, how often they run, and how much they get to run. This system literally controls ALL scripts running within any given game - in-game scripts, addons, the mission itself, and everything in-between.
Despite popular misconception, there is absolutely no way to set priority for anything within this scheduler. There are, however, ways to get around to. I will cover those later. First - lets actually talk about what this scheduler does. The scheduler itself consists of basically a 3-layer execution, that walks through everything executing within any given game - and runs it. This is pretty simple so far. The 3 layers are:
These three layers get ran, in order, every single "Scheduler iteration". What does this mean? It means you are sharing speed with absolutely everything else running in the game, AI included, at all times.
Execution Order 编辑
Execution Priority 编辑
YAWN! Okay so. Now we understand the scheduler, what it runs, and what order it runs in. Now, though, we need to worry about this most critical thing of the scheduler. Exactly what gets to run and for how long. There is a large amount of scenarios here; I have tried to condense them down into the most commonly used and efficient list possible.
In the scheduler, you currently have the following "methods" or "types" of execution. Basically, these are the different ways you're SQF code gets ran. From this, determines exactly where you live in the scheduler, if at all:
References and Tests 编辑