I can confirm that the issue has NOT been fixed since the very first SU12 beta, I just installed the final version.
Wow. What a disappointment. Unfortunately, not surprised.
This really impacts my workflow. It basically renders Navigraph, Simbrief Panel, and Sky4Sim, all useless in VR now. All three of which I use on every single flight. Iâm angry.
In the Navigraph Charts panel, you can use the Interface scale
setting to change the size of the interface, and the Use large-scale map
setting to increase the size of the map itself.
I just updated to SU12 (I wasnât participating in beta) and I can confirm, the bug is here, despite @Jummivana attempt to bring Asoboâs attention to it. As I heavily depend on 3rd party toolbars in my simming and I sim only in VR = not simming for me for some time. The only hope is in the toolbars creators, who my find a way around this new regression.
I was reluctant to acknowledge, that with recent decision of HP to discontinue Reverb G2 (once the âdefault VR headset for MSFSâ - as based on Windows Mixed Reality) and the cuts and forced reorganisations in Microsoft VR product development team, Asobo will also limit the efforts on supporting VR. Such plain act of ignoring the beta testers and releasing the SU12 with such obvious regression, points me to the conclusion, that for Microsoft/Asobo VR is now considerd niche feature, not worth the development or even listening to beta testers.
Please please please fix this. For us VR users this really is game breaking. Even if some third party devs will apply a workaround weâll be stuck for potentially a long time to get those.
I really do question what the point of betas is, if regressions, even grave ones like this, ever get addressed, let alone fixed. Another example is the water polygon bug.
That doesnât mitigate the fact that one canât zoom in as much anymore on the map (which is quite important when looking at the airport layout for taxiing) and the charts jump weirdly while zooming in or out.
For those of you who fly with Reverb G2 (based on Windows Mixed Reality) you can try to move your entire Windows desktop to the VR, with the apps you need on it. It has some limitations though:
-
There are interaction issues, as you must transfer your mouse focus from the virtual cockpit, to the Windows desktop. I go around this by bringing to VR my 2nd display/desktop only, while my sim window is running on my 1st display. I also donât need to switch often with mouse from the cockpit to the desktop, as I have several H/W panels so I donât need to click anything in the cockipt with my mouse - it can stay focused on the desktop (where I have my charts, Skydemon, VATSIM vPilot, Whiteboard for copying my clearances, Navigraph charts, the browser with SimAware or any windows app I need). When I need to switch between cockpit interaction and desktop interaction I have a button on my yoke defined, with Alt-Tab assigned to it via FSUIPC, which allows transferring focus from the sim to the desktop. Going back to sim is easier, just just click outside the desktop area in VR.
-
Windows desktop in VR is sourrounded with strong Windows borders, which breaks immersion. To limit this, I place the windows desktop in VR on my (virtual) lap like oversized GA kneeboard.
On the positive note: This newly invented issues in the sim remind my of my real flying, when the real airplane can surprise you any day with some brand new issues and you need to stay creative and find your workarounds, while still flying safely. I would call it the next level of flight simulation
If we want to fly, we will overcome all these issues, no matter how creative Asobo will be with throwing the new challenges on us.
I only wonder how Jorg, Sebastien, Martial can one day be the truly passionate fligth simmers, spending hours with us during their dev chats. And another day they also the tough business people, deciding to ignore some regressions and beta issue reports and to proceed with the releases, fully knowing that such release will hit some users hard. It reminds me of Dr Jekyll and Mr Hyde case.
This should be conditional on being in VR, as it is now too big in non Vr mode, quite common workflow to get aircraft and maps setup outside of VR then drop into VR once clearance received. There is a VR variable set to true that can be used to determine state. Also VFR maps donât seem quite right in VR when zoomed , but need to do some more flying
it all sounds great until people like myself who have spent 1000âs of hours developing freeware add-ons to benefit the community find that some random regression bug has screwed up our software. its hard enought developing in undocumented and unsupported environments.
I have much more pressing personal issues to sort, but had to pull a few long days to sort out a workaround because some chaps at Asobo had to make âtough business decisionsâ. They have acknowldged the issue, why go ahead and release the software knowing it will do over part of their user base.
Moving the desktop doesnât sort the issue; fixing the problem does
You are 100% right. We should have the base product functioning well, without the need for inventing workarounds and fixing things which arenât broken.
I didnât do the SU12 beta so this was a new problem to me. Since updating to SU12 I have exactly the same problem using Navigraph in VR. OK, itâs partially solved by increasing the size in settings to 2.6 which is fine in VR but totally useless when swapping to 2D. If ever there was a case for a hotfix to be rushed out, then this is a top candidate. Goodness only knows how this bug was allowed through the testing?
Believe me, there were much stronger regression cases, like the obelisks from space all over the landscape just before the 2021 Christmas and long Asobo vacation, the autotgen tall buidlings on final approach and may other, affecting all the users, not just the small minority on VR users. Hope for a miracle, but donât rely on it.
Most of these regeressions were walked around by some clever users, only weeks, months later Asobo fixed them. Some regressions are still with us, deep ungerground, buried under layers of clever mods
But some 3PD applications wonât work with this workaround (like the pushback planner) and yeah, itâs quite immersion breaking. The SteamVR apps (like OVR Toolkit) are much better in this regard, but SteamVR comes with a huge performance impact.
It canât be that difficult fixing this issue for Asobo, can it!? Or did they make any architectural change here?
Ok, hear me out, i think what Asobo did here was a good thing, as now vr panels and nameplate text resolution are tied to the VR size, not the desktop window size.
This means that you wonât get ovals instead of circles and you dont have to keep your desktop window at the same aspect ratio as your VR area. I also did the autohotkey trick of making the desktop window very large and mostly offscreen for VR recording, which has the benefits of clear nameplates and easy to read text in panels. But now, devs must rewrite their panels with this new scaling factor in mind.
I tried using OpenXR Toolkit to set the VR size much lower than normal, and you can see that the icons are designed for a window height of something in the 1000-1500 range.
2324x2000
4648x4000 (i run this normally)
edited to add: i think this method will be more future-proof, as VR gets to even higher resolutions, much like the change that apple went thru going to âretinaâ displays. The devs needed to scale to the resolution they are given.
Hello Simmers!
To all sky4sim users around here, I just published a quick workaround to be able to scale Sky4Sim in VR until we get an official patch.
All details are available here: https://sky4sim.com/msfs-sim-update-12-vr-workaround/
Wish you all many great flights and cross our fingers to see that fixed as soon as possible!
Seb
I canât express how sad I was to find this fault was not fixed in SU12 release. I fly in VR exclusively and as a VFR pilot heavily rely on the use of moving maps and EFBs. This renders a number of even my Payware addons (FSKneeboardPRO, Sky4Sim NG, Flightsimulator.me, etc) plainly unusable
I donât ask for improvments. However, we had continous regressions, repaired and replaced by new onces, since, I think, SU7. We just want a VR toolbar which just works under VR, as it once did.
[MODERATOR EDIT: Please do not ping team members.]
I kindly ask to bring this to the attention of the development team once more. A preferred place would be the Q&A tomorrow. I feel a hotfix would be in place for this. Waiting for another 3 months or even longer canât be the solution.
Thank you very much, Michael
However you want to spin this; its been an unwanted amount of effort on us âdevsâ. Some of us donât make any money from this, so this change is n othing but a burden.
Remember, this area is effectively:
UNDOCUMENTED & UNSUPPORTED by Microsoft
There is no real Asobo to development community (NOT DEVs) liason channel unless you are a big beast, so we have to work blind and hope things donât break.
Iâve run support and development functions for some of the worldâs biggest corporations in my career; I wouldnât dare treat my development and user communities the way Microsoft treats us. No amount of âthis is a good thingâ , âtied to window sizeâ etc, technical arguments can hide the fact this is a shocking way to role out breaking changes.
Us âdevsâ should get some respect, not have cheerleaders like yourself just telling us to suck it up and get on with fixing things.
@smitty9792 While I definitely aggree with the fact that VR needs a proper UI and do not scale on the windows desktop size which could probably help restoring panels at the location and size they were on the previous flight in VR. I guess you donât really take in consideration what the VR resolution is currently in panels and why a 2D interface shouldnât get to this kind of scaling.
By just resizing my addon panel to approximatively the size of the the side window in a C152 I checked the resulting resolution on Coherent Debugger (5521px / 6154px)
This is like 100% of my headset resolution for a panel rendering size smaller than a quarter of my view
While this can be really cool when you just want to display SVG images and Text, what happen when you try to display things like maps or images which are not scalable?
As a simple exemple: Open Street Map / US sectional charts and a lot other map providers tiles are locked to 256x256 which leads to unreadable texts on the map when you jump to crazy resolutions and especially more tiles to be rendered at the same time which have of course an impact on the network usage and available bandwidth. Even retina bing map backgrounds texts looks tiny and almost unreadable right now as they are based on 512x512 tiles.
While I agree that screens become bigger and bigger, their resolution remains small compared to a VR headset resolution. Current average desktop resolution is 1920x1080 and even if in the Simmers community we have big screens with resolutions up to 3840 x 2160 these numbers are still low compared to a panel with a resolution of 5521px / 6154px and I donât guess that websites which are the main sources of 3rd party addons panels are ready to be compliant with such high resolutions.
I definitely agree that the VR UI in MSFS needs to be reworked but what we are experiencing right now is clearly a problem as no 2D interface in 2023 should make itselft scalable to resolution twice higher than the maximum available 2D resolution.
Discovered the undocumented ability to resize the content of an app in VR a while back; this helps with fixed content such as map panels. Not ideal, but can also be used in some instances to get round this regression bug.
In the end I re-coded VSR, but the map libraries such as leaflet are still causing some minor issues.
Thanks so much for this!