cidfr

_MMoney doesn't exist in the scope of the activation callback (neither _box nor _dropoffmarker) You can inject a variable into it by setting a variable in the trigger : _Boxtrg setVariable [ "_mMoney", _MMoney ]; _Boxtrg setVariable [ "_box", _box ]; _Boxtrg setVariable [ "_dropoffmarker", _dropoffmarker ]; And then, into the setTriggerStatements : _Boxtrg setTriggerStatements [ "this", " _firstplayer = thisList select 0; private _Amoney = _firstplayer getVariable [format['_Amoney_%1', _firstplayer],0]; private _MMoney = thisTrigger getVariable [ '_mMoney', 0]; // <--- Check this private _box = thisTrigger getVariable '_box'; // <--- And this private _dropoffmarker = thisTrigger getVariable '_dropoffmarker'; // <--- And this deleteVehicle _box; deleteMarker _dropoffmarker; hint format ['You picked up $%1', _MMoney]; _Amoney = _Amoney + _MMoney; _firstplayer setVariable [format['_Amoney_%1', _firstplayer], _Amoney]; deleteVehicle thisTrigger; // Money was picked up for the trigger associated with the box and it can be deleted now ", "" ];

You can either modify _pos to add the 0 value for the z axis at the end using pushBack : _pos = [obj1, 1, 100, 1, 1,0.25, 0] call BIS_fnc_findSafePos; _pos pushBack 0; createSimpleObject ["Land_HelipadEmpty_F", _pos, false]; or keep the _pos array unchanged and perform the modifications in a copy using + syntax (see example 3) createSimpleObject ["Land_HelipadEmpty_F", _pos + [ 0 ], false]; Alternatively, you can use select to extract the components to create a new array : createSimpleObject ["Land_HelipadEmpty_F", [ _pos select 0, _pos select 1, 0 ], false];

player is still a reference to the client who execute the code (in that case, the trigger creator?) If the trigger creator is a server, there is no "player" Can you share the setTriggerStatements you wrote? You may be closer to the solution than you expect

I don't think it's the first player, I think it's the player who created this _box. The code if (player distance _box < 5) would work only with the player that created the _box, because that script is only executed on a single client (each client executing their own version) If you create the boxes only server-side and execute remotely the spawned code on each clients, it may work but I wouldn't recommend this approach. Game logic should be executed server-side

I think it's a locality problem, since all players and the server execute init.sqf once I suppose the amount of boxes is 50 * number of players And each player execute their own : [_Mname, _rndPos, _Mcolor, _Mtext, _box, _MMoney] spawn { // ... }; I would rather use triggers if all you need is a player-proximity checker

I strongly advise you to indent your code correctly. Readable code is far easier to debug and maintain. My code editor showed me an invisible character at this line : _box = "Land_PaperBox_01_small_closed_brown_f" createVehicle ��[_rndPos select 0, _rndPos select 1, (_rndPos select 2) + 3];

You can use BIS_fnc_hasItem

Hello, Considering the BIKI, I can localize any text fields in the editor : And considering SPOTRED #00042 : So, I used a localized role description for my units, such as : And then, when launching the mission in the editor : So far, so good. Now, when using the mission on a dedicated server, the default name appears in the lobby : If I select any unit, join the game, then come back to the lobby, the expected localized name is now available. I suppose that since the clients haven't yet loaded the mission file, the StringTable.xml file isn't yet parsed and then the engine uses the class display name as fallback. Am I doing things wrong or is this a bug feature ? Or perhaps I have misinterpreted the spotrep and the localized units name was just a translation for configfile >> "CfgVehicles" >> _unitClass >> "displayName" Here is a PBO file to reproduce Thanks

Without that much context, I think it's quite hard to help you What timer? What sector? Pretend you are asking this question to people who aren't in your head and don't know anything about your project (hint : we are not 😋)

The Hunter is based on the real-life M-ATV and there's a mod with such mounted guns already : Oshkosh M-ATV by Burnes Armouries ( matv )

because you're always taking the last element of the array and they could be sorted by floors. If you want random elements, you can keep your algorithm as-is and just change _posArray = _x buildingPos -1; To : _posArray = (_x buildingPos -1) call BIS_fnc_arrayShuffle; Now, the array containing the positions should be randomized and taking the last one would mean taking a random one More informations in documentations : BIS_fnc_arrayShuffle

Thank you, Larrow ! This should be added in the documentation, which is often lacking of many precisions. I usually read the source code when I need clarification and for once I don't do it, the answer was in the code... 😅

