Super Grover

There's nothing suspicious in the "mess" continuing after unpausing because it's directly linked to the velocity error which is introduced during the active pause period. Yes, the range is slant; however, when applying the INS update, the difference between the aircraft altitude and the TACAN elevation is taken into account. I'm not sure what is your procedure to prime the INS. Did you perform FINE GND alignment? Did you move during the alignment? Or maybe you entered a hot aircraft? There are many reasons leading to such drift. Moreover, it's not scripted, and it's not a simple function. Even when you perform the same alignment twice, each time the error of the alignment (and hence the drift) will be different. Updating own position by editing it through CAP/TID or via VIS FIX should give the same results. I think I don't understand what you call "manual bombs release". The INS should work fine for Computer Pilot or Computer Target but using it for anything else will probably fail.

Thank you for your report. It's a known thing and a limitation of DCS. The nose gear on the F-14 is unique - long-travel strut which is almost fully extended on ground, and the AI animations/procedures can't handle that properly (we don't control those animations/procedures - they are built-in DCS functions). So this is the best compromise I managed to achieve for the AI aircraft.

It's the active pause that messes with your INS. The INS "thinks" that it's flying in some direction, and it applies all corrections necessary to keep the platform level, but it doesn't move so the correction is wrong. I've just checked it with my debug tools, and everything is ok until I hit ACTIVE PAUSE. I'll look for a solution to stop updating the INS with active pause in use. Also, I wanted to mention that we model TACAN inaccuracy accordingly to the device specification, so I just wanted to warn you that comparing with that introduce some additional errors. Finally, I wanted to reassure you that we haven't touched the INS for weeks and that I check the debug output regularly and we haven't observed any INS anomalies when the device is used properly.

It's a feature of the real F-14.

Thank you for your report, Shadoga. The log doesn't contain anything suggesting that the F-14 caused that crash directly. Although I can't rule out some indirect F-14 impact on that crash, the log looks as it was a crash in the core of DCS. Also big thanks to everyone reporting that the CTDs are gone for you.

Hey Shadoga, Thanks for your log. Unfortunately, nothing is suggesting what caused that crash, and it's a bit unlikely that accepting a client RIO could trigger something fatal on the F-14 side as nothing changes in the F-14 until the RIO gets spawned in the cockpit. If the simulator keeps crashing for you in such situations, please let us know, and we will investigate it further.

As we've been hunting down those random crashes you reported (as Cobra wrote before, DCS doesn't produce crash logs because of the DRM, so it has been extremely complicated), we've received multiple reports with crashes happening outside of our code and in the other parts of DCS. So just that you're aware that only some of the crashes you experience while flying the F-14 are from the F-14. And of course we're very sorry that you experience any crashes with the F-14. Nevertheless, our testers haven't got any F-14 crashes for weeks and probably the next patch should eliminate that last issue with PAL/TCS that I discussed in this topic before. Finally, I wanted to write that we take all your reports very seriously, and after we receive a proper crash log, either from you or from our testers, usually we have it fixed the same day or the next day. So I wanted to thank you all for your reports because you're making the F-14 module better.

It's fixed internally and should be available to you with the next update.

Those were static objects placed in the mission editor so the fix should apply to all maps.

I want to thank huppel for suggesting that mission, and everyone for reporting their crashes. I've finally managed to trigger a CTD using that mission, and it's probably the weirdest DCS crash I've ever seen. It's a mix of a very specific avionics setup, plus the environment, plus some static objects in the vicinity of the aircraft. But the key was some partially initialized static objects - like the oil rigs, gas stations, etc. That's why some of you experienced those crashes, while the other didn't - it was very mission specific. So at least one source of the CTDs is fixed. I can't guarantee that it was the only reason of the CTDs you got, but I can say that at least this one is going to be fixed for you on Wednesday.

That is indeed a bug. Thank you for letting us know about it. I've just fixed it so it should be available in the next update.

Could you post a screenshot of the VDI or HUD, please? Also, could you write the annunciator lights which are on before and after the repair, both cockpits? Quite possible that you are in AHRS/AM and the AHRS is just misaligned due to operations at >82° of pitch. In that case, could you press and hold for 3 minutes the HDS set pushbutton on the compass panel? It requires being stationary or in a straight horizontal unaccelerated flight.

The simplest answer to the question asked in this topic is that you can't switch between the RIO and the pilot seats in multiplayer because DCS doesn't support it at the moment, and it wasn't our design decision.

