Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by airforce2

  1. Hi Pete; I am getting a Win 7 "A fatal error has occured" message in P3D V2 that appears related to FSUIPC 4.923. I have a bare install of P3D with only FSUIPC added--if I disable FSUIPC in the dll.xml, exit from P3D occurs normally. If I enable FSUIPC, it always crashes on exit. It appears to be a relatively benign error, in that I can't see any obvious adverse effect. As I recall, there were some menu-system related problems with P3D V1.4 a while back...wonder if it might be related. Cheers
  2. Pete--I just tested your suggested fix from post #12 above with UseAxisControlsForNRZ=Yes in the 777's joystick calibrations section. Worked as advertised--now the throttle axes do not interfere with the PMDG autothrottles. Thanks for that! Cheers Bob
  3. Hi Pete; Was tearing what little is left of my hair out last night trying to discern why the autobrakes in the PMDG NGX had suddenly stopped working. I had apparently made a global change when I assigned the pedal axes direct to calibration while trying to get the Aerosoft Scarebus to behave in-between catastrophic CTDs. I deleted the FSUIPC assignment for the pedal axes and set the NGX' aircraft-specific calibration page to "not processed", but could not get the autobrakes on the NGX to return to working. It turned out that FSUIPC had left a dangling assignment in the calibration section of the .ini file (LeftBrake=0) which somehow had FSUIPC still intervening with the brake axis or axes. The PMDG NGX autobrake does not play well with others--pretty much any intervention by FSUIPC causes the autobrakes on the NGX to malfunction. I found that I had to manually remove the LeftBrake= line from the Calibration section to get things to work again. Oddly, the RightBrake= line had been deleted, so I pass this along in case there might be a minor bug that's preventing the removal of the appropriate lines in the .ini when the assignment/calibration is deselected in the menu. I'm using 4.859m Happy New Year to you and yours.
  4. 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
  5. Pete; I've been using 2/3/4 separate throttles and a single-lever all-throttle reverse lever config with my PFC gear forever. I recently replaced the pots in my PFC yoke/quadrant/rudders with Hall Effect sensors and the quadrant electronics with Bodnar USB joystick interface boards, so I can't use the PFC driver any more to do that. The commercial add-on in question appears to intercept throttle inputs at 3330/3332 and then uses those as inputs to a FADEC simulation...effectively fly-by-wire control for the engines. If the throttle axis inputs are negative by virtue of a throttle lever calibrated to go into reverse range, the FADEC code sees those negative values on offsets 3330/3332 and puts the engines into reverse. If the reverse range is selected with a separate throttle lever, 3330/3332 remain at zero and it has no effect. I guess what might be baffling me is that there is no reverser "axis" listed in either the FS control axes menu or the FSUIPC for Programmers document...my belief was that the reverser input was somehow combined with the throttle inputs and applied to the simulation via a negative value on the throttle axis, as throttle is the only "axis" listed in either document for engine RPM control. Anyway, I ended up solving the problem by programming the reverse lever to send a string of FS throttle-decrease controls...but I remain curious as to where the reverse input from a separate axis is applied to the simulation. Cheers Bob
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. airforce2

    FSUIPC not seeing PFC buttons

    Pete; The electrons are streaking your way now. Cheers
  18. 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!
  19. airforce2

    Fixing FS9 EPR

    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
  20. Thanks Doug...I'll do that. Cheers
  21. 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
  22. 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
  23. airforce2

    CTDs since 3.70

    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
  24. 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
  25. 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

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.