UNITAF Future
UNITAF

Caution

This site is a work in progress

This site is finished to different degrees. Feedback is welcome. Please bear in mind that most of what you see, if not everything, is still a work in progress.

Data from the live site is synced here every hour. Anything you do on this site stays here. It is not copied back to the live site until we switch over.

Discord and permissions are linked. Be careful with admin actions. Some of them also change Discord.

UNITAF members taking orders before an operation
Force Manual

The FM outlines our core skills, policies and guides to ensure every member stands ready for the mission ahead.

All platforms Arma 3 Arma Reforger Arma 4 By role

FM/BG-747 · v1.01

Object locality

Code
FM/BG-747
Kind
Guide
Version
v1.01 1yr ago
Views
354
Platforms
As its document
Published by
SPC Vyqe 10 Dec 2024
Last material change
v3.00 Removed Headless Clients

168 words added, 191 words removed.

Every object in Arma has In Arma, all objects have a locality: locality, which refers to the client that owns it. This in possession. It can be the server, a headless client (HC), or a player client. The locality of the object determines Locality will determine where the following calculations happen for that specific object: particular object run, including: Hit registration registration: Whether shots land and do their damage. Physics (vehicle steering, collisions,…) Physics: How vehicles steer, collide, and interact with the physical world. AI behaviour (movment, spotting,…) Behaviour: Handles movement, spotting and decision-making. Why care about locality matters All Non-local objects that are non-local (except for a special type called "local only" objects) have to be synchronized to synchronised across all other clients to exist. This means they need to be sent Synchronisation involves sending information to the server, and then from the server and redistributing it to all other clients. The longer this takes, the more “out of sync” the object becomes on other clients, causing issues like bad hit registration and teleporation. Another thing to keep Delays in mind is that some doing so may lead to: Bad Hit Registration: Shots not registering or registering wrong. Teleportation: Objects or units seemingly jump around. Some scripts require also need to be run where the object is local to work, or some executed only work when the locality is the server. This is the reason for the three options: where appropriate, that is: Global execution: run Execution: Runs on all clients every client at the same time. Local execution: run Execution: Runs only on the client that which owns the object object. Server execution: run Execution: Runs only on the server server. Headless clients Clients (HCs) As stated above, Headless clients take some load off the server CPU because AI behaviour runs calculations are done on the client that owns its side and the AI object. This explains how headless clients help achieve better server performance, as can handle just the game logic. AI calculations can be are offloaded to another client. However with this performance boost, comes a tradeoff: it takes longer to sync the object to the player clients, as client which owns the AI object. Tradeoffs of Using HCs While HCs offer better performance, they introduce some additional synchronization latency. The sync path is now HC<->server<->player instead of just server<->player. goes through HC ↔ server ↔ player, which may cause delays. To minimize the impact of this, headless clients need to alleviate this HCs should be run on the same physicial physical machine as the server, so that server to reduce network latency is nearly 0. latency.

Where it appears

Lives in

FM/G147 Underlying Arma mechanics

On role cards

On 8 role cards in 1 combat area.

Named on

The other 4 roles read it through these cards.

By combat area