Mission Support Observer Handbook

---

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

Your role access is determined by your skills, experience with those skills, and the specific roles that utilize them. With over 100 roles in UNITAF, creating detailed skill breakdowns for every role is a substantial undertaking that cannot be completed overnight. 

Estimated Role Cards

To ensure the entire unit can transition to the new system immediately, some roles are tagged as **"Estimated"**. These roles use a transitional approach:

• Temporary skill blocks simulate role-specific experience
• Estimated access levels are calculated based on these placeholder blocks
• Similar to LTS functionality but with improved accuracy and fewer limitations

Current State: Estimated roles provide functional access levels that closely mirror the previous LTS system while addressing many of its shortcomings. As development progresses, estimated role cards will be upgraded to the full FTS3 standard with detailed, role-specific skill requirements.

Important Note: When roles transition from "Estimated" to "Verified" status, your access level may change (either increase or decrease) as the requirements become more precise and role-specific.

This approach allows UNITAF to:

• Maintain operations during the transition period
• Provide immediate access to the improved FTS3 system
• Ensure continuity while detailed role cards are developed
• Gradually improve role accuracy over time

The estimated system serves as a bridge, ensuring no disruption to unit operations while we build toward the comprehensive FTS3 vision.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as any Game Master role until it's role card is completed.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as Lead Game Master until it's role card is completed.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as any Roleplayer until it's role card is completed.

This is a block which allows players to gain experience at the <15 level of Lead Game Master.

This is a block which allows players to gain experience at the <32 level of Lead Game Master.

UNITAF operations follow a strict framework which is outlined in this section. Ultimately the goal of standardisation in UNITAF is to ensure in our system of dynamic ORBATs that standardisation is maintained across all operations so players know what to expect when joining, preparing, planning, gearing out and executing UNITAF operations. This standardisation encompasses but is not limited to;

• What factions can be played
• Duration of missions
• SOP standardised ORBAT organisation
• ORBAT restrictions
• Equipment restrictions
• Database integration
• Limited arsenals

All UNITAF operations use a database framework which ultimately issues standard loadouts to players based on database driven loadouts directory. The framework can be obtained from Operations Command (OC) or Operations Staff (J3) a template is provided and can be copied to your desired maps.

For a mission to be approved, it must follow the framework, in order to follow the framework it must be in line with the following;

• Full arsenals are not to be used under any circumstances, this means;
  • Arsenal content is dictated by the Framework and restricted per the content provided to it by Loadouts Staff (J5) in accordance with FM/C110 - Loadouts and Factions
  • Arsenals with unrestricted content, or not utilising the Framework are not permitted.
• Loadouts should be attainable through the framework ORBAT injection system and must be approved by Loadouts Staff (J5)
• All mods must be on the UNITAF approved mods list
• The faction players are deploying as must be an approved faction
  • Approved factions have limited arsenals prepared already according to that factions equipment
  • Approved factions have default loadouts created for all combat positions that can be ORBAT deployed
  • If a faction is not on the approved factions list, then the faction must be created before the mission can be approved
• The mission file with integrated framework should be ready and tested, prior to the ORBAT being released.

• Theatre Operations must be named using the format:
  • Operation [Name] [Roman Numeral] (e.g. Operation Overlord I).
• The operation name must remain unchanged for all deployments within the same operation.
• If the mission is a one-off operation, there is no requirement to use a Roman numeral.
• The Roman numeral must increment sequentially for each deployment within the same operation.
• The maximum number of deployments within a Theatre Operation is 10, anything beyond this should be submitted to J3 as a campaign.
• The first deployment of an operation must use Roman numeral I.
• Each subsequent deployment must increase the numeral by one sequential value.
• Subtitles, additional descriptors, or secondary naming elements are not permitted.

Conduct a pre-deployment briefing for the Mission Support Team, ensuring all members are well-prepared for their roles. The briefing shall include:

• General overview: Summarize the overall mission plan and objectives.
• Pacing expectations: Communicate the expected flow and tempo of the mission to align team efforts.
• Task assignments: Clarify the responsibilities and expected contributions of Game Masters (GMs), Assistant Game Masters (AGMs) and roleplayers.
• Faction details: Provide the names of:
  • Friendly faction(s) units and role within the mission, 
  • Opposing faction(s) units and the allowed units and vehicles they are to employ.
  • Neutral faction(s) units including any approved units and vehicles for their representation.
• Civilian considerations: Identify whether civilians will be present, how they could affect the game, and the general approach expected when interacting with them.

Delegate by assigning tasks to Game Masters and Assistant Game Masters in line with mission needs and their capabilities. Tasks can range from:

• Broad scope: Assign broad responsibilities, such as the management of a certain objective, overseeing a sector, or coordination of a pack of assets.
• Narrow scope could also involve delegation of tasks such as driving a vehicle, operating a single unit, or executing certain in-game interactions.

What is server performance?

An Arma server is an instance of a game without rendering, hence it can perform better in comparison to game clients even on the same hardware. Much like the client, a server's performance is evaluated through means of frames per second (FPS), though on a server "a frame" would typically mean the amount of "game world updates per second.", A concept similar to "tickrate" used in some other games. 

Why care about server performance?

In modern versions of Arma, server FPS no longer directly affects client FPS. However, server performance remains critical to maintaining a smooth and enjoyable gameplay experience. Poor server performance can lead to:

• Bad hit registration: Impacts the accuracy and reliability of weapon fire.
• AI/Vehicle teleportation: Causes erratic movement of units and vehicles.
• Connection stability issues: Results in lag and disconnects for players.

