Version: 1.2.11.0
Frequency: Consistently
Severity: Blocker
Context: new Gunsight gauge development
I’m developing an html/css/js gauge for an aircraft that needs a working gunsight. I’ve logically created my gauge on the basis of a panel.cfg containing the element “hud = 2, 0.0, 0.0, 30, 30” so that my gauge is transparent, and with a graphical view of infinity.
Everything works perfectly, except for one extremely annoying thing. The graphics of my gauge, although totally static in its JS script, move in the window according, it seems, to the acceleration forces exerted on the plane during a turn, a climb, a descent…, etc… These movements of the gauge graphics may be fine for a Hud, but in the case of a Gunsight…, it’s very annoying! Is there a solution so that all the elements of my gauge don’t move and remain totally fixed, except those for which I’ve coded some kind of transformation?
If this isn’t the case, without actually being a bug, it’s at the very least a real necessity to create a “static” HUD model to be able to model this kind of viewfinder…, or gunsight…
What’s important with this gunsight, as with the Hud, is to maintain the vision of infinity, with the graphic elements moving out of the window according to the position of the pilot’s view. But the graphics must not be allowed to move as a result of the forces exerted on the aircraft!
Thank you in advance for considering my request!
No…! But is it really necessary…? I did a test on a normal gauge, on a black background, with exactly the same code, and everything is absolutely static…, as it should be for a gunsight!
It is somewhat necessary, yes. It is possible that the gauge is acting correctly as a collimated gunsight set at infinity, but that you are interpreting the normal camera sprung head movements due to sim forces as a bug. However, it would be correct for the collimated gunsight to move as the sprung camera head also moves.
If you disable head movement in your sim options, does this issue persist?
Thanks,
Matt
If you read what I’ve written, which is that I’ve tested this same gauge with non-HUD support, but with exactly the same HTML file, the elements making up the gunsight don’t move at all, you’ll understand why I question the need for a video.
On the other hand, I’ve created a camera so that the pilot’s vision doesn’t move with the plane’s acceleration, and the HUD moves through it all. So there’s a little problem to be solved here!
Hello to the entire Asobo team, and especially to @FlyingRaccoon, from whom I’d like an answer. I have carried out a HUD test with Asobo’s FA-18 on MSFS 2024 (camera shake disable…), and I notice the same problem of movements of the HUD elements, as if the projector of the information projected on the glass was not correctly fixed to its support! It’s not normal at all…, even if it looks “pretty”… It’s not at all a reflection of the reality of a HUD, and even worse when it’s a gunsight like the one I’m creating.
Thanks in advance for your reply…!
Here’s a video of the FA-18’s HUD, with the pilot’s head completely fixe :
https://1drv.ms/u/c/10b83b71e4b1c9c8/EZyZ-cjChJdLuhRwT1yZX-wBRqwaaV4xp3S91UuxyxX_Yw?e=1PeeGU
Hello @Chris-SMS
I agree, the behavior demonstrated in your video is suspicious for a collimated HUD.
I will run some additional tests and log the issue if I can replicate the problem.
Regards,
Sylvain
2 Likes