darkman222

Thats my settings. And I found why that checkbox is needed. If unchecked trimming the aircraft does not move the physical stick. So it needs to be checked. What seemed to work is to connect the FFB stick, start dcs with the "force feedback" checkbox unchecked. Then check it and trimming seems to work without the F4 pitching up. Its not the most convenient thing but at least it works. Here are my settings. null

A known issue is the constant pitching up that comes when force feedback is active. solution is to switch it off. Problem is: I have the FFBeast and use force feedback. The interesting thing is, that this pitching up is not happening on my second PC ( a laptop with DCS installed) that never had a force feedback device. On this PC the force feedback setting does not matter. DCS log attached. Edit: I just tested with "force feedback" checkbox off. Force feedback seems to work although its not checked. So why do we have that checkbox then? dcs.log

What is the appropriate frame rate. If I run a VR headset that works with 90 fps then I just set it to 90 fps? We have the same setting in DCS itself and setting it to 90 fps makes DCS even more stuttery.

DCS 2.9.8.1107 Improved. FLCS Pitch overshoot/creep when releasing stick. Was it really adressed? If you remember @DummyCatz test the pitch creep is about 5 degrees when the stick is released. If I try it with the recent version it almost looks the same. Although I dont know how much pitch creep the real jet will have this just looks like it was unchanged. Track attached. DCS 2.9.8.1214 pitch creep.trk

I have had no time to mess around with that yet. But one approach could be to use the "user curves" to rebuild whats shown in the graph above how the curves were set up before we got access to that. From that point just start modifying your own rebuilt curves to your liking could be a feasable approach.

I would say the pitch overshoot will only rarely contribute to that as it happens after the control input was made. These settings have their effect when you command a manover. (Still unsure about how much the pitch creep was reduced anyway)

@BIGNEWYHere you go. Its from the dcs dogfighters server. Just an airspawn in team deathmatch guns arena. HSD does not need to be SOI, it even happens when in DGFT mode. I also attached these files with the prefix "DGFT mode" for further reference. This is a multiplayer only issue. Could not reproduce it in a single player mission. dcs.log mobettametas_Dogfight_Arena_-_Caucuses_-_v2.30.1-20241001-214613.trk DGFT MODE mobettametas_Dogfight_Arena_-_Caucuses_-_v2.30.1-20241001-214948.trk DGFT Mode dcs.log

ED worked on the thread distribution on multithreading. For me very heavy multiplayer missions that used to get stuttery and bad performance if the server was up for a long time got a lot better. Will still keep an eye on that. But looks as if there is some improvement to report.

Deadzone is pretty self explanatory. As I am alternating between a spring stick and a a FSS, what does the "force stick gradient" setting do? I imagine it as a response curve to the stick input. If you enable "controls indicator" an approximately 70% pitch command at rate speed still makes the jet pull almost 9G. Which means the remaining 30% of the stick travel are just unused. I have to continue testing. But the "force stick gradient" setting just seems not to do a lot.

Did spotlight ever work in TWS before? If it worked in TWS I am pretty sure it was wrong if it did.

Also one thing to check, not sure if it applies to our block 50 F16, squawk transponder code can be set through the ICP too, and not only by the unpractical left console.

@Deltaalphalima1 Thank you so much. This is the exact thing I am looking for since months if not years now. Although I was hoping for something that didnt need an extra program to be run in the background, yeah, probably unless ED builds something into the "F16 special" menu, thats the best way to do it. Works just perfect that way. Thanks again! ************************** EDIT 1: It almost worked. The autostart drops this error: I can click okay, and start joystick gremlin manually after that and it works fine. ******************************* EDIT 2: Its a known autostart issue of Joystick gremlin. Workaround: Create a *.VBS file like joystick_gremlin.vbs Put that code into the file: Set oShell = CreateObject ("Wscript.Shell") Dim strArgs strArgs = "cmd /c cd ""C:\Program Files (x86)\H2ik\Joystick Gremlin\"" & joystick_gremlin.exe" oShell.Run strArgs, 0, false And that file then goes into your autostart folder: For example C:\Users\alex\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup Now autostart works. Thanks again for the script!

The option youre mentioning is "use mouse cursor" if you disable it, you have the opposite of what that thread is about. Then you can only move it with the head, which is not what we want. The problem with the current implementation is that you naturally counter move the head movement with mouse movement, which makes it so hard to click something in a battle, when you dont have time to fumble around. I dont want to disable the mouse movement. But I dont want to have it bound 1:1 to my head movement so that I have to keep my head perfectly still to hit the button I want and not the one besides it. It should just sit and stay where I put it. If it comes to the boundaries of the VR view (probably due to a head movement), it can be dragged around by the boundary. So you can bring it back in focus with a little mouse jiggle.