What affects server performance?

Various factors can affect server performance significantly. The following factors reduce the number or frequency of server-intensive processes, leading to better server stability and gameplay experience:

• Entities spawned: Frequent and/or large-scale spawning of units or objects.
• AI units: Great numbers of AI-controlled characters.
• Vehicles: Especially when moving or active.
• Static objects: Too many decorations or functional objects.
• Exploding munitions/submunitions: Explosions or ammunition that have fragmentation or secondary effects.
• Scripted audio: Particularly dynamic/moving audio scripts.

Monitor performance on the server during the mission, performing proactive actions to keep the game flow smooth. This involves:

• Monitor server FPS to spot any potential performance degradation issues.
• Look for causes that contribute to performance degradation due to excessive AI, vehicle usage, or unnecessary static objects.
• Take appropriate action to reduce spawned entities, clean up superfluous assets, and adjust mission parameters.
• Collaborate with other members of the Mission Support Team to implement solutions that prevent performance issues from impacting player enjoyment.

A mission should be planned with some downtime in mind, be it resupply or simply just transit from point A to B. This time allows players to recollect themselves and regroup, and provide a breather in potentially stressful situations. During any downtime, element leaders will be gathering ACE checks and drawing up any battle plan amendments or additions to better prepare for the next engagement.

It’s important to allow time for these brief pauses even if from your perspective nothing is happening often as a MST member the mission can feel slow or boring as a result of your knowledge of the whole battlefield, however, the feeling can be much different from the players’ perspective.

Manage the count of the enemy force to maintain a balance between the following parameters:

• Challenge: The enemy force should be fairly challenging for the player's force and ensure teamwork and strategic thinking from them.
• Player enjoyment: Avoid overwhelming the player force to maintain a positive and enjoyable experience.
• Mission pacing: Time the deployment of enemy forces in concert with the Field Leader's agreed pacing to maintain a consistent flow of action and downtime.
• Server performance: Limit the number of active enemy forces to prevent undue strain on the server, maintaining smooth gameplay.

Distribution of equipment is strictly forbidden except in the following situations, and only with the explicit permission of the Intelligence Officer or the Lead Game Master:

• Missing loadout items:
  • Issuing an item that was accidentally forgotten from the standard loadout.
  • Items intentionally left out of the loadout may not be issued ( FM/BP-711 - Required equipment discretion).
• Communication devices:
  • Issuing of a radio or CTab as outlined in the campaign briefing, so long as the relevant loadout policy is followed.
• Mission-specific equipment:
  • Issuing mission-critical items, provided they comply with existing loadout policies and are essential for mission completion.

Reinsertion procedures must be pre-determined and accepted between the Lead Game Master and the Field Leader well in advance of the commencement of the mission. The Reinsertion method shall consist of one of the following:

• Player transport:
  •  Transportation of the player from the spawn point to the Area of Operations (AO) with an appropriate vehicle or aircraft.
• Teleportation:
  • Teleport the player to their relevant unit, provided the unit is not actively engaged in combat.

Mid-mission adjustments:

If the Field Leader wants to change reinsertion procedures during the deployment, amendments can be made upon consensus with the Lead Game Master.

Technical issues:

Any person who needs reinsertion due to a technical problem has to be returned as fast as possible to his or her unit to minimize disturbance in gameplay.

The general approach to responding to player pings is as follows:

• Multiple pings: Respond to the ping for players who are pinging two or more times in quick succession; that is, three pings, or a series within 30–60 seconds, which usually means the player likely needs attention or assistance.
• Single pings: Generally ignore single pings because these are usually accidental and require no action.

Note that wherever possible, player requests should be pushed through the chain of command rather than relying on pings. This provides better flow and does not create unnecessary interruption to the Lead Game Master or Mission Support Team. Only directly respond to pings if it's clear immediate action is required or the request cannot be serviced through the traditional command structure.

When exporting a mission, the mission folder should contain the core files required for the scenario to function correctly.

Typical mission folders include:

• mission.sqm
• description.ext
• cba_settings.sqf (optional)
• Any mission specific scripts or assets used by the scenario

Mission files used by the server follow a standard naming format:

[OrbatID].[TerrainName].pbo

To achieve this format, it is recommended to save the mission project using the OrbatID as the mission name when first creating it. If a mission was created before an OrbatID was assigned, the Save As function can be used to create a correctly named folder. Any accompanying mission files should also be copied into the new mission folder.

The mission .pbo is generated using the Export to Multiplayer function in the 3DEN editor. This process packages the mission folder and its files, including description.ext and cba_settings.sqf.

Exported missions are saved in the MPMissions folder located in the Arma 3 installation directory.

Submit the mission file at least 24 hours before the scheduled start of the deployment to the UTFDEDI on Discord.

After completing FM/BS-764 - Send the mission file to the server, coordinate with a member of J9 Servers to test the mission PBO on the server. This test must be conducted several hours prior to deployment to verify the mission file functions correctly and to allow sufficient time to identify and resolve any issues.

Before a mission is played, key elements should be tested to ensure the scenario functions as intended.

Areas commonly checked include:

• Player spawning in the correct location, ensuring clutter around respawn points does not cause incorrect spawn positions
• Correct loadouts and Zeus access on spawn
• 3DEN placed objects spawning correctly and not appearing rotated, misplaced, or destroyed
• Headless clients connecting and spawning in their intended positions
• Intended enemy and friendly factions available for spawning
• Mission specific CBA settings applied correctly in the Mission tab of Addon Settings
• Mission scripts functioning as intended, including testing with another player connected to confirm correct global and local behaviour