Super Grover

This one doesn't look Phantom-related, but the log is so cryptic that I don't know what it can be. We need to investigate it further.

I'm sorry that you experienced all those crashes. It's a bit of a busy time, but I know that every user report in this section is logged, and we will fix everything ASAP, assuming that the F-4E causes those errors.

I'd maybe add that the manual suggests being "on speed minimum" before the final approach: http://f4.manuals.heatblur.se/procedures/landing/visual.html . Some of the diagrams even show "fast" - so 170-180 knots. However, I'd avoid staying above 200 knots, as above, you're getting close to the flap blow-up speed, which may retract or keep your flaps retracted until you slow down - and that can be too late for them to deploy before you hit the runway threshold.

You should check which lamps are 'push to test, rotate to dim'. Sorry, I couldn't resist - that's an inside joke - we put surprisingly high effort into getting all those 'push to test, rotate to dim' lights correct, including understanding which lights are like that, then understanding how they work - because they use mechanical dimming instead of electric/resistance - and finally modelling them correctly by our magnificent artists. Really, I suggest you try finding them all and adjusting their brightness - that's a very relaxing activity.

Thank you very much @Goofy12! I'd add that for the owners of FFB sticks, it's more like in real life, and this requires separate approaches for FFB and non-FFB sticks. The issue is that the real-life system was a bit annoying. It's very challenging to recreate the exact level of annoyance to give the aircraft the same feeling - not too much to make it unrealistically painful, which can be even more exposed by the limitations of our hardware - but also to keep the need for constant re-trimming. Add character but not pain. Otherwise, it won't feel like the Phantom. Once again, I want to reassure everyone that perfecting the aircraft's feel is a process that also requires user feedback based on individual perception and taking into account different hardware users may have. Our goal is not to have the F-4E, as we think is the most realistic interpretation, but the best software with which you can feel like flying the real aircraft and have fun doing that, so we don't take any decision just for the sake of being realistic. Realism, or rather observations from real aircraft and test pilots, which I often mention in my posts, are merely the entry point to a discussion to give enough context and also to be fully open with you and visualise all factors which we have to take in account when taking any design decision.

Oh, I'm sorry I didn't mention it previously. So, the crash from one of the logs was related to damage received after the cockpit part got disconnected from the rest of the aircraft (typically a total loss of control from the pilot being dead). An on-damage callback function tried accessing the cockpit state, assuming that the cockpit is always there. I know that it's not comforting, but you were about to crash anyway, just differently, and the crash to desktop at least made Jester suffer less. Nevertheless, that situation shouldn't have happened, but the code is fixed now. TBH, given the complexity of the simulation and relations between different parts of the program, the number of crashes from the module is relatively low. I think I can enumerate most of them: the one above - this is the same one as here , the crash which happens when the Jester overlay opens while the user is alt-tabbed out of DCS and DCS is running full screen (this is a peculiar one), some crashes related to waypoint creation from map markers, and when leaving the LAT/LON empty in Jester Wheel. All of them should be addressed in the upcoming patch. The rest of the crashes reported seem to be from other parts of the ecosystem. A surprisingly high number of crashes look to be caused by mods, so if anyone experiences constant crashes, I'd advise removing all mods, making sure that there is nothing DCS-related in your Saved Games (you can make a backup and restore the files later), repairing DCS, maybe even repairing it again for good measure, and checking if it helps.

I might have indirectly and unintentionally connected the control surfaces to one of the AC buses. Whoopsie. I'm cutting the wires, and it should be fixed in the next update.

I agree fully! The only thing I would add is that we can go the extra mile and tailor the delivered solution and in-sim-experience (immersion) to each user's configuration and expectation. We proposed some initial settings as in the release version, but we will continue tuning them with your feedback to provide the best experience without making the simulation unrealistic. That's why it's early-access software.

Thank you for your report. It's awesome that you included your logs - they make identifying the problems more manageable. Only one of those crashes seems to come from the F-4E. It looks like a crash that is already fixed internally, and the fix should be available in the next DCS update. One crash seems to come from SRS, but I don't know if SRS is the source or if it's just a coincidence. And the third one looks like a potential mod-related issue or a core DCS issue.

Would you mind recording your flight, uploading it, and sharing it with us? Then, we'd have a better understanding of what changes could help you.

Please check my comment here: The aircraft's creators did everything they could to improve manoeuvrability and pitch rates, but the cost was degraded longitudinal stability. Some sophisticated methods of augmenting controls were designed. However, while they helped mitigate some of the issues, they introduced quirkiness to the control systems' behaviour under specific conditions. As a result, the aircraft trim had to be constantly adjusted.

