The FM outlines our core skills, policies and guides to ensure every member stands ready for the mission ahead.
FM/BG-747 · v2.00
Object locality
- Code
- FM/BG-747
- Kind
- Guide
- Version
- v2.00 1yr ago
- Views
- 352
- Platforms
- As its document
- Published by
- SPC Vyqe 17 Dec 2024
- Last material change
- v3.00 Removed Headless Clients
271 words added, 0 words removed.
v1.01
In Arma, all objects have a locality, which refers to the client in possession. It can be the server, a headless client (HC), or a player client. Locality will determine where calculations for that particular object run, including:
Hit registration: Whether shots land and do their damage.
Physics: How vehicles steer, collide, and interact with the physical world.
AI Behaviour: Handles movement, spotting and decision-making.
Why locality matters
Non-local objects (except for "local only" objects) have to be synchronised across all clients to exist. Synchronisation involves sending information to the server and redistributing it to other clients. Delays in doing so may lead to:
Bad Hit Registration: Shots not registering or registering wrong.
Teleportation: Objects or units seemingly jump around.
Some scripts also need to be executed only where appropriate, that is:
Global Execution: Runs on every client at the same time.
Local Execution: Runs only on the client which owns the object.
Server Execution: Runs only on the server.
Headless Clients (HCs)
Headless clients take some load off the server CPU because AI calculations are done on its side and the server can handle just the game logic. AI calculations are offloaded to the client which owns the AI object.
Tradeoffs of Using HCs
While HCs offer better performance, they introduce some additional synchronization latency. The sync path now goes through HC ↔ server ↔ player, which may cause delays. To alleviate this HCs should be run on the same physical machine as the server to reduce network latency.
v2.00
In Arma, all objects have a locality, which refers to the client in possession. It can be the server, a headless client (HC), or a player client. Locality will determine where calculations for that particular object run, including:
Hit registration: Whether shots land and do their damage.
Physics: How vehicles steer, collide, and interact with the physical world.
AI Behaviour: Handles movement, spotting and decision-making.
Why locality matters
Non-local objects (except for "local only" objects) have to be synchronised across all clients to exist. Synchronisation involves sending information to the server and redistributing it to other clients. Delays in doing so may lead to:
Bad Hit Registration: Shots not registering or registering wrong.
Teleportation: Objects or units seemingly jump around.
Some scripts also need to be executed only where appropriate, that is:
Global Execution: Runs on every client at the same time.
Local Execution: Runs only on the client which owns the object.
Server Execution: Runs only on the server.
Please note that using the “Local Only” option on an object should be avoided, as it significantly impacts the server performance.
Headless Clients (HCs)
Headless clients take some load off the server CPU because AI calculations are done on its side and the server can handle just the game logic. AI calculations are offloaded to the client which owns the AI object.
In UNITAF we are using Zulu Headless Client (ZHC) mod, that allows the Game Masters to be better informed about the performance impact their mission has. ZHC uses multiple ways of communicating the performance hit.
On the bottom right of the in-game map every player has an information about the number of active HC, and the server performance:
The information contains the name of the Headless Clients, its performance graded in frames per second (fps), and how many local units have been transferred to it.
The information is colour coded:Green text indicates that the HC is performing well, and above 30 fps.
Yellow text indicates that the HC is struggling, and its performance is between 20 fps and 30 fps.
Orange text indicates that the HC is performing unwell, and its performance is between 10 fps and 20 fps.
Red text indicates that the HC is performing very bad, and its performance is below 10 fps.
Additionally the Game Masters have an access to the per AI group information displayed above the AI groups if the Debug Mode is activated:
To Toggle Debug Mode you have to press a key combination. By default it's “Ctrl+]”
The information is colour coded. The colours correspond with what the unit is offloaded to:Yellow icon indicates a group that hasn't been transferred yet.
Red icon indicates a group that is transferred to the server.
Green icon indicates a group that is transferred to the Headless Client.
Pink icon indicates a group that is local.
Tradeoffs of Using HCs
While HCs offer better performance, they introduce some additional synchronization latency. The sync path now goes through HC ↔ server ↔ player, which may cause delays. To alleviate this HCs should be run on the same physical machine as the server to reduce network latency.
In Arma, all objects have a locality, which refers to the client in possession. It can be the server, a headless client (HC), or a player client. Locality will determine where calculations for that particular object run, including:
Hit registration: Whether shots land and do their damage.
Physics: How vehicles steer, collide, and interact with the physical world.
AI Behaviour: Handles movement, spotting and decision-making.
Why locality matters
Non-local objects (except for "local only" objects) have to be synchronised across all clients to exist. Synchronisation involves sending information to the server and redistributing it to other clients. Delays in doing so may lead to:
Bad Hit Registration: Shots not registering or registering wrong.
Teleportation: Objects or units seemingly jump around.
Some scripts also need to be executed only where appropriate, that is:
Global Execution: Runs on every client at the same time.
Local Execution: Runs only on the client which owns the object.
Server Execution: Runs only on the server.
Please note that using the “Local Only” option on an object should be avoided, as it significantly impacts the server performance.
Headless Clients (HCs)
Headless clients take some load off the server CPU because AI calculations are done on its side and the server can handle just the game logic. AI calculations are offloaded to the client which owns the AI object.
In UNITAF we are using Zulu Headless Client (ZHC) mod, that allows the Game Masters to be better informed about the performance impact their mission has. ZHC uses multiple ways of communicating the performance hit.
On the bottom right of the in-game map every player has an information about the number of active HC, and the server performance:
The information contains the name of the Headless Clients, its performance graded in frames per second (fps), and how many local units have been transferred to it.
The information is colour coded:Green text indicates that the HC is performing well, and above 30 fps.
Yellow text indicates that the HC is struggling, and its performance is between 20 fps and 30 fps.
Orange text indicates that the HC is performing unwell, and its performance is between 10 fps and 20 fps.
Red text indicates that the HC is performing very bad, and its performance is below 10 fps.
Additionally the Game Masters have an access to the per AI group information displayed above the AI groups if the Debug Mode is activated:
To Toggle Debug Mode you have to press a key combination. By default it's “Ctrl+]”
The information is colour coded. The colours correspond with what the unit is offloaded to:Yellow icon indicates a group that hasn't been transferred yet.
Red icon indicates a group that is transferred to the server.
Green icon indicates a group that is transferred to the Headless Client.
Pink icon indicates a group that is local.
Tradeoffs of Using HCs
While HCs offer better performance, they introduce some additional synchronization latency. The sync path now goes through HC ↔ server ↔ player, which may cause delays. To alleviate this HCs should be run on the same physical machine as the server to reduce network latency.
Where it appears
Lives in
FM/G147 Underlying Arma mechanicsOn role cards
On 8 role cards in 1 combat area.
Named on
-
Assistant Game Master
Mission Support
-
Game Master (≤15)
Mission Support
-
Game Master (≤32)
Mission Support
-
Game Master (≤64)
Mission Support
The other 4 roles read it through these cards.
By combat area