pierremgi

Absolutely! Perhaps a parameter for radio in game setting (say min distance for AI report) ? + things to be improved anyway: avoid dumb AI leader ordering to unconscious units ! avoid dumb stand-in AI leader to order different actions than the previous ones (by player) when player is unconscious. Trying to cope with an immediate situation, ordering to jump into distant and not accurate vehicle(s) (but previously used if I'm right), or move to a previous wpt, or whatever bad idea, is just a waste of engine code! You can even hear (and inherit after heal) some "cease fire" totally weird while in combat behavior. Your group is upside down when you recover the health. All of this is not implemented when the leader player is dead-respawn and it's far better! https://forums.bohemia.net/forums/topic/143930-general-discussion-dev-branch/?do=findComment&comment=3367077

Check your six!

I give up. Continue to be happy with that. Just let me think that's horrible to hear each minute "what's your position?" for an insight AI team as you split your group (you know for a pincer attack), no matter you're gamer or simmer! and Nothing to do about a "lung question" when everyone is static... Roger Out (not implemented).

Each time you can use a local (underscored) variable, it's better, especially if you have many inner codes (scopes in fact) inside other ones. You don't need these variables at every scope of a script. But, IMHO, if you define a local variable on main scope of a script/ sqf, this difference is not great. So it's on your side to decide if _AIside is OK everywhere it should be, and use it preferably. Don't forget: a global variable runs globally on a PC (locally, not broadcast) on every sqf file you run for the mission. There is no more "scope" question in missionNameSpace. See also other name spaces. Each time you want to have a specific global variable for objects / units (like loadout), you can use the set/getVariable commands which allow handy distinctive strings, in a one line code: For example, {_x setVariable ["LDT"+name _x , getUnitLoadout _x] } forEach allUnits; Now, in MP, you need to understand where the scripts are mandatory: server, clients, everywhere... The event scripts are fine. For variables, if you run a common script, say init.sqf, each PC will run it at due time (when player is starting the mission). The global variables are working locally. That means independently. If you write myCount = 0 in init.sqf, along with some script for increasing it, all JIP will have 0 but the players in game will have their own different values. That can be weird. You need to publicVariable them, each time you need to broadcast them, for the same data everywhere. If you setVariable something, add the 3rd parameter TRUE in the array and don't forget to do that, each time the variable data changes. Public or not public? Try to understand how and where scripts and variables works. No need to share (broadcast) some common data like kill count. When a unit dies, all PCs are able to work independently for the same result (here count). On the other hand, you'll have to share some data which are elaborated locally (server or client), on a local event/code, but not everywhere. If you need that all PCs work with a common data coming from one PC, then make it public.

Really? I must justify a team mate player can be 150m in front of one of these guys, at clear distance view, without having to suffer these totally useless and repetitive position reports? wow!

Just go close to car/door/heli. Well sometimes you would like your unit able to reach and jump into a car without seeing it when you order that. If on map select unit and click on vehicle/heli etc and that's. There are plenty of cases you can't see the vehicle on map. If I'm wrong, just remove the pages and pages of mount menu (4).

But perfectible in SP. If you split your group for 2 different combat actions (let's say 400m distant, but it's same for several km!!!): Something like: 2,3,4,5 go here; 6,7,8 do something else. When you'll order a general regroup, you'll see 6,7,8 rejoining your 2 (???) to finally regroup on you, no matter if 6,7,8 was very close from you and 2,3,4,5 very far. No interest and counter-intuitive in far most of the cases. But it's so clever to make 2 as deputy leader! Problem, he's dumb. In MP now? , erffff... Good luck with that (not assigned but easily reproducible)

Disagree. You're free to find useful an AI asking every minute for your position when you're running on a runway of airfield, 150 m in front of the AI! At this level of absurd, let's add a "Mum, mum, where are you?" Veteran is a choice, not a common usage. Let's speak about regular. So, if you're familiar with the "worst", you'll understand it's not satisfactory for many other players. BI should improve that mess. Action menu (6) is jammed by all available weapons (never mind if it's impossible to reach them) at top of the list!, before the inventory (the Sit down and salute is probably never used and it's a good example of dev skill => dev overdo).

{ _x addEventHandler ["Reloaded",{ params ["_unit", "_weapon", "_muzzle", "_newMagazine", "_oldMagazine"]; systemChat str [_unit,_weapon,_muzzle,_newMagazine,_oldMagazine]; if (_weapon find "Katiba" >-1) then { if (magazines _unit findIf {_x == _oldMagazine #0} < 0) then { _unit addMagazines [_oldMagazine #0, 3]; } } }] } forEach (allUnits select {!isplayer _x}); You just need to replace "Katiba" by a working string from your class name (whole or not, case SenSiTiVe)

+ all aircraft towing, from hangars to aprons, or else.

Is there anything to do, not referring to an umpteenth workaround or script, for the constant dialog of Ais asking for the player (leader) position every time the distance is greater than 150m? Really? Nothing else than shutting/allowing general comms? It's utterly stupid and boring. Did you never try, in five years, to lead an AI group, in stealth mission, with stealth behavior and AIs opening fire for nuts if you forget to hold fire? That plus the same dialog flow for nuts, even if whispered, are totally unrealistic. I finally thought that: when one dev knows how to do something, dialog reports that is to say, the game uses and abuses of the feature, no matter what it could be the real world or for the game play (as another example, see the whole pages of command actions for jumping into an existing vehicle or grabbing a weapon on ground: pages and pages of scrolling menu, no matter the distance, no real clever limitation). There are so much weird features, not really bugs, who could be improved with some considerations for tickets and reports. May I suggest to open a list, offical and updated, WITH priorities voted by the community? Or, we are just

Yes it's possible. Why not? What was your script and the error in rpt file? Modules can be used.

For sure! Animations are so "optimized" in term of code, that you have to "heal yourself" in front of a damaged vehicle for repairing it. A repair animation exists but for a reason, devs prefer the healing one (with the little sound of a vial, it's so cute!).

That's 2 separate events if you're not too close to a black hole horizon. Key down is something "repeatable", lasting the time you press the key. These is no reason to do that for key up. If you want to make these codes interact, try to add a conditional variable: for key down: if ((_dikCode in actionKeys "MoveForward" && isNil "blaBlaKey") then { blaBlaKey = true; your code....}; for key up : if (_dikCode in actionKeys "MoveForward") then { blaBlaKey = nil; your code...} (not tested)

Sorry, I can't reproduce this problem. Try with: player switchMove "" in initPlayerLocal.sqf. No other clue so far.

Anyway the question stays: who fights who? Give all your factions the side you want. And you can modify the relationship with setFriend while in game. BLUE vs RED only means they will fight each others by default. No matter the country/faction. Just limited by imagination and too often cliché. GREEN are BLUE friendly, RED enemy or the contrary via editor. CIVILIAN says "don't shoot at me. I have a diplomatic immunity", but they are enemy to RED by default (just give them a weapon!) Slightly different than captive who fall in CIV but keep their feeling (unilateral relationship) against other sides This way, setting relationship (don't forget both ways), you can have 4 camps fighting like 4 armies. For very bad trip, you can use RENEGADE. Enemy to anyone! Bilateral: this aspect is not often used because the rating of AIs doesn't often fall below -2000! IMHO, the only missing point, impossible to workaround, is to keep a good relationship between renegade guys from the same group (faction?). This way, you could fight group against group, which is not possible so far.

setVelocity is not supposed to be persistent and never gives a destination (waypoint). So it's normal that engine stops, wheels don't turn, like the truck at stop. The good question is: what do you intend to do with that? There is probably (not sure) another solution.

Only issue I'm running into is, when I use one of the "at ease" units they spawn at my spawn point (as they should) but the unit stays where I placed it in editor, duplicating the unit. Could you elaborate? What script are you using? I can't understand the duplication, simply using an animation. Replacement?? Do you teleport the player at start? Sync problem between server and client?

In fact, you can break the loop if you hold a key like "forward" while the animation ends. (Tested with the codes above) But it's better to add a: player switchMove "" in the initPlayerLocal.sqf for example.

Stay logic! triggerActivated trigger1 && (Player1 in thisList OR Player2 in thisList)

As you spoke about editor, I gave you a script to be written in init field of the edited object, on each launcher/radar/UAV... you want to modify the side.

Oups my bad! In editor you can't connect "group to" on a leader. I checked what workaround I did by the past. It's simple: In the init field of the launcher: if(isServer) then {this spawn {_grp = createGroup EAST; [_this] joinsilent _grp}} This way, you can choose the side.

yes. I guess viper01 is also the vehicle player. So no problem for writing what you want as far as you're in vehicle... But I don't really understand the viper01 doMove position player in this case... Perhaps needed to fly at a new altitude. That doesn't hurt.

Yes, I was on one anim only. For course, if you want the "ease" one you need to create another function fn_ease or else and call it by the remote execution.

First of all, you can easily replace getPosATL CoPilot01 select 2 by the altitude of the vehicle itself: getPosATL viper01 select 2 same for (vehicle CoPilot01) flyInHeight _endAlt, Then, are you sure you are in the gunner seat as copilot? Depending on helo, the gunners are sometimes at doors, and the copilot is (always) at turret [0] see Viper01 turretUnit [0] instead of gunner Viper01 For driver, less problem. Just in case the turret is [-1]