Hey everyone, thank you for all your messages. First of all, I wanted to ask everyone reporting if you could be a bit more precise - I mean, please include the conditions in which you performed your observation, like gross weight, fuel and stores (or simply CG location), altitude, and speed. Those things have a super high impact on trimming. Second, please remember that the trimming speed in the F-4 was dictated mainly by the requirement to cancel stick forces during quick force changes, usually when accelerating. Also, the requirement for trim speed consistency wasn't very high. It took approximately 8 to 13 seconds to move the actuator between the extremes. I just wanted to note that 13 is 163% of 8 . I mean, don't shoot the messenger; send letters to McDonnell. Finally, please let me quote some test pilot ratings of the pitch trim. They come from various feel trim configurations, but please remember that those configuration changes were a slow evolution rather than a revolution, so most of the comments on the controls can be applied to all versions of the F-4. I can promise that I'll take a look and maybe increase the time for the actuator motor to get to full speed, but it may be a bit difficult to achieve the results you'd like to have without sacrificing realism. However, I don't see a reason why we can't look for some not-so-realistic optional settings for those of you who prefer usability over historical accuracy. Also, please don't feel bad if you like such settings - it's a sim/game, so the most important thing is to have fun, and with the hardware we have, it's impossible to get the same accuracy and feedback as in the real aircraft.

I think it should be faster, around 17 units.

Yes, they do, but sadly, the airflow doesn't know about it. Neither does it care. As a result, the AoA probe angle is "something" with "some" relation to the production AoA. There is a reason why you won't find in any manual or other doc a precise formula for that relation. Similarly, you won't find any trim settings for any state other than take-off because, with the layout of the system and maintenance materials, it was impossible to guarantee a fixed value. And then, there's my favourite quote from the final approach speed chart: So, I'd phrase it this way: sometimes, real life can be much worse at fulfilling our expectations than a simulation. By the way, we apply such variance in calibration and properties to multiple components, so unless you fly a reference airframe, you may experience such differences as those 6 knots quoted above.

I'm in contact with VPforce. Hopefully, soon, I'll get my hands on the glorious Rhino so I can tune all outputs from the F-4E for the best experience. And, of course, I'll do my best to find the best way to expose from the code anything the stick needs for proper operations.

I haven't looked into all Navy data. Still, I know that the indicated AoA vs fuselage production AoA is slightly different with the landing gear down in the truly carrier-compatible version, as the nose gear door impact is higher.

54% seems a bit high. This can be a bug. Thank you for reporting it. I'll look into this. Also, the hydraulics modelling for the control surfaces is not final and will receive more details.

It's a Schrödinger's APU. It will be there, but not yet. You'd never know unless you tried finding it. But seriously, some F-4E had APU, and some did not. We decided that our version would eventually have it, but it didn't make it into the EA version. Although, technically, this is still a missing feature, it's not unrealistic.

I mean that, of course, everyone is free to run any value and adjust all effects to their liking. However, we must conform to the industry standards so we master everything to look as correct as possible for 2.2. That, of course, implies that if adjusting gamma settings will make dark things look darker, the cockpit may look darker as well when using those settings. I wouldn't call it a user error but a decision that has some consequences. You may say everything else looks too bright with the standard value of gamma, but that is beyond our control.

The art is mastered for the standard gamma setting, which is 2.2. There should be a huge warning sign in the options saying that changing that value may and will negatively impact user experience, which isn't DCS-specific. However, I can imagine that a bug unknown to us might make the cockpit too dark even with gamma set to 2.2 and global illumination on - but I'd kindly ask you to include in your reports your gamma settings, your global illumination settings and some example screenshots to better visualise the problems to our artists.

But the F-4E is not like every other module in DCS. It's THE PHANTOM.

May I correct your statement a bit? You may reconsider using the word "we", as neither you nor I model those modules. I mean that I can't address how a system is modelled in another module.

That's a negative, Maverick. The control linkages are not attached to the control surfaces, so there is no feedback from the control surfaces to the stick as the control surfaces are moved by hydraulic power actuators.

Please note that the roll channel in the F-4 doesn't "emulate" any aerodynamic loads, and it's centred by a pretty simple spring.

You're correct. I was looking at the controls display and ignored the HAT on the stick. What happens when you keep the trim button pressed for longer, like a second or so? The time required to move the pitch trim between the most extreme positions is around 10 seconds.