Hey! I'm sorry that the radar doesn't detect tankers for you. I've checked it on my end today, and the result is as in this picture: So as you can see, it works in our internal builds. To help you with your problem, and to help us understanding if there is any bug, could you try the location from my screenshot? Then could you send us the mission you used in your flight, the precise location of the ships that have no radar returns, provide us with some screenshots of your radar display for those ships, and finally describe all actions you took (step by step) to set up your radar? I'm sure we will find a way to make the ships appear on the radar display . Best regards Krzysztof

It's fixed internally. Today's patch is based on a build we submitted earlier this week, and it doesn't have that fix included. It should be available in the next build

@Voyager The INS accumulate drift all the time, not only at high G. Of course, high G manoeuvres may introduce more significant errors. However, those are mostly position errors, and attitude errors are less pronounced. On the other hand, there are two ways for break the INS completely: by pulling too much G, and as a result of a random failure (emulating all other aspects why the device can break). One common misconception is that the skewed pitch on the HUD comes as a result of a broken INS (IMU). Quite often the scenario is: the IMU breaks, the AWG-9 detects that failure and automatically switches to AHRS/AM, the AHRS becomes the attitude source for everything, including the HUD. However, the AHRS can easily tumble, because it's designed to work for +/-82° only. Usually, that shifted/rotated pitch ladder is just a result of heavy manoeuvring in the combat phase before the IMU broke. As an exercise showing the limitations of the AHRS, you can manually switch the INS mode to AHRS/AM, do some aerobatics, and observe how the accuracy of the attitude displayed degrades. @Talonx1 The magnetic compass/sensors are sensitive to the magnetic field of the carrier and can easily be off by 10° or more.

Just wanted to ask if you are sure it was "T" and not "TC"? Because Ticonderoga should show "TC" ( http://www.heatblur.se/F-14Manual/general.html#threat-symbology ), and if it was "T", I'll start looking for a bug in the RWR code :smilewink:

The RWR doesn't have any means to know if you are the target or someone else, and hence a conservative approach: if there's a potentially lethal missile flying towards your aircraft, you must be warned about it. It is possible to lock and launch at a friendly aircraft by mistake, and there's a reason why we all know "buddy spike" so well. We know that the AI SAMs in DCS never make such silly mistakes as blue on blue launches, so you may ask why to show those missiles if they can't be lethal in DCS? - Just because we try to simulate the real device as realistically as possible, and who knows, maybe one day the AI will stop being that perfect in judging who is red and who is blue . Summarising: all "N", "F", and other settings are ignored in the critical ring. So when the RWR thinks that you may be the target, it always warns you about it.

The bug has been solved internally, and it's being tested now. It was introduced as a byproduct of fixing another bug and slipped into the release build unnoticed. Sorry for the inconvenience.

It worked the last time I tried it (although some time ago), and the code is there. And you shouldn't be able to break the INS at 8G, at least the threshold in the code is set higher than that. Oh, and BTW, if you have "Random System Failures" set to on, the INS and other devices will sometimes break too (maybe the INS a bit more often than the rest).

Usually, it's a mechanical failure, which means that the whole INS has to be replaced by the ground crew - only DCS "repair" function can make your INS fully functional again. In terms of in-flight re-alignment, it's impossible with the F-14A/B. You can erect the IMU to a state where it can serve as the attitude source, but you can't restore full INS abilities.

Thanks for sharing your observations. I haven't noticed such problems with accuracy, but I'll take a look, and check if there's anything we can do to improve the precision for you. However, this as well might be just the nature of the weapon or the profile used for the attack (the bombs use very rudimentary steering), or the networking thing, and then we won't be able to do anything on our end. I'll let you know about the results.

I'm sorry that the radio doesn't work for you. However, I've just tried that cold start instant mission, using both Easy Communication and regular radio settings, and the radios have worked. We would need more information to help you with setting the radios up. Please describe all your actions precisely, if possible include screenshots. Alternatively, you could record a video. I'm sure we will find a way to fix the radios for you, no matter if it's a bug or some mistake in the procedures.

Thank you for the report. Your observation is correct - Jester forgets about switching the NAV MODE to OFF. However, I've already asked him to be more focused when performing alignment and he promised to improve after the next update. Jester is a nice guy :-)

Thanks for reporting this. It's a bug which I introduced when I added the code ensuring that Jester moves the switch out of OFF once airborne. I'll correct it.