Zabuzard

Unfortunately your description is a bit too vague to be actionable. Unless you are able to dig out more details, this will be a blind investigation. The fuel system is quite complex and it does not really show you exactly what is going on, so I would probably first of question your interpretations of what the plane showed you. For example, how did you determine the tank was empty? The light on the warning panel does not say that the tank is empty. The fact that it transfers only for a short amount of time and then stops is also correct behavior. The number increasing from 4/5k upwards when getting refilled is also correct. You mentioned damage. So it would for example also be possible that you damaged perhaps one of the valves between, for example tank 3 and 4, 5 and 6. In which case your external tanks would only fill up tank 3 and 5 and from there on it would stop. Or possibly you damaged the sensor that controls opening and closing the valves. Or one of the transfer pumps between perhaps tank 2 and 6. When your engines died with fuel on the totalizer and they actually died because they ran out of fuel, that could also indicate a battle-damage failure of the auto-transfer system that would otherwise force trapped fuel into the engine feed cell 1. It is also possible that the auto-transfer system did work and tried to perhaps get fuel from your wing tanks to cell 1 but you stayed in afterburner for a minute or two, with which the transfer system cannot keep up with if there is only one or two tanks still supplying fuel. As you might notice, there are way too many moving parts around this system to really say if you encountered a bug or just a correct behavior of a complex system.

It is a known issue and as long as you do not read anything hydraulic related in the changelog, it will still be present

Fixed for the upcoming patch

The upcoming patch has a first quick iteration of this animation change. Cheers

The Altimeter flag thing has been fixed for the upcoming patch

Fixed for the upcoming patch

This command represents a Jester Wheel action that is only present in a niche case: When you missed the alignment dialog twice, Jester will say something along the lines of "Okay, just let me know when you want to align" and then this command becomes available in the Wheel to trigger the dialog again. The bind presses this wheel command and only works when it's available. It is more meant to be used for Voice Attack users who want to map it to a phrase.

Finally captured on track! Thanks, will let someone take a look :)

The math is pretty much the same as IRL and solves the equation used by the Dive Toss math. But parts of it (release range computation, i.e. how far this specific bomb will travel when released in the DCS engine) are using DCS built-in methods that are also a blackbox to us. The real world formulas dont work very well for DCS and you are supposed to use our calculator. Which is also part of why we even provide such a tool to begin with. Without it, it is simply impossible to compute solutions that work in-game. If our calculator spits out values that dont work well in-game (despite you flying the procedure correctly that is), then you found a bug and we will fix it.

The drag coefficient is only used in DT and TGT FIND modes. All other modes release based on the range or counters that you have to enter. For Laydown, release happens after you travelled the entered RELEASE RANGE value (measured using the INS ground speed). How are you designating the target/the IP? Are you pressing bomb button when you are visually over your desired IP? Or when the depressed sight lines up with the target? If latter, perhaps the issue is in the sight depression computation.

This is on the list already. Cheers

Those will be available in the next update. They have been added to the manual already.

Would it be possible for you to send a screenshot of the issue?

Right. I would be careful with CBUs currently though, as our Bombing Tool does not consider the fact that the container opens at a certain height yet. Instead, it is treated as if it would fall like a ballistic bomb all the way down from release to impact on the ground. Although that should usually result rather in everything falling too short, as the container opens mid-flight, leading to the bomblets all falling down before the target. (This is of course something we will address eventually. In the meantime you probably would have to add the release altitude of the bomb fuze to the target altitude to get usable values. I haven't tested this a lot yet.) Ive seen a detailed report regarding CBU and Laydown with similar results before already though. Its possible that there is a bug here, probably in the Bombing Tool, given that it works just fine with some of the other standard bombs.

In the Phantom it is probably currently inconsistent. On our next project we made the design choice to allow moving all switches with cover closed, but it would automatically open the cover then. This is to make it easier for people with less binds available. For the Phantom we probably have to go through it and align all of them. Affected are likely all 3pos switches under a cover, as our 2pos switches with cover have that mechanism to block the switch command with cover closed. Thanks for the headsup, I will put it on the list :)

That is indeed the reality for a F-4E Phantom. It makes large oscillations around the trimmed position, even when trimmed out perfectly. It will roughly keep you there and prevent you just going down if you go heads down, but it wont allow you to fly straight hands off. (In case unclear, make sure to only tap the trim button, dont hold it. It is operated by multiple short taps and should not be hold down.) But again, we are indeed looking into possibly giving a less sensitive trim command. Especially for people who use hardware that has a minimal signal duration that is not low enough for quick taps. Some sticks let you adjust that in their configuration, but not every product has this. We have seen reports from people who, after adjusting that in their stick configs, had a much better experience with the trim in-game as their stick stopped holding down the trim command for too long despite them already releasing it physically.

