itn

That's too bad, but thanks for the reply.

Sorry for the somewhat long text but I wanted to make this reply as comprehensive as I could to make the point as clear as possible. You have received specific, actionable feedback and requests for specific files to be exluded. In my opinion you do not address that specific feedback regarding CMDS luas. The argument is not for or against pure scripts IC (PSIC) altogether. The argument is that you should exclude CMDS luas from PSIC. Including them is user-hostile unless good reason has been demonstrated for the restriction. What happened with 2.8, supposedly a quality of life update, is that for this part we lost some QOL which we would like back. Specifically the ability to edit CMDS luas. We're not asking you to support any 3rd party DTC mods either, we're just asking you not to actively hinder the experience or remove the "feature" we've had before, unless for a good reason. Especially for ED's own modules I think it's hard to argue for including CMDS luas in PSIC. - If there are known exploits, you should fix them. Why would you let people suffer from known exploits, with or without PSIC? - If there are no known exploits or other, truly relevant adverse effects on other players in MP, they should not be included in PSIC. Including them has caused QOL issues with no concrete benefits to anyone. Exclude them for at least as long as you implement saved CM programs / DTCs in-game, which we're all eagerly waiting for. - If 3rd party modules (planes/helicopters) are an issue, make them fix their stuff. Do keep their CMDS luas in PSIC if there are known exploits, or if there is a strong possibility for such exploits. For example if they have huge luas with lots of stuff, I'd say they belong under PSIC. (NOTE: I don't know much about 3rd party planes and if they have similar CMDS luas or not). The fact that PSIC is optional for server admins does not justify too far-reaching IC. Server option should be a secondary aspect, to limit the negative effects that cannot be removed even after trying to make the PSIC itself as user-friendly as possible. if you gave server admins these two options, mostly I think they'd choose only the first one, not both: - Prevent who knows which exploits might lurk in LUAs now or in the future [ ] - Prevent pre-made custom CMS programs with no known exploits whatsoever [ ] At the moment the server options is more like: "Prevent who knows which exploits might lurk in LUAs now or in the future, and prevent pre-made custom CMS programs [ ]". It's the latter part we have issue with and why we're asking for limited exclusions. I sincerely thank you for the efforts to restrict cheating and trying to make the MP experience as level as possible. It's not easy. This time I think you have overreached and hope that you'll find the proper balance. Thanks, itn

Have you checked your axis tune (curves)? There might have been some changes to defaults there.

Small correction: Speedbrakes won't open automatically from 43 to full 60 degrees. They stay in the limited 43 degrees position. However, after you have weight on nose landing gear, you can extend speedbrakes to the full 60 degrees position and they will stay fully open without having to keep the switch depressed.

In your screenshot time in briefing is 17:30 and time on ded is 14:31 (not 16:30). The 3h difference between DED and briefing is because of time zones. DED time defaults to UTC. Syria is UTC+3 so local time is 3h ahead. Mission Editor and briefing show local times.

Like Exorcet said. Functionally I would say no difference, you can set them up the same way. However, if you can spare the buttons (like the 3-way switch in TM Warthog throttle), I would recommend to always use MSL mode for A-A. You can pre-set radar and displays for Air-to-Air in MSL mode, while keeping the normal mode setup for NAV. And on an Air-to-Ground mission it's even more useful. Setup normal mode for A-G (or NAV enroute, to A-G at fence in or whatnot). Then you can just use use MSL OVRD to check the airspace for friendly formations, enemy fighters etc. before going back to AG in one simple switch, and continuing with your e.g. strike mission with all the displays setup. And if you get a threat call about hostiles nearby, again your a2a mode is just one MSL OVRD away. Very useful. After trying out MSL override mode, I pretty much never use normal "A-A mode", my normal mode is always in NAV or A-G and MSL is what I use for A-A. Of course, each to their own and this is just my two cents.

I think you should be able to do a squat fix (ground overfly) before departure. You would use a known location with a steerpoint on it. Steerpoint is represented to three-digit accuracy, so it would be more accurate. Based on my quick test on the ground, i'm not sure if the ground overfly update works as it should. And in current DCS context, if GPS in available, It Just Works and you need not bother with any of this. Without GPS you need to provide in-flight FIXes due to inaccuracies and INS drift.

Simply round the Degree Decimal Minutes (DDM) coordinates from three to one decimal when entering them for INS alignment. If you're in a freshly pitted cold start jet, the coordinates should match so you will just confirm the coordinates and elevation each with ENTR (and dobber down to switch line).

Just so others know: Sent a PM to BN. They will see if the functionality/document reference is valid for DCS variant.

