Grumpy Old Man

Wrong classname maybe? {_x removeWeapon binocular _x} forEach crew _vehicle This snippet never failed me. Cheers

The binocular command returns a string, maybe you got it mixed up somewhere? Cheers

You can also work with a simple parabolic formula for bullet trajectories, since arma doesn't simulate coriolis force, earth curvature or air friction for bullets. This page has saved me many headaches, heh. You can get all values either from config (ammo muzzle speed at launch, etc.) or from model (barrel direction vector), just make sure you're using ASL positions. This way your artillery gun will be able to do direct fire and actually hit its target. Cheers

Was there? Can't remember, heh. Should be in \scripts\GOM\functions -> GOM_fnc_aircraftLoadoutInit.sqf Line 1952: _obj nearEntities ["Air",50] With 50 being the distance, if I'm not missing anything. Cheers

I believe you won't even notice 200 of those checks happening at the same time. Cheers

Glad you got it sorted, and posted the solution instead of [solved], heh. As @Harzach stated, string is a data type that can contain text. Variable handles (or identifiers) like _value can hold any data type (like numbers, arrays, code, etc.). The format command automatically converts any passed variable into string, like so: _text = "Ten"; _number = 10; _howToGetTen = {5 + 5}; hint format ["How to get %1(%2): %3",_text, _number, _howToGetTen]; Cheers

Maybe they're firing at a game logic entity or some other hidden object other than the lasertarget? Other than disabling scripts/mods and enabling them one by one, there's not much to do if you want to get to the bottom of it. Also try putting the misbehaving units targetsQuery into the log via diag_log, might be worth a try. Cheers

Just had a quick glance over it and noticed the same error with "_text" as above (string instead format) in this line: _cam cameraEffect ["Internal", "Back", "_text"]; Cheers

I believe this line to be the culprit: _tv setObjectTexture [_add,"#(argb,512,512,1)r2t(_text,1)"]; Second parameter is a string. Try this to properly pass _text: _tv setObjectTexture [_add,format["#(argb,512,512,1)r2t(%1,1)",_text]]; At least that one's sticking out for me, heh. Might do the trick. Cheers

