Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by airforce2

  1. 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
  2. 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!
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hi Pete; The LDS team released an SDK with the 767 add-on which gives access to a variety of extern variables, including one with the A/T state (via an IPC DLL they provide for their panel). If you don't have it already, hopefully a member of their team will provide it to you shortly. Cheers
  14. I could envision a few uses for such a beast... Cheers
  15. Lots has been written in the F1 ATR forum on the interaction of FS throttle inputs and the auto-torque on the F1 ATR. For the F1 auto-torque to work, the throttle input needs to be at 0 (idle). Any throttle movement...even the fidgety back-forth drift caused by a noisy pot, will cause interference with the panel's auto-torque control. That, unfortunately, is a panel programming characteristic, not an FSUIPC problem. I got around the prop beta (reverse) problem by assigning reverse to a separate lever on my PFC quadrant. Probably not an option on the CH unit. Regards
  16. Interesting...but what's it used for? Are you building a sim with real avioncs boxes? Sounds kinda expensive... Cheers
  17. The keplerian elements that describe the orbits of the 24 GPS birds are readily available in multiple venues on the internet. It's a relatively straightforward process to compute the azimuth and viewability of the sats for any given date/time (epoch). But...that said, it's a lot of computing power being devoted to a really esoteric piece of background data that one would almost never look at in real day-to-day ops. Regards
  18. Hmmmm...a set of offsets for "user head position" could be very useful, indeed. That way, when somebody sends in a log file with a problem with an FSUIPC-enabled program, the support staff can first check to see if the head position offset indicates that the user's head position is "up his... OK...never mind... :mrgreen: Just a spurious thought... Cheerio
  19. All three of the airplanes you listed are actually fitted with spoilerons, which behave exactly as you describe in real life. In the aircraft.cfg file, under the airplane_geometry section, there is an entry "spoilerons_available" When set to 1 it enables this type of flight control action. So if's there, it's because the FDE designer put it there. Regards
  20. Hi Pete; Actually, the takeoff thrust setting on the 727's center engine is always a tad higher than 1 & 3 because the bleeds are shut off on that engine. Use of asymmetric thrust to aid in ground handling on a jet with tail mounted engines isn't particularly useful. Anyway, absent abrnomal circumstances, having the two outboards slaved together and the center separated does make some sense. Cheers
  21. Hi Pete; Along these lines, also an option to map one lever to throttles 1+3 would be helpful for 3-engined birds. Right now with a 2-throttle quad, you have to do 1+2 and 3. Cheers
  22. Try running DXDIAG also...go to windows start -> Run and type "DXDIAG" in the window. It'll do some basic testing on your drivers w/r/t DX. Don't know what the SIS utility is, but anything flagging a memory error with the kinds of problems you're having calls for a closer look. Did you run memtest86 as I recommended? I've found that utility to be very good at finding physical memory problems. It also might be worth swapping the two memory modules as well. Regards
  23. Howie; It's very unlikely that the drivers which came on the CD for your video card are up to date. Win XP SP2 includes an imbedded update to Direct-X 9.0C, and many older drivers have big problems with the new version of Direct-X. Recommend you update with a recent version from http://www.guru3d.com or the nvidia website. WinXP SP2 also included many changes to networking components, and it's possible your LAN drivers aren't current either. Likewise, the Soundblaster 2 drivers should be updated from the Creative website. I'd recommend you find a memory check program like Memcheck86 (http://www.memtest86.com) and run it for several hours to see if there's a problem with your RAM or some other part of the memory subsystem. Also, the freeware program MBM may help in resolving the temp indication issues. Most CPUs have more than one thermistor, so varied readings can happen, but not usually by that much. Also see this article: http://www.vanshardware.com/articles/20ttling.htm A hot spot on the CPU could cause the hardware to throttle the CPU, with the possibility of system instability. A hot spot is easy to create with less than fastidious attention to heat sink bonding. Or...also possible is a CPU with a faulty thermistor. Honestly, my less-than-fully-informed guess would be a driver problem...but the odd CPU temp readings are a troubling sign that needs a closer look. Good luck
  24. The short answer: FS does not perform any meaningful simulation of engine vibration for any type of engine. Values produced (for jets only) are notional. The prop amp indication is an equivalent to the engine vibration readings in a jet engine. The prop amplitude is a measurement of the peak amount of vibratory motion per unit time, and is proportional to the magnitude of the mass imbalance on the prop assembly. Resonant vibratory stress becomes a problem if either an excessive mass imbalance is present (prop/gearbox/engine is not balanced properly) or also possibly by the resonant effect of the regular power pulses applied to the prop by the power-stroke detonation in each cylinder of a reciprocating engine. This explains why some recip powered aircraft have ops limits which prohibit sustained operation of the engine in certain RPM ranges that produce this power pulse resonance. That said, modeling of vibration response of a particular recip/prop combo is well, well outside the bounds of what MSFS will do. It'd be an interesting add-on feature. Cheers
  • Create New...

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.