cameroon

You can put this in your init.sqf { _x setMarkerAlpha 0; } for each ["marker1","marker2","markerEtc"]; Obviously replace the marker names with those you use for EOS ;)

Getting AI helicopter's to stay landed (or to land at all) can be brutal. I ended up creating a pair of functions that make it easier for me to accomplish and in general it seems to be working well for me. If you want, take a look at the file dynamicTransports in this sandbox I was using to create themhttps://dl.dropboxusercontent.com/u/8018430/DynamicHeliTransports.Stratis.zip. You can ignore/remove the EOS stuff, that's just there because I was testing it out. Essentially, the various behavior modifiers (e.g. CARELESS) are there because the AI pilots are extremely likely to simply fly off if they know about any enemies. I really want to be able to flag a helicopter as primarily a transport and have that modify it's priorities. Since that doesn't exist, this is what I ended up with. The loadAt is actually the hardest, because there has to be some way to tell the AI that it's loaded. I wrote in two methods, either by providing a variable to watch (which would let a radio trigger or some other event tell it to take off) or to pass in a group, in which case it will wait until the group is loaded. I've tested it out in SP, local hosting and dedicated and it worked fine in all of them. Feel free to use, modify or ignore as needed ;)

The units are still assigned to the vehicle, which is why they try to get back in: { unassignVehicle _x } forEach [s1,s2,s3,s4,s5,s6,s7,s8]; or { unassignVehicle _x} forEach (units (group s1)) if s1-s8 are in one group I was actually just working on building a reasonable solution to having some helicopter transports with escorts helicopters, since ideally you'd want the escorts and transports to travel together. Hopefully I'm allowed to post links now, since I have a demonstration mission that works great (assuming the helicopter pilots don't kill themselves or each other of course): https://dl.dropboxusercontent.com/u/8018430/TransportDemo_2.Stratis.zip The "loadAt" function expects to rejoin an original group to rejoin. Sadly I have to make it temporarily leave its original group, it just refused to work properly otherwise. Anyway, feel free to look at the mission and the scripts and use any of the parts that work for you. I went with using radio triggers instead of trying to detect when everyone was loaded or unloaded, but really the triggers are just methods to get to calling the loadAt and unloadAt functions in a reliable demonstration. You could do it by detecting distance, height - whatever.

I've been going crazy trying to figure out why my testing of a co-op mission on a dedicated server would silently desync. In this mission, a player needs to have a couple AI units join the player's group. This works fine in single player, but as soon as I put it on a dedicated server I'd end up returning to base only to see that everything had come to a stand-still. As far as I understand it, the "join" and "joinSilent" commands are global actions with global effects, so I wasn't expecting this to be a problem. This portion of code (_crew is the vehicle crew group) runs on every client at init, the addAction shows up just fine { _x addAction [ "Secure Crew", { _target = _this select 0; _caller = _this select 1; missionData setVariable ["CrewSecured",true,true]; (units (group _target)) joinSilent (group _caller); }, nil, 0, true, true, "", "!(missionData getVariable [""CrewSecured"",false])" ]; } forEach (units _crew); However, when the action executes the two AI units in question join my group and then a few seconds later the server AI units (or at least those on the WEST side) come to a stop. I can tell exactly when it happens, because the traffic from #monitor will go from ~100Kbps out to ~10-7Kbps. If I take out the (units (group _target)) joinSilent (group _caller);, then there's no problems but of course joining is kind of needed. I also tried setting the group of the caller in a missionData (a Game Logic) variable and then executing the join command from the machine where the group leader was local, but that didn't help any (I didn't think it would, but I'd hoped!). I've been searching the forums and Google for hours, so I apologize if this is something that actually is covered somewhere. I'm really hoping someone has some insight to this.

I was able to figure out what was happening. When I created the crew to be secured, I stored a reference to the unit objects themselves. A pair of triggers was checking whether they were dead or had been returned to base. Turns out, that if the units change locality, then what I was doing is bad and seems to break whichever side the units were on (other sides seem to keep going, but I haven't tested that exhaustively). What I ended up doing instead was to use setVariable on the unit objects for the crew and then use something like { alive _x && _x getVariable["myvar",false] } count allUnits in order to count the number of crew that are alive.

Awesome, I'm glad they're working for you!

I hope I hear back from Norrin, I've been working on a variety of tweaks and updates for my own missions. Convoy's behave much better going through urban areas and should generally cause less of a performance penalty, particularly if something causes an obstruction in confined space like city streets and I think I've gotten rid of all the potential infinite loops that could keep the convoy stuck (like if a driver can't get back in due to pathing problems). I've also been adding some fun things, like evac:

Following up on my earlier post, I've fixed the issues with the convoy restarting (except for if there's not enough transport; I still need to look at that): First, we need to stop ejecting units that the script exempted in convoyMove. convoyRestart.sqf, replace line 20 with the following: { _tmpVcl = vehicle _x; if( (driver _tmpVcl) != _x && (gunner _tmpVcl) != _x && (commander _tmpVcl) != _x ) then { unAssignVehicle _x; [_x] allowGetIn false; doStop _x; }; }forEach _units; Next, we need to make sure that convoyMaxSpeed does not get stuck in an infinite while loop: convoyMaxSpeed.sqf, change line 25 to exit it's movement loop while {alive _vcl && !(_vcl getVariable "NORRN_convoyDestination") && _vcl distance _vcl2 > 60} do { convoyMaxSpeed.sqf, change line 38 for the same reason while {alive _vcl && !(_vcl getVariable "NORRN_convoyDestination") && _vcl distance _vcl3 < 40} do { I also commented out lines 19 and 20 in convoyMaxSpeed.sqf because the loop in convoyMove already takes care of those checks. I'm not sure that you have to (leaving them in _might_ make them react to ambush more quickly). Without these changes, when a convoy unit was killed and the convoy restarts, there would be at least two scripts fighting to set the velocity to potentially two separate destinations. This is obviously bad. ;) Additionally a dead unit might never exit the while loop since it could never reach its destination. The changes to lines 25 & 38 check that the vehicle is alive and also that some other portion of the script hasn't told it to exit (Norrin uses that NORRN_convoyDestination flag generically, it does not mean it reached the end just that the convoy has been told to stop). I'll submit these changes to Norrin and look at the other potential infinite loop problem in convoyRestart later - still, for anyone using the convoy scripts, this should let you get them behaving as expected. EDIT Another bug now that they restart, turns out the marker list being passed to the restart didn't actually have the already-passed markers removed. Replace convoyMove.sqf, line 32 with: _markersRemaining = _markersRemaining - [_marker];

