airforce2

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

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

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

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

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

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

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

Pete; Last night my car started making this kinda funny ker-chunky sound, with a little bit of high-pitched wheezsazz noise at times. At the same time, my son's GameCube started randomly re-booting, usually right around the time I told him to head for bed. I usually flash the lights at him, and I think the GameCube may be plugged into the same socket as the lamp. These two events certainly cannot be coincidences. I have four college degrees, and wrote a computer program once, and I feel sure that it must be a bug in FSUIPC. Fix it or else!! :lol: Cheerio Bob

SBRelay must be run on the host PC. SBHost and SquawkBox both run just fine on a client PC using WideClient in lieu of MSFS. Regards

OK Pete. Nothing as ominous as stolen keys there. Looks more like they've written an add-on panel that may not coexist with the most popular add-on utility in FS-land (FSUIPC) and choose to suggest that people now need to contact you to resolve the perceived incompatibility with their stuff... Personally, I'd rather be able to use ActiveSky, FDC, Squawkbox, and my PFC flight controls than use their panel anyway. Cheers

Pete; Might be a good idea to have a look in the FeelThere forums...their developers seem to be quite content to quickly point their fingers at FSUIPC as the root cause of a number of their new add-on's problems. Cheers Bob

I wrote a few netpipes test apps and noted the same...widely variable lag and jitter. It was unuseable for any real-time IPC needs. Regards

Pete; Please accept a monster-sized thank you for the dual-protocol support in the latest WideFS! The road has been rocky since the switchover from IPX to TCP/IP several years ago. I had, over time, stabilized things into a reasonably smooth system, but the recent combo of Win XP SP2 and all the networking changes it brought, then FS9.1, and then a motherboard failure, threw everything out of whack again, and I have simply not been able to get it under control. Though FS was clearly writing a steady stream of packets, they were arriving to the clients in bunches, with surging and ratcheting readily apparent all over the distributed system. I think there are simply too many processes that touch on TCP/IP control, due to security, internet throughput and other issues. To make a long story short, I installed IPX on my two Win XP Pro machines, and in a few minutes I had a near-perfect smooth flow of data. Coupling FS 9.1 running at 30 fps with the latest Project Magenta builds yields the best performance I've seen on a distributed FS system ever. I can't imagine ever going back to TCP/IP...hope you'll continue to support it in WideFS. Cheers

To use Oleksy Frolov's panel with the PFC controls, you have to assign your engine controls in the PFC setup to engines 3 & 4 rather than 1 & 2. I'm not sure why he did this...seem to remember a conversation a while back about direct access to DirectX by the panel for the normal throttles. I do it this way and it works just fine. Regards

Doctor Dowson to the rescue once again! Thanks Pete. Cheers

This makes sense...I confirmed that the PSS A320 A/P is using only elev trim for pitch control. It does not use the FS A/P...it controls the trim directly. It appears that the 330/340 also uses elevator, which would explain why it works when the 320 doesn't. There's a gent persistently experiencing the opposite problem on the PSS forum...his A/P works, but the joystick axes are dead when he disconnects the A/P for a manual approach. He also gets a full-nose down trim runaway during taxi in after disconnecting the A/P. Sounds like there may be a connection. Regards

I'm not sure that's all of it. I fly the PSS Scarebuses with a full PFC yoke/throttle/rudder combo with no problems. I currently use FSUIPC version 3.317. Regards

I experienced this diving behavior several times, although I am not sure what precipitated it. It was soon after the FS2004 update for FS9 came out, as I recall. I fixed the problem by creating a new flight in FS using the default B734, and with the engines running I switched to the PSS Scarebus 320. Voila...no more Ju-88 Stuka noseovers. I suspect the problem was some lingering .flt file settings...so far the only known way of resetting them all is to load a default MS airplane. Regards

If all you're trying to do is run FS9 across several monitors, the best solution may be to buy one of the many fast dual-head video cards on the market, and run two monitors off one PC. And to a lesser degree of performance, it's also possible to run a 3rd and 4th monitor off a second (PCI) video card on the same PC, assuming you only want instruments and not 3D views. I run FS9 on a 3.06GHz P4 with a dual-head 256MB nVidia FX5600 Ultra, giving me two 1280x1024 displays that appear to the PC as a single really-wide 2560x1024 display that does DirectX or OpenGL acceleration across both. I also have a PCI nVidia MX440 card that runs a third monitor at 1024x768 resolution, 2D only, and it works quite well for instrument panel displays. On my secondary PC, I have another dual-head AGP card, a 128MB nVidia GF4 Ti4600 driving two 15" LCD monitors at 1024x768. I use this PC for Project Magenta, Radar Contact, ActiveSky, SquawkBox, and a few other utilities all running over the LAN via WideFS. I find that multiple diplays on multiple PCs is very cumbersome...getting displayed wx to synch across machines, for example is nigh onto impossible. Cheers

Phillippe; If you had to fix the old wraparound bug, you are using an extremely old (the very first, in fact) version of the VB .Net SDK interface. I highly recommend that you use the latest version. I use VB .Net programs built upon the SDK here regularly for a number of different utilities. Cheers Bob Scott ATP IMEL Gulfstream II-III-IV-V L-300 Washington, DC

Pete; When I made the switch to PFC 1.90, the throttle quad was no longer recognized. After several unsuccessful FS restarts I added the line Speed=9600 in the Connection section of PFC.INI, and that cured the problem. It's odd, because the driver removed that line when it re-wrote PFC.ini, but the driver continues to work now without it. Is it possible that, with the new logic arising from use of both 9k6 and 19k2 PFC devices, the port config is not being positively written under some circumstances when using a 9k6 device? May be worthwhile to allow explicit port speed assignment (Speed=9600 as well as 19200) to remain in the ini. Cheers

I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate. Cheers Bob

Pete; I'm at home on holiday next two weeks, so I've lots of time to play with it if you send it. Cheers

Pete; I think it would be useful for all axes, and the ability to disconnect them is critical in some cases to getting things to work. On pre or post-calibration, I assume that the calibration is context specific, based on the particular axis assignment. I could use either, but for a feature like this less may be more...intent is to divert axis data to an accessible place, and then the programmer is responsible for scaling/smoothing/processing and injection into FS. Simple, directly-readable raw data works for me. One possible use of this capability is to program some means of emulating a Direct-X joystick input from a PFC axis. I note that the PMDG Control Wheel Steering mode (very well implemented) appears to rely on ability to read the joystick axes via DX...PFC serial devices aren't seen and therefore don't work. I'm also interested in software detents for prop controls on several turboprop panels etc etc. Lots of useful possibilities here I think. As always...thanks a bunch!

Pete; I was wondering if, at some point, it would be possible to provide a new option for the various analog axes on the PFC controls. It'd be nice to be able to map a PFC analog channel straight to a FSUIPC offset, so that an external program could read the raw PFC data...process it...and in turn write the post-processing data back to FS via FSUIPC. Right now I'm trying to write a program that takes throttle inputs and translates them into keystroke controls for the PSS Airbus panels. It'd be a very straighforward thing if I could select, rather than Throttle1, FSUIPC Offset &Hxxxx, have my program read that, and then either pass keystrokes to the panel or set the throttle axis value via a FSUIPC write. There are a few other applications for such an interface I can think of off the top of my head... Cheers