airforce2

Hi Pete; I'm trying to get a joystick controller that uses two throttle axes and a separate reverse axis to work with an FSX add-on that uses FSUIPC4. When reverser is applied (the output as shown on the reverser calibration page appears OK, ranging from 0 to -4096), the throttle input offsets at 3330 and 3332 do not reflect the reverse input, so the add-on does not respond to the reverser application. If I set up the throttle axes to have a reverse range, then the reverse values are reflected and the reverser works. Is the absence of the reverser input from a separate reverse axis at the post-calibration throttle offsets a bug or a feature? Cheers

Hi Pete...yes, I did try that, but how does one get a calibrated value sent direct to an FS axis? All I could seem to manage to get to the axis was the raw PFC axis value rescaled to the FS axis range. On a related note, is there a way of setting the reversers via an axis input? The regular throttle offsets, for example at 088C/089A, don't work with the Wilco bus, as his code watches for input events. When I send values from -16383 to 16383 to the axis, that corresponds to the 0-100% throttle range. Cheers Bob

Hi Pete; I just did something like what you recommended here to get my PFC throttle quadrant to work with the Wilco Scarebus. In doing so I got to thinking that it might be a good feature to add to either the PFC driver or FSUIPC to allow a FSUIPC-calibrated value to be applied directly to the axis input. Anyone using a standard HID control device has the option of calibrating that in Windows or possibly in FS itself...with a PFC setup, the best I could do with FSUIPC was to send uncalibrated values direct to the axis, which makes it impossible to scale the inputs, establish dead zones or use the control curves elsewhere available. It wasn't hard to write a mini-driver to do that, but custom programmatic solutions are only available to a relatively small number of us with that skillset. PFC users in particular might appreciate being able to use their gear with the growing number of fly-by-wire implementations. Cheers Bob

A quick post-script on this--it appears the problem with ATC.DLL crashes was related to either flashing a new BIOS that put my overclock right on the ragged edge of stability, or some issues with nVidia's 196.21 drivers, or some combo of the two. Not sure why I saw the same ATC.DLL fault each time, but getting the overclock stable again with a Vcore change and reverting to 182.50 drivers seems to have slain the dragon. Or maybe it was the dried lizard's feet positioned facing towards Salem on top of the CPU case... Also, FWIW, I had unchecked the voice checkbox in the FSX sound control dialog, but left the slider up--turns out that does not turn off the voices. That checkbox only allows the voice sounds to be redirected to a different sound device than the other acft and environment sounds (i.e. to a headset). Turning the voice slider down is what's needed to kill the ATC sounds. Cheers Bob Scott Colonel, USAF (ret) ATP IMEL Gulfstream II-III-IV-V Colorado Springs, CO

Hi Pete; I am seeing the same thing... a lot of crashes due to atc.dll in FSX when using Radar Contact v4.3, and also I am hearing FSX's ATC voices at low level in FSX even with the "voice" checkbox unchecked in the sound dialogue. I run RC on a remote PC via WideFS. Regards Bob Scott Colonel, USAF (ret) ATP IMEL Gulfstream II-III-IV-V Colorado Springs, CO

Hi Ed; My suggestion is, in addition for testing for presence of a DirectInput throttle axis, to also test the single byte FSUIPC offset 0x3373 for a nonzero value, which indicates that a PFC control system is present and active. My understanding of your control methodology leads me to believe it will work unmodified with the PFC systems, as the PFC throttle control inputs will be present at offsets 3330 and 3332 no differently than a joystick axis, and right where you watch for them in your code now. There is a fairly sizeable group of us that use these (pricey) high-end flight controls, so the small effort to include us in your coding considerations will result in enough sales to make it worth doing. Regards Bob Scott Colonel, USAF (ret) ATP IMEL Gulfstream II-III-IV-V Colorado Springs, CO

Pete; I don't see anything specific on the topic. The aircraft-specific assignments are made when you press the "assign to aircraft" button in the driver dialogue window. It places an entry in the Aircraft Quadrants section of the ini file: aircraft_title=Uxx where Uxx is one of the 15 quadrant definitions, yes? The question is, can I use a substring, e.g. Feelthere A3=u15 to catch every aircraft that starts with "Feelthere A3", for example: Feelthere A318IAE Feelthere A320CFM Feelthere A319CJ etc etc Cheers

Hi Pete; Are Short names (aircraft title substring matches) enabled in the PFC driver Aircraft Quadrants section like they are in FSUIPC? My Aircraft Quadrants section in pfc.ini is immense...shortnames could cut that down to size considerably. Cheers

