FSDreamTeam forum
Developer's Backdoor => GSX Backdoor => Topic started by: freddie on January 13, 2022, 03:59:50 am
-
will GSX come to MSFS ?? as i think MSFS2020 need GSX ground services i love it in FSX and i miss it :-\
-
Of course it will, and we are working on it for quite some time, but we can't say right now when.
-
hi Umberto, did you got any update from Asobo about the menu implementation inside MSFS?
-
hi Umberto, did you got any update from Asobo about the menu implementation inside MSFS?
Yes, and it's not very good news, since they said they have no plans to restore that missing functionality from FSX, not at least the way it was in FSX/P3D, with a specific Simconnect call that made the menu appear programmatically.
That's unfortunate, but there are ways to overcome it, either using the new HTML/JS method like several other addons in the tool bar use or, in the worse case, using a custom menu that works by placing an extra window on top of the screen, which is also used by many other add-ons.
The first method is better, because it would work in VR and it's more integrated in the sim, but the biggest problem with it is that is completely undocumented so, every knowledge of it is based on looking at the source code of the default menus AND there have been several breaking changes between updates (it was undocumented, so Asobo didn't feel bound to any kind of backward compatibility), which resulted in many "toolbar addons" stop working, especially after SU5. It has been officially confirmed that documentation work on HTML/JS HAS now started, so we think this will be the route we'll use.
Another issue we still have with the SDK, is another missing feature from Simconnect that always worked since FSX and it's not working in MSFS, is the ability to temporarily block keyboard/mouse/joystick events from reaching the sim, which is required for all things in the GSX editor ( airplane or scenery customization editor or the Quick Pushback ). In previous versions of the SDK, it was documented to be working but, after our report about not really working, they said they don't like the fact an add-on could "steal" keypressess or joystick buttons from the sim, so they changed the documentation recently, removing the feature ( and managed to add a bug in the *documentation* itself too! ) and they wanted to introduced a completely new method to do the same thing in a more reliable way.
Lack of such feature is not affecting GSX only.
Take for example a feature available in some of the best airplane add-ons out there: the ability to momentarily "steal" the PC keyboard to use it as an input for the MCDU, so you can just type something instead of having to click on the buttons. This can't be done right now, because it would require to prevent the sim from getting the keyboard events for as long the "keyboard input" mode is active in the airplane. While reverting to mouse only and VC events might not be a huge loss for a typical MCDU, latest-gen airplanes like the A380 or the A350, which have a FULL SIZE real keyboard as one of their standard input methods, they could benefit a lot from this feature.
So, clearly, something should be done to allow this, and that's was the last we heard from Asobo, they would like to redesign the whole system, to allow add-ons to do that without risking having multiple add-ons stealing events at the same time, causing problems.
So, these are the two main issues we are still missing from the SDK, with the 2nd one being the worse, since Asobo hasn't provided with any kind of ETA for the "new way" to "steal keys", only a generic intention to fix the problem.
But it's not as if we could release GSX tomorrow, if those features would magically appear today. We think a proper GSX for MSFS should feature proper MSFS models with proper MSFS textures, new animations using all MSFS features and proper LOD optimization, and these will take some time, while we wait for the SDK to get where we need to.
-
My brain hurts trying to read all that, so I'm just going to say that I agree.
-
deleted.
-
That's my impression, hopefully I'm totally wrong.
Unfortunately, that's my impression too, they don't seem to be very interested to spend too much time on SDK, except maybe for some airplane-related issues, like WASM having performance problems and being too limited in functionality, which clearly is required to bring advanced aircraft add-ons to Xbox.
In general, it seems they have issues with developing things they "inherited" from FSX, like Simconnect. This seems to be confirmed by the mention they want to redesign the Mission system, which is also derived from FSX, and right now the Mission editor is in a basically unusable state, possibly because they tried to design a node-based UI system around the existing system.
This might be read in two different ways, positive or negative:
POSITIVE:
- They really want to refresh the engine with completely new methods and technologies entirely made by the new team, so they could be better supported, and possibly adding new APIs that might be both more modern and better performing than Simconnect, perhaps making letting it go of its ability to run over a network, which has a strong influence of its design, even when it's run on a single machine.
I wanted to believe this, but then I really don't understand why, after more than a year, they still haven't documented ANYTHING of the new Html/Javascript/Coherent method of creating Gauges and add-ons in general, which IS a completely new part of the sim, with nothing in common with FSX and developed entirely by Asobo. The result is, every add-on out there, is based on reverse-engineering of the default airplanes, and too many times this resulted in things being broken by an update, which is understandable, since we still don't have ANY official documentation of an entire (very important and new ), sub-system of the simulator.
NEGATIVE:
- They don't want add-ons doing things too advanced, because they fear this would confuse Xbox and in general Marketplace users, who usually ( I'm trying to not generalize, but this is mostly the case ) prefer an easier experience with simpler add-ons that have less potential for issues.
A worrying indication of this is the very limited usage case for stand-alone WASM modules.
While WASM gauges can do something, stand-alone WASM modules are extremely limited by the sandbox approach, which is really excessive. While I understand, and even agree with, the prohibition to write anything outside a specific folder that is local of the module itself, it's really overkill denying the ability to *read* outside your own package area. What damage can do an add-on accessing other add-ons in read-only mode ? While a WASM Gauge is reasonably expected to find everything it needs in the airplane own package, a Stand-Alone WASM module which, by definition, runs together with the sim, is not very useful if it can't read anything outside its own package.
This would prevent creating ANY kind of add-on that needs to read (for example), the airport database. Yes, of course, we managed to do that with GSX for MSFS anyway, because we have the Couatl executable, which runs external to the sim, so it can read all airports (except the encrypted ones), but it means these add-on will never by sold on the Marketplace, and will never work on Xbox. We would need to rewrite Couatl as a Wasm module but then, it won't be able to do much, with no access whatsoever outside its own package. We asked long ago for an official API to read the airport database without having to reverse-engineer the .BGL format and wouldn't require any file access to begin with, this is currently one of the most voted SDK proposal, but nobody knows IF and WHEN this new API will come, if ever. Not having this API, will make sceneries bought on the Marketplace to be second-class citizens, because their data can't be read by add-ons. Not just GSX, of course, Flight planners need to read the airport database, for example.
Right now, the ONLY usage case developers have been using stand-alone WASM modules, is to act as Simconnect servers to external .EXE Simconnect clients JUST to give back data which is not normally available through Simconnect, like L:, H: or B: vars and events. With the result that everybody ( and his dog too ), reinvented the same wheel over and over, so now we have several of WASM modules, ALL loaded at start, ALL taking away previous CPU time to the Main Thread, ALL doing the same thing, which could have been easily avoided IF there was a way to get those variable directly through Simconnect OR the stand-alone WASM weren't so limited, so they could be used to do more, instead of acting as dumb slaves to external .EXE which, being external, can do anything they want. Again, an API to get access to these new variables is also one of the top voted SDK request, but nobody has any idea IF and WHEN this API will come, if ever.
So yes, my impression was more negative than positive, we can only hope they'll come up with something new/better/safer to replace the old stuff which, even if it's "old", allowed very complex add-ons.
-
Sounds not very encouraging :(.
Maybe a solution could be creating an MSFS "professional" for users with advanced claims and more possibilities for developers, maybe without being able using Xbox. They can stay at the "standard" MSFS. Of course this would be not for free but I'm sure may simmers would pay for such a model.
-
And this is the basket into which all of your eggs are placed?
-
And this is the basket into which all of your eggs are placed?
You couldn't possibly expect we'd disclose *everything* we are working on, or how it will work, or when. Obviously, every announcement is made when we are prepared to do it.
Also, your comment doesn't make much sense, considering we JUST released a MAJOR update to GSX for P3D so no, we don't put "all our eggs in the same basket". People are still buying GSX for P3D right now, more than we expected so, as long they'll continue to buy it, we'll continue to support it.
Do you think it would be a wise choice trying to RUSH a GSX release for MSFS with some half-baked hacks, rather than wait to see if we could do it in a better way, possibly we new technologies that might be added to the sim ? Or are you suggesting we should invest in some technologies that might even disappear from the sim one day ?
It's not as if we are not doing anything, we are modeling, and modeling, and texturing, and re-modeling and animating, this is work that needs to be done in any case, regardless which underlying technology GSX will use, and it's the thing which takes most of the time.
-
Umberto,
…As "competition is the mother of invention". Do you believe now that X-Plane12 is seemingly starting to aggressively market their update, that this could light a proverbial "fire" under MSFS's seat? And, X-Plane12 might finally start to encourage Asobo to deal with these long overdue "shortcomings"?
I personally don't use X-Plane currently (for no particular reason other than I don't care to maintain multiple platforms at this time), but it still appears to have a very large user base.
It also seems, after reading some forums, that MSFS is really starting to aggravate and frustrate many flight simmers and developers. I'm afraid that this could start driving more, and more people away from MSFS. As you stated they don't seem to be very interested to spend too much time on SDK
As a very long time flight simmer, I too am trying to be patient. But in reality aircraft wise, FBW's Airbus is the only aircraft that is keeping me on MSFS right now.
Thank you for all of your hardwork. I love all of my FSDreamTeam products and hope your frustration comes to an end as well.
-
Umberto, I will be more specific...
Yes, you continue to support GSX/GSX2 and I appreciate it. If you want to charge for the updates, I'd gladly do so to support that work (honestly).
However, you refuse to update older sceneries (KCLT) in P3D, which is your choice and right, in favor of the new sim. However, for me, that is placing MOST of your eggs in the MSFS basket as regards to what appears to be the primary footprint of your business - scenery. This was my point.
-
However, you refuse to update older sceneries (KCLT) in P3D, which is your choice and right, in favor of the new sim. However, for me, that is placing MOST of your eggs in the MSFS basket as regards to what appears to be the primary footprint of your business - scenery. This was my point.
The point is, you cannot make a point, without knowing what we know which is, you know, actual sales figures of, let's say, GSX compared against sceneries.
So yes, continuing to support P3D with GSX for us is NOT "putting all our eggs in one basket", but rather the opposite, because GSX is a far bigger deal than any scenery can possibly be.
-
Well, I've been "away" for awhile, as FSX got first sidelined while working with MSFS2020, and then removed from my machine. But FSDT is sorely missed - I went and grabbed KEYW to keep FSDT in the loop. And then I wanted to check in and find out what was up with GSX.
Glad to hear you're working on it, and sad to learn that MS/Asobo isn't exactly cooperating. Like you, I feel they're letting X-Box issues get in the way. But I'm a patient guy, and I know you won't let us have it until you've got it done right.
-
A look at the number of objects GSX scans in an update check, one will realize the sheer number. If all of that has to be done from scratch, doing it the right way is bound to take time. Add the new complexities brought by a new platform, one gets the idea or should get the idea.
-
Hello, every day I look at the forum to know about updates. But it makes me more anxious. Could you give some feedback on how we are progressing from GSX to MSFS? Now which part of the process are we? Do we have a minimum date forecast?
-
We released a preview not long ago:
https://youtu.be/OgjQ2-sixkg (https://youtu.be/OgjQ2-sixkg)
Which shows a very small part of the product ( Pushback ), but of course we are working on all the rest and, as explained so many times, it's a long process because we have A LOT of models to remake from scratch, because we don't want to recycle too much from the P3D version, since GSX will be the definitive ground service product for the next 10 years, so we need to do it right, so we don't have any release date to announce right now, but I can safely say it will be released in 2022, and likely earlier than many are assuming.
We are planning to release other videos in the future, as long as new services are completed. Note that, this doesn't mean in any way that as of today we only completed the Pushback, the GSX code is already fully running in MSFS with all its features, it's just we don't want to release videos/screenshot containing old objects from FSX/P3D.
We need to keep up for MSFS updates. For example, there are some new things that has been added in SU9, which will make the program working better, more efficiently and easily maintained and updated, so we want to take the chance to support them, which might result in a longer dev time ( because some things we did before need to be reworked ), but it will be worth having them in the long term. Users must understand the sim is constantly changing, and the SDK is still lacking, but IT IS improving, in many areas that have profound effects on GSX, most of them in a positive way, but we still don't have everything we would like to have, and some SDK/Simconnect bugs we reported that will affect GSX, are being scheduled to be fixed for SU10, so it's a constant process of waiting for bugs to be fixed, new features to be added and IN THE MEANTIME ( it's not as we "stop" waiting for Asobo to fix the bugs ) keep modeling/texturing and animating new things, redo old things, to achieve the level of quality users are expecting.
-
Being a unconditional user of GSX since 2015 on P3Dv2 until now on P3Dv4 (skipping v3) and slowly turning to FS2020 which, although still lacking many good airliners apart from the recently released PMDG 737 and Fenix A320, for Ggeneral and light aviation it is already a wonderful Simulator and although I like flying Airbuses and Boeing, I also love lighter aviation and VFR and for that it's already a good sim, so I'm slowly moving to this sim, keeping P3D as a backup for airliners, so now that I'm moving to FS2020, here's a topic I will anxiously follow to see the development of GSX under MSFS 😁
Best regards and best of luck!
-
hi Umberto, did you got any update from Asobo about the menu implementation inside MSFS?
Take for example a feature available in some of the best airplane add-ons out there: the ability to momentarily "steal" the PC keyboard to use it as an input for the MCDU, so you can just type something instead of having to click on the buttons. This can't be done right now, because it would require to prevent the sim from getting the keyboard events for as long the "keyboard input" mode is active in the airplane. While reverting to mouse only and VC events might not be a huge loss for a typical MCDU, latest-gen airplanes like the A380 or the A350, which have a FULL SIZE real keyboard as one of their standard input methods, they could benefit a lot from this feature.
Is this still the case? Because in the FlyByWire A320neo, the EFB can "steal the keyboard" so it can be used for text input without triggering any sim-related actions.
-
Is this still the case? Because in the FlyByWire A320neo, the EFB can "steal the keyboard" so it can be used for text input without triggering any sim-related actions.
Yes, addons written in Javascript can steal the keyboard. In fact, even GSX for MSFS can do that, in the very small part of it which is written in Javascript, that is the menu. However, the menu is less 1% of what GSX does, because most of its code runs completely external to the sim, and relies on Simconnect to interact with it.
This has the obvious advantage that *nothing* we do in GSX could possibly slow down the sim. As long as we model 3d objects in a optimized way ( and lots of time went into this, since every single object uses multiple LOD levels ), the "code", as complex it might be, won't even slow down the sim, since it runs in its own thread, on another process, which will use spare cpu cycles from unused CPU cores, thanks to the OS thread handling, so we won't hammer on the main thread, like a complex full Javascript add-on running in-process would.
And, since you might not need GSX while in flight, with an external app, you might even decide to quit it altogether after takeoff, and restart it again when you arrive, we made some changes to the Couatl scripting engine, which now has a Tray icon where you can restart or exit the app without stopping the flight.
So, the advantage of using an external app that connects through Simconnect only are many and, in fact, what is currently one of the best products available in MSFS, that is the Fenix A320, runs in its own app, which allow it lots of flexibility.
And yes, another advantage is using an external app that works with Simconnect, is that we could keep most of our existing code still working, which would allow to continue to support P3D, without having to rewrite everything from scratch, just like Fenix could use the Prosim engine, which allowed to offer an extremely high-end product in a *reasonable* time.
What is still lacking in the sim, is the ability to steal keys from Simconnect: you can intercept keys, but the sim will always get the event as well. Basically, the key "masking" flag, which worked since FSX, it's not working in MSFS. We MOSTLY used workarounds this, but the issue is not solved entirely. However, it's now very minor, so we'll release the product anyway, since the only effect is that you might have to disable some rarely used keys from the Drone Camera ( Focus blur, for example ), because the various edit modes ( Quick edit Pushback, Parking and Airplane customization ) are the ones where we would need to steal keys.
But sure, it would be nice if we could prevent the sim from getting an event, momentarily, anyway.
When we reported what is an obvious Simconnect bug, since key masking was even documented in the SDK, they replied they don't like the idea of an add-on stealing the keys, not at least from Simconnect, which is puzzling, since they allow that in Javascript, and after my explanation why this could be useful, they seem to realize IT COULD be useful, they said they wanted to take some time to redesign the system, and offer some kind of new solution. We'll surely use it as soon it will came out.