Draken35

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...

@Str][ker @Recluse Since I hear you two volunteering for testing... This involves a replacement of the hooks script and the 2 extensions. The procedure (that I tested in SP) is: In a clear screen type @{type} were "type" is the type of airplane (list bellow), it is case sensitive. Hit the "Load Wypts" button Clear the screen and work normally @{RESET} in a clear screen restores normal functionality. Types list: RESET AV8BNA F-15ESE A-10C_2 A-10C FA-18C_hornet M-2000C Mirage-F1EE F-16C_50 AH-64D_BLK_II OH58D UH-60L SH60B MH-60R CH-47Fbl1 SA342 * Working is a clear is probably not necessary as long as @{type} is the top most command. Obviously, any coordinates already capture in the screen will not change if you change the plane. Have fun EDIT: Files removed. Will repost when Hornet issue reported below is fixed

Maybe. I'll think about it

And you guys are absolutely right... 12 drops from active pause, all short. Fairly easy to reproduce test viper ccip.miz

The screenshot doesn't seem to reflect that but that is just a handful of drops, but it thy are always (or just favor) falling short, then that's a bug. I'll setup a test of my own... Been a while since I dropped dumbs from a Viper

What was the release altitude (yes, I know it is in the track, but I cannot download it right now) and what is the CEP of the mk.82 ? (JDAM is 5m, I have not been able to find any info for the mk.80 series) A more consistent test would be to dive, active pause and drop 1 bomb with unlimited ammo, once reloaded, drop again (this eliminates the station as a variable) and keep alt, speed and dive angle constant... I definitely do not expect the bomb to hit exactly on the piper every single time... If ccrp is doing that, then ccrp is buggy

@greyeagle787 Not much different than mine \ I wonder why yours keep saying "creating" the 0000.txt file after several tries. Not sure if it has anything to do, but can you verify that you the file was actually created? EDIT: Actually, see that after creating it, it doesn't find it (nothing after loading pages). If it is not there, try to create it manually outside of DCS

That line is omitted when the script does not support the selected plane. The plane type on the API used by the script is populated AFTER the plane spawns, when you are in that screen, the plane does not exists.