OK, thanks Pete. I did previously check the .dll digital sig per the docs. However, before I run FS I use always Ken Salter's FSAutoStart utility, as many others do. In FS AutoStart I discovered that I had the Cryptographic Service selected to be stopped per the program's recommendation. FYI for the future...may be a good idea to test that the service is running and throw an error code if not, given the wide usage of FSAutoStart and the fact that it explicitly recommends people stop the crypto service. Your call, of course. But...the problem was indeed intermittent...however that error was coming from FSLook, not from FSUIPC directly. Cheers

Pete; When using FSUIPC 3.72 and FSLook from the v27 SDK, I am getting intermittent errors from FSLook complaining about the version number of FSUIPC. It's a sporadic thing, but almost always comes up, especially with more complex aircraft. I recently saw a post on AVSIM with another guy using 3.72 seeing a version error reported by the PMDG 737 panel. Reverting to V3.70 stops the behavior. Cheers

Pete; The electrons are streaking your way now. Cheers

Pete; Having trouble trying to program my PFC yoke buttons in FSUIPC in a new FSX installation. Programming buttons within the PFC driver works OK, but if I go to FSUIPC Buttons+Switches tab, and press the PFC button, nothing happens. Have repaired SimConnect, and tried 4-5 versions back from 4.03/4.065...same thing each time. Regards

Hi Pete; Yes, it's true that FS9 does not compute EPR in any meaningful way...EPR values coming from the FS9 FDE engine are generally nonsensical...like seeing 1.6 EPR at idle on the ground. Much has been written on the topic in the AvHistory.org FDE forums among others. Indeed, some competent panel programmers do in fact get it right with custom programming in their gauges...PMDG, Dreamfleet, even my own gauge work in the TinMouse II 737 (shameless plug alert!). But I'd love to be able to divert the indirection in FS, making it write the flawed EPR values to some unused corner of the data area, and replacing the data at the address used to access EPR with externally generated data in lieu of the flawed EPR values that are being read from FS by a number of otherwise decent panels written by guys that simply didn't get that part right. Anyway, the project at hand right now is to make a working EPR gauge for the JT3D-7 in the CaptainSim 707...they, unfortunately, use a single massive multigauge panel (the entire main panel is a single gauge) that doesn't lend itself to replacing one errant gauge, and they are utterly hopeless when it comes to fixing things once they consider a product to be close enough to done. Cheers

Pete; Is there any way that you could put a feature into FSUIPC 3.xx that would allow a programmer to write an EPR value to an FSUIPC offset and have that value poked into FS9's extern data table (overriding the flawed FS-derived value)? As you know, the EPR computations in FS9 are hard broken...but there's a lot known on how to derive valid EPR values from other parameters such as CN1. In an ideal world, each panel developer would do this, but the world isn't ideal. I'd like to be able to write a piggyback program to compute and write valid EPR data that would override the FS value and be retrieved when a lookup of the FS EPR value is performed by otherwise salvageable panels like the CaptainSim 707/727 for example. Anyway, I figured if anyone could work that sort of magic it'd be you. Happy Holidays from sunny central Chile!

Thanks Doug...I'll do that. Cheers

