Is there any way to detect from js at an early stage that we are in MSFS 2024 (or 2020)?
6 Likes
I had the same question but I was too shy to ask it
I think a variable that can tell us on which simulator we are on may be very useful. We could âswitch offâ functions that do not work in MSFS2024, or enable some that will only work on it.
It should be a function, not a variable because the variable system may not be initialized too early.
There is already GamePlateform() that returns âPCâ or âXBOXâ.
We could have something like GameVersion() that returns â2020â or â2024â.
2 Likes
For now, the only way I had to determine whether it was 2024 or 2020 was through some detailed file checking of both the 2020âs common.js and the 2024âs common.js, and look for any JS types (classes or functions) declared in the 2024âs common.js file, that are not available on the 2020âs. This is something I made for the EMB-110âs EFB which reports the MSFS version number. However, if the common.js changes from 2024 eventually get backported to 2020, this would cause the detection not to work correctly, hence causing⊠letâs say⊠an âidentity crisisâ on either platform.
So, +1 for the idea from @ScorpionFilm422 of having a dedicated JS function declared that can help determine whether itâs 2024 or 2020.
Regards,
Carlos Daniel GonzĂĄlez GĂłmez
NextGen Simulations
1 Like
We would also need to detect the MSFS SDK framework version (2020 or 2024) used to manage the flight plan in the cockpit.
1 Like
BUMP.
weâre learning there are a lot of coding detail changes in MSFS2024 vs MSFS2020 (particularly anything to do with nav) and itâs crucial to be able to tell which sim youâre dealing with.
There must be some coding fragment that will reveal which sim is which, preferably using numeric simvars as thatâs about the only thing supported in common between the various programming environments. I have issues in simconnect mods and also issues in html/js gauges (we glider pilots are heavily invested in nav support). The only method for simconnect weâre trying so far is to get the Windows Task List and search that for MSFS 2024. Crazy eh?
Anyone got any idea using in-sim simvars?
I experimented with the ânewâ simvar âAIRCRAFT AGLâ which is in the 2024 sdk docs but not 2020, and discovered that simvar does actually exist in 2020. otherwise AIRCRAFT AGL = 0 would be a winner,
2 Likes
We definitely need a Simvar for it
We are finding this to be essential to deal with the differences between 2020 and 2024.
A SimVar would be ideal, for example SimVersion=1 for 2024
2020 would return 0 because the simvar wouldnât exist.
Versions after 2024 could be incremented.
Hope this can be added to help with the migration and, appreciate all the work done so far.
1 Like
hey if a simvar can be designed from scratch, SIMVERSION = 1010700 gives us the whole â1.1.7.0â
2 Likes
still no official answer? due to large amount of differences between new and old sim, we have to apply exceptions anyhow. adding new simvar with static value is a 5 minutes deal.
best workaround I may think is try to enumerate some of the new variables. in FS2020 it returns 0, but such practice is dangerous as may cause unexpected result.
ENUM test = get_aircraft_var_enum("GENDER");
if (!test)
fprintf(stderr, "MSFS2020 DETECTED!\n");
else
fprintf(stderr, "MSFS2024 DETECTED!\n");
1 Like
Minimal example in C++/WASM:
bool gIsMSFS2024;
void CALLBACK MyDispatchProc(SIMCONNECT_RECV* pData, DWORD cbData, void* pContext)
{
switch (pData->dwID)
{
case SIMCONNECT_RECV_ID_OPEN:
{
SIMCONNECT_RECV_OPEN* pOpen = (SIMCONNECT_RECV_OPEN*)pData;
DWORD appVersionMajor = pOpen->dwApplicationVersionMajor;
gIsMSFS2024 = appVersionMajor == 12 ? true : false;
}
}
6 Likes
Neat answer. simconnect is very old but you have to credit those guys for focussing on the required simulation apiâs. I guess we could have a wasm gauge that writes that value to âL:SIMVERSIONâ and then XML and JS code could read that.
1 Like
Yes, thatâs what we do in GSX, to show the menu with a different color theme in case itâs running under MSFS 2024.
1 Like
A variable is ok but not enough.
We should have a JS function too because, in some cases, the variable system may not be initialized when we need to know the MSFS version. A typical example is for the toolbar panels.
Is there any official way to know if we are on MSFS2024 or MSFS2020 ?
Hi everyone,
- There isnât right now but can you clarify in which context you would like to know this? Would it be from WASM, JS, XML, RPN?
- For SimConnect applications the example provided earlier should suffice.
- Do you have any scenario in mind where you would like to know this at runtime?
- What would change in your flow with this information?
Best regards,
Eric / Asobo
Hello Eric (@EPellissier),
For WASM, I think the example provided by @Umberto67 should suffice, just like you said, and thanks a lot Umberto for your sample on the FS20/24 detection.
But, for those who work a lot with HTML/JS instruments (myself included), there is no direct way. The only way I could manage to be able to detect whether it is 2020 or 2024 was through differences found in the common.js file found on both sims. Just like I stated on my post above:
Again, the above helped me for my product, as long as the common.js file from both platforms remain intact/unmodified. If a specific, future-proof function could be added to determine whether it is 2020 or 2024 among the instruments framework, this would help a lot! (Even if this strictly requires using the TypeScript framework; not ideal because we also code basic instruments using vanilla JS but it can help at least).
Regards,
Carlos Daniel GonzĂĄlez GĂłmez
NextGen Simulations
@EPellissier
My two cents (Dino from IndiaFoxtEcho) - we would need this information on XML and JS.
The usage of this boils down to two points, IMHO:
- how long we (third party devs) will support MSFS2020 updates
- how different MSFS2020 and MSFS2024 will be in future (Iâd assume the difference will be bigger and bigger)
The idea is this: if we need to support BOTH MSFS2020 and MSFS2024, it would be far easier for us to manage a âsmartâ code which can adapt to both 2020 and 2024, using different features as needed.
Different features meaning:
- use workarounds for things that work in MSFS2020 but not in MSFS2024 (although the list will be smaller and smaller over time if backward compatibility issues keep on get ironed out)
- implement exclusive MSFS2024 features when it makes sense
Now, I would agree this would be useless if (when) all users will have moved to 2024, and third party devs will no longer support 2020 / update 2020 planesâŠ
2 Likes
My usage would be straightforwardly in html/js with similar rationale to @Scimmia1974 . Most of the complex JS code in my gliding nav panels remains common (e.g. computing speeds-to-fly, estimating arrival heights and cumulative task speeds) but 2024 does have significant changes with regard to the flightplan data. FWIW I think weâll have glider pilots in 2020 for as long as that sim stays alive although the community is very keen to get going on 2024.