Unfortunately, there is not too much that can be done. The process is to hand in the files to Microsoft & Co for explicit whitelisting. Which we (and ED) did right when it started to happen. Seems it takes some time until they update their products. Sadly, whenever the files are just slightly changed in a DCS update, this process needs to be repeated. We are looking with ED for an alternative solution to hopefully get this sorted out long term. After all, it is not just our files that are affected, but also other thirdparties. Fingers crossed

I personally havent heard of that yet. Sounds like something we can have a look at, thanks.

It is currently not supported due to technical issues but will be added eventually, yes.

Thanks for re-checking. Seems this particular switch was overlooked. Ive applied the same fix to it now and it seems to work (If you do not want to wait, this is its new bind-code:) switch_3('Antenna Stabilization Mode', { 'Drift Out', 'Nor', 'Stab Out' }, nil, device_commands.RADAR_WSO_STAB_SWITCH, device_commands.RADAR_WSO_STAB_SWITCH_INC_DEC, device_commands.RADAR_WSO_STAB_SWITCH_NEXT, device_commands.RADAR_WSO_STAB_SWITCH_AXIS, bind_templates.radar_antenna_panel(), { binds = { dec = { value_down = -0.5 }, inc = { value_down = 0.5 }, } }),

Would need DCS changes. You cant input anything during replay unless you click "Take Control". A possibility would be to introduce some form of HB UI with "replay controls" that you can mouse-click. Since interacting with our UI is something DCS still allows during replay without taking control.

We are. But we want to emphasize that the current behavior, according to our knowledge, is exactly how the F-4E Phantom behaves in real life. All of our SMEs confirmed that we nailed its annoying pitch trim behavior. Trimming in the Phantom does not move the stick directly. Instead, it changes the length of the lever with which the bellows apply their force on the stick. Which in itself is dynamic as well, as they scale their force based on speed. And then there is also still the bobweights pulling on the other side of the stick. Also with dynamic force, this time based on G. Trim is extremely dynamic and its behavior essentially changes whenever you just slightly touch throttle or stick. The trim system IRL needed multiple reconfigurations until the test pilots even considered it okay to fly with. Eventually they accepted it.

This is temporarily done on purpose to overcome the bug with the tanker where a full com-cycle is needed to get him to cooperate again.

Thanks, will improve on this :) 1) Release Advance is a setting on the WRCS panel that allows you to let the computer release the weapons a set amount of milliseconds earlier than planned. If you drop for example 10 bombs, this will cause the entire pattern to shift so that not the first bomb hits the target (and 9 bombs behind the target) but for example 4 bombs before the target, 5th bomb on the target and 5 behind. 2) RBL is the radar boresight line. In simple terms, the reticle will be put where the radar looks at, i.e. "straight forward". 3) You are supposed to put the pipper on something that has the same altitude than the target, as the radar measures range. So, it is okay if the radar is pointed a few meters before or behind the target or next to it if it stands mostly on flat terrain. On a hill, it would lead to more significant range differences if you do not point directly on the target. In practice, the procedure would be to point before the target, lock the radar range and then let the pipper slowly and naturally walk onto the target. When right on the target, the bomb button is pressed to confirm the target position and start the weapon release computations.

Thank you for your feedback. It would be a bit more helpful for us if you can send a track showcasing a scenario where Jester was not able to spot a target while you think he (or a human WSO) should have. Then we can spot if there is an issue with how Jester behaved in that situation and address it. From my experience debugging reports like that so far, it's mostly down to people not understanding this radar system properly and not necessarily Jesters fault. I.e. if replaying the same situation with a human WSO, they also would not have been able to spot the target any sooner. The pilot positioned the aircraft incorrect and expected too much from the radar. For example direct head-on, next to clutter, target distance around own altitude, look-down attitude,... For Boresight, there are two modes you can use. Regular Boresight can be entered through a command on the Jester Wheel and covers roughly up to 10nm. Cage/Boresight covers 5nm and can be entered using the CAGE button on your throttle. In both cases, you can command Jester to lock the bad guy by holding Jester Context Command and placing the bandit in your pipper. For details see the manual: https://f4.manuals.heatblur.se/jester/combat/radar.html#dogfight