opusfmspol

Most maps contain "Hill", "RockArea" or "Viewpoint" locations. nearestLocations can find them, and locationPosition returns [x,y,z], where z is -1 * getTerrainHeightASL at the location. Not a real answer I know, since there's no knowing a location would exist on the actual highest point of a particular map, but maybe something to ponder.

You can view in Config Viewer to see what classes and values are present.

Variables containing arrays are a reference to an array. That means when an array gets changed (i.e., resized), all the variables that refer to that array will also see and reflect that change. _units = units group leader; // Gets the (units group) array. _unitsToDelete = _units; // Both _units and _unitsToDelete now refer to the same array. _units resize 3; // Both _units and _unitsToDelete change (they refer to the same array). _unitsToDelete = _unitsToDelete - _units; //Both _units and _unitsToDelete become empty; they're the same array. To prevent a change in one variable from affecting other variables through array reference, you make a copy of the array. _units = +(units group _leader); // Makes a separate copy of the (units group) array. _unitsToDelete = +_units; // Makes a separate copy of the _units array. _units resize 3; // Doesn't effect the _unitsToDelete array by reference. _unitsToDelete = _unitsToDelete - _units; // Doesn't effect the _units array by reference.

Edit: [deleted] , deferred to @pierremgi and @7erra.

I've used the headset piece for 8 years @Gunter Severloh, also mainly for flying, and had to replace twice. Once it was the clip part of the clip-on that failed, the other time it was the hinge part of the clip-on that failed, both times (I admit) it resulted from rough handling. Once from dropping the headset, the clip broke; once from grabbing the lower IR extension instead of the mic (which pivots up and down), and that made the hinge fail rather than breaking the IR extender. I used duct tape until the replacements arrived. The last time I also got an extra one to have on hand, anticipating it could happen again. It works fine and I'm content, but I've found the contentment with it really depends on the headset being used. There are five headsets around our house, on two of them it fits fine, two of them it won't fit at all because the braces are too large for the clip and the slide adjusters are far too high on the head, and one (the headset I use) it has to be manipulated a bit to fit secure over the brace, because the slide is too high on the head, but this leaves stress on the clip and hinge, thus I have to anticipate another potential failure in the future. I expect that if or when I do replace this headset, I should take the TrackIR clip with me to make sure the setup I get is one that the clip will fit onto properly without the IR extender getting confused for a mic. The alternative is wearing a hat (the hat clip you mentioned), but not all are inclined to wear a hat with headphones. I have to use headphones, so sound doesn't disturb others in the house, thus I stick with the headset clip, though I have had frustration when it fails. But I also consider the particular headset I use results in the high tension on it, and that the TrackIR manufacturer can't anticipate for every style of headset the headset manufacturers are going to make.

RemoteExec also targets a side, so you should just be able to put West.

May we all be blessed with such suckiness. "Of all the things I've lost over time, I miss my mind the most." - I can't recall who said that . . . . To reiterate some basic debugging techniques, in case they be forgotten: - 1) The Debug Console is a tremendous help, but it doesn't always provide an answer by itself. - 2) When debugging a problematic script, use the startup parameter -showScriptErrors. When an error occurs, a black box appears which displays the error (on the machine which encounters the error; sometimes client has an error but server doesn't, and vice versa). The appearance of the black box helps one to observe exactly when an error occurs as the mission goes on. - 3) Use the .rpt log to your advantage. It logs what the error was that occurred. This means when debugging a problem script, you do not want to use the startup parameter -noLogs, as that prevent errors from getting logged to the .rpt file. The .rpt file logs the errors in sequence as they occur, and one who is debugging can review them in depth and at leisure to determine what's going wrong. A casual gamer would want to use the -noLogs param to maybe prevent a huge spam .rpt log getting generated, if perhaps it affects gameplay, but when debugging a problem script, one should not use -noLogs, they would want the log generated. -4) When no errors are getting thrown, but the results are still unexpected, use diag_log and diag_log format in your code to send messages and variable values to the .rpt log for review. I could not possibly list the number of times I've had to resort to this method in the end, when all else failed, and achieved success. A simple nonsense Example: And when the problem gets resolved, you go back to remove all the diag_logs and diag_log formats from the code which are no longer needed. Hope this helps.

I don't know the exact answer to that. I suspect the behavior is controlled by internally used .fsm's, but could be wrong. From observation, they report "Ready" when a command is given and they complete the command. (Or maybe a better way to say it is that an action gets commanded, and they complete the action, because not every command will provoke a response of "Ready" from them.) They report "Ready to fire" when restricted from firing, but are given a target and they have acquired the target in their sights (regardless whether they are in formation).

unitReady page doesn't reflect its locality, but be aware it should be run where the unit being checked is local. My own testing in the past showed the unitReady command only gave an accurate return on the machine where the unit was local. When the command was run on a machine where the unit was not local, it always returned true, regardless whether the unit was ready or not ready. And that caused scripts and fsm's which were relying on it to jump the gun, advancing instead of waiting.

