IMPORTED AIRCRAFT - HTML5/JS Maps do not show airspaces, airport symbols and other symbols

[B21]

@CodenameJack447

Thank you for your understanding,

I think we’ve reached an impasse - every question we ask about “can we do this in JS” results in an answer “here’s the solution, use Typescript” as if we never mentioned JS.

I wish the answers were a bit more direct, like “Working Title have no intention of providing any JS map support in MSFS2024”.

I actually wasted time trying to see if the ‘recommended map’ could be embedded in a JS gauge (I tried to make that as clear as possible) but quite quickly it became obvious step 1 was actually going to be “install the TS toolchain”. Wow.

[MattNischan]

@B21

I think we’ve reached an impasse - every question we ask about “can we do this in JS” results in an answer “here’s the solution, use Typescript” as if we never mentioned JS.

I wish the answers were a bit more direct, like “Working Title have no intention of providing any JS map support in MSFS2024”.

The MSFS Avionics Framework is provided as plain JS ES modules. The reason we don’t say we have no intention of providing any JS map support is because it isn’t true.

@B21

I actually wasted time trying to see if the ‘recommended map’ could be embedded in a JS gauge (I tried to make that as clear as possible) but quite quickly it became obvious step 1 was actually going to be “install the TS toolchain”. Wow.

I get that heading into a new modern era is a scary prospect, truly I do, and I am enormously sympathetic, especially if one is not particularly experienced in the common webdev stack, as not all folks are.

Here is an example, in plain JS, no TS in sight. It took me approximately 25 minutes to set up, with the largest amount of time being the setup of the MSFS project itself. The project.json for this example has a whopping three dependencies, and is buildable easily using a single npm run build command.

GitHub - mattnischan/mapsample: MSFS 2024 Map Sample

Hopefully this clears up any continued misunderstandings.

Thanks,
Matt

[MattNischan]

Hello @Scimmia1974 @CodenameJack447,

This issue is now addressed in the latest SU1 release. FS9GPS simvars were returning the new 18 character ICAO facility identifier format, instead of the legacy 12 character format. This was breaking requests to the V1 (2020) JS facility APIs, thus causing the map to not load those facilities.

We have added code to the FS9GPS backend to convert to/from the new 18 character ICAO format to/from the original 12 character format, which both solves backwards compatibility issues with FS9GPS-based code and solves the issue with the map facility requests.

Special thanks to Nick at BlackSquare for providing some Coherent error logs that were not seen in these reports here; that started us down the path towards resolution.

-Matt

[CodenameJack447]

Good afternoon, I am very happy to hear that you have found the origin of the problem. In fact it makes perfect sense when the rest of the content was shown on the map.

I personally was taking a look at the WaypointLoader.js file within the path asobo-vcockpits-instruments\html_ui\Pages\VCockpit\Instruments\Shared\FlightElements. And although I saw that the class FacilityLoader is there, along with JS_LISTENER_FACILITY registered, I did not understand why considering that the class NearestAirspacesLoader works perfectly in both 2020 and 2024, and the same for class WaypointLoader showing the waypoints of the flight plan… in the case of class NDBLoader, class VORLoader, class IntersectionLoader and class AirportLoader, they only worked in 2020 and not in 2024. I was trying to change calls from FS9 directly to Coherent Calls, but to no avail.

In any case, much appreciated. It is possible that with this fix it will also be possible to load departure, arrival and approach procedures outside of the flightplanner in MSFS2024 (I currently have this implemented in one of my aircraft and it works in 2020 but not in 2024, and I think it may be precisely because that fix needing to be implemented).

If you like, I will confirm in the next few days that your fix works.

Thank you.

[CodenameJack447]

Confirmed:

[CodenameJack447]

However, what it means to activate departure, arrival and approach procedures outside of the flight planner would not be resolved. Let me explain, what you see in that screenshot is a flight plan, with procedures created directly from the flight planner, and sent by ATC (first option), which I receive on my screens and that I can view on the map. That is to say, I perfectly capture that flightplan with procedures included in 2024 just as I would in 2020.

What has changed:

