Zabuzard

Yes, this is because on ground your bellows dont measure any speed and hence the bobweights start taking over and push the stick forward. Trimming in the F-4E changes the length of the lever the bellows use to apply their force. When the bellows decide to not apply force (or just barely any), i.e. when you are on the ground, trimming wont do much. The bobweights are its counterplayer and will then have much more room to apply their force. To make this clear: * the stick is moved aft by the bellows - which increase their force with increasing speed (measured through their air intake next to the rudder) * the stick is moved forward by the bobweights - which increase their force with increasing G Trimming changes the length of the lever used by the bellows. It does not influence the bobweights and it is also not connected to the stick directly. The resulting stick position is the result of this complex and dynamic play of forces that changes completely whenever you touch stick or throttle. A (simplified) example to make it easier to understand: Suppose your bobweights push the stick forward with force 100 and the bellows move it aft with force 5, resulting force on the stick is 95 forward. Lets say your trimming is neutral, the lever is extended 50%. Now you might move your trimming between both limits, lets say 0% to 100%. The result is that the bellows force changes between 0 and 10. Total stick force is 100 to 90 forward. Trimming barely changes anything in this setup. If your initial setup however is more like bobweights applying 10 forward and bellows perhaps 80 aft (on neutral trim), then trimming can change it between 0 and 160. Resulting in a total stick force between 10 forward to 150 aft. Now, trimming has an extreme influence on your stick travel, because the bellows applied much more force to begin with. The more speed you have and the less G you pull, the stronger the effect of the bellows, hence the stronger the influence of trimming.

The module is at a stage where performance issues are usually not necessarily related to good or bad hardware anymore, but instead to very specific combinations of hardware, software and other setup related things that lead to niche and super specific issues. Thats why you will find people who play without any issues, as well as people who do experience problems throughout the entire spectrum.

What I can tell you is that our SMEs (who are real life F-4 pilots and WSOs) are quite happy with how the trim system feels and works. Happy as in "correctly modelled", not as in "easy to use" I understand that you might prefer hearing it from them directly, as well as getting details of the procedures and perhaps someone will also respond

I am sorry if that is your impression. It is of the utmost importance to us that our customers can fly our modules, have fun and are not experiencing any problems. I hear you and I believe what you are describing. Unfortunately, in order to help you by either pointing out a possible user error or identifying and fixing an actual bug, I need more details. I have checked the fuel systems repair code and tested it today, but could not find any issues.

If your problem is the radar, you can try enabling the "Radar Performance Mode" option. That causes the radar image to be slightly less detailed, as the radar will not be operating at its full potential. I suspect this would also lead to the radar making less raytracing/terrain collision calls to the DCS engine.

You might have ran out bc of long afterburner usage with occasional negative G, which the system can't necessarily keep up with. The remaining fuel might have been trapped in the wing tanks while you perhaps had the external tanks selected. You might have had the refueling door opened accidentally, causing the transfer to get stopped. You might have over-G'ed some equipment, gauge or sensors after your repair. The engines might not even have died due to running out of fuel to begin with. And for sure, it is also possible that there is a bug. But its unfortunately impossible for me to tell where. Or to know where to start looking for it without more info what exactly happened :/

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.