Arma 3 Dialog Creator builds config-ready HPP for two related UI surfaces:

• Dialog UI: interactive displays with buttons, edit boxes, listboxes, dropdowns, map controls, panels, and apply/cancel workflows.
• HUD / Turret Optics: overlay-style resources for reticles, range ladders, sensor/weapon status, lock cues, compass tapes, and RscTitles-style HUD output.

The tool creates the static display structure. Your addon still owns the runtime behavior: SQF population, validation, multiplayer authority, object selection, and gameplay changes.

An Arma UI normally has two layers of work:

• HPP/config: declares the display class and its controls.
• SQF: fills controls with live data, reacts to clicks, validates input, and applies changes.

This tool helps with the first layer and gives notes for the second. It cannot prove that your addon include path, inherited base classes, texture paths, or SQF functions exist. That still needs addon-side validation and in-game testing.

1. Open http://dialogcreator.rkslstudios.info/.
   • Why: the tool is file-backed and runs in the browser. There is no database or install step.
2. Choose Dialog UI or HUD / Turret Optics.
   • Dialog UI means the player interacts with controls: buttons, lists, edit boxes, maps, checkboxes.
   • HUD / Turret Optics means the UI is mostly an overlay: reticle, range ladder, headings, lock state, sensor state.
   • Why: the chosen mode changes the defaults, wizards, and export assumptions.
3. Fill in the left setup panel before building.
   • Why: class names, IDD, IDC ranges, and namespace keys are the contract between config and SQF. Changing them late can break scripts that already reference them.
4. Add controls with the palette or guided wizards.
   • Palette: use when you know the exact Rsc* control you want.
   • Workflow wizards: use when you want a complete pattern with related controls and notes.
5. Place controls visually, then refine in the inspector.
   • Why: dragging is fast for rough layout, but exact X/Y/W/H values are better for repeatable addon work.
6. Export HPP and include it from your addon config.
   • Why: Arma reads displays from config. The exported HPP is not active until included by a real addon or mission config.
7. Implement or connect the generated SQF function names.
   • Why: button action strings and lifecycle hooks call functions. If those functions are missing, the display may open but behavior will fail.
8. Test in game and read the RPT.
   • Why: browser preview can catch layout mistakes, but only Arma can confirm inherited classes, safezone behavior, texture loading, control events, and script errors.

The top-level display or resource class name in the generated HPP.

Why it matters: this is how the display is opened or referenced from config. Keep it stable and unique, usually with your addon tag or prefix.

The display ID.

Why it matters: Arma uses IDD values to identify displays. Collisions with other displays can make scripts target the wrong display or fail unpredictably.

The uiNamespace variable used by generated onLoad and onUnload.

Why it matters: uiNamespace lets SQF find the live display after it opens. onUnload must clear the reference so scripts do not hold stale display handles.

The first positive control ID used for interactive controls.

Why it matters: SQF finds controls with displayCtrl IDC_NAME. Static controls should normally use idc = -1; controls that SQF reads or modifies need positive unique IDC values.

• Dialog / RscDisplay: for interactive UI opened as a dialog/display.
• RscTitles overlay: for persistent HUD-style overlay resources.

Why it matters: overlays use different lifecycle expectations from interactive dialogs. A turret optic/status display normally belongs closer to RscTitles behavior.

The browser preview aspect ratio.

Why it matters: Arma users may run 16:9, 16:10, 21:9, or windowed layouts. A panel that looks correct at one ratio can overlap or drift at another.

Exports positions as safezone-relative expressions.

Why it matters: safezone output adapts to UI scaling and aspect ratio better than raw screen constants. It still needs in-game testing.

Generates #define constants for the display ID and positive IDC values.

Why it matters: named constants are safer than scattered numeric literals. They make SQF and config easier to audit.

Controls placement increments when moving, resizing, and keyboard nudging.

Why it matters: consistent grid values produce cleaner HPP and reduce near-miss alignment issues.

