Zabuzard

Also when you now replay the track on your end? Thanks, ill check the track and see what commands ur sending and what Jester is attempting.

Can you send a track file? Your the first to report this for whom it didnt got fixed by checking the binds

This is a typical symptom of a bind clash. Where your bind fights with Jester trying to move the stick elsewhere while yours sends towards DCS "move it to 0 (center)". Try to remove your binds to the Antenna Control Stick - especially any axis binds. See if it works again then. If it works, then make sure you add a modifier to the bind so it is not actively sending inputs to DCS while inactive :)

Would you be willing to share a track of a landing attempt? We (and the community) can then have a look and identify what went wrong, trying to give tips

Yes, it is known. No ETA. The bug lies somewhere on the LUA side in the files that define the binds. (So it is something the community could fix until we get around to it.)

Eventually, sure

Those are iirc default ED animations. Yeah, needs to be deactivated and replaced by custom made effects.

Unfortuantely, the Tomcats Jester Menu (including the text) is written in C++, not Lua. There is no way for you to mod this for localization purposes. This could possibly change when/if we port the UI over to what the Phantom uses, which is accessible to modders. Cheers

Back online

Not sure why you are so negative. This is exactly the reason why people would not want to interact and rather prefer to stay in private channels. My advice is to think this attitude through to ensure your actions actually lead to the goal you pursue - which I am going to assume is having a nicer experience with the Tomcat.

During the work for the -A we made the Tomcat compatible with our component system. It could be reasonable to add a few wear/tear properties here and there. But ultimately it would probably be way too expensive to be reasonable to execute on a big scale. Like, we are talking about multiple months, possibly years, of pure porting-work just to get the Tomcat to the "Phantom Standard". But yes, having such stuff in mind for anything new, such as the -A or -B(U) is generally a reasonable thought.

Rail weights are modelled but included in the default aircraft weight. While the "no pylon"-selection in the loadout menu has negative weight to subtract it again. For multiple reasons this is the preferred way of doing it. Overstressing the aircraft has consequences in multiple ways, not all of them are easy to notice or directly visible. But ultimately for a super granular, dynamic and aircraft spanning feature you need the component system with wear/tear simulation that our Phantom and future modules have - probably too late for the Tomcat.

Aye, the site is temporary down since yesterday. Cheers

This is a question you have to ask ED about. The effect of jammers in DCS are not implemented on the side of the ones who make the module carrying the pod, but on the side of the module with the radar. That is, whether and how a weapon will be effected from a jammer is decided completely by the code of the one who is responsible for this weapon, similar for aircraft. That is, how an enemy F-18 will be effected by your Viggen jammer solely depends on the code of the F-18 - not the Viggen. Cheers

Good point, I've just added it there (to the Tanks subchapter https://f4.manuals.heatblur.se/stores/tanks.html), thanks (Note the manual is open source, you can hit the edit button if you think some information is missing on a certain page )

Its here: https://f4.manuals.heatblur.se/cockpit/pilot/weapon_management.html#selective-jettison-control Where did you look for it? Just so we know where to put it

Kindly try out what I explained 3 messages up. So far it fixed it for every user who reported it :)

This discussion is a bit tiresome as the argumentation repeats, even within the same thread. The worn look of the module is a realistic representation of what some Tomcats in service looked like, as confirmed by multiple of our real life Tomcat pilots based on their private photos and memory. Of course the clean look that you saw on your own research is totally valid as well, which is why we already expressed interest in making an official clean cockpit version as well. We havent yet found the time, as creating a full cockpit texture set for two pits in "our quality standard" typically takes the artists several months full-time work. Which, btw, is quite expensive and currently behind other items on the priority list that we think you all will enjoy more, for example the announced Tomcat variants. It will come eventually. Until then, its great that the community made mods for it that you can enjoy in the meantime[emoji106] (All of this applies to the Phantom as well)

Nope

I did not intent to insult you, sorry if you perceived it that way. I am trying to prevent rumors of "desyncs" and the bombing tool being "useless" when it seems to work for the majority and most reports (about 90%) turning out to be user error. We share the same interest and we will identify and fix the cause of the problem. Being it our code or the manual

You guys must be doing something wrong. Everyone else in our tester group and the Discord community seems to have no problem hitting stuff in Multicrew. And whenever someone had trouble it usually turned out to be user error (no offense though, its a complex topic and very easy to make mistakes). Im very confident we can figure out what's going wrong in your procedure as soon as we (or the community) checks out your track files.

nope

You could modify your input lua file to add urself binds that only exist in the WSO pit.

The actual data to refer to is our manual: https://f4.manuals.heatblur.se/stores/air_to_ground/missiles/shrike.html#land-based-threats If the data there is outdated, yes please update it. Either you or us, the manual can be edited by anyone, its open source

This is a known issue, thank you.