Guppy

I decided to check out VR again in DCS. I got the Reverb G2 and I'm pretty impressed with the headset and lenses, in other games. Anyway... My frames show above 45 in most scenes (the frame counter that DCS displays) even well into the 60s/70s and 80s. However the cockpit, when I move around, microstutters and ghosts. It's really choppy when I move around. In fact, if I keep my head still, looking forward, the scenes and things flying by my view are pretty smooth. but it's whenever I move around... things ghost, micro stutter, it feels terrible. Interestingly enough, when I take my headset off and move it around, the reprojection of it onto the monitor looks smooth, but man when that headset is on it is absolutely atrocious. Any thoughts? DCS Settings: - Stock VR settings; even lowered everything to the lowest with no improvement - I also turned off all of my exports in the .lua and cleared out the typical cache folders. - PD set to 1 STEAM VR Settings: - Refresh @90hz - Resolution per eye: 60-150% no noticeable change - Super Sampling off Windows Settings: - I followed the various guides and have all of the normal non-sense that windows thinks is better turned off. I'm running: 8700k @5.2ghz EVGA Hydrocopper 3080ti 32gb RAM NVME for windows SSD dedicated to DCS.

Let me rephrase my question; based on the Newsletter(s) it sounds like there are a bunch of significant changes coming to the core application (Additional Edge updates, Vulkcan, multicore support, etc.). Will those core changes impact our ability to have home cockpits as they exist today (Exports, DCSBios, etc.)?

Question related to the future release of Vulkan and Edge 2.7... Do we have any idea if exports, as they currently exist, will be supported through this release? That is, setting the client to window only and expanding the client view screen to other monitors so that MFD can display on other monitors, etc; along with all of the exports related to DCS Bios? Basically, those of us who have built home cockpits -- do we know if these will still work like they do today for future significant client updates?

Admittedly it has been awhile since I've flown, but when I hopped into a hornet today to do some A/G I noticed when zooming into a target with the Lightening that the zoom seems to stutter vs. smooth. Previously, the zoom was completely smooth vs. noticeable changes between 1x,2x,etc... is this working as intended? I tried going back to some of the patch notes and saw nothing on it.

I was able to figure it out on the Discord with some help.

So I am so confused as to what files I need to download. Here is what I did: I went here: https://github.com/DCSFlightpanels/dcs-bios and clicked the green code button. From there I downloaded it as a .zip. I linked the doc folder to chrome for the control references. I added "dofile(lfs.writedir()..[[Scripts\DCS-BIOS\BIOS.lua]])" to my export script. I commented out DCSBIOS Hub's line so that it will not be executed. I went to: H:\DCS BIOS_old fork\DCS-BIOS\Programs and launched the multiple com ports.cmd and got the following error: 'socat\socat' is not recognized as an internal or external command, operable program or batch file. I have no idea, at this point, how to link my arduino boards on COM3,4,5,6,7,8,9 to get them to work.

okay - I think I'll make the shift to your fork. I'm having an issue though with the installation instructions here: https://github.com/DCSFlightpanels/DCSFlightpanels/wiki/Installation It says to "click on assets to expand a list of downloadable files"... where is the assets link? I do not see that anywhere. **Nevermind - I figured it out, I think***

Hello - I finally was able to make the ECM change for the hornet, but it is still not working in game. Before changes to DCS Bios : defineTumb("ECM_MODE_SW", 0, 3116, 248, 0.1, {0.0, 0.4}, nil, false, "Dispenser/EMC Panel", "ECM Mode Switch, XMIT/REC/BIT/STBY/OFF") After Changes: defineTumb("ECM_MODE_SW", 66, 3001, 248, 0.1, {0.0, 0.4}, nil, false, "Dispenser/EMC Panel", "ECM Mode Switch, XMIT/REC/BIT/STBY/OFF") Ardunio code: const byte ecmModeSwPins[9] = {27, 29, 31, 33, 35}; DcsBios::SwitchMultiPos ecmModeSw("ECM_MODE_SW", ecmModeSwPins, 9); This was working prior to the implementation of the jammer. Any ideas?

