I am the developer of “All in One,” and indeed, the addon does not appear with SU2.
By modifying the code, I have managed to make it visible again, although the challenge now is allowing it to be grabbed with touch controls in VR to reposition it.
We have no documentation on the changes Asobo has made, and we don’t know if this new behavior is a general issue or intentional, requiring us to update the source code of our addons.
Asobo, please, document the changes or at least give us hints about what has been modified so we don’t have to spend hours figuring out the updates.
From what I have observed, this same issue is affecting many in-game panels that work fine in the stable version of FS2020 and the latest SU1 of FS2024.
There is a significant change in the way in-game panels are displayed, causing the windows to appear transparent.
The windows are there, but they are not visible. You can verify this by moving the mouse over the areas where the window borders should be—the cursor changes to indicate resizing, and the window can be resized, but it remains invisible.
If I modify the source code to make it visible, the window appears on the screen, but I still can’t display the window header or move the window by dragging it. The only way to reposition it is by resizing and adjusting the borders, but not in the usual way by dragging the header—because the header no longer exists.
Asobo, any hints on what’s going on? Is this a permanent change, or is it an issue introduced in this version that will be reverted?
I ask because I need to decide whether to rewrite the program or wait for a fix on your end.
Would appreciate some comment on if this is something that was deliberate as a breaking change or just something being looked at to update/fix again. Either way is ok, just more if worth spending some time figuring it out in the short term or not.
After a lot of research, I finally realized the solution was right in front of me from the beginning.
Asobo has added the hide class to all <ingame-ui>, making them hidden by default. They have also removed the window title, even if you had it defined in the .spb file.
The solution is to remove that class from your <ingame-ui></ingame-ui>.
If you also want the panel to be draggable, you need to remove the panelInvisible class as well.
However, be careful! Don’t remove it unless the hide class is present, so the same code works in FS2020 without modifications.
Attached is the code I added to the JavaScript initialization of my ALL IN ONE panel:
<script>
setTimeout(() => {
const panel = document.getElementById("Your ingame-ui id in your html");
if (panel && panel.classList.contains("hide")) {
panel.classList.remove("hide");
panel.title="Your title for your panel";
if (panel && panel.classList.contains("panelInvisible")) {
panel.classList.remove("panelInvisible");
}
}
}, 1000);
</script>
They’ve also done something to the panel size constraints set in the XML/SPB, as these appear to no longer work.
Also gone is the ability to close it or pop it out to another screen via top right panel buttons.
@FlyingRaccoon Could you please document exactly what you’ve done here?
Toolbar addons are an extremely useful and highly used area of the sim, and knowing what is going on with it development wise is important. Thanks!
Related Issue: Also, where are the 2024 UI scaling controls? Theses are badly needed back in the sim, for both flatscreen and VR UX. I made some adjustments in my last release of LM2 to implement some scaling, but it’s far from ideal and the solution should be at sim level via the accessibility scale UI controls, which is MIA. This was an essential UI setting in 2020, and is sorely missed in 2024.
If they’re not going to be reimplemented could you please let us know, as it means (in my case at least) I need to develop my own scaling functionality, which is doable but semi-complex. Knowing if it’s coming or not has an impact on development planning.
If it is coming sometime, do you have a possible timeline? Thanks!
Same problem on my panel. The gaps between the elements have completely broken it since it changes when I enlarge the window, which was not the case before.
Thanks for that, and it does help, and if your toolbar is just showing a simple iframe and using external html to render then it’ll fix it up.
Unfortunately if you use any other MSFS html toolbar panel elements (Scroller, Tab, Panel, pretty much all of them) then they (a) don’t scale/resize anymore and (b) come with random ‘hide’ class additions.
At this point it might be easier just to cut losses on using a MSFS 2020 style toolbar in MSFS 2024 and just rewrite to the EFB components and docs. The ideal would be that someone from Asobo would now come back in SU2 beta and say ‘Yes, that is the way to go’ or ‘Works as designed in SU2, move on’.
The compatibility and sheer surface area of all the CoherentGT MSFS HTML use in toolbars might just mean it no longer works in MSFS 2024, and the trick now seems to be just guessing if this SU2B change was deliberate or accidental and will be rolled back. Assuming silence on this we’re going to wait a bit longer till the next update, but probably just bite the bullet and rewrite for the EFB anyway (once it works in VR of course, as for us the toolbar is really only for VR users).
No, All in One requires all the Coherent libraries and elements to work. It’s not a simple iframe.
What I’ve done is a function that checks all the DOM elements and removes the classes I don’t need. This way, I break the inheritance that Asobo introduced. As I mentioned in a previous post, we don’t know if this is intentional or not. The fact is that now, as a workaround, it works.
From here, I ask ASOBO to say if this change is a bug or intended behavior.
Yes, I noticed this one too. Add another one to the list.
I had this thought originally, but it’s actually not practical. Also, toolbar is definately not “for us the toolbar is really only for VR users” for most toolbar addons, and rewriting to squeeze a useful toolbar widget into the EFB isn’t viable.
While the EFB is a great addition, it’s also got it’s own pros/cons/issues that make the toolbar widget a better approach for some use cases. There’s also UX issues, in the cases where you wish to display multiple toolbar addons at the same time - which is quite a common occurrencee.
The toolbar widget approach is a great complementary system.
Being able to pop them out to another screen was also highly useful, as is the ability to “roll it up”. Making the header much shorter in height would be nice though as it’s too big without the aforementioned missing global UI scaling, not remove all the functionality in it!
We removed all the new hides with a DOM search, but the changes in scaling and the virtual scroller and Tab panel working differently still means we have no workaround. Ironically the in game ATC UI dialog is also broken in a similar way with scaling heights, meaning the resize doesn’t allow the bottom buttons to be accessed.
Because this topic is marked ‘Solved’, and Asobo might now have moved on, we’ll wait a bit and create a new topic, as we haven’t got a workaround currently.
It’s not strictly required to set the title in code, the problem (or “undocumented change” ? ) with SU2, is that the <title> element in the <head> of the html file is now ignored, but if you set the “title” attribute in the <ingame-ui> tag, it will work.
Of course all the various size issues are still there, no questions about it. My point was just about not having to explicitly set the title with code.
I actually like being able to set it by code tbh.
While you don’t technically need a title you can use in various ways, such as adding a version number so users know where they’re at. Yes, there’s plenty of other places to put that info.
If you need to modify it it’s currently a pita because you need to go back and regen the toolbar template. I never do that, I just update the files in it directly, easy to regen the manifest with a simple tool.
So that part is a win for me!
Actually, now I think of it, you can probably use that title field now as a regular display field, so I can remove another row of info from the working display area and shift it there, so an even bigger win. Except the buttons are missing. sigh
I never said it’s not useful being able to change it in the code or you shouldn’t do that (your title might need to change dynamically), just that is not required, if you don’t need it.
My only point was understanding why it happened, and it was the “title” attribute of the panel class had an higher precedence over the <title> tag in the <head> section which, if you think about it, it’s not even wrong, but it’s surely a change from previous versions starting since 2020.
The fact that this one doesn’t have a tag of fixed, bug_logged or reviewing while most others have been updated since this was posted is sort of hinting so far it might just be by_design maybe? Time to review the EFB docs and hope that does get working in VR as a window during this flighting.
If they were removing the toolbar it would be gone completely.
It looks more like a wip toolbar panel refactoring gone wrong, considering they’ve nuked their own toolbar panels too.
Relying on the EFB as the only interface for flight mode apps would be a big step backward in UX as well, for reasons explained above and more. Not to mention the UX issues within the EFB itself. It’s a nice tool, and will get better as well, but right tool for the right job applies when enhancing the flight mode with extension apps.
I suspect it could be related to VR improvements wip, as there seem to be some in the beta, at least from my testing. Issues aside, it’s a better VR experience than before, so there’s some progress too.
I like the toolbars too, it was more that I think the new docs talk about the EFB more and what we use in the toolbar isn’t technically part of the SDK (I don’t think).
Anyway, if it helps a bug report using the template:
Version:1.4.9.0
Frequency:Consistent
Severity:High (toolbar fails to work without changes due to SU2b)
Bug description:
For our toolbar to work again in SU2 beta we had to do the following changes from the SU1 release:
The ingame-ui element in this beta gives var values set for --min-width and --open-min-height that break compatibility with SU1. We unset these on the panelReady event.
As noted above, the panel and children now get the hide classes added, meaning we just look for that on the ingame-ui initially as a ‘SU2 beta workaround mode’ flag and then go remove them recursively, with some exceptions of things we still want hidden.
The initial scaling of the viewport in SU2B panels is set to 1 and we have to force a resize to reset it, although that isn’t reliable. The html root doc calc vars of --viewportHeightRatio and --viewportWidthRatio are now initially set to 1, which is a new SU2 beta change. Previously these values would provide a scaling ratio e.g. 2.77 and 4.2 etc for higher resolutions.
The Close (X) and Pin icons on the default ingame-ui window title bar if clicked will cause a sim crash to desktop. Previously to SU2 beta they did work by default. The only way to hide/show the panel is through the Toolbar menu.