I can create a flight plan from origin to destination (point A to point B) outside the flightplanner.

I can add ENR waypoints (i.e. any waypoint that has nothing to do with procedures).

I cannot load or modify procedures in 2024 as I can in 2020.

I understand that you are not going to support anything that is outside your avionics framework and that is fine with me.

But I would ask you, since the procedure call functions are defined in flightplanmanager.js
and that it is based on FS9, you will take a look at that file (not for its modification since I repeat I am not asking for support), simply to assess if those functions based on FS9 can be used to manage procedures or do I have to look for an alternative to activate these procedures.

Thanks in advance.

Edit:

In other words, I would like to know if, for example, these javascript functions found, for example, in FMCMainDisplay.js or analogues in Navsystems.js, can be used in 2024 for procedures in the same way as we do in 2020, or if I should resort to another different logic.

[MattNischan]

@CodenameJack447

I cannot load or modify procedures in 2024 as I can in 2020.

When you say you can’t modify procedures, do you mean that you’re expecting them to show in the EFB and your instrument and they only show in your instrument, or that they don’t get modified in either location?

It’s expected that a procedure change from FS9GPS wouldn’t make it all the way to the EFB, but I would still expect it to work in your own instrument.

-Matt

[CodenameJack447]

Matt, very simple, I have extracted from Flightplanmanager.js a series of functions that work in 2020 precisely to read, load and delete departure, arrival and approach procedures. This works in MSFS2020. But not in 2024. I can perfectly read the flight plan created in the flightplanner (when i say fligtplanner means the built in EFB APP for MSFS2024) once it is imported. I can activate legs, delete legs, etc. I can read the procedures, but I cannot modify them mid-flight in 2024. Yes in 2020. And I think it is linked to those functions that I tell you come from flightmanager.js.

@MattNischan

It’s expected that a procedure change from FS9GPS wouldn’t make it all the way to the EFB, but I would still expect it to work in your own instrument.

And no, I don’t expect my changes to be reflected in the EFB, because I understand that the EFB is an app in which you create a flightplan and send it to SIM or instruments, but not built to receive data or be altered by other instruments. In my case, I can create a flight plan without resorting to the EFB, what I cannot do is create my procedures as I do in 2020.

Example: i create a flight plan from airport A to Airport B: this works on both 2020 and 2024 but i show you 2020 screenshots:

Now i want to load a departure (AGID1A):

when pressing load i’m calling the loadDeparture() function:

and is displayed in my FPL page by DP(X) waypoints:

Well, that does not work in 2024, I am referring to the procedures, let’s say “set data” but the “get data” do work, I can see the list of procedures for each airport, etc., but I cannot activate them except through the EFB and import them.

[MattNischan]

@CodenameJack447

Well, that does not work in 2024, I am referring to the procedures, let’s say “set data”

OK, I thought you were setting them through FS9GPS simvars. The FlightPlanManager JS listener (and associated flightplanmanager.js) does not use FS9GPS for this at all, but just the V1 (2020) ATC flightplan JS APIs.

Our team was not involved in FlightPlanManager at all (that was before our time), so I can’t really hazard a guess as to why that wouldn’t be working in 2024 from here, but we can log this other issue for investigation.

-Matt

[CodenameJack447]

Well, I would appreciate it very much.

And no, I don’t call the FS9 variables from my projects at all,
but I usually use the functions of these files based on FS9 or coherent calls. just as I incorporate mapinstrument element (for displaying the maps), I also incorporate the asobo-vcockpits-instruments\html_ui\Pages\VCockpit\Instruments\Shared files related, which include flightplanmanager.js among others, because they allow the management of flight plans and procedures among other things.

In other words, for those of us who are not using your avionics framework in typescript, we use pure javascript similarly based on the structure of these projects:

Although these files are no longer supported and are no longer used by most stock aircraft since you replaced them with WT avionics, for us they are very easy to understand and even expand their modular structure, without having to throw it away and start a new project based on typescript.

While airliners are based on baseairliners.js, the rest, such as pelican, fa-18 (which currently in MSFS2024 has not been replaced) are based on Navsystem or Navsystem touch.

