Thanks Matt.
If this is the Official word, then its good to hear it spelt out so clearly and with ambiguity.
So, unlike FSX, P3D & XP, we are not lightly to see support for the Trainer Garmin GPS system, as developed by RXP … so no point in expecting them unless there is some major change of direction by MS/ASOBO.
Time to accept that an move on … (probably to XP.)
I don’t think it’s the SDK or the sandboxing that is preventing those addons from coming to FS2020. Those make things complicated, for sure, but I think it’s the autopilot interactivity that’s the blocker, if i remember correctly.
No, of course not. A lot of this feedback is making it back up. We (WT) were a prime example. We are way outside the usual third party viewpoint. We were brought on specifically to build out some parts of the SDK and make them modernized and add our viewpoint to the mix. And this plays into your second point. As I mentioned, my goal is to democratize a lot of this with better tooling and APIs, but it is going to be evolutionary over the next year or two as there’s a lot of work to be done. And the new AnswerHub, which will be more open, will also enable better MSFS team to developer communication. There is definitely an awareness that better back and forth is needed, but doing so via the forums has become drinking the firehose, so to speak.
Sandboxing is industry standard these days; allowing processes like games that have fairly low level access to load arbitrary untrusted code is just not a good idea. Just look at the drubbing Cyberpunk took for their code load vulnerability. Consumers expect that third parties can’t load things that are unsafe. I understand that from a practical perspective that hasn’t been a problem yet (although there are a couple of historical FSX examples, they aren’t the rule), but regardless it’s important in 2021.
I agree that having some sanctioned, safe, and high performance communication solution would be a good thing. We’ve been discussing that in the context of how to move data between the JS side and the WASM side, for example. There are already some solutions getting data in and out: on the JS side you can run an external process (it doesn’t even have to be local, could be anywhere on the LAN or WAN/cloud) and communicate to JS via websockets, for example. On the WASM side you can use SimConnect client events to transmit data. The SimConnect client events solution is a bit limited, of course, but those are some options presently if you need to move data to external processes.
We are actively working on making the sim autopilot and associated vars much easier to work with and write to for overriding scenarios. I don’t know when those features will land yet, but it is something we are definitely tackling.
-Matt | Working Title
Speaking as someone who is presently working on producing “study level” Garmin instruments, I think the idea here is to develop high quality instruments that don’t require communication with the real Garmin trainers. Forwarding data in and out of the Garmin trainer itself is enormously limiting, as an architecture:
If folks want to make really awesome GPS units without compromises, I would definitely recommend avoiding the external trainer approach. But that’s just my opinion, of course, folks are always totally free to disagree.
-Matt | Working Title
Whilst i would agree that the best possible solution is to have a fully featured, 1:1 Garmin clone built with native sim code, I don’t think that’s enough reason to limit the access other developers have to the sim. After all, who can compete with you right now when it comes to marketing a G1000? You have privileged access to not only the sim internals, but you can change the course of the SDK. With great power comes great responsibility 
Further more, just because some other addon built using some other methodology might have shortcomings, is that reason enough to block it? The WT G1000 currently has all sorts of shortcomings, including a hard to update database, and that it doesn’t completely sync with the sim nav data, and there are a number of bugs due to the limited implementation, and a lot of people report a significant performance impact when using a glass cockpit as opposed to steam dials. But no one said you should give up on it. We all encouraged you to keep working on it to make it better and to weed out those issues. And that is also why we all are happy that you joined Asobo, in order to produce a better G1000. But now you’re using those shortcomings to cast other developers in a negative light. That’s hardly fair. Why not think about the situation you were in before joining Asobo? With an incomplete simulation, with a wall set in front of you, blocking you from fixing some issues. Shouldn’t other developers be given at least a tenth the opportunity you got? I don’t see how this would not be beneficial for all parties involved. Because, after all, I don’t believe that this is some petty attempt at monopolizing the Garmin implementation market. I think we’re all better than that, i hope.
Again, this isn’t necessarily about you fully embracing @CptLucky8 and declaring him your beloved leader. No. This is about him being given a chance to make his argument in an official setting, with the Asobo devs, rather than on this forum with the rest of us average mortals.
Either way, i said my piece, and i won’t continue with this further, unless you have any questions for me personally. I just hope that in the same way you guys were given a massive opportunity, a very good decision made by Asobo that I appreciate, maybe more developers can be brought to the table to at least offer their opinion, especially when they have proven themselves as knowledgeable as @CptLucky8.
I think this is hardly warranted. To be super fair, our position was always that the sim was already capable of doing most of what you needed to make study level instruments, and we were able to work extremely well to show that was the case with the CJ4. Our opportunity was created because we wholly embraced the new way of working, which does, unfortunately, include a sandboxed environment. I agree with you that our G1000 is not finished (although it does use the native flight plan and AP, so it actually does sync up with the sim nav data and has no database of its own), but we’re also going to be using our learnings while building the next big version as takeaways for how to make a framework that leads people into the “pit of success” as I call it, where it is clear how to get great performance and work quickly.
I’m a huge fan of Jean-Luc, I’ve owned a number of RXP products over the years, it’s all really really great stuff! Me pointing out those architectural limitations isn’t an attempt to downplay the high quality that he has produced. Just pointing out that there are indeed other avenues for creating 1:1 recreations of those instruments that don’t involve those same architectural limitations, which may be worth considering and pursuing. Yes, the accuracy of the awesome RXP trainer based products is amazing, as are the technical achievements, but just because that specific way of working is not possible doesn’t mean that the same fidelity is not achievable via other means. And we’re happy to speak directly to Jean-Luc about his use cases so he can get his goals reached in ways that don’t require direct hardware or native code access.
My job with the MSFS team is absolutely to open the most doors possible for making development modern, easy, and streamlined with the fewest pitfalls. But part of that modernization is definitely a team focus on security, and so sometimes there are just going to have to be other ways of solutioning. That’s not me purposefully putting up walls to box out “competitors”, that’s just a reality of modern game addon design that we all have to deal with, myself included.
As an aside, you don’t have to speak with me long to hear me rue the lack of information sharing and high level of boxing out that is the standard in the FS third party community. My goal is to slowly erase those knowledge gaps and even the playing field for everyone, so that everyone from the two decades old study level gurus to the first time devs have the same opportunity to make something great for simmers. Yes, there will sometimes be non-negotiable limitations, but the goal is to make it possible to still achieve super awesome things even given those, for everybody and everyone.
-Matt | Working Title
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.