Recluse

Hey quick question: Based on some limited testing, I believe the answer is NO, but can the FCR pick up infantry??

I saw a similar thing when taking over the track. I think it is something odd with the sequence of events here...because when I cycled the MAV seeker to INS and then Back to IRMV, made sure the target was locked, it fired normally, and I could lock another target with the same sequence (UNCAGE/IRMV/LOCK)and fire normally. It SHOULDN'T MATTER, but this is DCS after all.... if everything is in constraints (gear/nozzles) BEFORE you got to IRMV and the seeker locks, everything should work fine.

When I watch your .trk, I see your nozzles are forward by about 40 degrees. You can't fire weapons with the Nozzles that far forward. I think 20 degrees is the max, but best to be at 0. The BEEP on pickle is due to TONE boxed on the STRS page

Well considering I just updated my beta branch, that ship has sailed, but I now consider that one the Stable Version The "Stable" version is so out of date the update would have taken twice as long.

This is probably a FAQ but maybe bears repeating here in light of the harmonized installs. What is the recommended way of DELETING another install since a lot of us might have had a STABLE and BETA install and now there is no need. I updated to my previous Open Beta folder, but have an OLD Stable Install that I haven't updated in quite a long time but I could never bring myself to delete it. The time has come!!!

DEFINITELY SIM MODE. The issue is when I first jump into a plane, ANY PLANE it all works perfectly. It is only after I get shot down (or maybe ANYTIME I SWITCH CLIENT AIRCRAFT...haven't checked) it stops working. So no issues up until the aircraft switch. And, as mentioned, if I go into the CONTROLS SCREEN, even when it stops working in game, it all shows that it works there. SIMAPPRO is probably running in the background, but shouldn't matter as this is the way I have always flown. I will try shutting it down completely next time.

Lately I have been seeing something VERY ODD. I have the CORRECT PTT/Call Radio Menu comms button set on my HOTAS (the one that brings up COMM1 or COMM2 for AI comms... RALT-\, RCTRL-\ for the F/A-18, e.g. Everything works perfectly. In Multiplayer, if I get shot down and spawn into another aircraft (either the same one I was flying as a RESPAWN or a totally different available CLIENT) My HOTAS COMM1 and COMM2 buttons don't work any more. - I can go to ADJUST CONTROLS and verify that the bindings are good (Using the HOTAS control highlights the appropriate commands) - I can use the keyboard equivalent in game and it brings up the menus perfectly. - FOR SOME REASON, JUST THE HOTAS controls just no longer function in game. - EVERY OTHER HOTAS CONTROL WORKS PERFECTLY AS FAR AS I CAN TELL. WINWING ORION2 Throttle with F-15EX grips + WINWING ORION 1 F/A-18 stick. The comm switches I use are on the THROTTLE. I did a REPAIR and nothing changed. As far as I can tell it ONLY happens in MP under the conditions described.

@Chad Vader Great! I was going to suggest an ORDER issue as I have been bitten by that. BTW, my reply about the troopCarriers variable was directed at @Spankinvicar. Lots of similar issues going around

Hi, Not @cfrag but I am a HUGE fan of the UH-60L and have used it so I will take the liberty of answering. In the csarManager module (the csarManagerConfig zone) there is a variable called troopCarriers which specifies which aircraft can do CSAR. You can use ANY or ALL which will work with ANY HELO including the UH-60L or add the UH-60L separately along with other helos (or aircraft) you might want to use See the manual section 5.6.3.3 This is the configzone I have where I added the UH-60L to the demo mission using the any qualifier. null Most of the Demo missions have thorough explanations in the manual that explain everything that is going on. They are a good way to see how things work but flying them and then checking the various ZONES and how they are configured even if there isnt a manual entry for them.

I did some testing and kludged up the Herc HERCULES_CARGO.LUA logistics script (found in the AIRCRAFT\MODS\Hercules folder) and loaded MIST for it and I got Airdrops working with the Herc. I guess you could also go full CTLD.. I just loaded the units in the Herc and dropped them, rather than using any of the menu items. Managed to spawn units suitable for capturing zones.

My issue with it was if I make a FARP and populate it with support units, and use a regular ownedZone, the Rock Paper Scissors hierarchy that we observe holds. But when I use a FARPzone to auto-generate the support units, that hierarchy kind of goes out the window. Maybe it is the ownedZone code doing its magic.

@cfrag Another report on WilliePete and Multiplayer groups. Sorry that I did not capture the script errors, but maybe the description is enough, and I will try to capture them the next time. - Been using WilliePete in Multiplayer. Since we noted issues (that you described) when the FAC is part of a multi-unit group, I've been either taking a singleton FAC aircraft, or more oftenI just take one aircraft from a multi-unit group when NOBODY ELSE is flying another client in that group. I believe this issue might be related to that, but may be an issue with a singleton as well, but I don't think I have specifically noted it. - Things seem to work fine up to the point where I (the FAC aircraft) get shot down AFTER checking in and marking some targets. The Host gets deluged with script errors. My hypothesis is that the WillePete script keeps checking for the presence of the FAC after it is gone and throws the errors. Possible it is also due to the fact that even though they haven't spawned, WilliePete might also see the other units in that group (which get initialized at mission start) and looks for THEM when the spawned FAC aircraft gets shot down, but since none of them spawned, it throws errors. Just wanted to see if you had any thoughts. I will try to get the actual script errors. Also.... wondered if you had any thoughts about my post above with the odd Capture behavior of FARPzones that spawn resource units. As always, thanks for your hard work and tireless support

So there is still something weird (or I am missing the obvious) about FARP support vehicles. Here is a little mission (FARPCapTest.miz)that has a farpZone owned by RED with spawned Resource vehicles. I have a Radio trigger to trigger either 1 or 3 Blue M2A2 to enter the zone. In fact, you can trigger all four of them. They are initially set to ROE Weapons Hold and the FARP does NOT get captured when the Bradleys enter the zone. It isn't until they kill some number of the resource vehicles (when they reach WP1 with ROE Weapons Free) that the FARP is captured. NOW if I switch from a farpZone to a normal ownedZone, and place similar vehicles: (FARPCapTest2.miz) null A single M2A2 captures the zone immediately on entry. (note: I also increased the number of vehicles to 8 to mirror the FARPZone and the M2A2 still captured) If I replace these with STATIC Vehicles, (FARPCapTest3.miz) a single Bradley AGAIN captures the FARP upon entry to the zone. null FARPCapTest.miz FARPCapTest2.miz FARPCapTest3.miz

Interesting effect on farpZones since the Resource Vehicles are auto-spawned with the coalition (and country) that owns the FARP. I believe they are STATICS, so maybe they have that extra power that was observed in the testing above. I was expecting to see some hierarchy, but I didn't get a capture until the Resource static vehicles were destroyed. I didn't test exhaustively, though, so maybe a SINGLE Armor unit doesn't beat all the Resource vehicles. The armor unit WILL kill the Resource statics Before the FARP is captured, the units (or an airstrilke) have to kill all the the resource vehicles, so it requires some pretty good firepower. A squad of 4 M249 soldiers managed to eventually kill them and capture the FARP, but I guess a single infantry unit shouldn't be used as a capture element in that situation. So not sure about the hierarchy here.

I am using a unitZone to check for all units in a coalition to be gone from the zone. The flag banged by exitZone! triggers a message through messenger. Now, the message shows up at the beginning of the mission, but also triggers when it should. I AM PRETTY SURE that this is because the units being checked for are spawned from a Cloner at mission start, so, I think the slight delay at mission start BEFORE they are cloned when the zone is EMPTY is triggering the message. To test this, I set the messenger to mute and triggered the messageON? flag using a ME trigger that waits 10 seconds after mission start, and all is working, but I am wondering if there is a more elegant way to do it. It is ironic, because the last cloner issue I had was the ownership seeing the template objects at mission start BEFORE they were wiped, and now I am having the opposite issue where, even though the cloner is set to fire ON START, there is enough of a delay to trigger the exitZone! flag!! --and another unrelated question: I was experimenting with capturing zones and bases by airdropping units and paratroops from the Anubis C130 mod. It required me to load MIST and some flavor of the Hercules_Cargo.lua (or CTLD). Is this going to cause any bad interactions with DML modules? LOL.. HINT HINT could we get a DML module for dropping stuff out of Hercs (palletized Units and Paratroopers) and Broncos? (Paratroopers) as another means of capturing zones? Already works fine with HeloTroops when embarking/disembarking on the ground.

Thanks for the clarification!! I read that section over and over, and I think I was coming to the conclusion that it was just the capture circle since it talked about color, though, of course the T in the middle of the FARP has a coalition color as well. Actually, the Cloner in the FARP works PERFECTLY!! (I was surprised!) The FARP remains neutral or whatever it starts at. until the cloner fires. I recall the issue I had previously in this regard which was solved by using another cloner as SOURCE, but in this case, it seemed to work as I wanted it. Right now, I am only needing it to go from neutral to BLUE, but I will look into the strategy above to make it more versatile. In this case, actually, it is the CLONER firing a BLUE unit that actually captures the FARP vs, the CLONER getting ownership from the FARP. Kind of backwards, I know..

Thanks for this! I did go back and study up on FarpZones, and, you are right. I can pretty much do what I want with them, and a nested Cloner to supply the AI Helos. Now for my most recent discovery: I tried to use the various hidden attributes (hidden itself, and hideGrey, hideRed, hideBlue). I only tried hidden: true (or yes) and hideGrey (true or yes) and combinations of the two, but the FARP object (and the resource vehicles) were always visible on the F10 map. On mission start, the Cloner hasn't fired so the only object is the FARP. When the cloner fires, it essentially captures the FARP for BLUE. Any ideas? Mission Editor In Mission at start

Not exactly what I had in mind, but let me mess with it some more. While testing another thing came up: I created a CloneZone that contained a FARP as well as the support objects. I used this ClonerFARP as the SOURCE for a couple of other CloneZones When the Cloners activated, I got all the support units but it did not clone the FARP object itself. The FARP object (and Helos) spawned at the location of the SOURCE zone, but not at the destination zones using the ClonerFARP as SOURCE. Are FARP objects a special case? IT seems like whenever I make a CloneZone with a FARP, it does not seem to be part of the Cloner, but it spawns at mission start (the other units do not as long as onStart is false). LOL, I guess FARPS shouldn't spring from NOTHINGNESS, but hey... I will do a deeper dive into FARPZONES to see if that is another option. As long as I can live with the FARP being present, the CLONEZONE works great to populate the other units and helos.

I guess I should just TRY IT, but I will ask Can CLONE ZONES be nested? - I want to build a generic FARP CLONE ZONE to spawn when a nearby base changes ownership to allow capture helos. Wanted to just build one FARP and use it as the SOURCE. - I want to also spawn AI helos on the farp with Waypoints to the nearby base, so I wanted to clone the specific helo with the waypoints separately from the FARP source. (hence nesting the HELO Cloner inside the FARP cloner,) FOR AI, I don't really need a Real FARP, but it adds a bit to the immersion and I am thinking that CLIENT Helos can use the FARP to pick up troops to capture the bases if they choose to do so instead of letting the AI do it. - I considered spawning all the necessary helos along with the SOURCE farp and using other flags (in the ME) to PUSH the AI Task to control an uncontrolled helo (or some other method) so it will fly to the right spot. I wasn't sure if providing WPs to the helos to the desired bases in the FARP CLONEZONE, which would be distant from any of the bases would still work. I would still have to set a specific flag to start off the correct helo on its way. Again I started to test this, but I thought I would ask before I went down a rabbit hole that I couldn't climb out of. Thanks!

Thanks. Slot Blocking SEEMS To work in the FOOTHOLD missions in Single Player. Not sure if it is something in dzekeb's Zone Commande.lua or some other script in that mission, but it gave me hope

Have a bunch of questions: Looking for a good way to spawn client accessible Aircraft when a base is captured. Originally was going to use Slot Blocking, (and got that working) but would like to have it work for Single as well as Multiplayer. - I placed the clients with Late Activation and was going to use one of the flags banged on a Capture event by the correct faction to spawn them. - In the baseCaptured zone, there is a "baseOwner" that should set a flag with a value corresponding to the faction that I could use, but it doesn't seem to work. In the documentation, the "baseOwner" doesn't have the usual ! after it for an output. Should it in order to have the value captured in a Flag? Or should it get a # like the ownedBy# in the Airfield zone? - I tried to use the same flag banged on capture of the base from a certain faction, but, of course, the ME itself doesn't work well on Change or Increment, and setting the flag to TRUE (assuming it started out un-initialized) will check this. - Is there anyway for DML to do the Group Activate, or do I have to use the built in ME Triggers for that? - My understanding that I cannot use CloneZones or SpawnZones for Clients, but I didn't actually try. - I realized in my testing, I forgot to SELECT ROLE to actually check if they ACTIVATED. Forgot that the clients wouldn't show up on the F10 menu without StopGap...I also noticed that I can still enter an Inactive Client, I just get the "MISSION DELAYED" message, so slot blocking looks like the best option. Do you think it might be possible down the line to institute some kind of Single Player Slot blocking?? Thanks

I don't (yet) know how to do it in DML, but I have done it in the ME Flag section, basically creating the AND condition THERE in the conditions to trigger the appropriate clone? Flag.

Finally got to do a real MP test. - Indeed there were no more Script Errors being thrown, so the tweak seems to have worked. - Not unexpectedly, there were issues when we were in a group of more than one aircraft. We were a flight of 2 and my wingman (who was number 1) was RTB and I was hanging around slinging WilliePete. Once he got far out of the zone, it wouldn't let me check in saying I was many kilometers away, when I was really well within the zone. It probably checked position of the Flight Lead. It did let me check in the first time when we were both close together. So it makes sense to stick to Single ships or have all the flight members stay together when using WilliePete. We never did try to see what happened if BOTH of us tried to mark targets once checked in, or, in fact if it would let both of us check in, or say we were already checked in.

Be advised if you have Mavericks (any flavor) loaded, this switch will not work for the FLIR. With AGM-65F it will only change FOV on the Maverick Seeker. With AGM-65E, I don't think it does ANYTHING, but still doesn't operate on the FLIR Pods

James Brown might have been the Hardest Working Man in Show Business, but @cfrag seems to the the Hardest Working Man in DCS Utility Modding!! Thanks for all you do and your willingness to answer our (MY!) stupid questions!! o7