Galinette

Are you in OpenBeta or Stable?

Fixed! Thanks for reporting

You used the word "weed" several times in this thread, this might be the root cause of the "unexplained myriad of problems" you encountered

Just breaking wings is for sure very simplified, aircraft over speed damage is more complex. There can be destructive oscillations, excessive heating, engine malfunctions or compressor damage... From a development point of view its not really cheesy, just simple. The goal was to punish people going 15% faster than the envelope and breaking parts is easy in DCS. You deserved to be punished For instance, with over-G damage, wings are bent and the FM is altered, which required much more work, whereas other modules just break wings in this case.

It's not a gimmick, the mini-feeders just before engine fuel pumps don't refill in negative G conditions, and thus can only supply the engine a couple of seconds, depending on fuel flow. That's actually very common. Designing a fuel feeding that can sustain negative G indefinitely increases complexity and weight and can be considered unnecessary in most cases. Besides this, staying at negative G in a fighter aircraft has mostly zero benefit and is never done by pilots more than a couple of seconds because it's very uncomfortable and demanding for the body. For pitching down by an important amount, reversed positive G pull is faster, more effective, and more comfortable. Besides airshows, where it's not uncommon, nobody does level inverted flight. Now for the F-16, I know it has the capability of sustained negative G. I don't have the information for the F/A-18, but it really could just be not modeled in DCS. What about the tomcat? From NAVAIR 01-F14AAD-1, 11-21: And for the A-10C, I don't have the information either, but it would seem absolutely dumb to have designed the fuel system for sustained negative G given its missions. It's simply not yet modeled in DCS. What you see in the F-15E now is the norm IRL, and the F-16 is an exception. Now every DCS module has its simplifications, don't consider to perfectly know how a real jet behaves because you know it in DCS. That's true for every module from any developer.

Wing damage is triggered, not "anywhere near its rated speed", but 15% above the mach max at altitude. This means you absolutely can maneuver around the air frame limits without causing any damage. CptSmiley and SMEs might comment about that limit better than me. The actual damage realism (broken wings, fire) could be debated. But you are fully outside the specified airframe limits, and that's a fact! The engine fuel starvation under long enough negative G is also realistic, as far as I know. The argument "Yeah but F-15C in DCS doesn't loose engines" isn't elligible... This is an old FC3 module, systems models are simpler.

A fix is being tested. This should be released in December if it works well. The oscillations have been caused by several changes in FBW laws, mostly the one coordinating the rudder. AP gains have been tuned but we need to test it a lot to be sure we do not impact negatively the autopilot.

For information, that system was implemented in the Mirage 2000 for about two years. A special option check box enables this for the SRS bind (the module has SRS binds in DCS, like a couple of other modules such as the Tomcat) which bypass SRS hotkeys when it detects the module. If enabled, a quick press of the PTT menu will not trigger SRS PTT but open the respective comm menu. And a long press will not open the menu. There was initially concerns about the short PTT delay required for this to work. But after some time everyone got used to it and it's not a concern anymore. It's being added for VOIP the exact same way and should be available soon. So it's definitely something doable in the modules themselves.

Could you please follow your own advice?

These videos are outdated, the aircraft always draws the route back to base point after the last steer point, and this was fixed with the TSD route update.

No, it's actually one of the most irrelevant one. Please explain how either: Including only a small set of liveries in the base game, with additional downloadable livery packs Including only low res liveries in the base game, with additional HD livery packs Would allow more cheating than possible today, or would prevent improving an hypothetical existing livery cheating problem by classical means such as adding liveries to IC. In the case of the first point, yes a player without the additional livery packs would see a default livery for players using the additional ones, not a "ultra high visibility cheated livery". In the case of the second point, it's even less relevant. Edit : For the record, I'm using three DCS installations for various reasons such as module development on my desktop (gaming & main dev hardware) and two on my laptop (which is a PITA to upgrade for storage space) with only the required module installed on each.

@SharpeXB I think everyone in this thread knows your opinion now. I summarize: Anyone considering that $65-$100 is a significant amount should re-examine its life priorities. Having 50GB (and growing at a fast pace) of textures on the base install is not an issue for you. Removing liveries in the base install is bad because it will allow people cheating. Please add something constructive, or let us discuss the topic constructively, your last posts were just bitching and not significantly helpful.