A manual call to have the unit report status (unit -> 5 ->5) should do it, but I agree, I too don't understand why it doesn't update automatically, even if it were done silently. I think it's reflecting the last status reported by the unit. Maybe an fsm or event handler I'm unaware of is what sets it at orange, but doesn't continue monitoring to automatically change it back.

Assuming you want each group to have a global variable so you can work with them outside this particular code block or outside the script, first you would declare the index before the while-do, then you would use call compile format : (not tested) _spawnMarkers = ['enemySpawn_4', 'enemySpawn_5', 'enemySpawn_6']; _groupIndex = 0; //initial index while {true} do { _enemyGroup = [getMarkerPos (selectRandom _spawnMarkers), east, (configFile >> 'CfgGroups' >> 'East' >> 'CUP_O_RU' >> 'Infantry_Ratnik_Summer' >> 'InfAssault')] call BIS_fnc_spawnGroup; // Define the group by the index# (septemberGroup0, septemberGroup1, septemberGroup2, etc.), Call Compile Format ['septemberGroup%1 = _enemyGroup',_groupIndex]; _SADwp = _enemyGroup addWaypoint [getPos waveTrg3, 0]; _SADwp setWaypointType 'SAD'; { if(_x inArea waveTrg3 && alive _x) then {_enemyGroup reveal _x} } forEach allUnits; { defend3 reveal _x; apc4 reveal _x; _x forcespeed 10; _x setSkill 0.8; _x allowFleeing 0; } forEach units _enemyGroup; _enemyGroup setBehaviour 'COMBAT'; _enemyGroup setSpeedMode 'FULL'; waitUntil {{alive _x} count units _enemyGroup < 5 }; //waits for previous group to have less than 5 units alive _groupIndex = _groupIndex + 1; //add +1 to index number for new group to be created sleep 1; }; - Format creates the string: "septemberGroup0 = _enemyGroup" - Compile converts the string to code: {septemberGroup0 = _enemyGroup} - Call runs the code; you then have the variable defined so you can work with it. - And as index increases, the strings contain "septemberGroup1", "septemberGroup2", etc. Assuming the server is running this: if clients also needed to work with those group variables, then you would use publicVariable to broadcast to all; but first format the variable to include its index. After the call compile format line, you would insert: publicVariable Format ['septemberGroup%1',_groupIndex];

Not certain, but I think it's: configfile >> "CfgInGameUI" >> "CommandBar" >> "UnitInfo" >> "UnitStatus" It has a "colorNoAmmo" array. Looking these up in configViewer, I didn't see idd or idc's.

Depending on which scripts you have running the code, it could be an Order of Initialization issue: - In single player, the init.sqf runs before the initServer.sqf, initPlayerLocal.sqf and the initPlayerServer.sqf. But in multiplayer init.sqf runs last of all. - In all cases, Server runs the initServer, but joined Clients don't. - While Server runs the initServer, the joined Clients instead run initPlayerLocal. - After these, a hosted Server runs initPlayerLocal for the host player. - The Server then runs the initPlayerServer as players join. - All these run in scheduled environment, which can also effect timing, as it gets impacted by the workload. So it depends on what is run before the other. It's possible that Clients call the _satReliability function while Server is still doing its own initializing, and they have not yet received the publicVariable. In which case you could wait for spotterChance to be defined on client before having client call the function.

Player is a different unit on every connected machine, and a dedicated server has no player. You need to use assigned variables (variable names) for units and then run getPos on them by that means.

@Billy EatWorld , The image you show (the RscGroupRootMenu) is not listed in the Description.ext , so you couldn't add anything to it from there. Whether it could be patched by creating an addon, someone else would have to say. But the "Supports" menu is customizable by using BIS_fnc_addCommMenuItem and BIS_fnc_removeCommMenuItem , and that can be used to add the sort of custom team management function you seek; maybe consider it as a "Team Communications" type of support and assign it the radio or instructor icons. I looked into A2 Warfare to see how it provided the menus for a leader to "dismiss" selected units (actually kills them off though), or "send" selected units off to another team (reassigns their group). In A3, one can build similar custom menus for that, and access it in the comms menu (under "Supports"). Below is an example, for a team-switch scenario. Note: I found that the hardest thing about doing a Communication Menu is figuring out the use of the simple expressions, so that a particular menu item will appear or disappear, or is active or inactive, when you properly want it to do so, without relying on BIS_fnc_addCommMenuItem and BIS_fnc_removeCommMenuItem. I'm not going to go into how simple expressions work, I'm just going to use the "IsLeader" expression to ensure that the group leader can see and use the menus, but a switchable subordinate (not the leader) can only see the menus, not use them. Example: Find the mission folder, create a description.ext file inside it, and add this: description.ext Then create an initPlayerLocal.sqf in the mission folder, and add this: initPlayerLocal.sqf Save the mission. Launch, and play around with the support menu and the teamswitch function, to see how the menus respond between being leader and non-leader. And if not satisfied with the "dismiss" and "reassign" action results, change the remoteExecs to something you'd prefer, maybe run a function instead. Just remember that the code lies within an "expression" string, where you have to use semi-quotes ( ' ' ) instead of actual quotes ( " " ). Hope this helps.