Yeah, getting them restarted seems to be a problem. Here's what I've discovered so far: In convoryRestart.sqf, there appears to be a bug at line 20. The script kicks everyone out when an ambush happens (in convoyMove), unless they are a tank or helicopter crew. However, at restart it unassigns and kicks everyone out again - including tank and helicopter crews (which seems ill-advised for a heli). Then it tells everyone to get back in using a variable that says which vehicle they were assigned to. However, tank and helicopter crews don't have this variable assigned since they weren't ejected to begin with. What happens is that the tank crew hops out and won't get back in while everyone else remounts their vehicles. Then the restart script sits waiting for everyone to board and so never restarts. That can be avoided by changing line 20 to the following: { _tmpVcl = vehicle _x; if( (driver _tmpVcl) != _x && (gunner _tmpVcl) != _x && (commander _tmpVcl) != _x ) then { unAssignVehicle _x; [_x] allowGetIn false; doStop _x; }; }forEach _units; That gets everyone loaded and the convoy will restart, but then something else is not right and after about 20-50 meters or so, the convoy will come to a near halt. Sometimes (possibly only when the lead vehicle is hit) they'll get started and then 2-3 seconds later come to a complete halt and dismount again, in which case they won't start moving at all (although they seem to remount). There's also a problem if (for whatever reason) a unit or units won't get back into a vehicle. In this case, the script seems to just wait and wait and wait and wait (lines 55-60 in convoyRestart). I'm thinking about ways to deal with that, possibly after a certain amount of time just using a moveIn command in case they're stuck for some reason. Alternatively, it might work to drop them from the convoy if they won't load up.

Hi Pipyn, I recently did something very similar to this and it turns out that it's a bit of a pain, but it is possible to do. I described some of the issues with it in feedback report 16443 at feedback[dot]arma3[dot]com (argh, can't post the link directly), but I'll try to describe how to make it work. Initial setup 1. Create your helicopters as separate groups (that is, make sure they are NOT linked in the editor) 2. In each helo's init portion, assign that helo's group to a variable (e.g. escortHeloGroup1 = group escortHelo1; ) 3. In the transport helo's init, also have it load the troops 4. Create some markers on the map, they're going to be used to create waypoints dynamically so you can just make them invisible Scripting 1. In init.sqf, join your escort helo's to the primary helo group ([escortHelo1] joinSilent transportHeloGroup) - this way the escorts can follow the transport in 2. Use a trigger or waypoint activation script (or whatever logic) to re-assign the escort helos' to their original groups (e.g. [escortHelo1] joinSilent escortHeloGroup1) when the escorts should split off 3. Use addWaypoint to dynamically add some LOITER or SAD (or whatever) waypoints are needed for your escort helos - this is why I created the markers, since then it's easy to add waypoints for the escorts 4. After your TR UNLOAD fires and your troops unload, you should be able to join the helos together however you want. Note that TR UNLOAD can be very tricky to make work correctly, _particularly_ if your transport is under fire. In this case you really have to use the CARELESS combat mode for the transport so that it ignores the fact that it's taking fire. In my feedback I have a sample mission that shows some broken behavior with TR UNLOAD and/or waypoint synchronization with dynamically created groups, which is why there's some convoluted setup in order to make this work. If my description of how to get it to do what you want isn't enough, let me know and I can provide my "messing around" mission that has it all working. In that script, I have 2 transports and an escort. The transports split and fly to different LZs and the escort provides area security. The helo's remain in the area on Search and Destroy waypoints. I'm not sure what the etiquette is for linking to missions and what-not, so I'll PM you with it if you want to check it out.