33 minutes ago, MattNischan said:

and then delivers the already built waypoints back to the plane code.

And after that the plane code does "something" with it, doesn't it? At the very least, display the result? That is what I mean by "interpret". Imagine the data format changes or delivers an error = is not as expected any more. Are you willing to take that risk? Or would you rather want to check your code? Would Asobo simply trust that all their planes will just work, or will they plan for an in-depth test of every single one that makes use of the flight planner.

Of course, everybody can do as they please. From a point of view of risk management and effort estimates, IMHO this remains a complex work item that involves a lot more than is apparent.

Best regards

Edited October 26, 20205 yr by Lorby_SI

9 minutes ago, Lorby_SI said:

In this case, if Asobo changes the in-sim plan builder as Matt describes above, you can either trust in them that the result is what you expect - or you play it safe and make sure. And if something would be broken in the central module, all depending addons break at the same time. Ideally this happens through an undetected merge or build error in the release version.

If any 3rd party is using the built in plan builder, as they all are right now (only indirectly, as they're all using stock instruments), there's no change to be made, since waypoints are not managed anywhere else. As I said, the plan builder gives you the complete waypoints. Whether or not you trust the results is immaterial: you can't change them or affect them anyway. Additionally, since the plan builder is in sim code, not aircraft code, there would be no merge or build error.

The only time a 3rd party would have to take a look is if they were using the JS interface to the plan builder, FlightPlanManager, directly, and there were significant API changes to it. That doesn't strike me as particularly likely, though (we've seen no API changes at all to it since release).

4 minutes ago, Lorby_SI said:

From a point of view of risk management and effort estimates, IMHO this remains a complex work item that involves a lot more than is apparent.

Living in the code right now creating our own flight plan system, you are correct that it is complex, but not at all for the reason you describe. There's no reason to change the shape of the result, which is just an array of very complete waypoint data. At this point there's nothing that would need to be added or subtracted from those classes. If Asobo, right now, today, fixed all the bugs in their procedure interpretation logic in the plan builder, every plane that currently exists would be fixed without needing to change a single line of their code. And I know that because that is literally what I am doing as we speak.

-Matt

9 minutes ago, MattNischan said:

Additionally, since the plan builder is in sim code, not aircraft code, there would be no merge or build error.

I meant a build error in the sim. Like they had in the SDK, where suddenly the included SimConnect libraries were from two versions before. It is not like these things never happen.

Anyway, IMHO the deciding factor about risk is the consequences. If you have to pay someone to write your code, risk assessement is different than if you write everything yourself. We hobbyists are just wasting our own time, but if you are the project manager responsible for keeping a budget in check, the perspective changes. And, also IMHO, the more customers you have (or the larger the sum is that they pay) the more you should be interested in playing things safe.

Best regards

Oliver-

MORE THAN ANYTHING ELSE, I hope you can write an elegant Community Folder program that searches for updates, and then loads and unloads with a single click.  The latter exists, the former does not and the manual process is cumbersome enough to warrant expenditure.

Hope you're well!

C

6 hours ago, Andreas Stangenes said:

without everything going haywire

Well...let's not stretch too much. They usually don't go haywire, but there are plenty of bugs. Getting there though...

 

6 hours ago, Andreas Stangenes said:

Finally, the only thing left for me to say is that I *really DO hope that Asobo reads this thread and fixes the issues so that we dont need to have every plane modded to follow procedures. 

Yea, some attention in this area would be a benefit, but I also really hope they complete the engine, flight dynamics and WASM aspects of the SDK because those are blocking items for complex aircraft right now, and for us specifically, the ability to build a proper FADEC for TO and CL power.

So I just tried the CJ4. Granted I am not familiar with this aircraft, but an FMC is an FMC is a CDU 🙂

So I planned a route that I am very familiar with between ENCN and ENGM. The route goes VAVET RIPAM and then the RIPA4M arrival for 19R via the Bavad transition. 

And this mod does not change anything with the problem with transitions just ruining the STAR.

This is how it SHOULD look:

And this is how it ends up in the FMC after programming both the STAR and the approach into the FMC:

It cuts the route short for some reason or anyother. This is the standard arrival route for Oslo airport, and it is an RNP procedure. The route gets cut off by GM428, and there is a total of 4 waypoints that are just lost. The STAR is supposed to route out in a fan up north of the airport before turning in on the Bavad waypoint for the ils transition.  

 

Edit: I also tried to do a direct BAVAD which is a normal ATC instruction, and to my surprise I could actually select it in the direct to menu. However, it does not go direct to bavad - instead it goes direct to GM429 (which is a little miracle since gm429 wasnt even part of the route in the FMC since everything between gm428 and Bavad was eaten by the MSF bug). Trying to upload an image to Imgur, but the service is buggy at the moment. 

Edited October 26, 20205 yr by Andreas Stangenes

1 hour ago, cavaricooper said:

that searches for updates

I don't know - search where? In your shop account with your credentials? In third party shops?

IIRC that has been attempted before, with little success. What was the last one called, not too many years ago? Simstall? 

Best regards

Edited October 26, 20205 yr by Lorby_SI

