Jer029

Thanks John, I've noted your post on the FBW forum where this is being discussed. I've done all I can with this on my end and had written off FBW aircraft for our Econ module where the payload data is vital - or until I could try to change the code of our ACARS program to try to pick up the missing values outside of FSUIPC and PayloadServices. I'll watch that thread on FBW forum for any resolution. It would seem to me that the problem resides with the FBW team rather than FSUIPC because FSUIPC continues to work with other MSFS aircraft - and it did previously with the FBW A320 until a recent update. Hopefully they can make their modifications without losing the data posted to the standard offsets expected by other addons. Thanks again for looking into this with the FBW team. jr

This was the information from the a32NX guys. If they're using station indexes 1-8 for all payload, should not the FSUIPC/payloadservice continue to display this data. I'm not sure what they changed that caused the failure to read values. Shouldn't offset 0x13FC display the count of payload stations to obtain values from? That is because we have split the payload stations from Front/Rear Pax and Front/Rear Bag to a much more detailed loading model. There is also an update coming soon which will remove the Pilot and Co-pilot stations as these values should ideally be considered as a part of the operating empty weight. The simvars remain same, the indexes have changed, not sure about how that affects the offsets. For pax, the indexes are 1,2,3,4 👍1

Thanks John, perhaps I put it in the wrong forum, as I think it might be specific to Payloadservices by Paul Henty. All I know is that the payloadservices data is not readable with the a32NX project but still works with other MSFS/fs2020 aircraft - specifically PayloadWeightLbs. I suppose I can rewrite the code to no longer use PayloadServices, but it would be sad to have to workaround just the specific model. It would be nice if the model could preserve the data in locations used by FSUIPC/Payloadservices and still accomplish their more complex handling of payload. jr

I've been using FSUIPC and Paul Henty's Payload services for some time. Recently it appears that FBW is making changes to their payload handling. Here's the thread that discusses the changes they've made, and that appears to have rendered the current FSUIPC7 and PayloadServices to no longer be able to calculate the total payload weight. Ideally, it would be nice to still access the payload data from the A32nx aircraft. Fligt details sampling broken · Issue #5891 · flybywiresim/a32nx (github.com) Thanks, jr

Thanks Paul, I've been working on this all morning. I'm an idiot...it was working but at some point I ended up with my "assistance" settings for "Unlimited Fuel". This just keeps the fuel at the starting weight throughout the flight. All the payloadservices items I've been using with P3d and FSX appear to be functional for me in FS2020 with FSUIPC7 - at least until the next FS2020 patch comes out. John

John, Sorry my very late response to your question here, but probably moot at this point because things seem to be working now with the flight plan loading in MSFS. I was using offset 0x0130. I'm not even sure I had MSFS installed at the time but was describing my user's experiences. Now that I have it and use it almost exclusively, I've not had problem with flight plan loading. Thanks, John R

Paul, I've been using your payload services, for quite some time now with FSX and P3d - including FuelWeightLbs. Is PayloadServices still functional with FSUIPC 7 and particularly the A320Neo? Thanks, John

Some of my users have also noted an issue with the Flight Plan File location with FSUIPC 7 and MSFS. I only use it at startup to get flight plan file location from sim. It appears that the memory location where this data is contained is either randomly populated or randomly blocked for reading. I don't think my pilots are trying to get the flight plan from the simulator without the simulator being running, as that would never have worked with FSX/P3D etc. Perhaps the MSFS development folks could shed some light on what's happening. I can always work around this by providing a menu option to load flight plan directly from a file location I suppose.

Thanks John! That will work for my modest requirements John

Yes, it would be great if those memory addresses can again point to useful plane type and model names. My ACARS program currently displays TT:ATCCOM.ATC_NAME CESS , etc. If there is a change or something I must do to alter programmatically to display simple type and model names again I'd appreciate the information. Thanks, John

Thanks Pete!, I wasn't aware that FSUIPC logged the flight plan from sim connect. It appears then that FSX (sim connect) is the cause (and it's likely that Mahogany mountain (1JY2) is an airport naming error). Here is the log results of Mahogany Mountain and then a standard flight plan that doesn't end in a period: OG15-1JY2 (1JY2 as destination airport causes no extension) 144375 C:\Users\john\OneDrive\Documents\Flight Simulator X Files\VFR Sage Ranch to Mahogany Mtn. KMSP-KDLH (airport names not ending in period results in proper file extension '.PLN') 269109 C:\Users\john\OneDrive\Documents\Flight Simulator X Files\VFR Duluth Intl to Minneapolis-St Paul Intl.PLN My program is an ACARS program that gets flight plan location from offset 0130 and reads the flight plan and populates orig, dest, etc. based on the file information. I could work around it, but I might just leave it alone since it's just one airport (I think), and it may not even be issue in other sims like p3d that might have corrected this airport name. John

