Vakarian

With the proliferation of FFB devices, mostly thanks to Walmis with VPForce Rhino, there was the talks of creating FFB rudder pedals. IIRC, the kit for MFG rudder pedals will be available soon, but from what the devs are saying DCS does not support FFB effects on the Rudder axis, only for Pitch/Roll. Main use case would be to support anti-torque pedals trimming for the helos that support it, but also to offload some of the haptic feedback to the pedals as well. I have searched the thread, didn't found another thread so I'm making this one. Please, take this into consideration, folks with FFB pedals will be really happy and by the looks of it, there'll be more and more of them.

Can you check log to see if there's any indicated error? Yesterday evening I was building a mission and I was able to add sound files. Another thing to check, I used "Sound to Coalition" action, can you check if that works for you?

Quite substantial work required, would make bug reporting an absolute hell but on the other hand it would be really awesome to have this kind of variation. This could make all the startup checks relevant as you might jump in the aircraft that has something out of the order and you have to re-slot into another bird. Ofc, to accomodate everyone, this should be optional as not everyone has the will nor time to go through all cold-start nuances, but I really don't see why would someone be against this if it's made as an toggleable option with factory-perfect aircraft set as default.

Hey, unfortunately, I can still reproduce the issue using the same steps. Here's today's log where I've tried it two times. As soon as the Dedicated server is booted up while the DCS game instance is already running, FFB is lost. dcs.log

Not the bad suggestion at all. It would be mandatory if those proposed "Default bindings" only follow assigned controller It would also be good to even the auto assignment altogether (could be a temporary measure) as I'd put my hands on the stake that the auto assignment causes more issues than it solves.

Then just go an play. Stop worrying about every update. When it comes, it comes, there's really no point in being anxious about it. There's plenty of fun to have, you just have to be creative

If you require updates to find DCS not boring, then I don't know what to tell you otherwise than maybe "you're doing it wrong"?

Until that's added, you can work around it with built in control mapping. You can bind for example BTN_15 and BTN_15_OFF (off binding is in the dropdown menu) for the toggle and then whenever you put switch in either position it will actuate it. One caveat is that you need to set the physical switch in a position and then with mouse you can sync it.

