Aircraft is Miltech Simulations MV-22.
Urgent matter - impacting many customers
After release of SU2, we have received reports of Xbox users (Series S primarily) that WASM Gauges are no longer rendering correctly (See attached image). This was perfectly functional prior to SU2. Looks as if the image sheet used to construct the gauge is being loaded, but positioning of each sprite is being ignored.
Important to mention, perhaps, is that we did get reports of this exact issue on PC before, which were generally related to resolution (eg. only occurred when simulator graphic settings were set to LOW), or happening with VR (when flight is started in VR mode - if started in PC mode and only then connect the VR headsets then it would work as expected). However, these are easily resolved on PC, but do not apply to Xbox and hence don’t have a good solution to provide to our Xbox customers.
Given our limited access to the Xbox platform, and that we have no idea what the root cause of the issue may be, I’m raising this to get assistance ASAP to provide a solution to paying customers.
Also important to note, the WASM file is the exact same used on PC, and nearly identical to the FS20 code, which has never presented any issues.
Can you please elaborate on this? As far as I can see the FS2024 native version of the aircraft has not been released yet to the public, hence the version that is currently available is the carried over FS2020 version - how can the WASM module be different from the FS2020 version?
Apologies - You’re absolutely correct.
We have a FS24 build that has been distributed through 3rd party stores, hence why I got confused for a moment.
But indeed this issue seems to be isolated to the Xbox ported version at this time, hence only affecting WASM that has been ported from FS20.
Can you please confirm if its a sim issue, or if there is something we can do on our side? Customers are waiting for an answer
I can confirm this is a sim issue which also affects the PC version when Texture Resolution is set to Low (probably similar to what happened during the Christmas period) - this is being investigated.
Would it be possible for you to send us the C++ code of one of the gauges used in the aircraft through Private Content?
From what I can see you load 6 PNG files when the module is initialized, and I guess you then create image patterns to draw the instruments. This requires you to provide coordinates which I suppose assume that the loaded image is 2048x2048 (the size of the PNGs). However in Textures “Low” mode we cap the number of pixels to 1024x1024, hence the texture is resized and the coordinates need adjusting - which we are supposed to do on our end.
What puzzles me is that your module seems to call “nvgImageSize” quite frequently so I am wondering if your drawing algorithm may mix static coordinates and dynamic sizes (which of course would not work too well).
We are still trying to find the right fix on our end but being able to look at your code would help us do this a bit faster.
We won’t need your code in the end - the issue has been identified & fixed.
However I’d like to point out that the bug existed and was visible in SU1 already - this is not an SU2 regression.
We will include the fix in a future SU3 beta - it is unclear at this stage if/when SU2 will be updated at some point.
