thy_

The script and its information in the main post have been updated! Jan, 18th 2025 | v7.2: IMPORTANT 1: the script folder inside the mission as renamed from "CSWRandomizr" to "CSWR"; IMPORTANT 2: the 1_Management, 2_Population and 3_Loadout files received a prefix number in their names to help editors to get the best sequence of file edition; IMPORTANT 3: the description.ext code was updated; Added > Helicopters > Through Population file, with helicopters use destination-type "_move_EXTRACTION" to schedule a extration that always bring you to the base (helicopter spawn-point); Added > Helicopters > Through Population file, with helicopters use destination-type "_move_TRANSPORT" to request an air transport to take your group to another area of your choice; Added > Helicopters > New helicopter class supported: Medium class with their own altitude (medium altitude editable too, perfect for transport/extraction helicopters); Added > Spawn delay > Just like 'by Trigger', 'by Object Target' and 'by Timer', now you can spawn something using 'Boolean flag', perfect for external scripts or codes with triggers; Added > Groups > One more formation options (three in total) for BluFor, OpFor, and Independent. Civilian still with two options; Added > Loadout customization > Now you can select two or more uniforms, for example, for infantry and randomize them automatically, perfect to create militia and PMC factions; Added > Vehicle cargo items > In Management file, the option 'CSWR_removeItemsCargo', if true, removes all cargo items from vehicles spawned by CSWR; Fixed > Coding > Two global variables weren't declared correctly, causing log error messages for servers; Fixed > Spawns > CSWR anti-spawn-blockers was deleting even the Player's AI members if they were over a vehicle spawn-point position. For those objects, only a warning message; Fixed > Spawns > CSWR anti-spawn-blockers was deleting custom helipads (those placed by you); Tweaked > Ethnicity > People from Civilian doesn't use camo face paint anymore, no matter what ethnicity is chosen; Improved > A few performance improvements; Documentation has been updated. New specialized destination type: _move_EXTRACTION New specialized destination type: _move_TRANSPORT New Spawn-Delay option: Boolean flag!

Thanks. So, in this case, following the @pierremgi said, this is the new try and looks it's working finally: Both in CSWR_globalFunctions.sqf: THY_fnc_CSWR_TRANSPORT_provide_pos_using_map = { // Returns _data: hashMap/array. params ["_data", "_grpCaller", "_grpVeh", "_veh", "_basePos", "_minDisCall"]; private [...]; // Initial values: _requestedPos = []; // Main function: while { alive _veh && alive driver _veh && alive leader _grpCaller} do { // Internal initial values: leader _grpCaller setVariable ["whereToGoPos", [], true]; // For caller group leader's machine: _requestedPos = [_grpCaller] call THY_fnc_CSWR_TRANSPORT_caller_pos; // Waiting for caller to provide position: waitUntil { sleep 1; !alive leader _grpCaller || _requestedPos isNotEqualTo [] }; // Validations // code... // Approved to leave the loop: if (conditions...) then { break }; }; // Code... // Preparing to return: _data set ["whereToGoPos", _requestedPos]; // Return: _data; }; THY_fnc_CSWR_TRANSPORT_caller_pos = { // Returns _pos: array. Positon where the caller group leader wants to go. params ["_grpCaller"]; private ["_pos"]; // Making sure player exist in multiplayer: waitUntil { sleep 0.1; !isNull player }; // Initial values: _pos = []; // Escape > If the machine has no interface, or the player is dead, or the player is not the caller group leader, abort: if ( !hasInterface || !alive player || player isNotEqualTo leader _grpCaller ) exitWith { _pos }; // Forcing player to open map: openMap [true, true]; // Check the click pos on map: addMissionEventHandler [ "MapSingleClick", { params ["_units", "_pos", "_alt", "_shift"]; // Defining: player setVariable ["whereToGoPos", _pos, true]; // Closes the player map normally: openMap [false, false]; // Ends the event handler: removeMissionEventHandler ["MapSingleClick", _thisEventHandler]; } ]; // Waiting for caller to provide position: waitUntil { sleep 1; !alive player || (leader _grpCaller getVariable "whereToGoPos") isNotEqualTo [] }; // prepare to return: _pos = leader _grpCaller getVariable "whereToGoPos"; // Return: _pos; };

