7erra

You're welcome 🙂

Each frame would be very excessive. You would be saving the variable 60 (or 30 times, depending on fps) every second. Broadcasting it too would be an absolute nightmare for performance. Instead you can save it when the display is closed: _display displayAddEventhandler ["Unload", { params ["_display"]; private _ctrlEdit = _display displayCtrl 9876; missionNamespace setVariable ["TAG_enteredText", ctrlText _ctrlEdit, true]; }]; It would also be possible to keep track of the text while it is entered but that would lead to more network traffic while only giving a little bit more advantage over this approach.

Hm seems weird. Maybe try this instead: missionNamespace setVariable ["TAG_enteredText", ctrlText _ctrlEdit]; /* instead of: TAG_enteredText = ctrlText _ctrlEdit; publicVariable "TAG_enteredText"; */ That's going to change the script significantly since we can't use booleans (true/false) anymore. We can either do it with the same logic as previously: Or we do it smart: #define IDC_MIN 6961 #define IDC_MAX 6963 private _fncUpdateButtonStates = { params ["_ctrlButtonActive"]; private _idcActive = ctrlIDC _ctrlButtonActive; private _display = ctrlParent _ctrlButtonActive; for "_idc" from IDC_MIN to IDC_MAX do { private _ctrlButton = _display displayCtrl _idc; if (_idc == _idcActive) then { _ctrlButton ctrlSetText "ACTIVE"; } else { _ctrlButton ctrlSetText "INACTIVE"; }; }; if (missionNamespace getVariable ["TAG_idcActive", MIN_IDC] != _idcActive) then { missionNamespace setVariable ["TAG_idcActive", _idcActive, true]; }; }; createDialog "GUITest"; private _display = findDisplay 12345; private _idcActive = missionNamespace getVariable ["TAG_idcActive", IDC_MIN]; for "_idc" from IDC_MIN to IDC_MAX do { private _ctrlButton = _display displayCtrl _idc; _ctrlButton ctrlAddEventhandler ["ButtonClick", _fncUpdateButtonStates]; if (_idc == _idcActive) then {[_ctrlButton] call _fncUpdateButtonStates}; }; The logic behind the second code is a bit more advanced but you can have as many buttons as you want. I also added some performance optimizations (not that they really matter in UIs). At least I hope those codes work...

Oh if you want to have all players have the same RscEdit text you have to broadcast it after declaring it. I added it to my last post.

_btnSave = _display displayCtrl 1234; _btnSave ctrlAddEventhanddler ["ButtonClick",{ params ["_btnSave"]; _display = ctrlParent _btnSave; _ctrlEdit = _display displayCtrl 5678; TAG_enteredText = ctrlText _ctrlEdit; publicVariable "TAG_enteredText"; }]; _ctrlEdit = _display displayCtrl 5678; _ctrlEdit ctrlSetText (missionNamespace getVariable ["TAG_enteredText", ""]); To load the text when display is opened.

You can return the text of RscEdit control with ctrlText and save it with a global variable: _btnSave = _display displayCtrl 1234; _btnSave ctrlAddEventhanddler ["ButtonClick",{ params ["_btnSave"]; _display = ctrlParent _btnSave; _ctrlEdit = _display displayCtrl 5678; TAG_enteredText = ctrlText _ctrlEdit; }]; Where 1234 is the idc of the button controls and 5678 is the idc of the RscEdit.

