Pete Dowson

Well, the problem if you are programming these as an axis is that the stick is sending the changes when it returns to the centre. If you stop those changes doing anything, how can you then change the view in the other direction? It is a logical impossibility. I recommend you either program chosen positions on the stick to send the discrete "pan left", pan right" etc controls instead of the axis controls (you can do this on the RIGHT-HAND SIDE of the axis assignments tab, don't use the left), OR simply remove the springs or whatever from the joystick so it stays where yo put it. You may need to stiffent it a bit to stop it moving about. I don't know what "analog triggers" are -- are they more joystick axes or just buttons? If buttons than you could program them to write to the FSUIPC offset for zoom (x2b2). Use the assignment Offset Word Inc or Dec. In that offset 64 represents x1, 128 x2 etc, so incrementing /decrementing by 1 gives you 1/64ths. For axes you could probably do the same and use the axis assignment multiplier/adder facilities 9editing the INI file) to limit that values sent. With the button assignment method, if you want to apply a non-zero lower limit you'd need to think about a Lua plug-in to program it instead. Pete

I think you must be confused. FSUIPC has no time dependent parts, and it doesn't "run", it just sits there waiting to be told what to do. It is not a free-standing program, but part of FS as a plug-in. Why are you blaming FSUIPC in any case, where is information about this 'crash'? There's no way anyone can help with no information -- you don't even say what Flght Simulator you are talking about, let along versions of anything else.. Test without VAFS and see if it is that which is the problem. Pete Pete

There's some misinformation here. The INI file LISTs all Lua file found in the Modules folder, but that listing only provides the references for Assignments. The only places in the INI file which can be responsible for automatically running a Lua plug-in are the [Auto] sections. Pete

Isn't this another version of the report I just answered? Pete

More details are needed. I don't know what that program which caused a crash does, but maybe it messed up your FSX.CFG or Simconnect setup? Also make sure you are using a supported version of FSUIPC -- nothing earlier than 4.92 is supported for FSX. The Windows error log will show details of what it thinks it wrong, and it would also be useful to see the FSUIPC4 log, as far as it got. If it is not producing a log then it is definitely a SimConnect problem and FSUIPC is not loading. Also see the FAQ thread about FSX not starting. Sorry, but I'm now away on holiday until Monday September 23rd. Regards Pete

Hmmm, maybe, but the successful closure was after a session lasting 42 minutes, as you can see: 4641 System time = 11/09/2013 16:40:26 ... 2540500 System time = 11/09/2013 17:22:42, Simulator time = 17:22:36 (15:22Z) Regards Pete

The information would be useful if it related to the currently supported version of FSUIPC, i.e. 4.92. Perhaps you could retry after updating, and let me have the same data which I can then possibly use? BTW, please note that the Log file you supplied does actually show a perfectly normal session with a tidy ending, so maybe it doesn't relate to the crash? Unfortunately I am away on holiday in a few hours, back Monday 23rd September. Please ALWAYS check that you are using the current version before asking for support. It saves time. Regards Pete

As with WideClient's log, the WideServer log file is next to the program which makes it -- i.e. FSUIPC4.DLL in the Modules folder. Everything to do with FSUIPC is in at folder. Try 8003, 8004, etc, whichever is not used. You'd need to change it in both Wideclient.INI and in the [WideServer] section of FSSUIPC4.INI. Details are in the documentation, as usual. Pete

I doubt if an FSX reinstall is needed. It'll be to do with USB HID device recognition. When I said to uninstall it I meant go to the Windows device manager, find the device listed there someplace, right click and select uninstall. Basically that tells Windows to "unrecognise it". Then when you re-boot and plug it in again it should reinstall the requisite USB entries in the registry. Well, yes ,even more so, but then I am developing software, etc, so most of my flying is really testing! ;-) Pete

You mean WideClient..INI I think. If thast is the correct IP address then you also need to sepcify the Protocol -- please see the WideFS documentation about configuring. You either omit both Server and Protocol details, letting the automatic system link the two, or you specify both server details (name or IP address) and the protocol to be used. If either are omitted then WideClient tries to locate the Server automatically, and that depends on Broadcasts being allowed. Broadcasts ARE allowed on all Windows versions since WinXP SP1, provided that both PCs are in the same Workgroup. This too is explained in the documentation. Please see the part about configuring the system, the part with the red section asking you to at least read the first few parts. You mean WideClient.log. The client is only one end of the link! The Server runs on the FS PC, and there is a WideServer log which tells us what is going on that end. I see the Client did actually connect using Broadcasting, (not your ServerIPAddr parameter): However the fact that the Server then closes the connection immediately appears to indicate that something else on your Server is using the same Port (8002) for other things and so doesn't recognise the Client's requests. This is the only explanation I can think of for a spontaneous closure. The Server log, which you've unfortunately not supplied, would be relevant there. I think you should look for other Networking programs which may use that Port -- perhaps you've configured SimConnect to use it? Either change that, or change WideFS, to use another port. Pete