To make clear, all these functions are in the file named CSWR_globalFunctions.sqf where its "access" is through THY_CSWR_functions. That said, the header of the CSWR_globalFunctions.sqf has NO restrictions about hasInterface or isServer because - may I be wrong - only the server can read these CSWR_globalFunctions.sqf functions... description.ext: THY_CSWR_functions.hpp: So, when I listen to someone much more experienced advise me literally to use the player command in a multiplayer context (yeap, multiple positions could be provided simultaneously), it makes a mess in my mind, "forcing" to use remoteExec hehe. Okay, got it about setVariable being more "straight" to the point: Do you mean... something like this below? Again, in my understanding, I cannot even see the possibility of a player machine reading this function to make the hasInterface needed. An honest question by something thinking hard: this solution below (transferring data by hashMap) is that bad, or, worst, doesn't make sense? I'm here to learn with you, guys... so bring it on hehe! Both functions in CSWR_globalFunctions.sqf: @pierremgi, I am trying but I cannot see the north you provided in my code. Can you post here a few lines of the change?

But how to get back the information that the leader-player clicked on their map? Storing in a var, is it enough? _dataPlus = [] remoteExec ["THY_fnc_CSWR_TRANSPORT_caller_pos", leader _grpCaller]; This solution is working for single-player, but not sure for multiplayer. What do you think? Server-side: Client-side: THY_fnc_CSWR_TRANSPORT_caller_pos = { // CLIENT-SIDE FUNCTION called by THY_fnc_CSWR_TRANSPORT_provide_pos_using_map. // This function asks for the leader of caller group its cursor position over the map by click. // Returns _dataPlus: hashMap/array. If empty ????????????? //params ["", "", "", ""]; private ["_dataPlus"]; // Initial values: _dataPlus = createHashMap; // Escape: if ( !alive player || player isNotEqualTo leader (group player) ) exitWith { _dataPlus }; // Forcing player to open map: openMap [true, true]; // Check the click pos on map: addMissionEventHandler ["MapSingleClick",{ params ["_units", "_pos", "_alt", "_shift"]; // Defining: _thisArgs params ["_callerRequestData"]; _callerRequestData set ["whereToGoPos", _pos]; _callerRequestData set ["isDone", true]; // Closes the player map normally: openMap [false, false]; // Ends the event handler: removeMissionEventHandler ["MapSingleClick", _thisEventHandler]; }, // Return > Where _thisArgs stores to be used out of EH scope: [_dataPlus] ]; // Waiting for caller to provide position: waitUntil { sleep 1; _dataPlus getOrDefault ["isDone", false] }; // Return: _dataPlus; };

Do you mean: should I do a remoteExec to add the addMissionEventHandler for the leader of the caller group? I don't think I got it because I wouldn't even know how to do that. Because if EventHandlers are local, it means it's running just on server once my entire script just use the server side. EDITED: forget it. I found the Larrow solution, working the addMissionEventHandler through remoteExec 😉.

I'm building one independently because it will integrate natively the CSWR script. Thanks anyway!

A question: How do I force addMissionEventHandler to consider only the caller group leader (always a player)? _data = createHashMap; addMissionEventhandler [ "MapSingleClick", { _thisArgs params ["_returnData"]; _returnData set ["some key", "some value"]; //Return whatever you need }, [ _data] //Important ]; waitUntil { count _data > 0 }; systemChat "map clicked!"; PS: I loved this way of "extracting" data from an EH.

Oi. I need help with: To set correctly that Global Var "TRANSP_GROUP", using a Namespace that doesn't compromise other players using the same Air transport service! What my script already does on single-player: Once the player requests the service, the server creates and sends a helicopter to the player's position. As soon as the helicopter lands over there, the player provides what position they wanna go. After the helicopter delivery, it returns to base and it's deleted, ending that service. Below is what happens when a player gets in the helicopter (pretty sure it will not work in MP if more than one player group requests the service to the server. // IMPORTANT: code running only on server! openMap [true, false]; // Defining the server AI group that will provide the support with its helicopter: TRANSP_GROUP = _supportGrp; // The coordenates that some side player will provide, clicking over their map: TRANSP_COORDS = []; // I would like to specify this event is attached ONLY to the player-leader of _grpAskedResrc group: addMissionEventHandler ["MapSingleClick", { // Not sure if it can help me here: params ["_units", "_pos", "_alt", "_shift"]; // I'm consern because another player in other part of the map can be requesting Transport too and this global var "TRANSP_GROUP" brings a mess: private _supportGrp = missionNamespace getVariable "TRANSP_GROUP"; // Defining the coordenates provided by some side player using this Transport resource: TRANSP_COORDS = (findDisplay 12 displayCtrl 51) ctrlMapScreenToWorld getMousePosition; private _wp = _supportGrp addWaypoint [TRANSP_COORDS, 0]; _wp setWaypointType 'MOVE'; _supportGrp setCurrentWaypoint _wp; removeMissionEventHandler ["MapSingleClick", _thisEventHandler]; openMap false; vehicle leader _supportGrp vehicleChat "Let's go!"; }]; // Wait until the helicopter gets the coordenates: waitUntil { sleep 1; TRANSP_COORDS isNotEqualTo []; }; systemChat "IT'S WORKING!"; I tried to setVariable to the group (namespace) to "isolate" that var changes from other groups but it didn't work.

Soon in v7.2, CSWR will provide Air transport/extraction automatically as soon as the player requests. The prototype is already working, and now, after initial tests in single and multiplayer, I'm refactoring it for this new logic.

What a great command this createHashMapFromArray. And I didn't know about the get command either. This will help me A LOT.

I'm sure there's a smarter and maybe lighter way to broadcast organized data (as in this case, in arrays) that will change during the game! (from 0 to 10 times, but probably never 20 times per side in multiplayer games. For single-player this number is reduced drastically, around 0-2) Can you suggest a better way to broadcast the example seen through both functions below? THY_fnc_bananasCounter = { params [...]; private [...]; // Initial values: _cntr = []; // Addressing each side-array in THY_allBananas = [[blu], [opf], [ind], [civ]] = [[0],[0],[0],[0]] switch (side _player) do { case BLUFOR: { _cntr = THY_allBananas # 0 }; case OPFOR: { _cntr = THY_allBananas # 1 }; case INDEPENDENT: { _cntr = THY_allBananas # 2 }; case CIVILIAN: { _cntr = THY_allBananas # 3 }; }; // Increasing the side amount: if (...) then { _cntr = [(_cntr # 0) + 1]; }; switch (side _player) do { case BLUFOR: { THY_allBananas = [_cntr, THY_allBananas # 1, THY_allBananas # 2, THY_allBananas # 3] }; case OPFOR: { THY_allBananas = [THY_allBananas # 0, _cntr, THY_allBananas # 2, THY_allBananas # 3] }; case INDEPENDENT: { THY_allBananas = [THY_allBananas # 0, THY_allBananas # 1, _cntr, THY_allBananas # 3] }; case CIVILIAN: { THY_allBananas = [THY_allBananas # 0, THY_allBananas # 1, THY_allBananas # 2, _cntr] }; }; // Broadcasting the new value: publicVariable "THY_allBananas"; // Return: true }; THY_fnc_reportingBananasAmount = { params [...]; private [...]; // Initial values: _cntr = []; // Addressing each side-array in THY_allBananas = [[blu], [opf], [ind], [civ]] = [[0],[0],[0],[0]] switch (side _player) do { case BLUFOR: { _cntr = THY_allBananas # 0 }; case OPFOR: { _cntr = THY_allBananas # 1 }; case INDEPENDENT: { _cntr = THY_allBananas # 2 }; case CIVILIAN: { _cntr = THY_allBananas # 3 }; }; // Showing the bananas amount by side: systemChat format ["The %1 side has %2 banana(s) available!", side _player, _cntr # 0]; // Return: true }; I tried the setVariable / getVariable logic, but I'm unsure if it would work like that or if I'm tripping because I don't understand Namespaces yet.

Now supporting single-player too. Cheers.

Smart move. Done: https://feedback.bistudio.com/T187980

The same problem was reported in Ago/2019:

@Maff, probably you didn't execute exactly what makes the bug take place as @kagenekosamareported. Below, I explain in detail a step by step to reproduce what is happening. And yes, it looks like a true bug which makes it frustrating to use mechanized infantry between player and AI in the same group. The "solution" for keeping your Commander or Gunner position and ordering the AI members to get in again is to ask them to STOP when they are stuck right in the vehicle's rear. Immediately you ask them to stop, they get in the vehicle hehe. Ticket already open in BIS Bug Tracker: https://feedback.bistudio.com/T187980