Zabuzard

Its mostly the radar. Try a bomber, from the side (not headon!), over water and put urself below it. You will notice that you can spot it from like 50-100 nm now. Theres a lot of factors reducing your odds and especially a fighter aircraft approached head-on will have a very small RCS. If you then add clutter and bad positioning into the mix you will not find them early enough. Practice is key! If you need help, please send a track and we can have a look

That is correct.

You have to ask ED, we cannot communicate their plans for future updates.

Could you send a track. Then we (or the community) can have a look and tell you what to change to improve the experience [emoji106]

Its up in the air. This isnt a secret we are somehow trying to hide from you. The module is so far in the future that there was no reason to decide and commit on this yet. Sometimes things just are that simple

Both was done IRL. It was mostly crew preference. The main issue is that, lacking stabilization, the WSO gets thrown off when the pilot suddenly moves the aircraft around. Its easier for the pilot to know when to not touch the Maverick stick because they want to execute a maneuver than the other way around. But therefore it is of course easier for the WSO to focus on picking targets while the pilot focuses on flying. Ill bring it up with the team and the SMEs for clarification. I vaguely remember a discussion though that sth like this was for DMAS or later only. Will see, cheers.

1. no 2. yes 3. yes dont forget to enter ur attack profile in the bombing tool previously and hit "tell jester"

I understand your frustration. But please understand that there is nothing we can do on our side to "fix" this problem. If you want to fly the aircraft, you either have to go through this or you have to wait until the Antivirus software distributors updated their databases to not flag this false-positive anymore. This process usually takes about 2-4 weeks and often has to be repeated after each DCS update again. This is not a new issue, multiple modules in DCS are suffering from this problem for multiple years already. Please understand that this is not a "we are too lazy to fix it on our side" issue. Our hands are tied on this. The AV distributors decided to flag this file and the only thing that can be done to stop this is to send in the file to them via a whitelisting request (which we always do on every DCS update). This process takes multiple weeks and has to be repeated on every single update. If you decide to wait for it to get resolved globally by the AV software distributors, you will likely run into the issue again in the future. Perhaps in 3 months, perhaps on another module, perhaps on another DLL file. It keeps happening and there is no way to stop it.

The stick visuals are subject to animation smoothing to ensure it doesnt look silly when you jank around your stick IRL. Otherwise it would teleport and it would look really silly and break immersion. Its a compromise. Take note that this is visual only, your input is being registered and transferred to the FM instantly. The stick animations are decoupled from that (see the Controls Indicator UI). Afaik Cobra said some time ago that he might be tuning the animation again to find a slightly better compromise.

Kindly read through this and other similar threads in the Phantom subforum, as well as the Mirage and F-15 forum. It has been explained multiple times in detail, also already in this thread, why it is not really possible and why this is happening. Cheers

For the F-4E pre-DMAS? Not that I am aware.

As said earlier, we appreciate the input and have put it into the backlog for investigation :)

Active Pause bombing can easily lead your to incorrect results as you often drop with G in it, leading to wrong AoAs. If you run into an issue please send a track plus screenshot of what you entered into the tool, cheers.

Yes, thats a good suggestion. Unfortunately, not as low hanging as it may sound, mostly due to the jet not having an easy way of understanding what kind of weapon you got. Its absolutely solvable, but would probably take quite some time to develop "just to save u one click selecting the weapon" and then likely still fail you in practice because you may be running a mixed loadout or not having selected the delivery type yet because you are still on the ground. IRL the "Bombing Tool" math is always done before even entering the cockpit. Its preplanned, you write down your solutions and then enter them midflight. That was also kinda the idea we originally had with the tool, hence the button to "save a profile". You are not really supposed to click through this UI midflight, seconds before attacking the target.

You might have missed a step as it did work for "everyone else" so far and also in the past years, as this issue keeps popping up very couple of months for some module in DCS. Id suspect you forgot to run DCS repair to get back the file that your Antivirus deleted :)

Jester cant guess the release altitude and speed you would want to use for your attack. This is a crucial piece for the drag coefficient, it is not static based on the weapon. What I could think of is telling Jester in advance, perhaps even on ground, that you plan on using this profile for this attack and that profile for that attack and then "attach" that to a waypoint as part of your flightplan. Then Jester could enter this preplanned data automatically when you approach the attack point as part of your flightplan.

They did not have any stabilization, nope. Thats how it was IRL [emoji106]

Yeah. Id wish there would be anything that can be done from our side to get rid of it. This will keep on happening for our modules occasionally and also for other thirdparty modules. Most of the time the AVs trigger on stuff that is more complex on the technical side. Which is why it doesnt happen that often on (coding-wise) simpler modules. For example the use of Jester, the UI, the recorders, having Special Options, the component system,... all those feature require doing things that can be AV sensitive like reading/writing files on your disk, spawning processes or talking to the internet. We (and ED) do send our files to the AV distributors for whitelisting but the process usually finishes only like 2-3 weeks after release of the update. Which is also why these problems tend to "resolve magically" after waiting long enough and why it rarely happens for modules that don't receive many updates anymore.

The main reason this is a rather uncommon sight for most games is because they delay all their updates by 2-4 weeks in order to whitelist the files explicitly at all AV software distributors. In case of bigger AAA studios they also pay them for premium and in order to speed this process up a bit. With the files being explicitly whitelisted in the AV DBs, they can then safely be distributed to users. This process often needs to be repeated whenever the file has been changed, i.e. on every single update. During development, also in those AAA studios, the AV triggers for the files as well, its standard practice to just locally whitelist the folders (you also gain some performance boost of that). For some Indie games its actually not too uncommon to run into the same problem as user.

You may have forgotten to run the DCS (slow)-repair feature afterwards to restore the files defender deleted :)

Your antivirus software is detecting false positives and deleting files. Before you continue you have to first teach your antivirus to stop messing with the DCS files. You need to add the files (or the entire DCS folder) to the antivirus exclusion/whitelist rules (not the firewall). Once your antivirus stops deleting files you can run a DCS repair to get back the lost files. Cheers

Ah, you are using the CTRL+1..8 binds. You can control the outer wheel (and also the inner wheel) using the CW/CCW binds (QWE by default). Cheers

Not sure I follow what your describing. What are the "last choices"? Which keyboard commands are you using? The wheel is fully keyboard compatible, mouse is not needed (only exception is the text entry currently).

This happens because your Antivirus program decided to delete one of the F-14 files (most likely a DLL because it thought its a virus). This stuff keeps on happening randomly to many modules whenever either DCS or the Antivirus providers ship an update. You can fix the issue by adding the DCS folder (or just the corresponding file) to the Antivirus whitelist and then running a DCS repair to get the lost file back.

The track has Jester working on my end: So whatever it is, it must be a local issue. Most likely your binds interfering with Jester and fighting his controls in some way. Can you check whether Jester worked at all for you? Like, did he respond when you select something in the Jester Wheel, does he do anything or is he completely gone? If latter, maybe he crashed (then there is a crashlog file in the SavedGames/DCS_F4E/Jester folder). Or you deactivated him accidentally somehow? (But that should also reflect in the track). I am a bit surprised that the track has Jester not moving the cursor when you replay the track in DCS yourself, as that should disable all your inputs and only listen for what the track says (which works on my end). Like, the experience replaying the track should be the same for both of us and only when you actually fly yourself I would expect Jester maybe to fight with your inputs.