Recluse

The Strike Eagle has some complicated Navigation logic compared to other aircraft. For the TSD PB 9 (Bottom row, 4th from the Left is used to select ROUTE A, B, or C for Display. In your screenshot, you see the A there which means ROUTE A is displayed. The route in the F-15E are A B C the 2 represents the Steerpoint, so 2A is steerpoint 2 on Route A. "B" alone is always "STEERPOINT 0" and gets you back where you started. You will not get a route to follow if "B" is selected. IF you are following ROUTE A, you should select "1A" in the UFC. You will then see the circles in the HUD starting with Sequence Point 1 and it will auto switch to the next Sequence point (if this option is selected). To select a Steerpoint on the UFC, type in the number and Route, e.g. 3A will get you to Steerpoint 3 on ROUTE A. Be careful, because if you have TARGET POINTS you need to put a . after it. Once you have a Route in a selected Steerpoint in the UFC, it assumes you want to stay on that route So if Steerpoint 1A is selected, entering 2 will get you Steerpoint 2A. 2. will get you Target Point 2.A It may be good to uniquely specify it... 3C will get you to STP 3 Route C. IF a steerpoint doesn't exist you can create it. Scratchpad basically automates the button pushes. See the Manual: (or find any one of a number of good YOUTUBE videos. For this reason, when I use ScratchPad to enter Targets for JDAMS, I usually do it for ROUTE C, so I can use Route A for pure Navigation. Several ways to do this with ScratchPad. In the DRAKEN 35 README file there are instructions for entering a starting point (WSS) or a specific WP on the # for each Coordinate (WDES) Examples from the README: Set WSS to point 2 of route A: @<2A> Set WSS to point 1 of route C : @<1C> @|#|N 41°39.650'|E 041°50.063'|2462| -> will load in the next point of the sequence/route @|#.|N 41°39.650'|E 041°50.063'|2462| -> will load in the next TARGET point of the sequence/route @|5B|N 41°39.650'|E 041°50.063'|2462| -> will attempt to load the point in 5B @|3.A|N 41°39.650'|E 041°50.063'|2462| -> will attempt to load a target point For example, what I do when I create TARGET POINTS in route C is to enter: @<1.C> at the top and use the @|#.| for each coordinate. If I wanted a pure NAV point vs. Target, I would just leave out the .

You need to first click the little box to enable the white Dot. Once the box is checked, the +L/L will appear to insert the coords. Note: In my example below I already had some coordinates in from a previous session.

Thanks @cfrag for the detailed explanation! Makes sense.

@cfrag Don't know if this is feasible, but a little enhancement suggestion: - I have been enjoying the heck out of Willie Pete. Being able to call down the Steel Rain has been a huge force multiplier in our Foothold adventures!! As you well know, there are issues when WP initializes with GROUPS of aircraft, and issues when aircraft in groups are trying to perform the FAC role. I've taken to creating dedicated single FAC aircraft to carry out the duty. Still, when WilliePete initializes, it does a ton of work and, when Verbose, sends a TON of messages about trying to initialize Groups. Wondering if it would be possible to add a Configuration parameter for the NAME of an aircraft Group or Unit, so, for example, WP would only initialize aircraft in a group (or an individual unit named *FAC. For the UNIT designation, for example, you could have a group, "Harrier CAS" and, let's say Harrier CAS -3 had a unit name of Harrier CAS-FAC. That way, WP would initialize only that aircraft to perform the role and ignore the others in the Group. If it has to be GROUP based, they you would still have to create a separate aircraft in a Group named "HARRIER-FAC" but the overhead during the initialization process would be significantly lower (unless the work of parsing out specific names would be even MORE overhead. Maybe I haven't though this through, but presenting it for your amusement if nothing else

Agree on all points. Laser Maverick E/E2 similarly a nightmare of switchology, at least when using the TPOD for the E2 Piece of cake when someone else is doing the Lasing!! My favorite Harrier Weapon is the APKWS... much easier to use!

It was hard to tell since the .trk cut off, but when you bring up the MAV WPN video, you need to do a SSS UP to put it into IRMV mode, and then you might need to do another TDC Depress to lock it (Crosshairs snap to target). I took control and this was the case. The Maverick wasn't in IRMV mode.

I noticed something when I posted that screenshot. I never THOUGHT TO use it, but I saw that the COMMAND MENU RETURN function (which I have bound to TRIM LEFT) turns off the Menu just like the Second press of the COMM 1/COMM 2 SHOULD DO. So, you only need ONE binding to get you back to a menu removal. No need to scroll all the way down. Agree that it would be good if it just worked like other Aircraft, but the addition of that COMMAND MENU is a great Quality of LIfe improvement, especially for VR!!

This is true, as opposed to most (all?) other aircraft. You CAN, however map the new COMMAND MENU bindings for scrolling through the Comm menu and selecting the EXIT function. I use my Trim hat which works fine while the comm menu is on screen, but I have to always be careful not to ACTUALLY need to TRIM while the Comms menu is up! null

I am resurrecting this thread. Last night I was in a Hot Start F-15E with NO steerpoints set, yet, with Bullseye at "BE01" the Bullseye showed up on my Radar in exactly the spot it was on the F10 Map. I added some Steerpoints, and, following the manual tried to Change the Bullseye by typing a number into the Scratchpad and clicking PB8 with BE01. As mentioned above, NOTHING happened, but I am thinking maybe nothing SHOULD have happened. I saw some posts over in the Discord that lead me to believe that BE01 doesn't really mean Bullseye is at Steerpoint 1, but that it is the location of "BULLSEYE 01" however that it set. In the Discord, they seemed to suggest that "BE01" is a discrete steerpoint outside the other routes that can be edited as a "normal steerpoint" but I did not get a chance to try this. Can someone from RAZBAM confirm or deny the BULLSEYE LOGIC one way or the other?

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..