AirPanther

My apologies if this has been answered... I couldn't find the answer. My P3D has crashed to desktop a few times, and I'm wondering; can sending lots of data to P3D via FSUIPC, while the scenario is loading cause it t crash? I'm repeatedly sending a control inhibit, and not sure if that is the culprit. In FS Interrogate, offset 0x3365 "In Menu or Dialog" turns to non-zero (usually 3) anytime the sim is loading or in a menu, so I'm wondering if checking for that offset to be 0 before writing data to P3D would lower the likelihood of a crash? Thanks, Robert

Are you referring to the APU EGT? If so, have you checked 0x648C (Length 4 [FLT32])? Have you checked the "Offset Mapping for PMDG 737" document from the PMDG SDK? Maybe PMDG is doing a more complex/accurate calculation and storing it in a custom area? Robert

Paul, Thank you very much for your response. That's what I ended up doing! Since my program was already sending network packets, I'm just sending the flags across the network whenever they change, and other copies of the software listen for the flags and update their local LVARs. So far, works really well. Thanks again Paul! Robert

Good morning, My app uses LVARs to read/write to Prepar3d, allowing gauges to read the LVARs and show failure flags. It works very well, except, in shared cockpit multiplayer as it appears local variables are truly only local. Any idea how to synchronize LVARs across multiple computers with shared cockpit? There are approximately 50 LVARs to keep in sync. Would I have to store each value in a seperate offset then have a client app to read it and process the LVARs on the individual computers? Seems like there's probably an easier way? Thanks, Robert

That's great, I will grab the update. Thanks much Paul! Robert

Wow...I FINALLY found the needle in the haystack... mainly while typing up my findings to you, Paul I finally figured out this was an issue caused by writing to FLOAT64 variables. In my app, in the length fields, I use length 9 to differentiate between Int64 and Float64 (both length 8). I do the same thing with length 5 for Float vs. Int32 (both length 4). When initializing the offset, I didn't realize I was passing the length 9 to your module, when instead, I should have been converting 9 to 8 and 5 to 4 before initializing the offset. This issue has always been there... but looks like I hadn't been using any FLOAT64 variables. So offset initialization didn't even occur in my mind as a possibility. I ironically, the reads work fine, especially since battery voltage is only 2 digits. Man... this is one of those bugs I need a strong beverage after............. I really appreciate your help Paul. Talking through it was a big help, and made me look at things from angles I hadn't considered. Thank you! Robert

Paul, I truly appreciate your help, but decided to roll back to an earlier build from before the problem happened. It's about 30 days old, but seems like it will be easier to re-stitch the changes, than trying to find the "needle in a haystack" issue that led to this. I changed something somewhere that caused this to break, as it's been working perfectly for quite some time, but can't figure out what the change was. I'm still curious, so I don't break it again, but for the moment, the blocker is averted. I'll keep you posed if the problem becomes revealed as I'm re-stitching the updates. You're super responsive; I truly appreciate it! Thanks, Robert

I went through the code and changed all offsets to not use a group, and made sure the Process() commands do not reference a group, and still getting the same error 😞

Hi Paul, FSUIPCConnection.DLLVersion returns 3.3.8.410 1) I am using a named offset group called "CustomGroup" 2) No multi-threading Robert

Thanks Paul, here's what I get: System.IndexOutOfRangeException: Index was outside the bounds of the array. at FSUIPC.FSUIPCConnection.Process(Byte ClassInstance, IEnumerable`1 GroupNames) in C:\Dev\FsuipcClient\fsuipcClient\fsuipcClient\fsuipcConnection.cs:line 707

Thank you; .NET Framework is 4.8. Just wondering... does it have anything to do with target platform, or anything similar? I'm targeting x64, but have also tried x86 and Any CPU, with similar results. Also, since upgrading, I'm now getting a second error from Process(): Exception thrown: 'System.IndexOutOfRangeException' in fsuipcClient.dll Exception thrown: 'System.Exception' in fsuipcClient.dll Robert

Good morning Paul, I'm on 3.3.8 now; Downloaded from NuGet successfully. I'm not seeing the fsuipcClient.pdb. Where should I look?

Ok, I will start with an update and report back. Thanks, Paul

Paul, DLL Version is 3.1.9.311. fsuipcClient.pdb isn't in the folder, and I can't find it on my system. Also tried downloading from your site (application templates), but can't seem to find it. Where can I find it? Thanks, Robert

Hi Paul, BLUF: Any idea what would cause Process() to generate IndexOutOfRangeException? Whenever I call Process(), I get the following error. The code (reads and writes) has been working perfectly for months, then this error started a few days ago, and I can't figure out what changed to cause this. I still get a successful fsuipc connection, but the reads/writes no longer sync properly to P3D (Presumably because of the error below). Exception thrown: 'System.IndexOutOfRangeException' in FSUIPCClient.dll System.IndexOutOfRangeException: Index was outside the bounds of the array. at FSUIPC.FSUIPCConnection.Process(Byte ClassInstance, IEnumerable`1 GroupNames) at FsuipcSdk.Fsuipcx.Process() in C:\Users\airpa\fsuipcx.cs:line 285 Line 285 is below: public bool Process () { if (FSUIPCConnection.IsOpen) FSUIPCConnection.Process(); // Line 285 return true; } Any thoughts are greatly appreciated, Robert

