Draken35

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!

Yeah, I did... Waiting for a response

Did a quick test and I don't seen any differences after removing that FFB driver. I actually inverted the pitch axis in the FF Tune/Controls and saw no difference. Stick doesn't move with trimming, but looking at the DCS logs I see this: ERROR INPUT (Main): Joystick VPforce Rhino FFB Joystick {E58621B0-F2B5-11ef-8002-444553540000} set spring autocenter failed! Unspecified error Don't know if that is "normal" or not.

I had VJOY installed a year or two ago and remember removing the device manually, but I went in to do double check. Nothing in device manager, but good call, this could be an easy gotcha for somebody. Now, I do not have any other FFB device but I used to have a TM Warthog base and your remark triggered my memory of seeing a Thrustmaster FFB driver installed... I just removed it and will test DCS in a bit... I'll update the thread with the results. @Art-J Thanks for looking! That was one the first threads I found with similar issues, before posting. Thanks!

I've been trying to make pitch trim work with DCS FFB native for the Spitfire and the P-47 to no avail. I have TelemFFB installed and I use an axis from a trim wheel to control pitch trim. No double bindings or VJOY or similar software installed. Trim tabs and controls animations, work and trimming shows in the control indicator. Both planes feel nose heavy and go into a dive regardless of pitch settings. Any ideas or pointers will be welcome!

You can create tabs in it and it can read DCS aircrafts kneeboards , briefings, mission and terrains tabs and even read PDF files in a tab (Chuck's guides!). I use Openkneeboard without a table in combination with Scratchpad.

Well... That is an awesome trick!

I flew this campaign in 2023... I guess I'll do it again with the remastered and the FFB stick... Curios about the lazy mig pilots gaining weight, did you use trigger.action.setUnitInternalCargo to add the mass? This could be a nifty solution for the UFO problem

That is, most like a bug with the auto lase script, not the MQ-9, since it is not really the MQ-9 who is lasing, The scripts just uses it as the source of the beam. EDIT, I see that you are using a CTLD from 2021 Recommend that you update it from here: https://github.com/ciribob/DCS-CTLD/releases/tag/v1.4.0 Mist is not that old but is would be best if you run the latest: https://github.com/mrSkortch/MissionScriptingTools/releases/tag/4.5.126 There has been several changes in the API since 2021

Try while manning a plane within a mission... That looks like your were in the main screen.

Make sure, because it will use the default DDM 3 IIRC for every plane... I did not save the code, so, if you want to continue using it, keep it safe

@Str][ker, @Recluse Sorry guys, put a few hours into this but I give up. Ran into some sort of nested execution context / variable scope issue that I don't fully understand. I'll keep it in the back of my mind but I won't put more time into it in the near future.

You can still capture the coordinates and have them at hand in scratchpad. Useful with a human WSO I guess

Nope... To much work for one waypoint at a time... And we have Jester...