Draken35

Seems that the CDU key codes were changed again... So, it is broken for the time being

The "wall" cannot be destroyed by explosions or the Scenery Destruction Zone trigger set at 100%. It can be removed with the Scenery Remove Objects Zone trigger. Please set it to be destroyable.

For what I read in another thread on the topic, it might be that the F1 is not reading the cockpit data from the files in the saved games livery folder... I guess we will have to wait for Aerges if that is indeed the case.

Feel free to share it if you have it.

@Japo32 sorry for the ping, but just in case you are unaware that the F1 English cockpit mod is broken and are able to do anything about it.

My reference to the NATOPS was a couple of days ago regarding the topic of the thread, which you, perhaps, missed ... And the screenshot was just the AI summary of a google search and it matches what I've read in multiple biographies of naval aviators, if you think that is worst that nothing, well, fine. As I said before believe what you want. null

It is a very long list of aviation books in Kindle. But you call me when you have a source for your claim first... At least I tried to backup my to claims here with SOME information (reference to the NATOPS and a simple google search) ... You haven't ... But, believe what you want.

The "typical" career of USN Naval aircraft are 6 to 9 months deployed and then 18-24 months at their home (land) base... The attached image matches with all the biographies of naval aviators I've read. Hardly a "vast" majority. Regardless, IIRC, for the legacy Hornets , there was a non-flared weight limit (39,000 lbs ? ) as well.

The same manual mentioned above explicitly mentions that it is automatically engaged during landing in low mode with weight on the nose wheel.

Support for the Ka-50's PVI-800 added. I posted it in the User files and will update this post with the link once the file is approved, extension attached meanwhile. from the read me: -- Ka-50 Blackshark PVI-800 ONLY WSS applies to Nav-Target points ONLY There is no validation on the quantity / number of points per type. The load sequence is reset to 1 for Nav-Target points every time the Load Wpnt button is pressed. WDes: @|#| ... will load/replace the next Nav Target point in the load sequence @|T| ... will load/replace the next Nav Target point in the load sequence @|N| ... will load/replace the next Nav point in the load sequence @|A| ... will load/replace the next Airfield point in the load sequence @|F| ... will load/replace the next Fix point in the load sequence @|#| ... WHEN # IS A NUMBER from 1 to 9 will load/replace Nav Target point number (#) @|T#| ... WHEN # IS A NUMBER from 1 to 9 will load/replace Nav Target point number (#) @|N#| ... WHEN # IS A NUMBER from 1 to 9 will load/replace Nav point number (#) @|A#| ... WHEN # IS A NUMBER from 1 to 9 will load/replace Airfield point number (#) @|F#| ... WHEN # IS A NUMBER from 1 to 9 will load/replace Fix point number (#) Download here: https://www.digitalcombatsimulator.com/en/files/3344152/

First of all, thank you for this feature! It might seem like a premature release and not that useful currently, but I see it like an opportunity for the community to help guide its development, specially since we don't have the Open Beta anymore. I did not pay much attention to it because of the current limitations, but, yesterday, at the end of a 2 hours MP session in a sandbox that contains manually placed and dynamically generated ground units, we were talking about the save feature and I decide to save the mission and take a look just out of curiosity... Well, I just did and I am (pleasantly) surprised that the dynamically generated units (using Moose in this case) were saved! Now, the sad part is that they did not keep the name used when generated but a generic "vehicle1-##". I think, that if the dynamically spawned units were to be saved with their proper names it would be a big win for the scripting community. (Names are important since they contain prefixes that are used in the scripts to setup thinks like IADS and EWR networks)

This is what I'm using for the Viper with the Rhino.. Not exactly force sensing but works well for me: (I'm running a WW adapter - which is about 100mm give or take - with a ww F-16 grip

yes, it can be done with TelemFF. Just export the settings with configurator and load them in the configuration file option in Telem

totally offtopic... we do need the "laugh" reaction to the topics back

Agree, there shouldn't be hackers creating viruses or altruistic Ethiopian "princes" who want to share their wealth but, sadly, they do exists. But it is! Every single new update or patch is, in fact, new software from an AV perspective. Consider as well that, between DCS updates, there are several millions of new malware pieces identified . At the moment, and in the foreseeable future, there are only 2 options when these false positives appear (and they will): 1) Add an exclusion the the AV. 2) Wait until the AV vendor whitelist the files summited by ED/3rd party. Of course, this will take time... Can you imagine how long it takes to process all those whitelist request? Which one to choose, is up to each of us and so is how to mitigate the risks associated to option 1)

Hold on... So, now you are saying that Heatblur intentionally added a malware to their code? "There is a suspicion", you (obviously) and who else? Based on what? Concrete facts please.

If you bother to read the other (or one of the other threads about this topic, I lost count already), you will learn that the files were already submitted to be whitelisted. Meanwhile, you can disable the module or add the exclusion. Your choice. Please, make sure to wave whatever law you mentioned to the bad actors that make the viruses, since I'm sure you didn't give them permissions to your PC either... Who knows? Perhaps that will make them stop pestering us...

Why did it pass QA? Perhaps, because when it was tested, there was no virus that matched it signature? See the screenshot I pasted above.

So, so how much are you willing to pay for a module if the developer will have to rewrite the code every single time that its hash/signature matches to a virus that will be discovery tomorrow? Not to mention, will you be mad and complain if a previously fixed bug in the module reappears due to that rewrite ? Of if new bugs are introduced because of it?

A bit earlier in this thread: Perhaps we should blame the people that makes the viruses ?

I work in IT for the Health Care industry... You would be surprised on how many 3rd party software vendors "require" that their products be excluded from AVs... And those are not $80 commercial products (mostly due to performance consideration to be fair) The threat environment we live in is scary, very different that it was 10 or 20 years ago. @MAXsenna I've been thinking on running VMs as well for some of my stuff in a 1:1 rate to add another layer but that sounds too much like work

Ditto... and separated VLANs... Except I do not use a Mac

Do a DCS repair

Is the DCS main folder excluded from your antivirus ( D:\DCS World) ? Any messages from the AV, like a quarantined file ?

Found the culprit. I have all my devices connected to 2 powered USB hubs. I moved the Rhino to an USB port in my mother board, and unplugged the 2 hubs: no error. Next step was to plug each of the hubs individually with the Rhino in the MB. Found which one had the device causing the error and it turned to be an old Ejection Handle made by Cigar Bear coming as "generic usb device" ... Unplugged it, and all its good (quick test in 2d, active pause and the trim wheel axis moves the stick...) @MAXsenna appreciate the help!