WarpD

Pete, What the individual was told was that the crash was not happening in our software. It isn't. They were told that it only happens if FSUIPC is loaded, this is true. I recommended they discuss it with you and Lockheed-Martin as it was a safer bet that either of you would have a better idea as to why FSUIPC being loaded would cause a crash when a flight plan is injected into the sim. They apparently don't like being told "we can't fix it" and there's not much I can do about that. As for notifying them on the issue: we did not have any information from Lockheed-Martin until after this entire thread was completed. Ed Wilson Senior Developer Mindstar Aviation

I feel I need to clarify some conclusions drawn in this thread. The problem is not caused by the Mindstar GNS units. Lockheed-Martin has confirmed the cause of the crash and it involves the process of getting the sim to use the entered flight plan. It only shows with FSUIPC enabled, which I believe that FSUIPC indeed peruses the flight plan information from the sim does it not? Lockheed-Martin will be fixing Prepar3D in a future release to prevent this from happening. For the record, Mindstar's products do not use any hooks or other methods that step outside the bounds of the officially released SDKs for Microsoft and Lockheed-Martin's products. As such, our GNS units don't touch API.DLL all of our code works through the panel interface and/or SimConnect and nothing else. We take this approach with the intent of reducing the chance of our products interfering with normal sim behavior. Ed Wilson Senior Developer Mindstar Aviation

Yep... thanks for your assistance and patience. Next time I assign the axi (is that even a word? LOL) I'll remember to unassign them in the sim itself.

Wow... ok... lots of information... First, I went into the Windows calibration routine and checked the raw values... 0 to 1023. A better range than I had actually expected as like you said a lot of axis values are limited to 512. After that I went into the sim and started going through things top to bottom. First, sensitivity on the throttles wasn't at 100%. That is where the 7040 came from, oddly enough. Once I adjusted to full sensitivity the scale was -16193 to 16192. However I still had values showing up that bounced back and forth. A review of my FSUIPC.INI file revealed where it was coming from. Apparently at some point I had used FSUIPC to assign the throttles directly through FSUIPC... which means the poor sim was getting input directly from the joystick as well as input from FSUIPC. No wonder it was sooo confused! I deleted the assignment entries from my INI file and now it all behaves as expected. The one thing that really surprises me is the sensitivity setting and that -7040 to 7040 range. Didn't expect that.

I will ensure to collect this information on the next crash. I don't know what is causing it, and I'm not willing to say it's FSUIPC that's doing anything. I just see it as the recognizable module in the stack list and hope that somehow the two of us can figure out what's actually happening and make it go away.

It's an access violation trying to read the address I listed above. That was while I was in Visual Studio so no module listed and no Windows error because I had to terminate my debug session on my own stuff. My 'stuff'... is gauge code for aircraft. It's not doing anything fancy, just reading sim variables and displaying stuff in the avionics.

I only download what's available from the main page. It appears to be 4.953. As I stated in my original post Saitek X55, dual throttles. Assigned via default sim interface only for throttle 1 axis and throttle 2 axis. I am intercepting using MapClientToSimEvent and AddClientEventToNotificationGroup and setting it to SIMCONNECT_GROUP_PRIORITY_HIGEST. Since my code is inside a gauge, that means I get to be the last one to ask for the axis data (I loaded last). That should allow me to intercept and control the axis values. I don't really care whether FSUIPC touches them or not... as I know lots of us use the calibration interface. I just want to be between the joystick and the sim so that the sim only sees what I send it. As for the throttle values... that's the values you display in the FSUIPC calibration tab area for the data coming from the joystick. If I disable FSUIPC so it doesn't load... I see the same range coming directly from SimConnect. So I have to assume that's the actual data range of the stick.

Hi Pete, Hope all is well across the pond for you. I have an odd issue I'm running into and I'm not sure what's going wrong, but hope that you can provide me insight. This is all in FSX:Acceleration with your current FSUIPC. I have set up an SimConnect interface to recieve the AXIS_THROTTLE1_SET and AXIS_THROTTLE2_SET events. The purpose is to intercept the axis values set by the joystick, override them and transmit the corrected values to the sim via SimConnect. I am using a Saitek X55 HOTAS which has 2 throttles. If I don't have FSUIPC running at all (module not loaded) I see a range of -7040 to 7040 in those events. If I have FSUIPC running, with no calibration active I see the inputs alternating between a min/max of -7040 to 7040 and a min/max of -16384 to 16383. I have never seen a behavior like this before and to be quite honest it makes no sense to me. If I calibrate... it still behaves that way. Any thoughts/ideas as to why I would be seeing such odd behavior?

Pete, Perhaps I can offer some information. I see a crash whenever I have FSUIPC loaded into FSX/Prepar3d and the last known module I see in the Call Stack list is FSUIPC4.DLL. I just had the crash happen and the call stack says: ->F9001810() FSUPIC4.DLL!14698623() [Frames below may be incorrect and/or missing, no symbols loaded for FSUIPC4.dll] etc.. etc.. I have no idea what is causing the crash... just that FSUIPC is the last named module in the call stack and perhaps this info may (probably not) be of help. I can tell you that I can catch this crash in Visual Studio no matter what aircraft I'm currently working on, code wise... so it's not aircraft specific, just something showing when I run my stuff. I also have another issue regarding FSUIPC and SimConnect I would like to discuss with you, however I'll make a separate thread for that sir. Ed Wilson

Pete, The point regarding DirectX is that the PFC hardware wouldn't show up in a Control Panel::Game Controllers listing. Or more simply, pretty much any controller that's visible to DirectX has worked... but this PFC isn't. I am reading the offsets as explained earlier yet a customer states that it does not work with their PFC Cirrus II. For a single throttle I watch 0x332E, for independant throttles I watch 0x3330 and 0x3332.

Bumping this thread... We have a customer who owns a PFC Cirrus II console. It does not work with our FADEC implementation at all. My guess is that the PFC is not defined as a joystick under the normal DirectX conventions and thus doesn't interface like a typical game controller would. I have listed in a previous post in this thread the offsets I read/write. Is it possible to get the PFC systems to work with our FADEC code? I simply haven't the income level to go purchasing a PFC system just to make it work. :(

I am reading 0x332E for single throttle as calibrated on page 1 of your joystick calibration interface. I am reading 0x3330 for left and 0x3332 for right as calibrated on page 4(?) of your joystick calibration interface. I am disabling the FS throttle via 0x310A. I am setting the left throttle via 0x088C and the right throttle via 0x0924. The issue is knowing whether the user is using the page 1 calibration interface or not. There is nothing that tells me if they have a single throttle or dual.

Because FADEC doesn't use a linear input/output process. The FADEC system has a 'target N-value' that it will seek and hold based on the physical throttle handle position and altitude. To provide this behavior I disable FS's input via FSUIPC and then based on physical throttle value from FSUIPC I set the FS throttle axis so that it hits the correct 'target N-value'. Of course, all of this requires they have a registered version of FSUIPC to work... but it does work.

Oh... the actual issue is even more nefarious than one might think. There's absolutely no way to know whether it's a single joystick throttle or a dual. There's absolutely no way to know if they're using the primary, single joystick throttle calibration or using the individual throttles calibration. In fact, there's absolutely no way to know if they actually have a joystick throttle or not. In short, since I can't detect their hardware configuration and how it's set up within FS and FSUIPC... I had to make a decision and a choice. It is, what it is.

A customer downloaded your latest version of FSUIPC and registered it. FSUIPC returns a version # of 0 when I do a read of it.