Big thanks, Paul; Looks like that solved the problem! The FSUIPC Console log still only shows changes, but the inhibit seems to be holding permanently. I did add the "inhibit" group since I have a bunch of variables (more than a hundred) in the main group. So for efficiency, I have the inhibit by itself. I really appreciate your help! Robert

Good day, I am inhibiting the throttles using 0x310A. This works great, but I noticed that every 10-12 seconds the throttles will uninhibit for a fraction of a second, then re-inbhibit. This causes the throttle to jump, which is bad if, for instance, I set full throttle digitally, with the throttle handles at idle on takeoff... I never reach takeoff speed. I recognize that the 0x310A offset has to be resent at least every 10 seconds, and that appears to be the problem. I am retransmitting the value every second, but when I look at the FSUIPC console log, it appears that the offset only gets rewritten to 1 after it changes to 0 (hence the split second change). It is as if all my offsets will only resend if they change even though I call .process() each time. The code below is wrapped in a timer with a 1 second interval, but it only takes effect once the inhibit changes to '0' after 10 seconds, even though it is constantly being resent, so the Any thoughts? Thanks, Robert public Offset<BitArray> ControlInhibit = new Offset<BitArray>(0x310A, 1); ControlInhibit.Value[3] = true; Process();

Pete, thank you VERY much for posting 4.974b in the other similar thread... that fixed the PMDG 777 offsets and they are now working properly! And thanks Chakko for pointing me in the right direction.

Hi Chakko, Thank you very much for looking into this! Pete, or others, any idea why it would work in 4.974b and 4.975a? Many thanks, Robert

Hi Thomas, Thanks for the reply! Per the manual (Offset Mapping for PMDG 777X.pdf), I updated the file 777X_Options.ini (located in the FSX folder PMDG\PMDG 777X). All the standard FSUIPC offsets work perfectly, but none of the PMDG offsets work for me. Robert

Hi Pete, I'm having a similar issue. When I monitor any PMDG variable, I get only 0. I've tried accessing the data via the logging screen and FS-Interrogate, and can't seem to get data for any PMDG offsets. Any guidance is appreciate. My setup is: FSX SP2 FSUIPC 4.975a PMDG 777 v1.1 I added the ini value: [SDK]EnableDataBroadcast=1 Best regards, Robert

Thank you for your response Paul! It was running Process() in a separate timer at 15ms intervals, but I also added it as the very next line after writing the transponder code and it does the same thing. FsTransponderCode txHelper = new FsTransponderCode((int)value); FSUIPC_TransponderCode.Value = txHelper.ToBCD(); Process(); I am indeed referring to the local variable FSUIPC_TransponderCode.Value, and I've called Process() Robert

Good day, I'm experiencing an issue when writing to an offset from an event delegate. In this case 0x0354 (Transponder). The code below, from the SDK, works PERFECTLY when I call the function from a button, timer tick, etc. However, once I call the same SetTransponder() from an event delegate, the value in FSX only updates refreshes about 20% of the time. The other 80% of the time it doesn't update. What's even stranger is if I immediately read back the offset from FSUIPC, I always get the correct value, even though the value in FSX hasn't changed. I added a counter to the function to make sure the function was firing, and it accurately increments every time the function is called. private Offset<ushort> FSUIPC_TransponderCode = new Offset<ushort>(0x0354); int counter; UDPConnection.UDPDataReceived += new EventHandler(SetTransponder); // Start UDP listener SetTransponder () { FsTransponderCode txHelper = new FsTransponderCode((int)value); FSUIPC_TransponderCode.Value = txHelper.ToBCD(); counter++; } Output If I fire this function 15 times from the event handler, and send the results to the Output window I get: Output Window (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15); But in FSX, I will see Transponder Frequency (0001, 0004, 0005, 0010, 0013) However, If I fire this function from a timer or button I get: Output Window (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15); Transponder Frequency (0001,0002,0003,0004,0005,0006,0007,0008,0009........0015) The function is definitely firing, as I'm getting the correct counter output on each function call AND I'm getting the correct value back if I immediately query FSUIPC. So, any idea why FSX doesn't update consistently when the function is fired by an event? Thanks much, Robert

This is very helpful. Thanks very much! So the big difference from what I was doing is I still need to use do all the FSUIPC_Read(s) during every loop iteration, but I only need to call FSUIPC_Process, once. I can see where keeping track of the tokens can get messy quickly. I thought about doing a token array, then tracking the elements, but I may look into switching to Paul's .net code, which seems a lot cleaner. Thanks! Robert

Good day, I am successfully able to read as many offsets as I want, but I realize I'm not doing so correctly. If I need data from 30 offsets, I run the following code 30 times, which means I'm also doing 30 reads and 30 process calls on EVERY loop iteration. This is really slowing things down once I try to read 10 or more offsets. private void getData(int FSUIPC_Offset, int Offset_Length) { result = fsuipc.FSUIPC_Read(FSUIPC_Offset, Offset_Length, ref token, ref dwResult); result = fsuipc.FSUIPC_Process(ref dwResult); result = fsuipc.FSUIPC_Get(ref token, ref dwResult); } What's the best way to efficiently read a bunch of offsets at the same time? Are there any sample code snippets that show reading, then outputting multiple (maybe 5 or more) offsets? I realize Paul's .net example accesses many values at the same time, but what about from C, C# or others? If, for instance, I'm reading 30 offsets using a loop, do I have to have to do all the FSUIPC_Read on every loop iteration, or do I just do all the FSUIPC_Read one time, then run FSUIPC_Process once on every loop iteration? Thanks, Robert