Issue still in current OB (DCS 2.7.15.26783 Open Beta). Auto sequencing should not operate when in manual ACAL, FIX or A/G. Now that we have ACAL and FIX in game, I have attached a track showing auto sequencing in all three. @BIGNEWY care to take a look? Thanks. STPT auto sequencing (ACAL-FIX-AG).trk

It's easy to replicate and see with time acceleration. Attached is another track. I used Unlimited Fuel to prevent any weight and CoG effects. HOTAS completely disconnected, using only keyboard and mouse. The pitch-up is slow but it's there, easily seen after I disable AP (04:04:00 cockpit time) and time acceleration is on. Pitch (time accel).trk

Good question about the TMS aft, and it's something I left out somewhat on purpose because I'm not sure how it should actually work and if it's actually CZ or not. I'm no expert and have no IRL experience so I'm talking about the in-game and public IRL information there is. In practice I think often you can just TMS aft your way back to the STPT and I think that's in my muscle memory by now. I guess you could verify if TMS aft is truly Cursor Zero by seeing if using TMS aft also slews FCR to the STPT, or if only TGP is slewed. If both go, this would indicate it's truly Cursor Zero and not for example some kind of "TGP only" function. If only TGP slewed, then it seems like it's some kind of pod function (true to IRL or maybe a bug in DCS) and not actual Cursor Zero. In one unclassified Basic Employment Manual (BEM) from an air force operating block 30/52 Vipers and LANTIRN, in one part it instructs the pilot to get in the habit of TMS AFT and CZ. So it seems at least in those non-"USAF/ANG circa 2007 Vipers with LITENING" you couldn't use TMS aft to CZ. You use TMS Aft to break track and then CZ to CZ. But it's a different variant, different user, different pod so I wouldn't call this as proper evidence to how it should work in the DCS variant. And again, CZ is independent of SOI so wherever you see CZ OSB and press it, it's for all sensors.

Checked the last one. I think you need to Cursor Zero (CZ). When you slew, the slew is kept in the system as a cursor delta. It is kept and transferred when you switch steerpoints. So if you have slewed, and you switch to another STPT, pod will look at that STPT offset by the delta (slew) that exists in the system. This is often not what you want, so you'll cursor zero (CZ) when you have slews and want to look at another STPT. CZ removes the delta so now it will look at exactly the STPT. That's why you want to CZ pretty much always after finished making your marks and after switching to the mark (STPT) you wish to use. No need to CZ between marks. And as I understand it, this is with all sensors and is system-wide. You can use CZ from any page where it's available (at least FCR and TGP) and it removes the cursor delta. And a helpful tip: On MARK page enter 0 and it will set current markpoint as the selected STPT. No need to go to STPT page to switch STPT after creating a markpoint.

After JFS you wait for engine to spool up to at least 20% RPM. If you want to be sure, wait for the RPM to stabilize and SEC light to extinguish (NOT lit anymore). In practice you can advance throttle to idle a bit before SEC is off but we're talking seconds here, like Northstar98 said on the second post to this thread, also marked as Solution. There's no reason to rush. If you're too early, you need a new jet or repair, so never go too early. You can actually run the JFS for quite a while, so there's never a reason to go too early and risk not having a good start. If you still have issues starting up, make sure your jet has fuel. For example in many MP servers you start with empty jet.

Try A-A mode if you're not tracking a radar target. DCS F-16C manual p. 186: And per the manual it should be slewable, but didn't seem to work when I tested while back. Not sure what you're looking for (as in a use case) but maybe HUD markpoint could be of use? Make a markpoint and input 0 on mark page to immediately select it as current STPT.

What makes most sense is to just implement GPS time functionality as it is on the jet IRL. In DCS missions with GPS available, I'd guess it would pretty much mean the same as "clock always correct (after some GPS acquisition delay on startup)". And without GPS in mission, you'd have to time hack as you should.

At least per MLU M1 Pilot's Guide you could change CRUS HOME Home Point (HMPT) without affecting current steerpoint and navigation. When you enter CRUS HOME, current steerpoint is selected as HMPT (p. 101 and figure 2-18 on p. 102). However, in CRUS HOME the steerpoint (HMPT) can be changed without affecting current STPT and navigation (p. 98). This is different from other CRUS pages. Obviously you might have better info and better references, but that's at least per the M1 guide. Best regards, itn

