The problem is that the market seems closed to any product coming from RXP.
I think its pretty safe to say this is exactly the case.
So true. Its ridiculous really.
PMS50 already has an incredible GTN mod. It would be a waste of time for MS to fund another one.
Besides, the RXP GTN is something completely different. It runs the real GTN trainer outside of the sim. That’s a completely different grade of product.
If MSFS can include controls with the G1000 pop-out, I will still be very happy with that capability.
I think Asobo - RealityXP collaboration is a vendor issue. RealityXP provides a software interface only using Garmin Trainer and Data. Then, RealityXP is used by other vendors for their hardware. Too many in chain. If one breaks everything breaks.
I think, If Microsoft/Asobo work directly with Garmin to integrate MSFS 2020 with Garmin trainer apps and that would be great. Yoke and Throttle quadrants already work with Trainer Apps. RealityXP and other vendors can then enhance upon it to provide additional capabilities.
That’s not true. Not only does RXP provide other things besides the GPS units, they have released a mod for FS2020, and can provide invaluable help to the developers. To view this as only about the Garmin GPS units is a very narrow view on the matter.
Not sure what you mean by that, but you can make that statement about both WT and PMS. So I don’t think that’s true.
So, in other words, you think that RXP going bankrupt is preferential to everyone working together?
I think there is some sort of miscommunication going on here… What exactly do you mean by “Trainer Apps”?
No any chance for that, the trainer do not work on Xbox which is the most important plateform for MS.
and i doubt they have the skill to do that in the same good way as RXP. They just lack 20 years of experiences
But it is true they prefer an integrate solution rather than by a 3rd party dev. Perhaps WT will do a GTN after the G1000, using FS api, so not a true 1:1 but something near that looks like. i can be enough for the majority of the MSFS audience. Which can explains why they are blocking GTN trainer base solutions like from RXP or recently the one from TDS.
But this thread is more than GTN/GNS, it is all about RXP can provide to the sim with their experience.
Ok. Looks like it is easy to get carried away. Let me explain.
I stopped short of getting RealSimGear hardware for MSFS2020 as it depends on RealityXP and which I know is not working with MSFS2020.
Definitely I don’t wish bankruptcy for any company but for a company to survive must have multiple plans and strategies. But looking at the big picture and from an end user perspective, the RealityXP products that I want to use GTN 750/650 are dependent on Garmin Trainer (GTN) app and also not working with MSFS2020.
What I see is that RealityXP may not be priority for Asobo or Microsoft. Either keep on waiting at mercy of Asobo or add additional fronts. GTN Trainer app is free and in demo mode I was able to play with it well.
If Garmin GTN trainer supports MSFS2020 (like Garmin Pilot), RealityXP can pick up area that may not be Garmin’s focus like sim experience enhancements, supporting end users, developers and hardware vendors (like RealSimGear) for great sim experience.
Also Garmin Pilot uses Flight Events to work with MSFS 2020. Not sure what information that community plugin provides and if it can be used by RealityXP. I am sure they may have thought about it but just thinking aloud.
BTW, I have already UP voted on this topic. But everytime I come and see that it is not moving forward. Sad state.
Really? It seems Matt and FlyingsCool have both laid out technical reasons why it’s difficult to integrate RXP as it stands, and it seems Jean Luc and MS/Asobo have opened up communications which was the intended ‘wish’ of this thread, so I’m curious to know what you think “STINKS” other than you haven’t got what you want yet.
Thanks for clearing that up.
This topic was created to achieve more than just bringing the RXP GPS units to FS2020. The main goal was for Microsobo to make use of @CptLucky8’s longstanding experience in developing for flight simulation (experience which he seems eager to freely give), all in order so they may create a better flight simulator than anything else on the market. Unfortunately, that doesn’t seem to have happened. All we know is that months ago there was some sort of meeting, and that was it.
Either way, we remain hopeful, but as they days and months go by with no progress on the matter, the situation looks ever more bleak. I really do have to wonder why would a company that is attempting to build off of FSX in order to produce a better simulator would not even want to hear from a developer that offers information freely, is highly experienced in simulator development, and at every step has shown nothing but support for this process…
I’m sure there were technical reasons why it was difficult to integrate PMDG’s DC-6 to FS2020, but that didn’t seem to stop Asobo from providing support for PMDG so they could bring their planes over. Why is the same not being done (as far as we know) with RXP? @CptLucky8 has also mentioned what he needs in order to port his products over, and the list seems to me, an ignorant, quite short and sensible.
Furthermore, I don’t see how any such technical difficulties are precluding RXP from getting a response to their market application? RXP already has an addon for FS2020. Maybe they would like to sell other addons on the marketplace.
So, I guess the question is: Why is everyone able to apply to the marketplace without getting questioned about their licensing with other external companies and why is everyone receiving support for their products… everyone except RXP?
I really don’t think forums are the proper way for 2 commercial entities to do business.
Absolutely, especially with well-meaning but excitable zealots goading from the sidelines and slinging partisan accusations of nefariousness against one of the parties
Were those technical difficulties anything approaching running external trainer programmes to interact with MSFS in ways that are not permitted to any other developer? Apples to oranges.
Are you privy to all communications between all developers and MS concerning marketplace applications? How do you know others are not being asked about their 3rd party licensing agreements? If you’re suggesting all other developers are receiving support for their products from MS/Asobo I think you’re intentionally ignoring a lot of developer angst about getting responses from them.
No one said they should do it in public, on the forum.
Yes, actually. Exactly that. Microsobotitle have been very clear that they will never allow DLLs to be run in FS2020 (even though, as far as I understand, they are actually running DLLs in FS2020). PMDG aircraft have always had all their logic coded inside DLLs. So seems to me that they found a way around that, why not with RXP, especially since @CptLucky8 has suggested alternatives that are already part of standard WASM, but not implemented in FS2020?
Looks to me like you’re looking at the end solution, assuming that this has always been the way things were, but that’s not so. PMDG are a clear example of Asobo finding an alternative for a process they forbid that PMDG relied on.
I don’t need to be privy to all communications between all developers and Microsoft concerning marketplace applications to know that a considerable portion of addons on the marketplace, if not all, are not officially licensed. Boeing, for example, doesn’t just give out licences. It took a lot of work for PMDG to get the official licencing they have, and keep it. Some very poor quality addons on the marketplace would never, ever receive this licensing.
I never said ALL other developers are receiving support. But as far as I know, those developers accepted to the marketplace do benefit from more support than those who have not been accepted.
DLLs are essential for any complex add-on containing custom code. When an aircraft developed in WASM is loaded for the first time, a private DLL will be compiled from the WASM source found in the installation package.
This compilation is performed by the simulator itself, and the DLL is then stored in /LocalState/packages under a folder with the same name as the add-on. This DLL is linked to the installed aircraft.
In the case of an aircraft written completely in WASM, like the Aerosoft CRJ, that initial DLL compilation will take several minutes on the very first load of the aircraft. It is a fully trusted DLL since it was compiled by the simulator itself.
What is not permitted is a stand-alone DLL created outside of the sim by something like Visual Studio and then installed into the aircraft folder.
I have something to say !
This is an important topic.
Took me a few afternoons but finally I just finished reading it in its entirety.
But first, just to state that my opinion in relation to the real deal thing is that it is possible to create a 1:1 replica of a GTN or a GNS device with the JS. I also believe it runs more efficiently and is far more flexible for the integration via various methods than any trainer based solution I’ve seen on the market (and I have seen all of them) - that some people glorify as the only single and holiest solution for the cockpit building and staying proficient in real life.
Now, there is this recurring narrative here that, at a certain point at the day 2 of reading whenever I stumble upon, it started somehow just rubbing me…not that well:
I’d like to say something about absolutely brilliant minds working on this project.
There are more than just a few.
They are seasoned engineers with deep knowledge of the latest ISO standards - devops professionals with INSANE sim development skills - experts with the decades long experience designing synthetic flight training devices for airlines - pilots, aerospace and flight engineers with incredibly precious experience on various aircraft with the amount of knowledge they share so passionately that they are completely mad - prospective team leads clouding GODS getting their visions into motion while taking care of the security, redundancy and code future-proofing, always supported by the sheer force of their teams the archangels, hermits and seers of the macro and micro code - engineering wizards behind the design and implementation of the simulator directory infrastructure and the continuous integration and development standards of the 2021 - all of them and all the way to my talented and oh so able colleagues scientists and engineers of BARE METAL - ancient high priests and priestesses of OLTs and GPONs, daylight dancers, Frigga’s cousins of information, fiber and light, masters of the arcane powers of DWDM, of the ancient wisdom of the network time and dark forbidden riddles of BGP, OSPF and EIGRP…together with gods of clouding and software development they remain among the last keepers of the keys for the atomic operations code access.
Some of the difficult issues in regards to certain features of that list have been explained somewhere up there.
@Bishop398
Concerning the C stuff the DLLs, a gentleman before me:
Pop out a display from MSFS and put it on an extra monitor … watch the FPS hit that takes place… Now do this 2 or 3 times… We sim pit builders want to make a cockpit…
Running the process and display (see the TDS product) outside of the sim and rendering in it’s own process… or better yet render on a separate PC than the sim… guess what… Way better and more efficient than JS in the Sim…
I support both sides of this… I want to see a very good implementation done in the sim for the masses that don’t care if it is 1:1 but is close… Even the G1000 NXi project has stated that there may be some things that they don’t implement… Like the flight Vector guides…
So if that is the case then I am sorry but for those of us that want to ALSO have a 1:1 solution based on the trainer that will make sure that we have access to the same equipment and software that run in our planes… yes we would like to have that too. This is not a one or the other it is a both…
XPlane does not seem to have an issue of trying to implement their own best example Avionics while also having these other applications… And they do support implementing a better system for cockpit and hardware interfaces in the SDK…
As for the base sim – ugh there are a lot of elements that need improvement… the Autopilot is still in need of work – Asobo a job posting for that … but have reposted it multiple times to I guess either because they hire and leave or more likely they have not been able to fill it and need to “refresh” the posting…
https://www.asobostudio.com/careers/autopilot-programmer-flight-sim-252
Point is there are lot’s of places that can use some work and we the customers were told “no simmer left behind” and further that 3rd party Devs were important…
WT is being paid by MS to build out avionics and API/SDK … Maybe open up a conversation about having RealityXP do something similar with a focus on the API/SDK and Autopilot improvement?? Then with in the bounds of of some of these things that MS says they won’t allow (DLLs from outside…etc)… RealityXP would have to consider making some changes to implement it if they still desired…
But I agree that none of this will continue in the public and we may never know the outcome… Until then I will keep my other sims and products close to hand…
I cannot stress how important this is. I have seen quite frequently people argue as if we can either have default, in-sim systems or external addons, and not both. When I have previously suggested that third party developers should be allowed to override the default flight model I have received quite a few responses from people saying that this shouldn’t be allowed cause it would lock out developers who cannot or will not develop their own flight models.
In the same manner, when the topic of trainer based GPS solutions is brought up, invariably someone will argue against it because they want the free GPS instead of paying for one, as if one invalidates the other.
This false dichotomy only splits the community up further, by making everyone believe that it is either their way or the highway. This leads to a very toxic environment. To all the people promoting this: STOP IT!
Yes. That’s the result of certain features introduced back in 2018. with the Redstone 4 build of Windows 10, changing the way the WDM functions, improving CPU thread and performance allocation, introducing fullscreen optimizations, etc.
Some of those elements are used by MSFS to support various accessibility features - like the ability of the sim not to lose focus, support quick alt-tabbing, enable the unobstructed use of overlays - and a few other things essential to certain groups of people.
That’s actually a hybrid of exclusive fullscreen + borderless modes…the idea is like to offer the best of the both worlds.
Due to way it works, any undocked element on a second display automatically halves the framerate and ensures the resources for the simulator are equally distributed, while maintaining support for all accessibility features and its native mode across the whole desktop.
We want that, yes correct that’s why we…
…usually do not rely on the native features of the platform we decide on using since they are almost always either limited in their capability, unable to accommodate for the specific use scenario we might face, or are completely non-existent - but instead with our decades long experience building all types of devices from BITDs and FNTPs to FDTs and Level-Ds, we possess the know-how as well as the engineering ability to build our custom solutions both for our home devices or the ones we build for professional clients.
Back in the day the knowledge was sparse and hard to acquire, but now all kinds of sources, various innovative study papers, software, utilities, tools and equipment on the subject are available to everyone and there are actually impressive devices being made by home cockpit builders.
We jump into the mess, design, draw, solder, bend and cable our ways trough:
In order to achieve the high performance low latency CPU and GPU interconnect, we utilize all sorts of ganging methods and arbitrary link aggregations, RDMA technologies, InfiniBand, etcetera:
And so we render whatever we need, however we want, with the highest performance and quality in order to build an awesome simulator - be it by bending and remapping areas of multiple displays:
Or by blended projection warping or image collimation:
Yes, that up there is MSFS. All of it.
The thing that’s certain is that the much higher performance and flexibility that the JS approach brings into the industry is a pure revolution, a huge step forward.
We are glad that the rest of the industry also sees this opportunity like the developers of Prepar3D who worked hard to recently deliver the v5.1 with the new SDK - increasingly converting the UI into the HTML and also finally offering clients the ability to implement the JS/HTML5 based gauges and panels.
The ease by which one can replicate every single instrument in real-time, anywhere on the network, in a completely OS and device agnostic manner via just a simple web socket server and a proper SimConnect interfacing - all the possibilities for introducing additional external services with a few lines of code - absolutely and I repeat absolutely beats the legacy approach with the separate applications and all the custom interfacing you defend as better and more efficient.
I honestly do not know about that.
As far as I recently heard, the flight path vector, also stuff like the so called “banana” and other features will be implemented fully, as the latest iteration of G5000 suite by WT and GTN750 (premium) by PMS already has done (try the G5000 with Cessna Longitude if you have time, send the feedback help the team, it is quite good).
Anyway, it is been said 1:1 - so 1:1 it shall be, have an absolute piece of mind about that and keep up the optimism, there is no reason not to.
Stuff works so good man it just totally rocks come on…
Cristi, nobody is being toxic man, at least not the folks who support and also have a good technical understanding of the reasons why.
I have made a remark towards the atomic read and write operations and property access - that earlier in this topic were mentioned by Matt as one of requirements for the solution that would represent the just way of your demand - yet that and few other things he was pointing out somehow slip as if unimportant and without anyone taking note. It was “reasonable things”. Not a big deal, why is Working Title the monopolist standing in the way…
It is 2021. and the simulator is part of an ecosystem that’s rewriting rules and setting new standards in technology that move the boundary of what is possible straight into SPACE - while we were standing on the hill.
Please understand that the things you desire and the hippy approach philosophy of “let’s give a chance to everyone, let’s open everything, let’s all be friends and work happily together and make the best simulator in the universe” - will not happen that way.
No, not because somebody doesn’t want happiness trough joint progress (quite contrary), or is evil, or wants a free GPS or doesn’t like Tom or Jill - but because there are new rules that even we who are seasoned professionals have to learn well and carefully stick to.
Otherwise everything fails.