opusfmspol

_groupToSpawn = objNull; Should be: _groupToSpawn = configNull; Makes no difference when using isNull. Makes every difference when using typeName. In case you -have- to use typeName at some point, it's wise to always keep the variable data types consistent.

I see. In that case, disregard grpJoined (used for group tracking) and create a new group for the created unit to join. _newGrp = CreateGroup West; // or whichever side player is on. _newUnit = _newGrp createUnit [typeOf _oldUnit, getMarkerPos "PlayerRespawn",[],0,"NONE"]; Military Symbols (MARTA) runs an fsm on the local (player) machine which determines which markers are shown. The fsm is persistent, it doesn't stop until player ends mission. It uses playerSide, Group Player and Faction; mostly it comes down to what side a player is on as to which markers are seen (can be custom set for factions). And as previously said, killed units become civilian, which maybe effects visibility during switch. After switch completes and player is back to proper side, the markers should restore.

private _OrigSquad = groupID group _OrigSquadLead; private _ReinSquadName = _OrigSquad + " Reinserts"; private _SQDCounter = _OrigSquad + "_Squad_Pack_Counter"; Here, yes; _ReinSquadName and _SQDCounter are now private variables containing the given strings as they were joined. _ReinSquadName = missionNamespace getVariable [_ReinSquadName, objNull]; _SQDCounter = missionNamespace getVariable [_SQDCounter, objNull]; Here, no; missionNamespace is the global namespace attached to the mission. It doesn't see private variables in scripts. You can either declare a global variable using the private variable, and the global variable gets created in missionNamespace: ReinSquadName = _ReinSquadName; or you can use setVariable to the missionNamespace as @Harzach showed. With setVariable to missionNamespace, you can use the public param to broadcast it for multiplayer. When doing getVariable, you would want to make sure the default is the right data type, or you could end up with errors in code, but that depends of course on how you're using it; here it sounds like you were specifically watching for objNull instead of string, for purpose of a test.

[_oldUnit] join grpnull; _newUnit = group _oldUnit createUnit [typeOf _oldUnit, getMarkerPos "PlayerRespawn",[],0,"NONE"]; You're having the new unit created in a new group different than the original group. Units killed are civilian and have their own show rules, apparently different than whichever side your playing. You can set custom rules for civilian to block showing any markers while switching. in init file: grpJoined = Group player; in PlayerRespawn file: _newUnit = grpJoined createUnit [typeOf _oldUnit, getMarkerPos "PlayerRespawn",[],0,"NONE"]; or if you don't want the new unit in the original group, create a new group for your side, then createUnit using that group. (not tested)

Because _LZNameID is a private variable (local variable, assigned private to a scope), it's kept within the scope of the script. The script sees it in the scope where it's defined; however onMapSingleClick runs in a separate scope of its own and can't see it. Define a global variable, like LZMark, within the script, and onMapSingleClick can see that - global meaning visible everywhere on the local machine where it gets defined. Any scope of all scripts run by the machine will be able to see it. But if it needs to be a public variable, where all machines connected in multiplayer also have the variable because their scripts will need it; first the variable gets defined global on the local machine, then publicVariable is used to broadcast it to all the other machines. Variable scopes Edit --- See if this is what you intended (not tested):