Or, if you want to leave all liveries, having a light, low detail aircraft (model and textures) that can be upgraded to a high detail version on demand. I don't need having rivets modeled on the stuff I destroy, only on the aircraft I fly.

When an anti-cheat mechanism is not effective (if you want to cheat aircraft visibility, you can hack with ReShade, which can't be IC checked) and increases the base game size by 50GB for everyone, it's not a good idea... Now count the VRAM GB $ cost of those liveries. It's not a secret, VRAM use explodes in multiplayer, while terrain is the same. That's not 1.60$ for 50GB (And wait the evolution of that 50GB figure in one year...)

Currently, the base DCS install contains about 50GB of module liveries only. You don't need to own the corresponding modules, they are installed for everyone. This also potentially causes a high stress on VRAM in multiplayer, if a lot of users use different liveries. With the F-4 incoming, this will likely not improve in coming months. The disk size option is alone, I think, something that prevents selling a couple of modules, for lower budget users that have a full SSD and try keeping their DCS installation slim. Having 50GB of liveries should definitely be something optional. There should be fewer / lower resolution liveries in the base game. Then, either install additional or higher resolution liveries with aircraft modules, or with dedicated free texture pack modules.

Issue with base liveries, is they add up to the base game size, not only to the people owning the module. The tomcat folder is 16GB alone for a base DCS install, mostly due to liveries. They also will eat VRAM whenever used on a multiplayer server. That's my 2 cents only, but there are already way too much big heavy liveries in the base DCS. And since they can be freely added in Saved Games, anyone can choose to have more disk space and VRAM use, and that's better.

What is your radar thread count setting in special options?

Hi! Sounds are extremely subjective. We tried to make them as best as possible from ground crew feedback and ground crew recordings, with good recording gear (high pressure microphones, etc...). I know that you don't like them, and live close to an airbase. People helping us on this work on the airbase on a daily basis. We are not against adopting a mod, if the author agrees, and if ground crew like it more than the official files. In the case of Sedenion's mod, they were unanimously unfavorable. Also, don't take youtube videos as a reference, phone and action cam microphones are very prone to distort and filter out a lot of noise components, because noise reduction is a feature. Sound update is not scheduled at the moment, unless a new mod is released that receives good feedback from SMEs. Thus, we encourage development and use of mods, especially for sounds, and fully agree it's a matter of taste. Some might be more pleasing to the eye. Other stuff are planned, such as IFF, failures, etc... The pace of updates is of course not the same as an early access module.

Wings do bend if you exceed 11G and the more you exceed, the more they bend. So if you experienced swinging, you most likely were significantly above 11G. No system protect you from this on the F-15E. And at 700kts you need to be very gentle while pulling the stick. That's actually intended. What we lack is the feeling of the load factor. Real life pilots will definitely "feel" when they are getting close to 11G (that's an understatement) while on a simulator there is no much help besides using a JetPad, ButtKicker or similar device

Did you try adjusting the thread count? A good starting value is 4. It should definitely not cause stutters with that CPU. TF is much less demanding than HRM. I'm interested by a video showing the FPS graph, and TF on and off showing the issue

It's not detecting jamming per se, but it detects that a contact with a high closure rate keeps a constant range, which he interprets as RGPO/VGPO. Interesting effect, though it will be very complex to make it work in active pause.

I will check this. Maybe a "low fidelity" checkbox could be a solution, but this would make it more prone to crash into stuff like power lines. Added to the todo list anyway

Yes. This is unlikely to be fixed soon. The problem is TWS does kalman filtering & track correlation. It assumes by essence that time is flowing. What I suspect is that the kalman filter gets flushed by continuous estimations at still time values so is unable to establish a proper track. Also, it sees a closure rate but the range remains constant. We don't rely at all on any object ID for tracking & correlation, to make it as realistic as possible in behavior. It would be significantly more complex to have this approach work in active pause.

That's likely because you had either: - a lock on the A/A radar - activated GUNS mode - activated an AUTO ACQ A/A mode All those prevent taking control of A/G radar, showing "RADAR IN USE" and preventing force control taking with a second press. It's independent of which page is on which display. The two latter also prevent taking control of the A/A radar from back seat

Most likely fixed in next release (the ASL was reworked a lot and INS related horizontal deviation issues have been fixed)