opusfmspol

@Gunter Severloh, I suppose it's not the word "time" that's the issue, it's the word "waste". What is waste? In refining, it's the slag. Raw ore goes in and the product is run off; but whatever's left over is the slag, cast off and disregarded. The product is the tin, the iron, the copper, the silver, the gold. All things precious. ("Precious": because of Tolkein and the brainwashing black boxes we live with, it invokes the word "Gollum" to mind, but is that what I'm speaking of here? I mean what's actually near and dear in each of our hearts. The things we treasure in our hearts and our minds, the things we appreciate. Should a parent look at their child and go, "Gollum"; or should we break the brainwashing and cast that aside?) We're all individuals. We all have things precious to us. All things precious to me may not be precious to you, and all things precious to you may not be precious to me. Those things precious to you clearly are not all precious to whoever criticized. But it seems they have their things precious too, which it seems you don't appreciate as they do. They look upon your time in Arma as a heap of slag, and they seek gold. Yet in your own eyes, what they see as slag is golden. Is that a paradox? No. It's human, it's humanity, it's who we are. We all have different values, and we all value the same things differently. I'm in the U.S., and here in the early 1800's there was a card game called Faro that was more popular than poker or blackjack and played in all the saloons whether for money or for fun. How do you suppose the people in the saloons would have reacted had someone come in and told the Faro players, "You're wasting time, those cards aren't real; the real world lies outside those cards!" I figure first you'd hear, "These cards are real", and they'd be right. Then you'd hear, "If I'm wasting time, whose time is it I'm wasting?" Anyone who might say it's a waste of your time would be more truthful to say "It's a waste of time to me." They're projecting if saying it's a waste of your time. We all live from point A to point B (whether we go on to point C, you decide). Simple fact is, from the moment we're conceived, we're doomed to die and we get a dash between two numbers. So what do we do with that time that we have? We live, we work, we rest. Some have more and harder work than others, some have more and greater rest than others. Some have more and better life than others. Make the best with what time we've got. Family; don't neglect family. But sing it brother, there's a song in there. And if a preacher can't preach about that, he's got no Spirit in him. Reality is that Arma, for most of us (because for some it is a job, putting bread and butter on the table), it's entertainment, it's amusement. We all seek entertainment, we crave it, because in life we have stresses and distresses all around us; and like a field laborer longing for the shade, we seek relief. And when we get it, relief itself is short-lived, it's not enough, we want amusement. I've heard it said that "amusement" comes from the Greek word "muse", which means to have in mind, to think. To a-muse is the antithesis, the opposite, to put out of mind, not to think. Think of what? The labor, the stresses and distresses we have to deal with. If we rest without entertainment, we think about those things. We don't want to muse on them, we want to be amused. And some people take their amusement seriously, like you do, and admittedly, so do I. What you're doing is taking your bit of shade that you found seriously; constructing a lean-to, making a mattress, adding a pillow. And others who share the shade with you appreciate that, because you share your stuff with them. The laborer expects his wage; to you and those around you, it's silver and gold. Those looking on from afar say, a trash heap; what a bunch of waste. It's not a waste. It's what you choose to do with your time in the shade. All I would suggest is, don't ever let the time resting in the shade detract from the work, or the life (i.e., family as well as friend time).

If a script is run repetitively, over and over again, you want to compile and run it as a function. Whether done using CfgFunctions in a Description.ext, or by using: THY_fnc_mainBasesProtection = Compile PreprocessFileLineNumbers "FolderName\mainBasesProtection.sqf"; . . . the file will only be compiled once, and the function can be called or spawned over and over again without it being recompiled. execVM compiles the script every time it gets used, and that takes away processer time that could be used elsewhere. So you would use ExecVM for scripts that are only run once, or remain persistent (like looping updates, which the base protection script sounds like), or scripts that are needed, but rarely get run. This is good strong advice (IMHO), because your mission might not use a CfgRemoteExec in the Description.ext, but you won't always know whether an addon that will be used has within its config a RemoteExec restriction against clients running the ExecVM command. On dedicated server, Player is objNull. If it has to be run by server, you may need to cycle through allPlayers array and determine who is inside the base limits. But on client, Player command will always return the object which is the client player's unit. It's different on every machine. So if the script is only applying immortality to a player, and nothing else, it should likely be run from initPlayerLocal.sqf

With that many tasks I would resort to a mission flow FSM to handle them the way BIS tends to do, but you may be unfamiliar with FSM's so.... - You spawn or execvm a loop that handles setting the task states. This way you have a single go-to script for testing whenever tasks get added in or modified. - At the start, before the loop begins, you declare flag variables. These flags prevent their specific task blocks from running more than once. - Inside the loop, each task gets checked to see if its condition is met. If so, the task state gets handled and the flag gets set. - Each task has its own condition to satisfy, but it also checks the flag variable, in order to disregard after the task has already been handled. Very basic and simplified: And if one task is dependent on another being completed, that too can be added into the condition using its flag variable: if (<task04 condition is true> && _task_02 && !_task_04) then {_task_04 = true; <set task state completed>};

That would be correct, player object changes to a different object on respawn. No need to copy it over, the loop continues until player disconnects. Just use Player command (or update the player object "_rc" each loop), and use condition that player is Alive for the info to update. While {true} do { if (Alive Player) then { hint . . . . }; Sleep 1; };

Why not have initPlayerLocal execVM the script? The remotExec and BIS_fnc_ExecVM seem unnecessary, and the remotExec 0 seems like it would be the issue.

Says it's "RemoteExec Restriction", is CfgRemoteExec being used with mode restrictions applied? I wouldn't know the answer myself, haven't as yet ever used a CfgRemoteExec in a mission.

I would suggest: 1) End the onMapSingleClick code with true or false, to tell the engine whether to include default engine handling. An example of default handling is, when player is the commander of a vehicle, clicking on map tells the driver where to move. Would you want that sort of engine click behavior included with the map click? - Ending onMapSingleClick with true tells the engine the code completes the click action, do not include the default engine handling. - Ending onMapSingleClick with false tells the engine the code does not complete the click action, also include the default engine handling. 2) Only use onMapSingleClick to get the pos. After that, have the addAction code do the work, but also handle interruption, i.e. the player chooses to close the map without selecting a position. At the end of addAction, clear the map click (onMapSingleClick ""). A very basic example: openMap true; hint "information"; PosClicked = false; _target onMapSingleClick {ClickPosition = _pos; PosClicked = true; true}; WaitUntil {Sleep 0.1; (PosClicked || !visibleMap}; PosClicked = false; if (visibleMap) then { // do the marker and waypoint stuff openMap false; }; onMapSingleClick ""; hintSilent "";

Assuming _targetMarker is a marker, it should be: if (_x distance (getMarkerPos _targetMarker) <= 30) then Is this the idea? (expanding from what @ZaellixA has above) Private ["_cars","_maxDist","_minDist","_nearest","_unit"]; _cars = [car01,car02,car03]; _nearest = objNull; _maxDist = 100000; _minDist = 30; ScopeName "DangerClose"; { _unit = _x; if (isPlayer _unit && Alive _unit) then { { if (_unit Distance _x < _maxDist) then { _maxDist = _unit Distance _x; _nearest = _unit; if (_maxDist < _minDist) then {BreakTo "DangerClose";}; }; } forEach _cars; }; } forEach playableUnits; // Something now happens.

_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?