Oof several mistakes there: 1) buttonSetAction only accepts sqs (old) code, sqf is what you want. Same applies to exec and execVM, exec is for sqs, execVM is for sqf. The modern User Interface Event Handlers (UIEH) are the solution, specifically the onButtonClick one: _display = findDisplay IDD; _ctrl = _display displayCtrl 6961; _ctrl ctrlAddEventhandler ["ButtonClick",{ player execVM "script1.sqf"; }]; 2) Button01 is not defined in missionNamespace at that point. 3) publicVariable can only broadcast global variables. Underscore means the variable is local (only accessible in the script). 4) You are storing the literal string "BUTTON02" into missionNamespace, not the control, which wouldn't be possible either way (you can't store UI related variables, eg. displays and controls, in missionNamespace). So, let's see what we can do here. First of all, your display config should look like this at the beginning: class GUITest { idd = 12345; class controls { ... Remember the idd you write here. We can use it in the script as follows: createDialog "GUITest"; _display = findDisplay 12345; Let's make use of those UIEH I mentioned earlier: _button1 = _display displayCtrl 6961; _button1 ctrlAddEventhandler ["ButtonClick",{ params ["_button1"]; missionNamespace setVariable ["TAG_button1State", true, true]; _button1 ctrlSetText "ACTIVE"; _display = ctrlParent _button1; _button2 = _display displayCtrl 6962; _button2 ctrlSetText "INACTIVE"; }]; // Same thing for button 2: _button2 = _display displayCtrl 6962; _button2 ctrlAddEventhandler ["ButtonClick",{ params ["_button2"]; missionNamespace setVariable ["TAG_button1State", false, true]; _button2 ctrlSetText "ACTIVE"; _display = ctrlParent _button2; _button1 = _display displayCtrl 6961; _button1 ctrlSetText "INACTIVE"; }]; To change the buttons locally we just update the them with the usual ui command ctrlSetText. To broadcast the change to the other players we use the setVariable command with the following syntax: missionNamespace // which namespace? the global one, global as in the player's game setVariable // the command [ "TAG_button1State", // TAG is your name tag to make it unique, eg for me it is TER true, // the value that the global variable should have true // true to set the variable in the global namespace of the other players ]; And lastly add these lines to the script (full one will be at the end of the post again), to get and set the states when opening the dialog: _state = missionNamespace getVariable ["TAG_button1State", true]; if (_state) then { _button1 ctrlSetText "ACTIVE"; _button2 ctrlSetText "INACTIVE"; } else { _button1 ctrlSetText "INACTIVE"; _button2 ctrlSetText "ACTIVE"; }; Explanation: _state = missionNamespace getVariable ["TAG_button1State", true]; Get the global variable from the global namespace. We can't be sure it was set yet by another client or by ourselves, so if it does not exist it will fall back to true. if (_state) then { //... } else { //... }; There are only two possible states. Either button1 is active or button2 is. Here is the full script then: createDialog "GUITest"; _display = findDisplay 12345; _button1 = _display displayCtrl 6961; _button1 ctrlAddEventhandler ["ButtonClick",{ params ["_button1"]; missionNamespace setVariable ["TAG_button1State", true, true]; _button1 ctrlSetText "ACTIVE"; _display = ctrlParent _button1; _button2 = _display displayCtrl 6962; _button2 ctrlSetText "INACTIVE"; }]; // Same thing for button 2: _button2 = _display displayCtrl 6962; _button2 ctrlAddEventhandler ["ButtonClick",{ params ["_button2"]; missionNamespace setVariable ["TAG_button1State", false, true]; _button2 ctrlSetText "ACTIVE"; _display = ctrlParent _button2; _button1 = _display displayCtrl 6961; _button1 ctrlSetText "INACTIVE"; }]; _state = missionNamespace getVariable ["TAG_button1State", true]; if (_state) then { _button1 ctrlSetText "ACTIVE"; _button2 ctrlSetText "INACTIVE"; } else { _button1 ctrlSetText "INACTIVE"; _button2 ctrlSetText "ACTIVE"; }; Note 1: The display is only updated when opening it. It is "easy" (in theory) to update the display when another user clicks on a button while all other have it open but it is a fairly advanced topic and complicated to explain 😅 (if you need it I can try to though). Note 2: The script can be optimized in several ways. I have gone for the most simple solution. If you want to have the best possible solution (which might not be understandable at first) I can also write that one out. Well that is all. I haven't tested it but I am confident in my UI skills 🙂 If you have any questions after trying it out feel free to ask.

Yeah @Lou Montana is reworking some parts of the BIKI. It should be done soon™ and be back to normal.

Huh yeah. I had a look at the function header ingame and it is wrong too. Corrected the BIKI page though. I have close to 0 experience with ORBAT, so good that you could solve the issue 😄

Answer to updating ORBAT groups: Have you seen https://community.bistudio.com/wiki/BIS_fnc_ORBATSetGroupParams? Answer to variables in configs (description.ext, config.cpp): So, coming from UI config making: It is possible, in some cases, to have strings instead of numbers: https://community.bistudio.com/wiki/CT_STATIC#tileH. The string just gets evaluated as an sqf expression at some point (probably when opening the UI). BUT this does not apply to all config strings! For example, the text attribute is not interpreted as an evaluable string. For sqf arrays in configs: 95% sure that they can't be used interchangeably. Configs are very static, which is the purpose of them.

Also the lower idc number ranges are reserved for engine behaviour. Afaik 0: OK 1: CANCEL 2: CANCEL too? might be more So to be safe start with your idcs at 100

The general opinion on the Arma 3 Tools is... not much in favor of them. I also personally use mikero's tools for my own projects. For your other issue: It seems like a Steam problem but am not sure. I simply don't have enough knowledge on that topic.

Here are some links: https://community.bistudio.com/wiki/Arma_3_Tools_Installation#Details_about_branches https://forums.bohemia.net/forums/topic/169362-tools-development-branch-changelog/ And yeah, seems like the latest version is from the 8th of April

v2.6 - "Config Viewer 73 Preview" update +++ Added +++ - You can now preview certain classes from the Config Viewer 73 (see the Steam description) - Shortcut for opening the debug console changed from "^" key to CTRL+D (same as CBA) ~~~ Changed ~~~ - Some background stuff, I am transitioning to using BIS_fnc_display for my displays If you have another idea for configs which can be previewed just drop a comment. @Tankbuster there you go 😉

Good idea! I added some more ideas that should be easy to do: https://github.com/7erra/Terra-s-Editing-Extensions/issues/28