Knowledgebase

Goal: make a button visibly react to hover.

1. Choose Create Animated Button.
   • What this creates: a button with mouse-enter/mouse-exit event strings using fade/commit behavior.
2. Set the visible text and action.
   • Why: hover animation should not replace the actual click behavior.
3. Keep the animation subtle.
   • Why: UI animation runs locally and can become distracting or expensive if overused.
4. Test the result in Arma.
   • Why: inherited control classes, parent display behavior, and UI scale can change how fade/commit appears.

Goal: let the user choose one value from a controlled list.

1. Choose Create Dropdown.
   • What this creates: an RscCombo plus generated notes for row population.
2. Enter options one per line.
   • Simple format: Display Text
   • Stable data format: Display Text=internalValue
3. Use stable data when possible.
   • Why: visible labels are for the user and may be renamed or translated. SQF should read stable data keys.
4. Give the combo a positive IDC.
   • Why: the lifecycle function needs to find it with displayCtrl.
5. Populate rows on onLoad.
   • Why: lists and combos are normally filled by SQF when the display opens, especially if options depend on mission state.
6. Read selected data on Apply.
   • Why: reading only the visible text can break if labels change.

Goal: build a predictable dialog where the user can edit values safely before committing them.

1. Create a panel layout.
   • Why: a stable frame/header/body/footer makes the dialog easier to scan and extend.
2. Add input controls.
   • Examples: edit fields for text/numbers, combos for controlled choices, checkboxes for binary settings, listboxes for larger selections.
3. Add Apply / Reset / Cancel buttons.
   • Apply means validate and commit.
   • Reset means restore UI values.
   • Cancel means close or discard pending local state.
4. Route all buttons into a function.
   • Example: ['apply', _this] call TAG_fnc_dialogAction.
   • Why: one dispatcher function can handle all dialog commands consistently.
5. In SQF, read values by IDC.
   • Why: IDC lookup is stable and does not depend on visual layer order.
6. Validate before applying.
   • Examples: numeric range checks, class existence checks, object locality, selected row data, map position validity.
7. Apply changes only after validation succeeds.
   • Why: users should not partially mutate gameplay state by simply typing into fields.

Goal: let the user choose a world position from a map control.

1. Choose Create Map Selector.
   • What this creates: a map control plus supporting controls for the selected output.
2. Position the map area.
   • Why: map controls usually need more space than text controls. Avoid squeezing them into small panels.
3. Use a click event to capture screen position.
   • What this means: SQF receives the map click event and converts it to world coordinates.
4. Convert with ctrlMapScreenToWorld.
   • Why: the mouse click is screen/control space; gameplay systems usually need world position.
5. Validate the selected position.
   • Why: spawning, teleporting, targeting, and artillery-style actions can break gameplay if the point is invalid or unauthorized.

Goal: create a readable overlay for a gunner, camera, sensor, or turret view.

1. Choose HUD / Turret Optics.
   • Why: this mode assumes overlay behavior and RscTitles-style output rather than an interactive dialog.
2. Add a reticle first.
   • Why: the reticle anchors the viewer's attention and sets the center reference.
3. Add range ladder, heading/compass tape, weapon status, sensor mode, and lock cues.
   • Why: these are supporting cues around the reticle. They should not obscure the target.
4. Use transparent backgrounds by default.
   • Why: optics must be readable over terrain, sky, smoke, thermal imagery, and night vision.
5. Use backing plates only where readability needs them.
   • Why: too many opaque panels reduce situational awareness.
6. Test in the target vehicle/turret camera.
   • Why: browser preview cannot reproduce FOV, camera shake, optics post-processing, thermal contrast, or game UI scaling.

1. Copy or download the generated HPP.
2. Include it from your addon config.cpp or UI include file.
3. Confirm all inherited base classes exist where the HPP is included.
4. Register lifecycle and action functions in CfgFunctions.
5. Keep static panels, frames, labels, and pictures in controlsBackground.
6. Keep interactive controls in controls.
7. Check IDD and IDC collisions.
8. Pack the addon.
9. Open the display in game.
10. Review the RPT for config and script errors.

• The display opens but buttons do nothing: the action function probably is not registered or the event string points at the wrong tag/function.
• A control cannot be found by SQF: it may have idc = -1, a duplicate IDC, or a define mismatch.
• A picture does not show in game: the texture path may be wrong, the file may not be packed, or the image may need conversion to PAA.
• Layout looks wrong in game: safezone/UI scale/aspect ratio differs from the browser preview.
• Dropdown labels work but behavior is wrong: SQF may be reading visible text instead of stable row data.
• Multiplayer action works locally but not for other players: the button runs on the local client and needs a validated remote/server path.

• Display class is included from the intended config root.
• IDD does not collide with another display.
• Positive IDC values are unique within the display.
• Static controls use idc = -1 unless SQF reads them.
• onLoad publishes the display to uiNamespace.
• onUnload clears the display reference.
• Button/event strings call registered functions.
• Lists, combos, and trees store stable row data.
• Texture paths exist in the packed addon.
• Layout is checked at 16:9, 16:10, 21:9, and narrow windowed ratios.
• MP-sensitive actions validate locality and authority outside the UI layer.