ColinM9991

Bear in mind this error is a stack trace. It's reporting the location of where the code was compiled, not where it's being executed from.

Ah okay. I'll leave it be in that case since it sounds like the current structure works fine.

I love picking up home projects! Watch this space.

Is the JsGME format different? I'll happily update my github action to push out JSGME, OvGME and Open Mod Manager formats. The foundation is already there so it's straight forward to do.

Ovgme package for v0.6.2 is now live on Github.

The point is that many others report a positive performance gain, while some report a performance loss. I have neither gained nor lost any frames. It's very much a case of "YMMV". At the very least I believe an implementation of this is worth looking at to give users an option over which they'd prefer, I'd certainly opt to use OpenXR over SteamVR but that's just me. We're still in early days but this proves the concept. Out of curiosity, what are your specs? In my case, where I haven't had a drop in frames even on the Hoggit training server which usually becomes a sped-up slideshow on SteamVR, ASUS Z390-E i9 9900k (stock) 64GB DDR4 at 2666Mhz 3080 Founders Edition I haven't tweaked graphics settings between SteamVR or OpenXR.

There is a contradiction in your first statement whereby you state you see no benefit but acknowledge the game loaded 45 seconds faster, in some cases. I'd consider that a benefit. I strongly disagree that this is "damaging" to DCS performance. While I certainly have not gone to the lengths that several people have in this thread, I have noticed a significant improvement with stuttering, or lack thereof I should say. From what I gather and what has been made clear is that this is not about instant performance boosts or being a magic bullet. This isn't a native implementation, so it's understandable the performance gains are negligible. However, it remains to be said that WMR on SteamVR has a plethora of issues which make DCS, and other SteamVR integrated games, unplayable. Issues on SteamVR for WMR such as stuttering, which continues until you quit the game, and while any one individual may not have such an experience the fact is many of us do. For me, using this extension with DCS has solved some problems by taking SteamVR out of the equation, and DCS runs now runs smooth.

Face-palm. I tagged the wrong user. Sorry

@nikoel FYI, I've updated my repository to factor in your opencomposite.ini changes, it'll do this as part of the build so the OvGME package will be ready out of the box. I've pushed a new GitHub release to make sure the package is correct. I've also removed the version from the archive name as this was causing OvGME to fail. There is a VERSION.txt file, which is based off of the GitLab release version, so the update process can function normally.

I've marked my github repo as public. https://github.com/ColinM9991/open-composite-dcs Still need to find a good way to trigger this as close to a release as possible. This should somewhat automate the process of creating the OvGME compatible archives.

Update. I have a Github repo that is now building the correct structure for OvGME also with a version.txt file. Unfortunately, gitlab doesn't have a great API so I'm doing some things manually. I'm going to update the code some more to be a bit more resilient, should hopefully have something to share at the weekend.

Tried it out, simply amazing. I'm going to see what options are available to subscribe to the releases and automatically create the OvGME compatible archive every time a release is pushed to the GitLab repo. I'll probably do my stuff on GitHub, will share a link here when I'm done - if somebody doesn't first beat me to it.

It doesn't. Why not make it black?

Does it affect the weight in flight, or is this potentially just a GUI bug?

Many thanks to everyone who replied to this thread. I am able to produce repeatable results now when performing laser bombing by applying the outlined strategies. More importantly, I've found that keeping an eye on the TGP in the MFD allows me to better predict where the camera is currently pointing. Also, auto stpt was enabled at the time of the mission but it wasn't triggering any waypoint change as I never passed the waypoint threshold. It was an issue of banking too far left, too fast, and reaching gimbal limits.

Thank you, I'll give this a try. Up to now I have been doing a gentle bank left, as depicted, which explains the behaviour of reaching gimbal limits.

I'm reaching wits end with laser guided bombs and the targeting pod in the F-16. At the moment I'm playing through the Red Flag 21-1 campaign and, while I've passed the first mission and continued, I have been unsuccessful in executing the following plan for the laser guided GBU's so I've been going back to try again. I can execute the beginning of the drop as well as lasing, but the targeting pod reaches it's limit and loses sight of the target always in the final 5-10 seconds until impact. This happens regardless as to how much I roll. How on earth do you use laser guided bombs, without a JTAC, in this aircraft? I have not experienced this problem in the F-18 or the A-10.

What?

Thank you for responding with this! Of course, it is disappointing to hear that switching seats won't be possible, however I think having multicrew is much much better.

Same situation as you. Purchased this several months ago, received the replacement cams and they're exactly the same if not slightly worse in some cases. I can't believe this is being recommended by many people as the best option for desk or rig mounting.

I do like that idea. Us Irish always suffer from voice recognition though, so that'd be my main concern. Aside from the obvious time constraints. That wouldn't be a quick thing to develop.

Hence why I said "there are other design options". Each to their own. I'm not going to suggest that in this thread because I wouldn't use it.

Raising this to follow on from a brief discussion in Discord and to request a redesign of the Function keys radio menu so that it provides a more user friendly experience to both HOTAS enthusiasts and VR players. In my limited knowledge of the engine, I don't see a technical limitation for redesign the radio menu because most mission editor and mission interactions with the radio menu are done via triggers or scripted commands. The rest simply comes down to the engine translating those functions into key presses which it seems to already do. (Please remind me of how inferior I am if this is wrong) The two options that I think would work are: 1. Allowing users to rebind the radio keys. While not ideal, because the menu still has UX and UI issues, it allows people to put their commonly used keys somewhere more accessible. The game should handle these new keys as it currently does with the F keys, a duplicate bind should be allowed and used only to control the comms menu when it is open. 2. Overhaul the comms menu. Jester's radial menu springs to mind as an efficient, VR and user friendly approach. There are other design options of course but my design skills look like a child throwing buckets of paint at a wall. While I appreciate there is software and hardware that exists, such as VoiceAttack, a mouse with side keys or a Function key pad, I'd emphasize that an additional purchase or download shouldn't be required to work around this. They'd get the job done, but it still leaves a design issue for VR users and adds an additional thing to configure and manage. I also appreciate this won't be at the top of the priority list. At the very least, having it added to the list would be a good starting point. The campaign menu has had some great improvements over the past several months, I believe this can too.

No offence to ED but they are a bit overly-paranoid about posting any documents on the forums. Rule 1.16 says but they'll still delete any threads or comments with public information, regardless. In other words, I doubt you'll see any Tech Order.