I've been thinking about this. There might be a better, easier way, but I don't have any PMDG aircraft to check it on. This depends on how the NGX and T7 read the thottle settings Ths is a possible solution for throttles without a reverse zone on the same axis. In the relevant JoystickCalibration section of the INI file you need "UseAxisControlsForNRZ=Yes". Then load FSX. Assign the throttle levers Direct to FSUIPC Calibration using the Throttle 1 and Throttle 2 entries. Then go to the Joystick calibration section, enable calibration on both throttles and, before actual calibration, check the No Reverse Zone option, top left. Then calibrate. As far as I can see from the FSUIPC code, if you do this then FSUIPC does not intercept throttle controls, it just sends the calibrated values as normal FS commands, not via SimConnect. The PMDG code should pick up the calibrated values correctly. The only chance I see of this not working is if the PMDG code actually reads the joystick values directly, like FSUIPC, and I can't see how it can do that as it doesn't know how you've assigned them if outside of FS. Let me know how this goes, please. Regards Pete

Andy, the T8 has 8 toggle switches, so "on" and "off" are discrete events occurring when you flip the toggle down and up. They aren't momentary butons. The P8 is the one with buttons. Pete

Are you also using Goflight's own software, because maybe it is also sending commands? Try using FSUIPC's Logging -- check the button logging and also the exent logging. If you run FSX in Windowed mode, temporarily, you can display the console Log by its side (another check box on the Logging tab) so you can see exactly what happens whilst you are operating the switches. As far as the NGX is concerned, I think that has its own methods for all the switches. So test on a defaullt. Note also that there is a way to get separate ON and OFF commands for each light switch. It uses an FSUIPC offset, x0D0C, with a bit for each of up to 10 lights. You assign to "offset word setbits" to set bits, and "offset word clrbits" to clear bits. Again whether this works with the NGX is questionable. Pete

Very strange. What does "Lever B" mean? Certainly there's nothing in FSUIPC which will see a "Lever B" if that's its ID. It sounds like there may be a registry corruption for this device. Try uninstalling it in the Windows device manager, then re-booting with it unplugged, then plug it in. If that doesn't help I can only suggest contacting GoFlight support. Regards Pete

