Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by airforce2

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. Doctor Dowson to the rescue once again! Thanks Pete. Cheers
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate. Cheers Bob
  16. 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
  17. 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!
  18. 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
  19. Ali; To check for the buffer wraparound bug, look in procedure FSUIPC_Process at the first case in the while loop. ("Case FS6IPC_READSTATEDATA_ID") Within that case statement there's an If...should be If(Hdr(2) <> 0) Then If it's more complex (can't remember what it used to be), then you have the bugged version. You might try to cut-and-paste the corrected procedure code from the new SDK. Regards
  20. Rickard--You're correct...looks like an error in the translation from VB .net to C#. I'll send Pete a corrected version for the next SDK update. Ali--the buffer wraparound bug was present in only the very first release of the VB .net API. Make sure you're using the one from the current FSUIPC SDK (v19). Cheers
  21. If you are using the C# API from a version of the FSUIPC SDK prior to version 19, there was a bug in the buffer wraparound that would cause reads to fail and return 0 or other low values when the data buffer wraparound occurred. That has been corrected in the latest version. Regards
  22. If you're using a serial-to-USB adapter, like the Belkin F5U103, it should have a driver for the serial port emulation. How are you connecting the PFC quadrant to the system? Regards Bob
  23. Pete; I found the problem...the PMDG panel is indeed re-connecting the throttle axes on me. I fixed it by patching out the offending calls. Didn't see it the first time through due to a typo when setting up the control trace...was looking, in effect, for the wrong offsets. Duh. Anyway, she's working much smoother now. It's possible that this was happening all along, but not noticed because I had left throttles all the way back from engagement of A/T at takeoff and beyond. Thanks
  24. Pete; I see this so far only with PM running on top of the recently updated PMDG 737 panel. If I put PFC throttles to idle...or disable them completely in the PFC pulldown menu...everything works OK. If the throttles are connected and above idle, the throttles will momentarily and semi-regularly twitch towards the power setting set on the PFC levers. It's probably the PMDG panel's throttle quad gauge doing this. I could probably fix it by patching out the throttle control calls in the PMDG gauge ...but thought a more elegant solution would be to have PFC driver disconnect the throttle axes any time it's aware of active A/T control (especially PM). Cheers
  25. Pete; When I run the Project Magenta autothrottle in conjunction with the PFC throttle quad, I see spurious excursions of the throttles any time the PFC throttles are out of the full idle position. Would it be possible for the PFC driver to detect the PM autothrottle state, and not affect the axis input if PM A/T is on? 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.