Peter, I've encountered an unusual problem with FSUIPC offset 0130 for flight plan path and file name. Things have been working fine until a user of my program encountered an error on FSX flight plan loading that included 1JY2 as the destination airport. This appears to be one of the few (perhaps only) airport where the name ends with a period - Abbr. for Mountain as "Mtn.". This creates an fsx- generated flight plan in the name of: "VFR Sage Ranch to Mahogany Mtn..PLN". Note that this file name has two consecutive periods (one for the end of the file name and the other separating the file extension). When I read the offset I get all nulls for the remaining 256 bytes after the first period (the second period and extension are ignored). I'm not sure if this is what FSX does, what FSUIPC does, or how the .net library handles it, as I'm using Paul Henty's .net for FSUIPC. The end result for me is that the flight plan file can't be found and produces an error. I guess I could work-around this by checking for the valid extension and adding it if missing. Not sure if I'm messing something up or if this just rarely appears ie. only with this airport and only when this airport is the destination airport. Removing the one of the periods to create a standard file_name.ext format allows the entire name and extension into memory at 0130 and the flight plan is found correctly. Any ideas? Thanks, John

Thanks Pete! That last quote was from a post from Mathijs himself on his AS CRJ 700/900 forum. Like many FSUIPC users, I have many addons that use this, and can work around the AS CRJ problem using EZdok Camera views to zoom in on the PFD, MFD, MCDU rather than clicking on them (which seems cause the random CTD for me). I was simply trying to figure out who might still be looking into this and which forum to watch for a solution. Based on the above quote from AS and related posts on their forum where they are encouraging the disabling of FSUIPC when using CRJ, I'm fairly certain that they have placed the issue squarely with FSUIPC and washed their hands of it so to speak. Welcome back, John

Thanks Thomas, I know how to disable files and where to find them. Below is a post from another CRJ user and Aerosoft's response. So am I to understand it's an "either - or" option on what we use? After writing an ACARS program that uses FSUIPC interface, am I to just tell my VA's pilots not to use FSUIPC or our ACARS program with Aerosoft CRJ and to manually file pireps? Perhaps I need to rewrite my code to use only simconnect and leave FSUIPC. Is this a dead issue for Lockheed Martin, Aerosoft and FSUIPC? John Posted yesterday at 02:22 PM I have not been able to complete one flight yet using the new version 1.0.1. The crash this time was attributed to menus.dll error. Over at LM forums they say it may have something to do with FSUIPC and to try disabling this utility. Seriously? They also mentioned that the next hot fix may alleviate this error. Anyone else experienced this? Thanks. Ilya Yes, Lockheed traced that issue back to FSUIPC. I can confirm that. I never had that issue after disabling FSUIPC. It's NOT related to the CRJ in any way. Mathijs Kok 22672 Aerosoft Forum Administrator

Pete, Sorry if this was asked elsewhere but couldn't find it. I've been using the P3d V4 Aerosoft CRJ 700/900. Clicking on the various PFD MFD screens can result in a sudden CTD without any error message or module listing in my windows error logs. Aerosoft claims that this is related to FSUIPC and not their aircraft. Can you enlighten me as to the status of this and where I should look for a solution? It sounds like Aerosoft is done dealing with it. On a likely unrelated note, I found and shared with Aerosoft continuous events occurring: When checking fsuipc logging I've noted that the following items continually log for CRJ700: 480483 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 5406 (0x0000151e) SPOILERS_SET 480545 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 5406 (0x0000151e) SPOILERS_SET 480592 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 5406 (0x0000151e) SPOILERS_SET 480670 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 5406 (0x0000151e) SPOILERS_SET 480701 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 5406 (0x0000151e) SPOILERS_SET . . . and 513695 *** EVENT: Cntrl= 65715 (0x000100b3), Param= 4608 (0x00001200) XPNDR_SET 513742 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 0 (0x00000000) AP_VS_VAR_SET_ENGLISH 513742 *** EVENT: Cntrl= 66705 (0x00010491), Param= 0 (0x00000000) APU_OFF_SWITCH 513742 *** EVENT: Cntrl= 65715 (0x000100b3), Param= 4608 (0x00001200) XPNDR_SET 513773 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 0 (0x00000000) AP_VS_VAR_SET_ENGLISH 513773 *** EVENT: Cntrl= 66705 (0x00010491), Param= 0 (0x00000000) APU_OFF_SWITCH 513773 *** EVENT: Cntrl= 65715 (0x000100b3), Param= 4608 (0x00001200) XPNDR_SET 513851 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 0 (0x00000000) AP_VS_VAR_SET_ENGLISH They told me it's supposed to do that and just don't log them as the logging uses more processing than the events - then promptly closed my topic to further discussion. Of course I knew that, but question the reasoning for continuous events occurring without me pressing any keys, and was a bit put off by their terse response and this CTD issue. These things make me wonder if the AS CRJ 700/900 is worth keeping in my hangar. Does the latest FSUIPC release address the CTD issue with the AS CRJ 700/900 ? Thanks, John