25 minutes ago, Andreas Stangenes said:

The route gets cut off by GM428, and there is a total of 4 waypoints that are just lost.

I must say the cockpit looks great in that screenshot! 🤭

11 minutes ago, Lorby_SI said:

I don't know - search where? In your shop account with your credentials? In third party shops?

IIRC that has been attempted before, with little success. What was the last one called, not too many years ago? Simstall? 

Best regards

I'm specifically addressing freeware.  Most of the Payware developers have a methodology.  Is there even a need to load and unload scenery anymore? TBT I haven't noticed much difference in load timings atm.

C

@cwburnett Could you please explain to me why you said that your mod has fixed these things? The first flight I had and the MSF bugs are there in all their awful glory.  Did I misunderstand you? The bugs I demonstrated above are the ones I have been talking about this entire thread, and the bugs are there equally in the modded CJ4 as in the default MSF planes - or ANY other plane modded or not. 

Edited October 26, 20205 yr by Andreas Stangenes

3 hours ago, Lorby_SI said:

Thanks for the explanation. That means that if they change the central modules, they (and all 3rd party developers who rely on them) have to revisit -all- their products to make sure that they can still call them and still interpret the result correctly? Doesn't change the effort involed by that much IMHO.

Best regards 

I am going to disagree here... There is a systematic error in flightplan sequencing in MSFS, and I would expect this to be fixable and then be used correctly by all GPS units.

1 hour ago, Andreas Stangenes said:

@cwburnett Could you please explain to me why you said that your mod has fixed these things? The first flight I had and the MSF bugs are there in all their awful glory.  Did I misunderstand you? The bugs I demonstrated above are the ones I have been talking about this entire thread, and the bugs are there equally in the modded CJ4 as in the default MSF planes - or ANY other plane modded or not. 

Yea, happy to... so first of all, you found a bug that we hadn't found yet with some procedures that don't have runway transitions coded. So, we'll have to address that...it's no worry, we find tons of bugs every day, that's why it's a beta.

But, here's what I meant...the FMS code has been re-written to interpret all of the possible transitions on both sides of the common legs of an arrival or departure. It does work most of the time, but admittedly as I mentioned in my prior post, there are going to be bugs while we iron it out. I of course haven't hand tested every procedure, but when people find problems, they log them and we fix them.

Here's an example: Let's check out the PARCH3 arrival into KJFK (https://aeronav.faa.gov/d-tpp/2011/00610PARCH.PDF)

There are three enroute transitions available: ENE, PLYMM and SEY. In the CJ4 you can select any of these and the correct enroute transition waypoints get added into the flight plan:

I'll select PLYMM. So then we get this:

Now we have the arrival in and the enroute transition, but we have no runway selected, so the flight plan is incomplete. So, we head back and enter our runway - and this is where it gets tricky - if we select runways 22L/R we should get a runway transition that takes us from ROBER -> CRAIL -> CAPIT and then to the approach, whatever approach transition we selected. If we select runways 4L/R or either of the 31s or 13s, we should get a different runway transition that takes us ROBER -> JFK.

So, when we select runway 22L for example, then we take a look and see where the flight plan wants to take us...and sure enough, after selecting ILS22L, we get sent via ROBER -> CRAIL -> CAPIT

Now let's select runway 4R, still with PARCH3.PLYMM entered....and sure enough, we get properly routed ROBER -> JFK

We have tested dozens of different procedures and airports, but admittedly had not ever tested ENGM. It is interesting to me that when I load the RIPA4M, I get the entire procedure to BAVAD, but when I add the approach, it removes a handful of waypoints. I think this is due to one of two things.... (a) it's because there's logic in the sim that sometimes tries to skip waypoints that are out of the way or (b) that there's a matching problem that's occurring when there are no runway transitions at all, which is common in Europe.

If it's (a) it will be solved by the new flight plan manager. If it is (b) we can probably fix it up for this Friday's bugfix release. Anyhow, I've created an issue in our github for it and you can track it there if you care to. https://github.com/Working-Title-MSFS-Mods/fspackages/issues/423

Edited October 26, 20205 yr by cwburnett

@kaosfere , @cwburnett , @Bert Pieke , @Lorby_SI all in the same post- @Asobo better be paying attention!

🙂

C

1 minute ago, cavaricooper said:

@kaosfere , @cwburnett , @Bert Pieke , @Lorby_SI all in the same post- @Asobo better be paying attention!

🙂

C

Don't forget @MattNischan -- he is smarter than me and @cwburnett combined.   😄

12 minutes ago, Bert Pieke said:

I am going to disagree here... There is a systematic error in flightplan sequencing in MSFS, and I would expect this to be fixable and then be used correctly by all GPS units.

That is not my point. What I am trying to say is this: TMBK there is no written spec for this module - and it is still early days. If that is the case, then Asobo can do whatever they want to fix or change it. They can even decide to change the entire logic, the format of the procedure call and the structure of the result. Provided of course, that they will update all their GPS units too.

Personally, I try to avoid making assumptions about how "fixable" something is in somebody else's code and what the result of that fix might be. By habit I tend to look at the worst possible scenario - call me a pessimist.