The code for onMapSingleClick is a separate scope from the rest of the script. Change _LZNameTXT from private variable to global: LZNameTXT; then it can be seen inside the onMapSingleClick. (And I don't see LZMark defined, I assume you have this string defined elsewhere, or is _LZNameID supposed to be LZMark?) As @Schatten pointed out, when you're referencing a variable defined outside of the onMapSingleClick, it has to be global for onMapSingleClick to see it. It won't see the private variables, they're out of scope. And same for variables that get defined inside onMapSingleClick, like your _marker variable; to be seen outside of the onMapSingleClick it has to be global, not private, because onMapSingleClick has its own scope apart from the rest of the script. As to strings, @Harzach rightly points out that semi-quotes ( ' ' ) are used to represent a string within a string expression ( " " ). If semi-quotes aren't used, then double-quotes ( """") get used, which can become a pain to explain or comprehend how they work when the engine runs the string expression. Semi-quotes make it much simpler to understand and use. But as Schatten showed, for onMapSingleClick either string or code can be used and by using code, you no longer have the string-within-string happening, so: onMapSingleClick ' ' (semi-quotes), perhaps should be onMapSingleClick "" (normal string), maybe same with 'Land_HelipadCivil_F'.

The error is indicating you haven't assigned a group as huntgrp1. In the script _grp is nil, thus an undefined variable error on _grp.

If they are Indy by config default and you're spawning them to East, the issue most likely is that BIS_fnc_spawnGroup uses Syntax 1 (main syntax) of createUnit, _unit = _grp createUnit [_type, _itemPos, [], 0, "FORM"]; and you're having them created in a group not consistent with their config side. First spawn them for their config side, then have them join a new created East group.

A loop in a code is no big deal if done right, it can be a big deal if done wrong. They have so many uses and advantages, one purpose being that a loop serves as an update; this gets updated, and that gets updated, to keep things current. And that's what your loop is doing, it's keeping the "respawn_guerrila" marker near the INDEP_Roger_Ball object. But as you point out, a real question is whether the marker needs constant updating of its position. You might instead consider using addEventHandler with a killed or mpkilled event handler (depending on whether SP or MP), to have the marker moved by the killed event, rather than a continuous loop.

Having the trigger repeatable, and set to spawn the function when activated, should take care of the Hunter pursuing the Hunted each time the Hunted enters the zone. The function's condition (select 4) and return (select 5) params are what would make the Hunter RTB whenever the Hunted leaves the zone. The function's params are: [ select 0: GROUP - The group that is the Hunter. Default: grpNull. select 1: GROUP - The group that will be Hunted. Default: grpNull. select 2: (OPTIONAL) - NUMBER: How often (in seconds) the Hunter updates their waypoint at the Hunted leader's pos. Default: 10 (minimum 5). select 3: (OPTIONAL) - NUMBER: Radius (in meters) of the Hunter's new waypoint from the Hunted leader's pos. Default: 0 meters. select 4: (OPTIONAL) - CODE: Condition that gets evaluated to end the hunt. Default {false}. select 5: (OPTIONAL) - STRING or ARRAY (POSITION) or OBJECT or NUMBER: Where the Hunter goes when the hunting ends. Default: 0. Can be one of: STRING: Name of a marker. ARRAY: Position (Hunter gets a waypoint with position inserted: [_position,0]). OBJECT: Existing object (Hunter gets a waypoint with object position inserted: [(GetPos _object),0]). NUMBER: 0 - Hunter returns to original given waypoints. 1 - Hunter stays at current position, searching around. 2 - Hunter returns to the position they began hunting from (when the script began). ] As I mentioned previously, the condition code (select 4) gets evaluated using isNil, which can be used to run a complex expression if necessary, but at the end must be an expression returning true or false. And in this discussion I had mentioned before that there can be a problem with using 0 (which is default) for the return parameter (select 5), when empty groups are getting deleted. Hope this helps.

while {alive player} do { _trg = createTrigger ["EmptyDetector", markerPos "marker_2"]; _trg setTriggerArea [ 500 , 500 , 0 , false]; _trg setTriggerActivation ["EAST", "PRESENT", true]; _trg setTriggerStatements ["this", "", ""]; funx = _trg ; sleep (.5); What's the purpose of these neverending triggers being created, with same variable name reassigned each time, until player dies? Am I missing something?

Have you tried listing magazines before weapons? Perhaps setUnitLoadout is using the commands addWeapon and addMagazine in the order given? And if so, this comment from @.kju would be relevant.

The _x is the element being cycled within the count, when _classnames are counted. {typeOf _synced == _x} count _classnames > 0 - or - {_synced isKindOf _x} count _classnames > 0 The count condition creates a separate magic variable scope within the forEach. That's why the cycled object _x gets redefined as _synced. Then you can have a comparison that in a way says "if (that _x isKindOf this _x) ....".

The "grantUnlimitedAmmo" function gets used by all, client and server, so compiling it should be done in the init.sqf: The spawn is a server update loop, it has the server update the array UNLAMMO_ARR and has living units not already running the "grantUnlimitedAmmo" function run that function where they are local. As @Harzach points out, it should be moved to the InitServer.sqf, and you need to change the BIS_fnc_MP call to RemoteExec. As I see it, UNLAMMO_ARR is a server-only variable. Unless clients also need of an UNLAMMO_ARR array, this: can be changed to this in initServer.sqf: And this is not good: Inside the forEach, you're deleting from the array being cycled by the forEach. It messes up the cycle. And when more than one unit is null, they all get removed at one go ( UNLAMMO_ARR - [objNull] ). Cycle a copy of the array instead of the array itself, and remove the null units first: The grantUnlimitedAmmo function is an update getting run on each local unit, by server and clients. Being a cycled update with suspension, use remoteExec and not remoteExecCall. The problem the function has (as I see it) is that: -1): _primeWpn can return an emty string. That means _magazineType will return an empty array. -2) _magazineType can return an empty array, wherein there is no "Select 0" to select from. This results in _magazineType being undefined. And the code is not conditioned to handle that. The sequence should be, I think: Hope this is helpful.

_magazineType = getArray(configFile >> "cfgWeapons" >> _primeWpn >> "magazines") select 0; When getArray returns an empty array, there is no _magazineType to select.

For helos, here's copy of a script I've used in my missions for years to have a helo circle a team, usually a support helo though. Should the helo be enemy, when it becomes aware of the circled unit or team, it will engage. The radius, angle and height can be adjusted to suit. The script's credit belongs to @demonized, @neokika and @jkhaaja, one of their postings in the forums years ago was where I picked it up, and it was so long I don't recall the forum post. The leader being circled: ldr The helo doing the circling: transport

what is / are Nicholas_wp_1 and 2?

When using multiple groups, the groups get identified individually, and the script is run for each instance of a stalking: group A pursuing group B. Don't limit yourself to BIS_grpStalkers and BIS_grpPlayer, those are example identifiers given for a single group stalking (BIS_grpStalkers) and a single group to be stalked (BIS_grpPlayer). Identify a group to do stalking, and a group for them to stalk (it can be the same group another is already pursuing). Run the script for the two groups. You can do it in unit init fields, or in an init script, or a trigger. A_1_handle = [grpA, grp1] Spawn BIS_fnc_stalk; // grpA pursues grp1 B_1_handle = [grpB, grp1] Spawn BIS_fnc_stalk; // grpB pursues grp1 C_1_handle = [grpC, grp1] Spawn BIS_fnc_stalk; // grpC pursues grp1 D_2_handle = [grpD, grp2] Spawn BIS_fnc_stalk; // grpD pursues grp2 E_2_handle = [grpE, grp2] Spawn BIS_fnc_stalk; // grpE pursues grp2 The condition code is optional, a condition to end the stalking. It gets checked each iteration (default 10 seconds) using isNil, as in: isNil {WhateverThisCodeReturns}, then whether the return is true or false. Because isNil evaluates the expression, and it could be a complex expression, it can first be used to set the stalking group's current waypoint to SAD before returning the true/false condition. But be very careful about that, 1) there can be no suspension, 2) don't make the code complex, keep it simple, and 3) the final code must be the return giving TRUE or FALSE, for ending the stalking. Example: // grpB pursues grp1 until all units in grp1 are dead, then returns to base (original start position). B_1_handle = [grpB, grp1,10,0,{[grpB,currentWaypoint grpB] setWaypointType "SAD"; {Alive _x} Count (Units grp1) == 0},(Position Leader grpB)] Spawn BIS_fnc_stalk; Zoom on a leader in editor, there is also a box for editing the group he is in. You can name his group there. Or old school, in a leader init field you can put "myGroupName = group this;"

Not tested, but: _marker = ["MARKER",_group] Call BIS_marta_getParams; - should provide a group's marker. Then you might try using setMarkerSizeLocal on the returned marker.

Editor triggers exist on every machine unless set to be server-only. So when the unit enters the trigger, everyone including the dedicated server runs the teleport script on the unit. They're getting their own clientOwner and remoteExec the cutText to themselves. - Set the trigger to server-only. - Set the trigger onActivation to remotExec "teleport.sqf" where the unit entering the trigger is local. - Since the local machine runs the script, no need to get clientOwner or remotExec cutText. Just condition cutText to occur only when Not isDedicated, and then only when _victim isEqualTo Player.

The function's code can be viewed using the Functions Viewer (configFile -> A3 -> Combat). It uses copyWaypoints command, but doesn't copy a waypoint's statements. Whether the command itself would copy the statements over, I don't know, wiki doesn't say and I haven't tested. But if groups are being deleted when empty, using 0 might be problematic. At start, the function creates a group and a unit, copies waypoints from the stalker group, then deletes the unit, leaving the empty group holding the waypoints. When stalking ends and endDestination == 0, the waypoints of the empty group are copied back to the stalker group. If empty group has been deleted, wouldn't those waypoints be gone as well? Any endDestination other than 0, it uses addWaypoint and doesn't add any waypoint statements.

I would suggest a server-only trigger with condition something like: {_x In [Hostage1,Hostage2]} Count thisList == {Alive _x} Count [Hostage1,Hostage2] The owner is a group. If the hostages are grouped, it could work by setting it to "whole group" present. But might be problematic (killed units go to grpNull, but still register in the team until the leader realizes they're dead, "We lost 2!"). But I don't suspect you would want the hostages grouped, would you? I miss ShackTac doing "Dark Business" missions, who would ever forget after watching "Giggles The Carjacker".

There's also the command mapGridPosition.

The code for the BIS_fnc_unitPlay function can be reviewed in the Functions Viewer, it lists under configfile -> A2OA -> scenes. And reviewing, you can see that it only sets the value True. I had first thought it odd you had to post that the function only sets value as true, I was aware of that from using it in OA. But now I realize why, seeing that the function in A3 is different from the one in OA (updated, revised, whatever...). The function in OA explained in its header description that whatever variable was given would be set 'True'. But the header of the function in A3 is a bit less detailed, and doesn't mention that particular fact; and the wiki entry currently follows suit with that. I think the wiki entry would benefit by being updated, in its "varDone" section, to read "Variable to set true on specified Object once playback has finished". But I too can't make an entry on the wiki.

Make a rectangular trigger (set to server only) that is larger than the marker, so the trigger size lines out the intended distance of the player from the marker, and have the trigger spawn the forces.