As the radar of the F16 is apparently worked on, I wanted to make sure that this bug is not overlooked. ACM and STT was not explicitly mentioned in the upcoming patch, but it would be a pity if that behavior still managed to slip through this radar patch. A TMS up command makes the radar start to make a slew from left to right, locking the first target that comes into its sight. In this example, you can see that it is almost impossible to lock the targets that are on the right. Track from recent DCS version attached. Video 6 months old. As the bug still persists but my original bug report got merged with the one of another user, so I can not find it anymore. sweep starts from right.trk

As the F16 radar is apparently worked on at the moment, I wanted to make sure that this long known bug is being adressed too. ACM and STT was not explicitly mentioned in the upcoming patch, but it would be a pity if that behavior still managed to slip through this radar patch. I made a bug report long time ago, but it disappeard, or better I cant find it any more as it was merged with another thread from another user. Reproduction. -DGFT mode -TMS up, TMS up to slave radar to JHMCS -TMS up hold "NO RAD" displayed -move the helmets boresigt on a target. => Despite showing "NO RAD" it still locks the target Its an important feature because the radar locks everything in line of sight while its being slewed, making it hard, and sometimes impossible to pick one target out of multiple ones. Trackfile from recent DCS Video 6 months old as this is from my original bug report. no rad still locks.trk

Please only bring the reflections and scratches back as user option to increase the strength. The initial release strength of scratches and reflections was very distracting in VR. I am very pleased with as it is now. Probably 2D users with sharper visuals on monitors may like more of them, but with limited VR resolution we have a good compromise now.

@Deltaalphalima1 The F16EX force sensor works like a charm. Nice piece of hardware. One thing I am wondering is if there is any way to disable the axis while the sensor is depressed? I was looking for that in the winwing software which does not offer that option. As there seems to be a firmware for the analog thumbstick I thought, maybe there is something similar for the F16EX force sensor. Disabling the axis while depressing the TDC helps in the F16 because depressing slews the Aim9 seeker. But moving the axis the same time also enables the radar again and auto locking the bandit which is no good for stealthiness.

If you use steam you can use fpsVR. Shows CPU frame times. You can have a maximum of 11ms CPU frame time for 90Hz / 90 fps playback

Nice you received yours. I am still waiting. And you have the one with MR cameras, which adds to the weight. The only thing I am afraid of is that it will be too heavy, especially too front heavy. Not intending to do MR, so I did not order the extra cameras. Let us know how the wearing comfort is, especially considering the weight distribution.

I dont know if the mission creator can do something about it but I realized on servers with dynamic spawns (contention DCS in this case), where the mission creator tried to limit the use of high performance jets like the F16, which is only available on very little airfields, it can be some kind of hassle to find the airfield that offers the F16 for example. So here youd have to click the airfield, then open up the dropdown, look for the F16. Go to the next airfield, repeat until you find one with the F16. Like so: null Wouldnt it be possible , or probably its already planned to get a "unit type drop down" like So: In this case it would bring up only the 2 airfields with F16 available. And if there is a thrid airfield available later in the campaign, I would not just miss it if its added to the list later in the campaign.

Thanks Lord Vader for adressing the energy bleed discrepancies. And thanks @DummyCatzfor taking the time for investigating. Until this will be adressed I hope this will stop the endless debate about people flying circles for Tacview and discussing a plus minus 0.2 deg / sec turn rate difference to the EM diagram when the real issue is the energy bleed rate. That was what I was suspecting for quite some time but I was not proficient enough to put it to a test like you did.

Just my amateur 2 cents. I did not expect the DCS F16 to bleed too little energy at corner speed. But 21 deg / sec wont win a fight against a 23 deg / sec jet anyway. Even if you can sustain it longer than you should be able to. The only option is just to stay fast and watch your opponent outturn you or to bug out and reset. Because going slow is even worse as it drains your energy so fast and you will struggle to get it back. It makes sense considering the overall impression the flight model gives, that the slow speed performance just punishes you a lot more than in other airframes.

How do you mean that? Max instantaneous turn rate is just a max performance max available G pull. Not sure how you could "fly" a max ITR.

What about the energy bleed at slow speeds? From 300 kts the DCS F16 bleeds down like crazy and does struggle to gain energy back.

As many people stated the trim speed of a trim button push is too sensitive to reset the trim properly, which of course should be adressed. But why cant we just have a "reset trim" function that can be assigned to a button for the time being. Its basically already there. The user YAGA just wrote a couple of lines for that. You just have to add these lines in the joystick/default.lua in the F16 folder: ( search for the "speed brake" entry and paste the code below the "speed brake" line) {down = control_commands.RollTrim, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = 0.0, name = _('ROLL TRIM RESET'), category = {_('YAGA MOD'), _('Throttle Grip'), _('HOTAS')}}, --MODDED {down = control_commands.PitchTrim, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = 0.0, name = _('PITCH TRIM RESET'), category = {_('YAGA MOD'), _('Throttle Grip'), _('HOTAS')}}, --MODDED It gets reset with every update though. Why just not make it be permanently accessible by ED?