Cat107

After recent update Jester should call out pressure loss if he determines that the pressure is too low (for current altitude) for at least few minutes which I think is very hard to achieve (if possible at all) unless you have real leak or pressure regulator malfunction. There is a possibility that there are some edge cases which we didn't predict or some bug in the logic, however it's hard to find anything like that right now without a track, a video or at least some steps to easily reproduce such issue. And by "too low pressure" I mean pressure that is visibly lower than the pressure that the oxygen system should maintain for given altitude as shown on this chart: (And of course keep in mind that this chart and cockpit pressure gauge are in ft and when I say "lower pressure" I mean the pressure that corresponds to higher altitude)

Hi, thanks for your feedback, we analysed the current Jester logic and it wasn't working exactly as intended. We adjusted it and now Jester will press the dispense button several times in short span using current CCU settings if he spots a missile visually and if he detects RWR launch warning, he will do the same but he will temporarily disable flares before that (not to waste flares for radar-guided threat). Should be included in the next update

Hi, thanks for your feedback, we analysed the current Jester logic and it wasn't working exactly as intended. We adjusted it and now Jester will press the dispense button several times in short span using current CCU settings if he spots a missile visually and if he detects RWR launch warning, he will do the same but he will temporarily disable flares before that (not to waste flares for radar-guided threat). Should be included in the next update

Hi, thanks for the feedback, we adjusted the kneeboard to display more waypoints and more info about them (names and types) and improved the formatting, should be included in next update

Fixed internally, Jester should be more thoughtful about identiyfing pressure loss soon

There was a small flaw in the logic, fixed internally, thanks

Hi, yeah, it's as @OttoSH wrote, the altitude hold function should hold the altitude at which aircraft was during engagement. So for example when engaged at angels 20 during a climb, it should stop the climb, then descent to angels 20 and then stay around it (with some limited precision). However, this system was designed during 60s and is not as robust and accurate as more modern systems. We put a lot of work into recreating it according to the documentation and trying to replicate its behaviour very realistically and therefore it has similar characteristics to the real one. For example, it may have some trouble when being engaged with high rate of climb/descent or when the aircraft is in a deeper bank or at specific speeds (for example very low near-stall speed or in transonic region). It needs some time to stabilize the altitude when you for example change throttle setting or bank etc. However, I personally I find it pretty solid and I haven't seen many complains about it so far. The way which provides fastest stabilisation is engaging the alt hold mode with near zero vertical speed and quite stabilised airspeed. Also you should check if you are not for example disabling it by moving the stick in pitch axis. Could you maybe provide a track of it struggling to keep the constant altitude? You can also read more about AFCS here: https://f4.manuals.heatblur.se/systems/flight_controls_gear/flight_controls.html

Hi, sorry for such a delay but we are all really busy recently. The automatic checks (slats, flaps, speed brakes, aar doors and hook movement reports) logic was adjusted and it should hopefully fix these issues. It will probably be included in the next update, thanks for all the valuable input

Hi, thanks for reporting, we have that one on our list

Hi, could you please attach a short track with this issue occuring? That would really help in identyfing the cause.

@WinOrLose Hi, some time ago we pushed a fix resolving some issues with the ARI check (the one that is a part of flight controls check), is the issue you described still occuring for you? If so, could please provide a track?

Hi, not yet, but we will try to deliver it in one of the upcoming F-4 updates

Hi, so a bug was indeed detected which caused the crew chief to not call "rudder neutral" in some cases. The fix is already prepared and should be in soon, thanks for all your input EDIT: should be fixed now

Thanks for the report, added to the list

Hi, so speed brakes as well as aux air doors are powered via MAIN 28V DC BUS, when you have the battery connected and generator switches set to EXT ON and ground power is removed, then the battery will provide power to the ESSENTIAL 28V DC BUS which will be tied with the MAIN bus as long as the battery voltage is above certain threshold, when the votage drops enough or when you move the generator switches to OFF then the MAIN bus will be disconnected from the ESSENTIAL bus and the speedbrakes as well as aux air doors will close as the MAIN bus will not be powered.

Hi, thanks for the report, it looks like I found the cause of that bug happening on some occasions. Fixed internally, not sure if it will be shipped in the upcoming patch, but should be there for the following one EDIT: should be fixed now

Nice idea, I'll add it to the list

Will be included in the next udpate

Actually, TID was displaying true bearing instead of magentic bearing in NAVRGID mode, this will be fixed in the next update

Will be fixed in the next update

F-4 is a pretty old plane, however it still features systems which assist you in controlling the aircraft. Although they are not as advanced and not as strong/present as in some more modern FBW planes like F/A-18 for example. In case of rudder, the first element is AFCS (Automatic Flight Control System) AN/ASA-32 which features yaw stability augmentation function. I won't go too much into details here, but generally it prevents yaw oscillations and helps in coordinating the turns. Another thing is ARI (Aileron-Rudder Interconnect) system which further helps in coordinating the low-speed turns but it works only with slats flap switch in the OUT AND DOWN position, and the airspeed below the flap blowup speed (230 knots). To disable the first one you can flip the yaw stab aug switch on AFCS panel and to disable ARI you can pull out the CB as @Zabuzard said. If you would like to learn more about these systems, I would recommend: This chapter of our manual: https://f4.manuals.heatblur.se/systems/flight_controls_gear/flight_controls.html And this video: https://www.youtube.com/watch?v=EXsTlmokAlQ. While these systems are helping you, the F-4 is still very "manual" and the rudder usage is important, especially in high AOA situations (similarly as in F-14). To understand that, I would really recommend watching this real life instructional video https://www.youtube.com/watch?v=iZiduQboyow. It explains different aerodynamic effects and teaches when and how you should employ rudder. And after you watch this I would say: practice, practice, practice . As @razo+r said, you have to fly and experiment to get the feel of this beast If you have any further questions, feel free

Thank you for the report, it's one of these bugs that seem easy but in practice are a bit annoying to solve, anyway it's on our list

Hi, it looks like some DLAA artifacts to me. Do you also experience such effect with different liveries and different aircraft? It is possible that this specific black-orange grid in that livery just doesn't work well with this type of anti-aliasing...

Hi, it's possible that this solution might work for you: https://forum.dcs.world/topic/355838-f4-causes-dcs-to-crash/?do=findComment&comment=5501197

Oh, that's a nice catch, thank you, we will have a look