No, I want to move the flap handle through the detents, but without necessarily moving the flaps. The flap handle position set & displayed with the make_slider macro uses an internal variable rather than the flap handle position in FS. The FS flap handle position (which seems inextricably linked to the actual flap position) is set by the gauge based on the internal flap handle position variable and the other conditions necesary to move the flaps. Changing the displayed flap handle position is done currently by writing a value to offset 0x6D11...2 for raising, 3 for lowering the flap handle position. Users map buttons via FSUIPC to control the flap handle (like my PFC quadrant's double-throw spring-centered switch) What I want to do is allow a hardware lever's position (mapped via FSUIPC so a user can use any lever FSUIPC can detect via a common interface) to be used to set the flap handle variable in the same manner. gauge now...but access to the joystick values by an external program via FSUIPC would be useful. The problem is that the relevant axis will vary from user to user. What I want to do is allow users to map any hardware lever to control the function. The lever on a CH yoke will be different than a PFC lever. FSUIPC does a nice job of detecting a hardware device and allowing it to be mapped to where needed. In this case I want to allow a user to select any FSUIPC-detected lever and have it send its position directly to a specific FSUIPC offset which is used to control the custom flap handle pos. I did that for the spoilers using PROP1 and PROP2 axes. But I don't see a lot of usable but unused axes. I can use any scale...0-255 works fine. That'd work fine. The desired endstate is to have a user use FSUIPC as the single routing function for key/button/axis assignments, and to be able to select which hardware joystick axis will be used to make the input to (in this case) an internal flap handle position variable via an FSUIPC offset used internally. Hope this is clearer. Cheers

Hi Pete; What I am trying to do is read a raw joystick axis value and, based on the value, control flap detent settings. I have to do it apart from the regular flap axis because I want to separate flap handle movement from flap position. This allows the flap handle to be moved, and if system configuration is not appropriate (hydraulic press, electrics, no assymetry etc) the flaps won't move with it. I've used the mask feature, but it tries to move the flaps initially before your code catches it and puts the lever back...and which also triggers sounds etc. I can think of other uses for such a feature as well. What you described...a special value for Parameter that would cause the axis raw value (scaled 0-16384?) to be sent to the offset if it has changed, is exactly what I had in mind. That gives a panel programmer direct access to hardware lever position data that can be used to perform proportional control over other than established FS axes...like operating an externally programmed engine supercharger, as one example. My current project (the TinMouse II B732 panel) is still FS9-only, but my intent is to port it to FSX at some point. As always, many thanks for your wizardry and help Cheers

Pete; Is there a way in FSUIPC to assign a hardware axis to send its value straight to an offset? I need to be able to take a joystick lever raw value and access it via an offset without trying to assign it to an FS axis...I'm out of usable FS axes. Thanks

I had something similar going on, and finally tracked it to a change that had occurred in my FSUIPC.ini that had removed the line: RemoveATC=Yes This caused the old ugly atc.dll CTD to come back and haunt me for the majority of one very frustrating weekend. No idea how the ini file was changed, but I went back to my saved copies and it looks like the change happened around the time I upgraded to 3.70 There had been a few random dumps...but a few weekends ago I found a flight profile that really tickled the atc.dll bug and it was a steady stream of midflight CTDs. Once the param was put back...voila. Regards

You might try changing var names...you are using same vars as defined in the functions (i.e. "Param"). The scopes look OK at first inspection, but could be a var is being mis-cast...in particular, Param cast as type Byte could have this effect. Also, given that these are defined as functions, calling them as subroutines looks strange to me... Agree with Pete that you'll need to engage in some more involved debugging to see more precisely where this overflow is occurring. Regards

OK, Pete, I'll try zapping those pesky joystick sections from the FS9.cfg Understand about letting FS9 rebuild it, but I have probably 3-4 man-weeks invested in tweaking the blasted config, and am less than cheerful about the idea of re-mapping the FS9 genome... :wink: Cheerio

Pete; I tried disabling the joystick and got an even worse storm of registry thrashing. Understand that PFC does nothing with the joystick...but I did think it important for PFC users to know that if using a PFC flight control with no joystick attached to the PC (I mean with a PFC unit at one's disposal why *would* one want a joystick on the PC?), FS9 will still be busily looking for a joystick in the background even while it's getting control inputs from the PFC driver via FSUIPC. My rather inelegant solution is to plug in a cheap joystick as a sort of FS9 pacifier. If you give Bad Billy what he wants, he shuts right up. I didn't know if (but was hoping) you had some wizardly way to head off DirectInput at the pass...as you often do with these things. Cheers

Pete; Was watching FS with Mark Russovich's RegMon utility, and noticed a steady stream of unsuccessful hits for joystick settings on a registry key for DINPUT.DLL (see screenshot). Hit frequency was something like 30-50 times a second. I use a PFC yoke and throttle combo without a regular HID joystick connected to the PC. After seeing this registry thrashing, I plugged in a USB joystick in addition to the PFC combo, and disabled all the axes of the USB joystick in FS9. The registry thrashing stopped, and frame rate excursions have smoothed out some. Not sure there's anything that can be done in the PFC driver, but it's a curiosity worthy of a look. Cheers

OK, well then I'd be looking hard at something like an IRQ or address conflict. Make sure the USB adapter isn't using the same I/O address as the onboard ports, or that there aren't two devices trying to be the same serial port. I've found that serial I/O does not always coexist peacefully with other devices doing interrupt-sharing, even though Windows PnP seems to think it should. Have you tried other serial devices on the ports in question...like a modem, perhaps? Cheers

I'd start first by reseating both ends of the cable, and if that doesn't work, then try a different serial cable. If that doesn't do it, try monitoring the serial port with a simple terminal program. Otherwise it's probably time to send 'er back to PFC. I like your sound sets, BTW. Cheers