Therefore, I reiterate, I am not asking you to support or fix these files (since they work well in 2020 taking into account their purpose), but rather to guarantee that they can continue to work in MSFS2024 for those of us who use this development flow.

Thanks.

[MattNischan]

Hi @CodenameJack447,

Can you check the recently released update of SU1 (1.33.2.0)? We have included a fix in this build that solved this issue on stock aircraft that still use the legacy FlightPlanManager.js stack based on the feedback in this thread, so hopefully it will also work for your code.

Thanks!
-Matt

[CodenameJack447]

Hi @MattNischan,

I can confirm that it works but partially. I’ll try to explain it in case you have something else to check:

In the typhoon I have a shortened version of the TSC where I can actually activate the procedures and they work,

In the Rafale, at first, it doesn’t work, that is, I create the flight plan successfully, I try to load the procedure and it doesn’t load it,

But if I do redefine the origin of the Flightplan once created for second time:

Works:

That is, Rafale, and the TSC of the typhoon share exactly the same Navsystemtouch.js code to be able to create flight plans as well as load procedures.

• In MSFS2020, by creating a flight plan just once from one of the MFDs I can load the procedures without problem.

• In MSFS2024, it seems to require me to redefine the origin again, so I can load procedures without problem.

Therefore, taking into account that it works, but not as it should (That is, requiring that additional step that I mention, and that I do not have to do in 2020), I am trying to debug the code of my instrument in case there’s something additional to add.

This is information that I am giving you in case there is anything else that you want to review on your part.

Thanks.

Edit:
You can ignore everything I have put above regarding what happens with the Rafale as opposed to the Typhoon. I have found the problem and they are the functions that I use to add Waypoints.

TSC actually uses this funtion to set origins for example:

in flightplanmanager.js that function is defined as follows:

Instead, I used the following function based on FS9 variables:

defined as follows:

Problem found: while in MSFS2020 you can use this function to define origins and destinations, in MSFS2024 does not recognize the waypoint as an origin or a destination when you enter it this way ( this.addWaypoint(icao, index, callback); ), so you cannot load procedures after that. You have to use setOrigin() or setDestination().

In my case, I created a function that formats the input value to the correct value needed by setOrigin or setDestination:

In summary, defining origins and destinations through the functions that I was using in MSFS2020 do not work here. But I don’t mind at this point formatting the input ICAOs to work with setOrigin or setDestination. Once this process is done, the procedures work:

[MattNischan]

@CodenameJack447

while in MSFS2020 you can use this function to define origins and destinations, in MSFS2024 does not recognize the waypoint as an origin or a destination when you enter it this way

Hi @CodenameJack447,

I’ve been looking into this this week and last, comparing the code in 2020 and 2024, and I can’t really find an indication that setting the origin and dest via addWaypoint is an intentional or intended effect of using the API; all of the stock legacy avionics from 2020 ensure that they use setOrigin and setDestination.

I think I would favor leaving this as is for now, if you have an available workaround that works in both simulations, since it appears to me that the intended API usage is to use setOrigin and setDestination. We can try to replicate the old behavior if it’s really needed, but I think it carries the risk of additional bug introductions since it looks to be a bit tricky.

Interested in your thoughts here. If we tried to replicate the old behavior it would be for SU2 at the earliest.

Thanks,
Matt

[CodenameJack447]

Hi @MattNischan, I agree with you.

The reason for using addWaypointByIdent() instead is that within the function, the input value is formatted before being passed to AddWaypoint(), whereas SetOrigin() and SetDestination() require the ICAO to be pre-formatted before the CoherentCall. In NavSystemTouch.js, this formatting was done within the NavSystemTouch_FullKeyboard class before calling SetOrigin() or SetDestination(), but I didn’t realize it until I started tracing where the “icao” that both functions expected came from.

The important thing here was to understand the root of the problem, and if SetOrigin() and SetDestination() work in both 2020 and 2024, the logical thing is to use them.

As far as I’m concerned, the problem is solved.

Your help has been crucial in allowing us to continue developing our instruments based on the old APIs, so I am very grateful for the fixes and adaptations you have made.

Thank you.