itn

The special options for automatic trigger safety and gear lever guards are absolutely useful and justified because we the players mostly work with simple HOTAS systems, not simpits nor a real plane. Those two options are and should be a player preference to work around physical control limitations that would never be an issue IRL, but are definitely an issue and a hindrance with basic HOTAS controls. I'm not sure I understand the change that was made to these options. Were the changes necessary for a MP sync issue in BE variant? If not, I'd really appreciate returning those two options to be strictly a player preference.

See the screenshot in darkman222's message above. The "FILE" text is a menu so just click on it to open. It's confusing everyone . You can just join a MP server, open DTC, edit it as you want. Then from FILE->Export the DTC file. Next time you connect to a server, open DTC and FILE-Import.

+1 for the tab to move to next cell, it's a basic UI functionality that should be there.

On hot ground starts it might be more debatable, but even then in my opinion it clearly should be autoloaded in avionics, as it should in air spawns. Some points to consider: A DTC would be loaded in the same process/checklist as e.g. avionics power and INS alignment. Those are all done on a DCS hot start, and so should the DTC. In general, a hot start in DCS is a way to skip the necessary cockpit simulation and to just expedite getting in to the air. Basically what I'm getting at is a "hot start on ground" is not about the pure engine startup. It's about the jet being ready to taxi. When you have a DTC this means the DTC is entered and loaded in the avionics. To me this clearly favors autoloading the DTC in avionics as what the user expects and what should happen on all types of hot start. Basically it would simulate the pilot loading DTC during the startup just like the startup manual/checklist says, and a hot start jet is ready to taxi.

In case you didnt’t know: The FILE on top of DTC interface is a menu button. Click on it and you can export a DTC file, which you can then similarly import later in any mission from the FILE menu. I agree these should be available automatically in the same way loadouts are, instead of having to import the file every time.

I don’t think that’s what I’m after. Hot/air starts should have the DTC loaded in the avionics without going through DTE or MUMI page. This should happen regardless of if a mission or client DTC is used. A mission maker obviously cannot have my personal DTC available in the mission or set as default. So say I join a random MP server and during slotting on an air spawn I load my personal DTC. I should not have to use DTE/MUMI because I would have done that as part of the startup procedure. It is least surprising to just have the DTC autoloaded in the avionics (DTE/MUMI).

This. It should look like a menu which it is. Now it looks like a label.

To be fair, in addition to CMDS programming, the DTC has comms presets.

Hi, I believe it would make sense for DTC to be automatically loaded into the jet avionics when spawning hot, or at least when spawning in air. Especially in air you're sort of pretending you already did your startup, takeoff etc. As part of startup procedures you would have loaded the DTC just like you would have started the jet and all sorts of systems that are on when you spawn hot or in air. Following the principle of least surprise, it would make sense for the DTC to be automatically loaded in the jet without needing to load it in the avionics. Thanks, itn

For the first one, AFAICT it's actually correct as is. After starting the count, second INC depress merely freezes the display, not the count. Third INC depress unfreezes the display, after which the display returns to show the count that has continued in the background. Unless, of course, you have some more relevant data for the DCS variant or something like that.

I wouldn't be surprised if this issue is similar to the feet/metric conversion/rounding logic issue I reported in Mission Editor a while back (and which was then fixed). Basically an error in rounding logic when converting between internal metric representation and others. In the Mission Editor it was about feet/metric conversion, but this might be similar.

Check the DCS F-16C Early Access manual (pages 200, 208-211) or Chuck's Guide (p. 701-702). Not sure what manual are you using, but check ED's and Chuck's and the MGRS thing is clear: It's available on steerpoints 21-25.

+1 yes please. Give the mission makers options to restrict some of these capabilities. It would enable historical and otherwise restricted environments.

Even if that's the reason for how it currently works, surely it should be classified as a bug as explained by OP. Sync cockpit controls enabled Physical control bound to a cockpit control The aforementioned cockpit control not synced

No you didn't imagine it. FLCS uses landing/takeoff gains during aerial refueling. In landing/takeoff gains the command system operates differently. For example in pitch instead of g you command pitch rate. So it's not as simple as "reduce sensitivity" but yeah, I'd say it's done to make it safer and easier. Note that I'm not sure how exactly it's implemented in DCS, but you can see the difference. It could simply use landing/takeoff gains or it could be some special mode, don't know.

In general you only change things for a good reason. The benefits have to outweigh the risks and costs associated. Changes cost time and money and usually cause more changes and costs in form of updated documentation and things like that. In this case you would modify hundreds of Vipers in order to save some Crew Chief sweat in the likely quite rare occasion of a pilot accidentally using one instead of the two bottles to start, as standardized and trained for. Other than that, don't know if there are some actual, hard reasons for keeping the panel as is. For example if it's used in some service/maintenance/checks.