Harrier default gain/brightness settings for MPCDs are not ideal. You really should play with them to get the correct contrast (it's been a while, not sure if they implemented grayscale so you can use it for calibration) and then stuff should start appearing on the MPCDs.

I mean, as DCS actually manages multiple files for the same device (when such stuff happens you get multiple .diff.lua files for the same device, just different HWID), it would be highly beneficial if DCS controls manager allowed you to scan for such files and automatically restore your bindings. Right now what you can do through GUI is to go to each and every one of the controls for each and every single one of the aircraft and manually restore profile using previous .diff.lua. Basically, when you startup DCS and it sees that the ID of the devices changed (more than one .diff.lua file for the same device name), it could automatically prompt you to restore control binding from the previous ID and most* of problems would be solved. It could then remove the old .diff.lua so there's always one file per device name. *Still wouldn't fix the issue when firmware update changes the device name, but that's a subset of the problem

I run both DCS and DCS dedicated server instance on my PC. I've recently noticed that dedicated server takes control over FFB forces, but only after it's launched after main DCS instance. Steps to reproduce are as follows: No issues (force feedback present): 1. Run DCS dedicated server 2. Wait for it to boot up 3. Run DCS game instance 4. FFB present when flying Issues (no force feedback): 1. Run DCS game instance 2. Wait for it to boot up 3. Run DCS dedicated server 4. No FFB present during flying I performed one additional test just to confirm that it looks like last DCS process that's run takes control over FFB forces. 1. Start DCS 2. Fly, FFB forces are present 3. During pause, launch DCS dedicated server 4. After unpausing I confirmed FFB forces are missing 5. With DCS dedicated server still running, stop DCS game instance 6. With DCS dedicated server still running, start new DCS game instance 7. With DCS dedicated server still running, launched mission and confirmed FFB forces are present. I've attached DCS logs, although I'm not sure how much of help are they. "dcs.log.old" and "dcs.log" are supposed to represent above mentioned steps with "dcs.log.old" obviously being the first part (steps 1-5). dcs.log dcs.log.old

It's a nitpick, but it's necessary to get things correct. FFB (Force Feedback) and Force Sensing (like FSSB from Real Simulator and how actual Viper stick works) are two completely different things. Currently even users with the FFB bases have same issues as ones with the the cam/spring bases. Please, do not mix those together as it can add confusion What we likely need is Force Sensing base friendly and Sprung base friendly controls set, although how easy it's done I'm not sure.

Mine just arrived. Although at work I did try to see how the buttons react and yeah, like expected all the 4-5 way switches are mushy as hell. One thing I noticed is that when you take the cap off, it is a tiny bit better so I suspect there's a bit of a slop due to the space between the switch stem and the cap groove. Will try to fill it with "something" to see if it'll help it. Still a miles away from VKB 4/5 way switches but that's because VKB produces their own and Virpil still uses off the shelf switches which are really sub-par. Will see later tonight how it is in action when I mount it.

Could it be that the final altitude is in meters? That would roughly equate to 22k-ish feet. IIRC few of the elements are in meters unless stated otherwise

Yes, something like this would be a great addition

From the changelog, CA section * Fixed issue with ground units that in some cases allowed them to track targets without clear LOS (AAA and SAM tracking target behind mountain).

Hi. At least now, with the latest you are doing something right as some models show OK, you see some variation. If I were to guess, liiks like those models that have "_dst" suffix are looking OK, those without are full bright through FLIR I did a quick and dirty drive by through all models in the asset pack. If this helps you figure out what are you doing better in some models, could you please make it work on the rest so the show up correct-er through FLIR? That would mean a lot to me and I presume everyone else using the pack.

I cannot right now confirm that Apache is not affected, buuuut when looking at Wags' videos, what I see in the video and what I see during playing is pretty much the same so I would dare to say Apache is not affected. Here's a quick comparison what I managed to scrounge through my screenshots (after the font update) and one of Wags' videos. About the zoom, it's not affecting anything at all. Zooming in or out, lines are still "wrong" on the 21:9 aspect ratio.

Trimming is not a disaster, you need to understand how it works. Plain and simple. It worked for me when I had joystick with springs and ofc it works with FFB base, but saying it's <profanity> because you don't understand its usage is funny at best.

@Massun92 In my group, we are loving the pack, especially the revetments, various HESCO barriers and "fortifications". I'd like to ask you do you plan on updating the models and/or textures (I have no clue what's required) to make them not 100% bright objects when looked through FLIR? There are quite few models that really stand out so when for example making some ambushes people can easily find them on FLIR. If I can help in any way, please let me know.

Yeah, EU store. I mean, production issue could mean a lot of things, not just "there are none". Maybe batch was smaller than expected because "something" and they distributed what they had... Oh well, it's not the end of the world. It will come when it comes. I pinged them just because there was a "mid/late January" for expected delivery when I made my order and it was still "processing" so I wanted to know if there's any known delay. Now that it is, I'm fine with waiting.

I messaged them and there was some production issue with the counter-balance kits so if your order contains it that might be why it's delayed. They should be ready to start shipping after 19th February unless something else prevents them

Yeah, it was quick and dirty test on Marianas just to see if there's any discrepancy after a few years. I'll do what you suggested sometime during this week. Have all maps so it shouldn't be an issue.

While it wasn't any definite test given that I lack modules from number of 3rd parties, I did throw a quick test with few ED, Heatblur, AvioDev and Razbam modules. With QNH set at default 29.92 in both tests, only thing changed was the temperature. First test I did was with the maximum allowable 40 degrees and second with the minimum allowable 20 degrees (Celsius, both values positive ofc) In +40C test, briefing QFE was 29.38, in +20C briefing QFE was 29.35. Aircraft +40C measured QFE +20C measured QFE A-10CII 29.39 29.35 AV-8B 29.38 29.38 C-101 29.39 29.36 F-14B 29.37 29.33 F-15E 29.38 29.38 F-16C 29.39 29.36 F-5E 29.40 29.36 I did also include P-47D in the test, but for the love of god I cannot figure out how to read the pressure setting that was set QFEtestWhileOnRwy_40c.trk QFEtestWhileOnRwy_20c.trk

It probably got renewed and it took a bit for it to propagate. Seems fine on my end for last two days at least