• Add: click a control type in the left palette.
• Select: click a control or its layer entry.
• Move: drag the control.
• Resize: drag the bottom-right handle.
• Duplicate: copies the selected control and offsets it slightly.
• Delete: removes the selected control.
• Reorder: use layer up/down in the layer list.
• Lock: prevents accidental mouse movement/resizing.
• Hide: visually dims the control in the editor but keeps it in the project/export.
• Zoom: use mouse wheel or the - / + controls.
• Pan: drag empty canvas space.
• Reset view: click 100.

Why zoom/pan does not affect export: the tool transforms only the browser preview. The actual control coordinates remain normalized 0..1 layout values.

• Class: the generated control class name. Use stable, readable names.
• Base class: the inherited Arma control class, such as RscText, RscPicture, RscButton, RscListbox.
• IDC: positive value for controls accessed by SQF; -1 for static controls.
• Text / texture: visible text for text/buttons or texture path for RscPicture.
• X/Y/W/H: normalized left/top/width/height values.
• Style: numeric Arma style flags. Use only when you know the base class expects them.
• sizeEx: text size. Browser preview is approximate; test in game.
• Font: Arma font class.
• colorText[]: text color or picture tint.
• colorBackground[]: background color array.
• Tooltip: in-game tooltip shown on hover.
• Action: button action string.
• Background control: places the control in controlsBackground.
• Visible: hides/dims the control in the editor preview.
• Locked: prevents mouse move/resize.

String fields commit when you leave the box or press Enter. This avoids redrawing picture/background controls on every keypress while editing long paths.

RscPicture controls can preview local PNG, JPG/JPEG, or TGA files.

1. Select an RscPicture.
2. Set Text / texture to the Arma texture path that will be exported.
3. Use Choose preview to pick a local PNG, JPG, or TGA.
4. Use the preview to align and size the image.

Why preview is separate from texture path: Arma commonly uses .paa, but browsers do not display .paa. A local PNG/JPG/TGA preview lets you design visually while still exporting the real Arma texture path.

The preview file is not uploaded, not written to HPP, and not saved into project JSON.

Goal: create a non-interactive picture or panel behind the rest of the dialog.

1. Choose Dialog UI.
   • Why: a dialog background normally belongs to an interactive display, not a HUD overlay.
2. Open Workflow and choose Create Background Image.
   • What this creates: an RscPicture control with background = true.
3. Enter a class name such as Dialog_Background.
   • Why: class names should explain purpose. This helps when reading exported HPP later.
4. Enter the Arma texture path, for example \myAddon\ui\dialog_background_ca.paa.
   • What this means: this becomes text = “\myAddon\ui\dialog_background_ca.paa”; in the HPP.
   • Common mistake: using a Windows path like C:\…. Arma needs an addon-relative path.
5. Set X/Y/W/H.
   • Why: these values define where the picture sits in normalized display space.
   • Tip: use a broad backing image first, then add smaller frames or labels above it.
6. Create the control.
   • What happens: it appears on the canvas and is exported in controlsBackground.
7. Optional: choose a local PNG/JPG/TGA preview.
   • Why: preview helps align the image without requiring the browser to read .paa.
8. Keep idc = -1 unless SQF needs to access the picture.
   • Why: static art does not need a positive IDC. Saving positive IDCs for live controls keeps SQF lookup clean.

Goal: add a button that calls SQF when clicked.

1. Choose Create Button.
   • What this creates: an RscButton with text, tooltip, position, and action string.
2. Give it a short visible label such as Apply.
   • Why: buttons should use short verbs. Longer explanations belong in tooltips or nearby text.
3. Set a tooltip.
   • Why: tooltips explain the consequence without making the button large.
4. Use a short action string such as ['apply', _this] call TAG_fnc_dialogAction.
   • What this means: the UI passes a command key and Arma event arguments to a function.
   • Why: short event strings are easier to debug than large inline SQF blocks.
5. Give the button a positive IDC.
   • Why: interactive controls may need lookup, enable/disable state, or runtime updates.
6. Implement the called function in your addon.
   • Common mistake: exporting a button that calls TAG_fnc_dialogAction before that function exists in CfgFunctions.
7. Validate before changing gameplay state.
   • Why: dialog code runs locally. Multiplayer-sensitive actions need locality/authority checks outside the UI.

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.