- Updated README.md files for extension, garage, locker, main, organization, phone, store, and task addons to provide clearer overviews, dependencies, main components, and usage notes. - Improved task module documentation to clarify timer semantics and server task flows, ensuring accurate usage of time limits. - Adjusted default values for task time limits and IED timers to enforce positive countdown requirements. - Added new CAD addon for dispatch coordination, including its overview, dependencies, main components, and event handling.
Forge Task Module
Overview
The task addon is a server-owned mission/task system for Forge. It manages task execution, task-owned state, participant tracking, contribution-based player earnings, and org-owned rewards.
Task operational state is mission-scoped. The extension-backed task catalog, ownership, status, and defuse state are reset on task store startup, so the system intentionally starts clean after each server or mission restart.
Responsibilities
- spawn and monitor task flows on the server
- track per-task entities through
TaskStore - track task participants and engine-rating contribution
- award player earnings through the bank module
- award org funds, reputation, assets, and fleet rewards
- notify task participants and sync org updates to online members
Dependencies
forge_server_extensionforge_server_commonforge_server_actorforge_server_bankforge_server_orgforge_client_notifications
Main Components
Task Flows
fnc_attack.sqffnc_defend.sqffnc_defuse.sqffnc_delivery.sqffnc_destroy.sqffnc_hostage.sqffnc_hvt.sqf
TaskStore
fnc_initTaskStore.sqf initializes TaskStore, which owns:
- task ownership bindings
- participant snapshots
- defuse progress
- per-task entity registries for cargo, hostages, HVTs, IEDs, protected entities, shooters, and targets
Reward Handling
fnc_handleTaskRewards.sqf applies org-owned rewards:
funds-> org fundsequipment,supplies,weapons,special-> org assetsvehicles-> org fleet
Player earnings and org reputation from task outcomes are distributed separately through TaskStore.applyRatingOutcome using Arma engine rating deltas.
Task Ownership
Tasks are bound to an owner org when they are started through fnc_handler.sqf.
- if a requester UID is provided, the task is owned by that requester's org
- if no requester UID is available, the task is bound to the
defaultorg
Org rewards always go to the bound owner org. Player earnings still use per-player contribution.
Usage
Task time limits use 0 for no limit on attack, destroy, delivery, hostage,
and HVT tasks. Defuse IED timers are different: each IED must have a positive
countdown value.
Start Through The Handler
Use the handler when you want reputation gating and task ownership binding.
["attack", ["task_attack_1", 1, 2, 1500000, -75, 375, false, false], 250, getPlayerUID player] call forge_server_task_fnc_handler;
["delivery", ["task_delivery_1", 1, 3, "delivery_zone", 250000, -75, 300, false, false, 900], 0, getPlayerUID player] call forge_server_task_fnc_handler;
Arguments:
0: task type1: task-specific argument array2: minimum org reputation required to start the task3: requester UID used for ownership binding
Start Task Functions Directly
Direct task calls still work, but they do not provide a requester UID. That means task ownership falls back to the default org.
Use direct starts only when that behavior is intended, such as:
- mission-authored tasks
- editor-placed tasks
- server-owned/random tasks
If you want the accepting player's org to own the task rewards, use fnc_handler.sqf instead.
["task_attack_1", 1, 2, 1500000, -75, 375, false, false] spawn forge_server_task_fnc_attack;
["task_hostage_1", 1, 2, "extract_marker", 1500000, -75, 500, [false, true], false, false] spawn forge_server_task_fnc_hostage;
Event Hooks
XEH_preInit.sqf- compiles functions
- initializes
TaskStore
XEH_postInit.sqf- registers the ACE defuse event hook
- starts the attack-only mission manager on the server
Notes
- the dynamic mission manager in
fnc_missionManager.sqfis now limited to attack missions only - it starts server-owned tasks through
fnc_handler.sqfand binds them to thedefaultorg - task lifecycle for the mission manager is tracked through
TaskStorestatus entries - task backend state is intentionally transient and resets with the active server/mission lifecycle
- task rewards are org-owned, not player-owned
- participant notifications are sent through the notifications module, not through local server UI
Authors
- J. Schmidt
- Creedcoder
- IDSolutions