Hello, Consider this key in the stringtable : <Key ID="STR_CID_FREE_CITY_TASK_DESCRIPTION"> <English>Clear %1 of ennemies</English> <!-- more languages --> </Key> Using a local context, I can easily do : private _localizedDescription = format [ localize "STR_CID_FREE_CITY_TASK_DESCRIPTION", _cityName ]; However, I'm wondering if it's possible to use such strings with BIS_fnc_taskCreate I could do [ _side, _taskID, [ format [ localize "STR_CID_FREE_CITY_TASK_DESCRIPTION", _cityName ], "some title", // could be localized too "" ] ] call BIS_fnc_taskCreate; But this will be evaluated server-side and the clients may receive strings in a language that doesn't match theirs I could remotely send the tasks creation on each clients with [ [ _side, _taskID, _cityName ], { [ /* same parameters than previous code */ ] call BIS_fnc_taskCreate; } ] remoteExec [ "spawn", 0, true ]; This may work, but will require extra work to sync the tasks between the clients and the server, update the JIP queue when a task has changed and probably more stuff And in my opinion, this will goes against the purpose of using the Task Framework, which already handle all of this and can send static localized strings to clients So far, the only clean solution I found was changing the description to a generic "Clear the zone of ennemies" and as title the _cityName. This is acceptable, but I was wondering if using formatted localized strings was possible using the Task Framework Thanks

Hello, I've made a script to help people to create missions having spawn zones with random spawn points and waypoints It can be used with any mods/maps (or even pure vanilla) The script, with a detailed usage guide can be found on GitHub Preconfigured (and non-configured) templates of the script can be downloaded here Usage All you need to do is to place one (or more) triggers on the map and name it respecting a specific format : DynamicSpawn_<Activating side>_<Side to spawn>_<Amount of infantry squads>_<Amount of waypoints for infantry>_<Amount of vehicle squads>_<Amount of waypoints for vehicles>_<Amount of air units>_<Amount of air units waypoints (actually unused)>_<ID of the trigger> Where : <Activating side> is the side that will activate the trigger when entering in <Side to spawn> is the side of the units that will spawn when the trigger is activated Both sides can have the values : "WEST", "EAST", "GUER", "CIV" <Amount of infantry squads>, <Amount of vehicle squads> and <Amount of air units> are the amount of squads that will be spawn (except for air, that's just the amount of units). They can have any value above zero (including zero if you don't want such type of units) <Amount of waypoints for infantry>, <Amount of waypoints for vehicles> and <Amount of air units waypoints> are the amount of waypoints for each kind of squads (actually unused for air units). They can have any value above zero (including zero if you don't want the units to move) or a range of values using a comma , as separator, such as 4,8 if you want between 4 and 8 waypoints. <ID of the trigger> is a numeric value used to identify each triggers. Keep them unique or you may expect bugs (such as units spawning/moving at the wrong place) For example : DynamicSpawn_WEST_EAST_5_6,8_2_4_1_1_1 will trigger when an unit from WEST enters the trigger and will spawn units from EAST such as : 5 infantry squads having each between 6 and 8 waypoints 2 vehicle squads having 4 waypoints 1 air unit The Id of the trigger is 1 Then, you can place spawn points, named such as : <Type of group to spawn>_SPAWN_POINT_<id of the trigger>_<id of the spawn point> Where : <Type of group to spawn> can have as value any of those : INFANTRY, VEHICLE or AIR <id of the trigger> must match the id of the trigger previously created, so that way, when trigger 1 will be activated, the script will know it must use the *_SPAWN_POINT_1_* as spawn points. That way, spawn points can be placed outside of the trigger (allowing, for example, air units coming from far away) <id of the spawn point> is used to have different unique names for spawn points (and that value is automatically incremented when copying/pasting the spawnpoints) For example : INFANTRY_SPAWN_POINT_1_1 INFANTRY_SPAWN_POINT_1_2 INFANTRY_SPAWN_POINT_1_3 ... VEHICLE_SPAWN_POINT_1_1 VEHICLE_SPAWN_POINT_1_2 VEHICLE_SPAWN_POINT_1_3 VEHICLE_SPAWN_POINT_1_4 ... AIR_SPAWN_POINT_1_1 AIR_SPAWN_POINT_1_2 ... The example below shows many spawn points placed in Stratis. You can notice the air spawn points are placed all around the map, far away from the trigger. The waypoints work the same way than the spawn points : Their format is : <Type of group>_WAYPOINT_<id of the trigger>_<id of the waypoint> : INFANTRY_WAYPOINT_1_1 INFANTRY_WAYPOINT_1_2 INFANTRY_WAYPOINT_1_3 INFANTRY_WAYPOINT_1_4 ... VEHICLE_WAYPOINT_1_1 VEHICLE_WAYPOINT_1_2 VEHICLE_WAYPOINT_1_3 ... There is no air waypoints, the behavior of air vehicles is different : Once spawned (1000 meters altitude), they will fly and loiter around the center of the trigger (Altitude 250, radius 500) When a unit from the activating side is detected by the spawning side, the aircrafts will go Seek and Destroy on that unit location. When the search is over, they will go back to loiter The script is highly configurable and customizable You can configure which units type will spawn. This way, you can use any mods, as long as you tell the script the classnames of the units/groups you want to use You can inject custom scripts that can be executed at : Trigger creation Trigger activation Trigger deactivation Trigger cleared (when all spawned units are dead) More informations on GitHub