Thank you! I'll make the adjustment -- appreciate it!

Did the hornet ECM switch change in the current open beta? Previously moving it I could go through off, stby, bit, etc. Now I move the switch and it performs no function in game. I am using DCS Bio HUB... This is the HUB code: defineTumb("ECM_MODE_SW", 0, 3116, 248, 0.1, {0.0, 0.4}, nil, false, "Dispenser/EMC Panel", "ECM Mode Switch, XMIT/REC/BIT/STBY/OFF")

Right - this is why I said at the end of my post if I did not have a simpit I would go VR. Also, this is why I said there are pros and cons to both. My comments were not to say one was better than the other. The mouse thing I could not get over, but probably because I have my pit. Like I said and you echoed... pros and cons. One is not better than the other unless in the eye of the beholder.

There are pros and cons to both. For me, having a simpt makes the move to VR less than ideal. The ability to quickly do things in the pit has been more fun. I've tried 3 or 4 headsets, at this point, and I have not been sold by any of them. The Reverb came close... Mind you - it is an absolutely fantastic experience and I love the feeling of being immersed in the cockpit. I just cannot get over how clunky the performance and graphics are though. In addition to the lack of hand controls. For me, it's more suitable for aircraft that do not require a lot of clicking in the pit -- it was pretty perfect for the F-15 as there is zero need to grab a mouse or click on anything. I had Mile's PointCTRL and while it was a step in the right direction, for the full fidelity aircraft, but there needs to be a better solution for hand controls. If I didn't have my simpit I would probably do VR, but for now the pros of my setup outweigh VR.

Guppy F/A-18

Is it possible to have a simple control for the parking break - On/off? This would perform the appropriate rotation pushin/pull out as required. As a pit builder the solutions to making this work are cumbersome and it would just be much easier to have a more simplistic control mechanism to engage/disengage the parking break.

Your rear wheels will hit slightly past the wire itself, the hook should snag the wire right on touchdown. Though, you're not to worry about where you touch down...sort of. You follow the IFOLS in the entire time and worry less about where your jet touches down. It's not a traditional runway with markers you aim for.

If they allow for the input of IFF codes then in theory the other side could try and guess them and look like friendlies up in the air. For DCS this is all kind of stupid since switching sides can give you the other teams IFF codes from the briefing. Or someone wanting to be "fun" by giving you the other side's codes. If you decide to switch codes and use something different then it would require a lot of communication with your team. Being DCS what it is -- that would mean hoping everyone is on comms. Otherwise giving the code to people will be a pain. All and all I hope they do not implement IFF to a more advanced level then it is now. Turn it on and it should function. It would be a waste of effort otherwise.

This was specific to my older setup, but might serve to be useful to you: https://guppy.home.blog/2019/02/06/configuring-screens-and-pulling-data-from-dcs/

It was captured at 30 FPS, so it exaggerates the impact. But it is still pretty noticeable.

Those have both been done already.

Here is a video of the issue. Pay attention when I look out the sides, it becomes super apparent at that point. Happens in F2/F3 views, too. Adjusting graphical settings to the lowest doesnt do anything either as it's not a frame issue. I'm a solid 60 the entire time or much higher when I lower settings. This is with all exports and DCS BIOS, etc shut off. I also did a flat spin so you can see just how terrible it gets. Oh... and the game crashed -- lol!

Mine is already off, but I continue to get the same behavior. 8700k @ 5.3ghz 32GB solo SSD for install 2080Ti OC'd Whether I use my exports or run a single screen... the micro stutters are there since the last update.

I have the same behavior here; exactly as you describe with or without GSYNC or VSYNC enabled and shaders deleted.

I'm not sure if my link fell off before, but here you go: https://guppy.home.blog/2020/07/13/out-of-control/

Thanks! I need to post updated shots, but this is the latest post on my blog. https://guppy.home.blog/2020/07/13/out-of-control/

As I stated in a previous post regarding other important issues, 100% agree. I am not asking nor am I insinuating That this is a critical issue. It is, an issue, that I would like one day addressed as the module matures.