Well, it seems the T7 is like the NGX in that it traps the throttle controls at a high priority, just like FSUIPC does for calibration, then passes them on to FS at a lower proiority, just like FSUIPC does after it performs the calibration changes. That means there are two different values being sent to FS. So, a conflict, but in this case due to two separate routes. As Andy says, there is no way you can use FSUIPC's calibration. But you can still assign in FSUIPC, just assign to the Axis Throttle controls. As for the axis reversal you can deal with that by the scaling additions to the axis assignments in the INI file. To reverse it you just add ,*-1 to the end, meaning multiply the value by -1. Well, you might be able to get it closer by using the scaling. You only have a multiplier and an adder to play with, though. Please see the details in the Advanced User's guide, around page 43 I think.. The only other possible solution would be to use Lua plug-ins to receive the axis value (via LuaValue assignments), manipulate the axis values in whatever way you like, (even including using the calibration values you've already determined), then sending them on as Axis throttle parameters. Regards Pete

As far as FSUIPC is concerned the TQ6 is just an ordinary joystick, like any other. And FSUIPC reads joysticks all the same way, and the same way as FSX. You said earlier "I went into Win 7's joystick calibration and all the levers on the TQ6 are recognized", but have you checked that FSX sees them? Pete

Well there must be some conflict going on, because "losing calibration" is not the same as "lever moves but flip back". That's a sure sign of a conflict. And seeing as you say it happens on reloading FS, that's also the time when FS would auto-reassign axes. You say you "disabled ALL controllers on FSX", which worries me because unlike FS9 and earlier, FSX has only one place to disable controllers. If you are simply unassigning axes in FSX, that is not the same at all. Use FSUIPC's axis logging to see what is happening. Pete

That sounds like the controllers in FSX have not been disabled, and so when you reload FSX it automatically re-assigns some axes. That really is the only explanation I can think of. FSUIPC doesn't "lose calibration", it is stored in the FSUIPC4.INI file and retrieved each time. And "the lever moves but flips back" sounds like conflicting assignments. Lost calibrations wouldn't do that, it would just act as an uncalibrated axis, not moving things to places they don't belong! Pete

Er ... didn't you see the "no reverse zone" checkbox, top left? That facility has been there for many releases, and it is also covered in the documentation . Pete

You could have used your P3D FSUIPC4.INI on FSX to save redoing everything. I think that's how it is on the 737NGX too. It's only the calibration (not assignment) in FSUIPC which messes it up, because they are doing the same as FSUIPC's calibration, they intercept the control at a high level. FSUIPC does this also, then passes it through the calibration computations and sends it on to FS at a lower level. The two values will rarely if ever be the same! However, this doesn't stop you assigning in FSUIPC, but you need to assign to the FS Axis throttle controls. At least then all your assignments will be in one place and you can disable FSX controllers. (Don't forget FSX doesn't actually calibrate anything -- it leves it to Windows Game Controllers, which affects the inputs to FSUIPC in any case). Regards Pete

Screenshots are really no help. The PFC Throttle Quadrant is best calibrated in the PFC driver Why are you using FSUIPC for this? Please don't attach RAR files. Windows doesn't recognise them. Why not just paste the INI into the message like others? Much more compact than pictures in any case, and readable and quotable. If you cannot get the thottle input down to 0 is is either because you have dual assignments to throttle so one input is interfering with another, or, more likely, simply that your calibration is poor. Which any axis, no matter how bad or good, calibration can ALWAYS allow you to acheive the full range. Because all calibration is doing is matching one value of the input, chosent by YOU, to one extreme value needed by FS, and another value to the other extreme value needed. Even if these two values were only a few numbers apart, the extremes could therefore always be obttained -- obviously the precison of control in a small range isn't good, so that's why you try to calibrate with the extremes ALMOST (but not quite) matching the extremes on the axis movement. BUT ALWAYS ALLOW LEEWAY, because the values coming in WILL vary. I expect this is what you are seeing. Calibrate again, but do it properly, allowing some dead movement at both ends. Regards Pete

I don't see a question in your message. What's the actual problem you are getting, just FSUIPC's wind smoothing not fully working? Those two hooks are only part of that, nothing to do with frictions. I don't know what "uxsms" does -- do you still get the Hook Errors without that being run? [LATER] I've just added that BAT file, and I don't get any problem (see below), so I suspect your FSX modules SIM1.DLL and VISUALFX.DLL are either not correect (patched or corrupted), or something is interfering with access to them. Maybe executing that BAT file so early stops those modules loading before FSUIPC wants to hook them. Try putting the "READY," keywork before the path inthe Run line so those net things aren't run till later, when FS is ready to fly. Pete 3620 Run: "E:\FSX\Modules\FSX.bat" 3620 LogOptions=00000000 00000001 3620 SIM1 Frictions access gained 3620 Wind smoothing fix is fully installed 3620 G3D.DLL fix attempt installed ok 3620 SimConnect_Open succeeded: waiting to check version okay 3620 Trying to use SimConnect Acc/SP2 Oct07 12402 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 12402 Initialising SimConnect data requests now 12402 FSUIPC Menu entry added 12512 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 12527 \\LEFT\FSPLANS\738 EGCC Cold and Dark.FLT 12527 \\LEFT\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR 129200 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 129356 System time = 09/09/2013 19:38:21, Simulator time = 19:36:24 (18:36Z) 131135 Aircraft="Boeing 737-800 Paint2" 135238 Starting everything now ... ...

There's a fix in 4.92 which allows it to reconise joysticks correctly in WinXP or in XP compatibility mode. If you are not using either of those you are probably right, it will not make much difference -- but i can't help till you try it. If you are using FSX in XP compatibility mode you could try turning it off instead, but you still need to update FSUIPC some time if you want support. Pete

Not really -- it was for your information, not mine. If there's anything you don't understand then paste in a fragment and i'll explain what it means. Does that stop the throttle drifting forward to foerward thrust? Or was all that about throttle drift actually only referring to the N1 figure, not to the throttle values at all? If the latter, then the logging isn't relevant. Regards Pete

Firewall on? Do you mean off? Yes, WideFS is only designed to connect when the flight has started. The data applications might get before that is not reliable and can upset some of them. The same normally goes for FSUIPC applications started on the FS PC -- the "READY" option on the Run parameter is there for that. Few applications like the initial data before FS is ready. Much makes no sense, or is all zero unexpectedly. Pete