Hi, FCR mode (RWS/TWS) is not remembered between master mode changes if the FCR mode was switched using TMS right or TMS aft (return to RWS). It's remembered only if FCR mode was changed using OSB. Track attached with some examples. The track and text below only demonstrate one instance, but the issue seems to be in every master mode, and it doesn't matter which master modes you cycle between. Not once did I see the mode remembered if I switched to it using TMS right or TMS aft. 1. Bug: FCR mode not saved when using TMS to switch it: Start in NAV master mode, FCR in RWS. Switch FCR to TWS using TMS right long. Switch to A-A or MSL OVRD. By default FCR now switches to RWS. Return to NAV master mode. What is expected: FCR switches to TWS, which you had switched to in Step 2. What happens instead (the bug): Radar switches to RWS because it doesn't "remember" the switch in Step 2. Same thing happens if you for example switch to TWS using OSB, and then return to RWS using TMS aft. It will remember TWS, not RWS. 2. Correct: FCR mode is saved when using OSB to switch it: Start in NAV master mode, FCR in RWS. Switch FCR to TWS using OSB. Switch to A-A or MSL OVRD. Switch back to NAV. FCR is now in TWS, to which you had switched to in Step 2. This is related to previous bugs and reports (one linked below). Also in latest changelog there was a line "Fixed: Missile Override will now save master modes" but I'm not sure if it's related to this or not. This issue definitely isn't only about MSL OVRD, and the issue demonstrated above, still exists in current patch. FCR, master modes, TMS.trk

For some reason you're combative and just grossly misrepresented what I said. You realize people can just look it up and see exactly what I said and how I said it? I explicitly said that since that one thing you claimed isn't true, the issues might be in somewhere else in the systems: "There might be something in play in here with the nav system, INS, GPS and Kalman filter". I don't know why, but since you seem to feel like fighting instead of learning, I'll just leave you to it.

I don't think you've reached the right conclusion. If this were true and easily reproducible, you could show it with a short, simple track. For what it's worth, FIX (in non-GPS environment) has worked every time I've used it between late 2022 and now, just tested today in Caucasus and Kola. Map is also something worth mentioning in any posts/reports. There might be something in play in here with the nav system, INS, GPS and Kalman filter, but I don't think "FIX does not update the entire flightplan" is correct, so any issues there might be, are likely something else. Consider what you're trying to test/prove/disprove and maybe re-consider the test methodology and reporting. Tracks are really useful for everyone, and ED pretty much just ignores bug reports without tracks. This thread and your post wasn't a bug report per se, so no fault there, but so you know, they're useful for rest of us, too.

This option would be useful for different types of training and testing from ground abd air spawn. For example, simulating RTB or mid-mission situstion where the drop tanks are empty.

So one more time: For now you need to give the JDAMs a sensor track (i.e. SPI from TGP) to have any sort of accuracy with them. Nothing much else you can do, until ED brings back the feature(s) that makes JDAM a JDAM. Forget what you know or you think you know about JDAMs, the current DCS implementation is not that. This was already answered in this thread, in your thread on Sunday, and at least one if not more previous threads about the JDAM issues.

The HMD setting only affects default choice, it does not restrict the player.

Don’t bother doing FIX when using GPS. GPS does update the INS and in current implementation you cannot improve it with FIX. This was just discussed in another thread. Issue with JDAMs is different and currently you need to give them a SPI from sensors (i.e. TGP track).

Yes, fly with the copied group. You could just manually place the steerpoints in wrong positions, in order to then fix them using FIX and see if it works. The nice thing when you copy the group, you get the exact same offset for every steerpoint (happens when you paste it to different location). This can sort of simulate INS drift (i.e. your plane thinks it's XXX feet off to direction NNN).

To test if FIX works or not, there are two easy ways 1) Active Pause and time acceleration. You can literally see the diamond moving in HUD. Wait for it to drift enough and try doing a FIX. [EDIT: This worked previously, haven't tested with current version.] 2) Purposefully offset steerpoints in mission. Add an air-spawn airplane group and put the steerpoints exactly on the targets (the correct position, atop the target or on runway threshold or whatever) Copy the group and paste it offset from where the original group was. Make the offset large enough for you to notice, and for anyone to notice it visually looking at the track or video. Optional: If you want to do this from cold start jet, set the spawn point to Start from ramp. Spawn, fly and try using FIX. FIX did work in e.g. 2022 and early this year before the INS upgrades (in Caucasus and Syria).