hammertime Posted January 17 Report Posted January 17 With the addition of LIVERY NAME / LIVERY FOLDER in SDK 1.1.1, do we need to request a dedicated FSUIPC offset from yourselves to get this info via FSUIPC as an alternative to interfacing with SimConnect? Had a quick read of the Offsets PDF from 7.5.1 and didn't see anything of relevance on the topic Thanks in advance
John Dowson Posted January 17 Report Posted January 17 42 minutes ago, hammertime said: With the addition of LIVERY NAME / LIVERY FOLDER in SDK 1.1.1, do we need to request a dedicated FSUIPC offset from yourselves to get this info via FSUIPC as an alternative to interfacing with SimConnect? First, only a subset of simvars are added to FSUIPC offsets. And I do not add any new simvars to offsets unless by request and I think it a useful addition for everyone. Several years ago I added a new facility in FSUIPC to allow the user to add any simvar to a spare/free FSSSUIPC offset via a file called myOffsets.txt. Please see the Advanced User guide for details on using this feature. Note also that as FSUIPC7 is compatible with both MSDS202 and MSFS2024, it is build using the latest SDK for MSFS2020 and not the MSFS2024 SDK. However, it should still be possible to request simvars from the MSFS2024 SDK, but make sure this is only done when using MSFS2024 and not MSFS2022. John
hammertime Posted January 19 Author Report Posted January 19 Hi John, Thanks for the reply. The reason why Livery Name got added to the MSFS 2024 SDK was because Asobo changed the way that native liveries are packaged. The "title" simvar now only returns the name of the "parent" aircraft type irrespective of livery, with no insight into the specific livery being used. I'll surely check out the advanced user guide in terms of adding custom offsets, however I raised it here as I believe the addition of a new offset native to FSUIPC will be of interest to other users/developers that need this info out of the sim
John Dowson Posted January 19 Report Posted January 19 7 minutes ago, hammertime said: The "title" simvar now only returns the name of the "parent" aircraft type irrespective of livery, with no insight into the specific livery being used. That is interesting - I hadn't noticed that. That will at least make the profile matching easier/more reliable for most people! 8 minutes ago, hammertime said: I raised it here as I believe the addition of a new offset native to FSUIPC will be of interest to other users/developers that need this info out of the sim It is not possible to add MSFS2024-only simvars to FSUIPC offsets at the moment, as this would create issues when using MSFS2020. I could look into only requesting certain simvars in specific MSFS versions at some point if needed, but I don't think this one is useful enough for enough people to add this to a fixed offset at the moment.
hammertime Posted January 19 Author Report Posted January 19 1 hour ago, John Dowson said: That is interesting - I hadn't noticed that It's not obviously clear from the SDK what the new (2024-native) livery structure should look like... But essentially liveries are now a child of the parent aircraft in 2024 VFS Child liveries don't have their own aircraft.cfg (and therefore no TITLE= line). Instead, they now have a livery.cfg that defines the parent aircraft (and engine-type relationship), with a [General] section where you can give a livery a name [Version] major = 1 minor = 0 [General] name="<Livery Name here>" So in 2024 native aircraft/liveries, TITLE returns the name of the parent aircraft only, and the new LIVERY NAME simvar exposes the name in [General] from the livery.cfg FS2020 aircraft and liveries that are "compatible" with 2024 (but are literal copy/pastes into the MS2024 community folder), still exhibit 2020 behaviour when it comes to TITLE, so aren't "problematic". But as developers slowly adopt the new 2024 livery packaging format, this will become more and more problematic to those of us who need livery info exposed. Thanks for the clarification around which SDK you're compiling against, and appreciate that FSUIPC serves both sims simultaneously at present. I'd have thought though, that any application that has historically relied upon livery detection would be interested in this feature potentially. As a VA we certainly have a requirement from an ACARS perspective, but appreciate this is probably the first your hearing of it. If this thread starts the ball rolling for others to chip in, awesome. If not, we'll have to potentially consider an in-house solution as you previously advised. TITLE has been around for donkey's years, has always served its purpose, and its frustrating that Asobo have decided to suddenly change this in 2024. Going forward, I for one certainly consider the new simvar as "core" as TITLE has always been. Thank you for engaging with this thread, and I'd ask (if possible) to keep this in the back of your minds when it comes to your wider development roadmap. 1
John Dowson Posted January 20 Report Posted January 20 I have added the LIVERY NAME simvar to offset 0x2480 (128 bytes) in the attached version if you would like to try it. This offset will only b populated in MSFS2024 and not in MSFS2020. John FSUIPC7.exe 1
hammertime Posted January 21 Author Report Posted January 21 23 hours ago, John Dowson said: I have added the LIVERY NAME simvar to offset 0x2480 (128 bytes) in the attached version Many thanks John! I'll certainly test and let you know
John Dowson Posted January 25 Report Posted January 25 On 1/21/2025 at 7:15 PM, hammertime said: I'll certainly test and let you know @hammertime And?
hammertime Posted May 2 Author Report Posted May 2 Hi John, Apologies for not getting back to you. This is perfect, thank you
John Dowson Posted May 2 Report Posted May 2 2 hours ago, hammertime said: Apologies for not getting back to you. This is perfect, thank you No problem.
jordanal Posted May 4 Report Posted May 4 On 1/19/2025 at 8:03 AM, hammertime said: It's not obviously clear from the SDK what the new (2024-native) livery structure should look like... But essentially liveries are now a child of the parent aircraft in 2024 VFS Child liveries don't have their own aircraft.cfg (and therefore no TITLE= line). Instead, they now have a livery.cfg that defines the parent aircraft (and engine-type relationship), with a [General] section where you can give a livery a name [Version] major = 1 minor = 0 [General] name="<Livery Name here>" So in 2024 native aircraft/liveries, TITLE returns the name of the parent aircraft only, and the new LIVERY NAME simvar exposes the name in [General] from the livery.cfg FS2020 aircraft and liveries that are "compatible" with 2024 (but are literal copy/pastes into the MS2024 community folder), still exhibit 2020 behaviour when it comes to TITLE, so aren't "problematic". But as developers slowly adopt the new 2024 livery packaging format, this will become more and more problematic to those of us who need livery info exposed. Thanks for the clarification around which SDK you're compiling against, and appreciate that FSUIPC serves both sims simultaneously at present. I'd have thought though, that any application that has historically relied upon livery detection would be interested in this feature potentially. As a VA we certainly have a requirement from an ACARS perspective, but appreciate this is probably the first your hearing of it. If this thread starts the ball rolling for others to chip in, awesome. If not, we'll have to potentially consider an in-house solution as you previously advised. TITLE has been around for donkey's years, has always served its purpose, and its frustrating that Asobo have decided to suddenly change this in 2024. Going forward, I for one certainly consider the new simvar as "core" as TITLE has always been. Thank you for engaging with this thread, and I'd ask (if possible) to keep this in the back of your minds when it comes to your wider development roadmap. I "think" this may have become a problem with the brand new PMDG B772er native aircraft released this week for MSFS2024. My standard "Profile.PMDG 777" profile in the FSUIPC.ini file is no longer working. My FSUIPC PMDG profiles have always worked in MSFS2020/P3D/FSX without issue and continue to do so. According to PMDG, the standard aircraft.cfg native to their livery folders is no longer documented in the latest MSFS2024 SDK and they chose to negate the file and thus the aircraft title. How will the FSUIPC profile feature work now with fully compliant MSFS2024 aircraft? There is a new ongoing discussion regarding this in the PMDG forums, here: TITLE is the same for all RR, PW, and GE liveries - PMDG Simulations Thank you,
John Dowson Posted May 5 Report Posted May 5 (edited) 18 hours ago, jordanal said: I "think" this may have become a problem with the brand new PMDG B772er native aircraft released this week for MSFS2024. My standard "Profile.PMDG 777" profile in the FSUIPC.ini file is no longer working. My FSUIPC PMDG profiles have always worked in MSFS2020/P3D/FSX without issue and continue to do so. Why is this an issue? Surly the PMDG B772er has a title - and will contain 772 and not 777. Did you add the title of the aircraft to your profile? i.e. when the aircraft is loaded, go into one of the assignment panels and click the 'profile specific' checkbox and then select your PMDG profile. You should then look at the name/title added and shorten that to a substring. However, as the livery name is separate from the title, this may not now be necessary. 18 hours ago, jordanal said: According to PMDG, the standard aircraft.cfg native to their livery folders is no longer documented in the latest MSFS2024 SDK and they chose to negate the file and thus the aircraft title. FSUIPC does not read the aircraft.cfg file for the title, or livery name - it uses the simvars, which were populated from the aircraft.cfg file. If this information is no longer available in the aircraft.cfg file, it must be available somewhere and it will be MSFS that gets this information to make available in the simvars. Are you saying that there is no title now for this aircraft? Could you please show me / attach your FSUIPC7.log and FSUIPC7.ini files, generated after a flight using the PMDG in MSFS2024 and I will take a look. John P.S. Is the SDK (header file) for the PMDG B772er for MSFS2024 the same as the one for the PMDG 737 for MSFS2020? Do you use the specific PMDG offsets? Maybe you could attach the header file for me and I will take a look, Not needed Edited May 5 by John Dowson PS removed
John Dowson Posted May 5 Report Posted May 5 Ah, its the 777-200er...I do have this for MSFS2020. Saw this was now missing for OC2 and so have installed OC3, but I can't see how to install the 777 in MSFS2024.., I will try and get this installed and take a look...
John Dowson Posted May 5 Report Posted May 5 I currently only have the 777-300er, which is only compatible with MSFS2020 at the moment. I will see if I can get hold of the 777-200er. John
jordanal Posted May 5 Report Posted May 5 6 hours ago, John Dowson said: Ah, its the 777-200er...I do have this for MSFS2020. Saw this was now missing for OC2 and so have installed OC3, but I can't see how to install the 777 in MSFS2024.., I will try and get this installed and take a look... I think I've got this sorted now. The log shows all aircraft as "777-200er GE"/PW/RR. So, for MSFS2020 I have the PMDG B777 profile detecting "PMDG 777" and for MSFS2024, I have the profile looking for "777-200er". Seems to work... [Profile. PMDG 777] 1=PMDG 777 2=777-200er
John Dowson Posted May 5 Report Posted May 5 3 hours ago, jordanal said: I think I've got this sorted now. The log shows all aircraft as "777-200er GE"/PW/RR. So, for MSFS2020 I have the PMDG B777 profile detecting "PMDG 777" and for MSFS2024, I have the profile looking for "777-200er". Seems to work... Ok, that makes sense. However, this still presents a problem... As the title of the aircraft doesn't contain 'PMDG', the additional offsets available for PMDG aircraft (provided by the PMDG SDK) will not be populated/available. I will need to update FSUIPC to handle this. Do you also use MSFS2020? If so, is the title in MSFS2020 the same?
Luke Kolin Posted May 5 Report Posted May 5 John, when I do the aircraft detection I check the aircraft directory, not the title in the .cfg. Having both should be reliable. Cheers
jordanal Posted May 6 Report Posted May 6 14 hours ago, John Dowson said: ... Do you also use MSFS2020? If so, is the title in MSFS2020 the same? Yes, I still use both MSFS2020 & 2024. The 2020 777-200er name still begins with "PMDG 777".
John Dowson Posted May 6 Report Posted May 6 18 hours ago, Luke Kolin said: when I do the aircraft detection I check the aircraft directory, not the title in the .cfg. Having both should be reliable. Profile matching can either be done on Title (simvar) or the folder name of the aircraft directory (aircraft.cfg location), the latter by using/setting the UseAirLocForProfiles ini parameter, but not both. It doesn't make sense using both for profile matching, as the name (aircraft title or folder name) is automatically saved and will only match one. However, yes, I can check both to determine if the loaded aircraft is a PMDG aircraft to start the PMDG-specific threads to load/update the PMDG offset area - thats a good idea. 5 hours ago, jordanal said: I still use both MSFS2020 & 2024. The 2020 777-200er name still begins with "PMDG 777". Yes, sorry - I should have known that from what you have already said! Could you please try the attached version with MSFS2024 and show me the log file afterwards so I can check to see if the PMDG threads have been started? This version also checks for the string 'pmdg' in the aircraft folder name to determine if the PMDG threads should be started. John FSUIPC7.exe
jordanal Posted May 8 Report Posted May 8 On 5/6/2025 at 12:05 PM, John Dowson said: Profile matching can either be done on Title (simvar) or the folder name of the aircraft directory (aircraft.cfg location), the latter by using/setting the UseAirLocForProfiles ini parameter, but not both. It doesn't make sense using both for profile matching, as the name (aircraft title or folder name) is automatically saved and will only match one. However, yes, I can check both to determine if the loaded aircraft is a PMDG aircraft to start the PMDG-specific threads to load/update the PMDG offset area - thats a good idea. Yes, sorry - I should have known that from what you have already said! Could you please try the attached version with MSFS2024 and show me the log file afterwards so I can check to see if the PMDG threads have been started? This version also checks for the string 'pmdg' in the aircraft folder name to determine if the PMDG threads should be started. John FSUIPC7.exe 679 kB · 1 download Hi John, please find the requested log files (sanitized), along with my .ini file, attached. FSUIPC7 PMDG 777 MSFS2020.log FSUIPC7 PMDG 777 MSFS2024.log FSUIPC7.ini
John Dowson Posted May 8 Report Posted May 8 2 hours ago, jordanal said: please find the requested log files (sanitized), along with my .ini file, attached. Thanks - they look good with that version and show the PMDG-specific offsets have been enabled. However, both your log files do contain errors because you are trying to operate the aircraft far too early. With complex add-ons, such as the PMDG, you need to wait a while before everything is loaded and available. You were operating things around 10 seconds too early in MSFS2024, and around 30seconds too early in MSFS2020. Not an issue though - just incase you were wondering why your initial button presses had no effect. Apart from that, it looks good. Thanks for testing this for me. Regards, John 1
jordanal Posted May 8 Report Posted May 8 25 minutes ago, John Dowson said: Thanks - they look good with that version and show the PMDG-specific offsets have been enabled. However, both your log files do contain errors because you are trying to operate the aircraft far too early. With complex add-ons, such as the PMDG, you need to wait a while before everything is loaded and available. You were operating things around 10 seconds too early in MSFS2024, and around 30seconds too early in MSFS2020. Not an issue though - just incase you were wondering why your initial button presses had no effect. Apart from that, it looks good. Thanks for testing this for me. Regards, John Ah, good to know John, I was not aware there is a little delay. Glad I could help and thanks again for all you do. Regards, 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now