Zabuzard

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.

This is a rare DCS engine bug that we have seen reported a few times since release. Users reported that running a DCS repair and/or getting rid of certain unofficial mods repaired the issue for them. So Id suggest trying out that :)

The WRCS will do the math dynamically. The problem is that the drag coefficient will be slightly wrong. Meaning that the WRCS will calculate with incorrect drag values for your weapon. For low drag weapons the consequences will be less severe, and it ofc depends on what kind of profile you are flying.

DT requires input of the drag coefficient (and a working INS). Drag coefficient depends on release params like speed/alt. To which extend usually depends on the type of bomb used, as well as how extreme your planned profile is. So some form of rough preplanning is required for DT as well. But in many reasonable cases the default drag coefficient would be so close to the real drag coefficient that you would hit as long as you do not deviate heavily from the plan - making it a rather flexible and convenient mode to use.

I dont think we ever put the blame on the users. In fact, I am trying to use every situation I can to make sure everyone (especially in our team) understands that user mistakes are typically due to lack of good documentation/tutorials/reference material. So while its ultimately the users mistake, the best way to improve a situation is to improve the teaching material. Im not sure why ur reaction is so heated. I am sorry if you perceived it differently. Please note that the manual is open source, everyone in the community (you included) can edit it and contribute and improve it for the benefit of every user. We are one big team[emoji106] The explanation of the "Bomb on Target" option shown in the Bombing Tool is explained by the manual in the Bombing Tools chapter: https://f4.manuals.heatblur.se/dcs/bombing_computer.html#bomb-on-target The manual also has a global search function, enter "Bomb on Target" and it will lead you there, cheers.