Please ED, could we finally get this quality of life improvement? It's literally two lines of lua and some testing. It has been requested since October 2019 (see https://forum.dcs.world/topic/215327-control-bindings-for-maintained-switches-23-position/?do=findComment&comment=215766 and other threads). Not having these by default means us who use it have to modify the lua file ourselves after every single update or repair. Even with 3rd party tools such as OvGME it gets old and feels kind of redundant and silly. For me personally it is the only dance I have to do after updates.

Hi, When in RWS and cursor over search target, target altitude is shown. If you switch to TWS, the altitude number stays on screen, statically in place, in addition to the correctly updating altitude info in TWS. This does not seem to happen if target is bugged in RWS before switching modes. However, at the very end of the attached track, you see there's again the ghost altitude number which somehow got back there when switching around, even after "clearing" the static, bugging in RWS and then switching to TWS. Steps to reproduce: 1. FCR in RWS and a contact on screen. 2. Slew cursor over contact (do not bug) - elevation is shown. 3. Switch to TWS. What happens: The altitude that was shown in RWS stays in screen, in addition to the correct, moving and updating number shown in TWS. Fastest way to see the bug is to change range scale and note the static altitude text stays in place. To clear the static number, switch back to RWS. If going back to TWS, bug the target first or slew cursor away from it so no altitude is shown. Current Open Beta (DCS 2.7.15.25026) Track attached. F16-RWS2TWS-ghost-elevation-text.trk

Quite sure it's not implemented yet. A few patches back I did some quick tests with similar results.

Hi, I think desertowl's bug report and later messages are quite clear. Some of the replies are somewhat confused about what the bug is about. It's not about getting a successful MAV lock, it's about the TGP commanding the MAV to lock (handoff) when it is in manual handoff mode and it should not attempt handoff. Strictly speaking I think the bug is: "MAV WPN page shows HANDOFF IN PROGRESS text when TGP is in manual handoff mode and TGP acquires point track." Not sure if the bit about TMS right in MAN mode is a bug (or unrealistic) or not. It would seem plausible to me that TMS right might be usable for handoff in MAN mode. In any case, I think it's quite clear TGP should not attempt completely automatic handoff after point track when you're in manual handoff mode. Attached is a track that works for me, where I demonstrate the issue. HANDOFF text shown when TGP in MAN mode. Note that the bug is not about getting MAV to lock or not, it's about attempting the handoff (lock) or not. And I think the manual and Wags' videos are quite clear about the meaning of "handoff". For example, see this earlier video (timestamped link). In PRE mode, both in MAN and AUTO handoff mode MAV seeker head slews with TGP. Handoff is specifically about commanding the MAV lock automatically or not. Best regards, itn F16-AGM65D-MAN-AUTO-handoff.trk

As the issue you describe sounds quite dramatic, I would check controls first. Seriously, check that you don't have any new axis or button bindings making weird stuff happen, like kicking the rudder or opening speedbrakes and whatnot. Other than that, post tracks, videos, ACMI and at least be a bit more specific about the loadout, weather, altitude etc. All I'm saying is that these discussions tend to get so muddy so fast, it's best if there are specific conditions where you have issues, so people can test as close to those same conditions as possible.

I think you're trying to do different, exclusive things at once. 4 (single/separate?) supersonic HARM launches and long-range missions are somewhat exclusive goals. If fuel is limiting your HARM practice, you could just set unlimited fuel for that specific practice. In any case it boils down to loadouts, mission planning and fuel/energy management while flying. Viper can have long legs, but it cannot have heavy, draggy loadout, high speed and long legs all at the same time. You have to compromise. But you'll be surprised what it can do when flown optimally and with a proper loadout. Some extra tips, even if this might be offtopic for your specific question about AAR: - Stay off afterburner as much as possible. On takeoffs use it as necessary for the loadout and environment. EDIT: Of course, also use AB when the situation or weapon employment calls for it, but for example don't climb with AB if not necessary. - In general, be mindful of your throttle and speed on long cruise legs. There are real life and I'm sure DCS charts and previous forum discussions available to suggest some optimal climb profiles and cruise speeds. Testing and experimentation was an eye-opener for me personally. Charts and discussions are good starters and I suggest looking them up, but Mission Editor is how you practice and learn .

True. The manuals are incorrect, as in they do not reflect DCS in its current state. CMS Left functionality came possibly with SEMI/AUTO modes or with the ECM pod. All subject to change of course and I'm specifically just stating the way it works in DCS OB at the moment. I can see how this might come handy especially with the towed decoys.

If you modify the CMDS lua manually as suggested by SCPanda, you have to re-do the changes after updates (if the file changes) and after repairs. DiCE ( https://www.digitalcombatsimulator.com/en/files/3312680/ ) is nice. It modifies the files "real-time", so it just works.