Local variables will only exist inside the scope(and child scopes) you created them. You can pass the local variable to another script as parameter or, as mentioned above simply use a global variable (which might not be what you want depending on what you're trying to achieve). You can also use setVariable/getVariable and use objects/units/groups etc. to save and retrieve those variables. I'd only use global variables as a last resort, since they can be overridden by other scripts/mods using the same variable names. Cheers

This won't really work in MP and due to logical errors, since there's no "player" in MP, at least on dedicated. Depends on if you're on dedicated or locally hosted MP, or on SP, needs an individual solution in any case. Also no need for _loups100 array in the first place, unless you need it somewhere else. Something like this might do the trick: _chasseurs = createGroup east; _pos = getMarkerPos "inf500"; _unit20 = _chasseurs createUnit ["O_G_Soldier_F", getMarkerPos "inf500", [], 0, "FORM"]; _unit30 = _chasseurs createUnit ["O_G_Soldier_lite_F", getMarkerPos "inf500", [], 0, "FORM"]; _unit40 = _chasseurs createUnit ["O_G_medic_F", getMarkerPos "inf500", [], 0, "FORM"]; _unit50 = _chasseurs createUnit ["O_G_Soldier_LAT_F", getMarkerPos "inf500", [], 0, "FORM"]; _unit60 = _chasseurs createUnit ["O_G_officer_F", getMarkerPos "inf500", [], 0, "FORM"]; _approach = [_chasseurs,_pos] spawn { params ["_grp","_pos"]; leader _grp globalChat "Waiting"; _validTargets = []; waituntil { sleep 1; _validTargets = (playableUnits select {isPlayer _x AND alive _x AND (_x distance _pos) <= 2200});systemchat str _validTargets; count _validTargets > 0 }; _target = _validTargets#0; leader _grp globalChat format ["Engaging %1!",name _target]; _grp move getPosATL _target; }; You can use _chasseurs, since this is already the group, to issue the move order. No need to give move orders to individual units. To test this in SP you'd need to replace playableUnits with allPlayers or similar. Cheers

"0" + _x simply adds a leading zero to the string, so if _x is "5" it will turn into "05". serverTime is global and automatically synced every 5 minutes, so no manual sync needed. Cheers

Few things: You can avoid this: { if (_x isequalto "1") then {_clock say3D ["01", 70, 1];} ; if (_x isequalto "2") then {_clock say3D ["02", 70, 1];} ; if (_x isequalto "3") then {_clock say3D ["03", 70, 1];} ; if (_x isequalto "4") then {_clock say3D ["04", 70, 1];} ; if (_x isequalto "5") then {_clock say3D ["05", 70, 1];} ; if (_x isequalto "6") then {_clock say3D ["06", 70, 1];} ; if (_x isequalto "7") then {_clock say3D ["07", 70, 1];} ; if (_x isequalto "8") then {_clock say3D ["08", 70, 1];} ; if (_x isequalto "9") then {_clock say3D ["09", 70, 1];} ; if (_x isequalto "0") then {_clock say3D ["00", 70, 1];} ; sleep 5; } forEach [ _firstnum, _secondnum, _thirdnum, _fourthnum] ; By doing that: { _clock say3D ["0" + _x, 70, 1] sleep 5; } forEach [ _firstnum, _secondnum, _thirdnum, _fourthnum]; Since you want to say single digit numbers and it's a finite amount of known strings ("00" -> "09") this should do fine. You could even rename all sound cfgs to "0"->"9" to avoid the "0" + _x entirely. From what I know, last time I checked say3D uses some kind of queue, you could try ditching the sleep inside the foreach, all sounds should still play in order, might have changed though. Also don't use sleep for your timer, build it around time instead, for guaranteed accuracy, since sleep can suspend for more than the given duration, depending on scheduler load. Cheers

Not 100% sure but I guess filenames with spaces get the space replaced with %20, so you need to replace spaces with underscores: sound[] = {"\sound\Free_-_All_Right_Now.ogg", db+0, 1.0}; Might give that a try. Cheers

Looks nice, not the kind of RPG script you'd usually expect around here. Neat that you added a way to write lines for it in .csv format and convert it via python script. I'm sure lots of mission makers will benefit from this, especially with those kind of features (integrated script execution depending on answer in .csv, nice). Cheers

Also a good practice to make variable names as unique as possible, to avoid complications with script commands, BI variables as well as other third party scripts/addons. In case of the threadstarter variables could come with a prefix like AG_, then probably some descriptor like _obj_ or _rsc_, so in case of fuel it could be AG_rsc_fuel or AG_obj_jerryCan1 etc. Well worth it in the long run. Cheers

Only use remoteExec where locality commands it. The wiki usually displays command/argument locality for each specific command at the top. Most usual cases for remoteExec are playing sounds via say/say3D, chat commands, hints. Then there are some other commands that require to be executed where an object is local. Not sure I've seen bis_fnc_call before, maybe it's deprecated similar to bis_fnc_mp? Looks like it's adding another call/spawn command, so doubt it's doing anything different to just using the function/command itself, definitely needs someone else to clear that up though. Cheers

For MP you need to add this on a respawn EH on the player unit, or in onPlayerRespawn.sqf or similar. Cheers

Check this out, should get you started, fairly easy to adapt. Cheers

This is by no means an easy task, especially considering that magazine classes not always have a tracer version, nor are the classnames consistent enough to make a reliable script without thorough error checking (gets into nightmare territory if you want to include compatibility to other mods). You can check for tracer mags like this: _allMagazines = "getNumber (_x >> 'scope') >= 2" configClasses (configFile >> "CfgMagazines") apply {configName _x}; _allTracers = "getNumber (_x >> 'tracersEvery') > 0" configClasses (configFile >> "CfgMagazines") apply {configName _x}; Magazines that act like tracers have the tracerEvery value above 0. Sometimes tracer magazine classnames include the name of the color, sometimes it's simply named with a "tracer" suffix. A solution would be to compare magazines by iterating through the (at most 3 deep from what I can tell) getUnitLoadout nested array, and replace it with a similar named mag from the tracer array, like this: //while iterating over getUnitLoadout array _allValidTracers = _allTracers select {toUpper _x find toUpper _mag >= 0}; if (count _allValidTracers > 0) then {/*replace element*/};//might pick a random one or the first element, should be a tracer in any case It's probably faster and more fool proof to make 4-5 custom unit loadouts using tracers to achieve what you want. Cheers

You can use the returned string to check if the marker has been created successfully. Marker creation can fail if the marker name is already used by a marker, the createMarker command returns an empty string in that case. Cheers

Ideas to what? You didn't provide any useful information: Cheers

You can also pre-heat the tank without the engine. Cheers

A simple knowsabout check should do it. If the player knows about a unit, the information immediately jumps above 0 and is shared with all other members of the group. You can check for player or group player, makes no difference: group player knowsabout targetoff > 0 Cheers

Can be quite a headache to do with waypoints alone, here's a little snippet that might do the trick: _nul = [] spawn { _dropOff = getMarkerPos "Chopper_DropOff"; _pickUp = getMarkerPos "Chopper_Evac"; _chopper = chopper; _passengerSlots = count (fullCrew [_chopper,"cargo",true]); _civs = allUnits select {_x getVariable ["TAG_fnc_chopperEvac",false]}; _transportedCivs = 0; hintSilent format ["Starting Evac\n%1 civilians\n%2 -> %3\n%4meters\n%5: %6 passenger slots\n%7 trips",count _civs,_pickUp,_dropOff,_pickUp distance2D _dropOff,typeOf _chopper,_passengerSlots,ceil (count _civs / _passengerSlots)]; while {alive _chopper AND _transportedCivs < count _civs} do { _civsToBoard = _civs select [0,_passengerSlots]; _civs = _civs - _civsToBoard; systemchat "Moving to pickup location"; _chopper move _pickUp; waitUntil {unitReady driver _chopper}; systemchat "Landing"; _chopper land "GET IN"; waitUntil {unitReady driver _chopper AND (getPosATLVisual _chopper #2< 1)}; systemchat format ["Boarding %1",_civsToBoard]; {_x assignAsCargo _chopper} forEach _civsToBoard; _civsToBoard allowGetIn true; _civsToBoard orderGetIn true; waitUntil {count (_civsToBoard arrayIntersect crew _chopper) isEqualTo count _civsToBoard}; _chopper land "NONE"; _chopper move _dropOff; systemchat "Moving to dropoff"; waitUntil {unitReady driver _chopper}; systemchat "Dropping off"; _chopper land "GET OUT"; waitUntil {unitReady driver _chopper AND (getPosATLVisual _chopper #2< 1)}; _civsToBoard allowGetIn false; _civsToBoard orderGetIn false; systemchat "Unloading"; waitUntil {count (_civsToBoard arrayIntersect crew _chopper) isEqualTo 0}; {unassignVehicle _x} forEach _civsToBoard; _civsToBoard = []; sleep 3; }; }; To get started you can mark civilians for evac by putting this into the init field of each civilian: this setVariable ["TAG_fnc_chopperEvac",true]; You can select multiple units, then right click one of them to edit all of their init fields at once, less hassle. Then you place two markers, as named in the snippet above. To guarantee the chopper landing at the marker also place an invisible helipad. The chopper will fly between pickup and dropoff markers and transport all marked civilians, after the job is done the chopper will remain at the dropoff location. Should get you started, you can easily delete civs at the dropOff location, or delete the chopper if it's no longer needed, add a gunship escort, what have you. Note that this is a barebones version, the chopper might react differently when under fire, same goes for the civilians. This snippet also doesn't take into account if one of the civilians dies. Cheers