Pete Dowson

You still haven't told me the range nor the min/max values you've set. If that is so with the filtering off it is to do with the aircraft model, unless you simply don't have enough brake pressure applied -- since you won't state the range and values i can't tell. Pete

"Newest" meaning what, exactly? 3.99 or 3.998d? Either way, it sounds like you've got something wrong with your FSUIPC installation then. Close FS9 and show me the FSUIPC.LOG file from the Modules folder. You can paste it into a message here. Regards Pete

That's simply because the way VRI program their devices it sends an On message on one press and an Off message on the next press, rather than an On when pressed and an Off when released. Therefore you need to assign exactly the same thing twice to every button -- once for press and once for release. The easiest way is probably to edit your [buttons] section in the INI file. Make a straight copy of all of the CDU assigned button lines, add them to the end, renumber the line numbers to follow on, and change the initial "P" (Press) to "U" (Unpress -- R is used for Repeat). Regards Pete

I couldn't imagine anything in the client being affected by FS pausing. I don't know. Possibly, if it shows the state of the stack at the time and identified the modules concerned. my betting is that it's crashing deep in the TCP/IP stacks. You could try uninstalling the Ethernet device or board on that PC and reinstalling, using the Device Manager. hopefully that will reinstall the drivers for Ethernet and may resolve things if it was down to some file corruption. Regards Pete

Not "these files", only the DLL.XML, the file responsible for telling SimConnect which DLLs to load. Does ASE use DLLs loaded into FSX? I didn't think so. I have none. FSUIPC isn't dependent upon the Simconnect.XML file and doesn't touch it. Since FSX SP1, or maybe SP2, even if local Simconnect support is omitted from that XML file FSX still supplies both TCP/IP and PIPE interfaces. It is possible to deliberately stop those by adding stuff to the XML to do so, but no installers I know would do such a daft thing. Regards Pete

it's not a good idea unless your pedals are pretty flakey. Try without the filter. Filtering can do that as it works on gathering samples. You should be able to compensate for that by adjusting the Min/Max points in the calibration. No two axis hardware components are exactly the same, that's why you need calibration. Try and get the OUT values shown in the Calibration the same for each pedal for different pressures. -940 isn't right.. What is the range of "IN" values for each? What have you calibrated for minimum and maximum for each? What values? If you assign in FSUIPC you assign in FSUIPC, else you assign in FS. Pete

Check the Lua example provided ("record to csv" -- see your FSUIPC Documents subfolder), which makes a csv file recording such things. It sends all this data to a file 20 times per second: hour, min, sec, hourZ, minZ, gs, tas, ias, lat, lon, alt, pitch, bank, hdgT, mach, vs That doesn't seem to have any great impact on performance! Regards Pete

I use ASE and I'm sure it doesn't mess FSUIPC's installation at all. But it never does any harm to run the FSUIPC4 installer in any case. Pete

Hmm. It was really the calibrations I was referring to. You can assign to FS axes without calibrating, just as you can calibrate axes without assigning. You appear to have gone through the calibration pages for your various FSUIPC assignments pressing the left hand "SET" button to tell FSUIPC to calibrate them, but then not actually done so. If you only want to use the assignments and leave your default windows driver-set calibrations to themselves you might as well go through pressing the left "RESET" buttons on each axis assigned to FS controls and just leave FS to it. This will work with all of the controls named "Axis ...." because those are the ones FS assignments would make. All you'd be using FSUIPC for is the switching for different aircraft. For axes assigned "direct to FSUIPC calibration" you do actually need to SET calibration, but you don't for the regular FS controls. Regards Pete

No,there is only one current version FSUIPC3, no other is supported. That'll be 3.99. The latest update for version 3.99 is 3.998d (in the Download Links subforum). No, it only needs at least 3.81 -- that's all they mean! There are no programs designed to work only with a specific old version, they just mean they use facilities not added until then so make sure you update! You are always meant to use the latest version, or you get no support. Pete

Sorry, I've no idea what you are talking about here! You don't refer to anything either in the title or your text. Are you sure you are in the correct forum? If so, what program supported here is it you are talking about regarding "versions"? If you mean FSUIPC, there are only two versions, but for different platforms. FSUIPC3 for FS9 and earlier, FSUIPC4 for FSX and beyond. No others exist. Pete

Yes, and I have a full suite of Project Magenta and other programs reading many variables many times a second too with no measurable performance effect. I'm sure FranklinJS's problems lie elsewhere, maybe with all this file handling he's talking about. Regards Pete

So why not use them that way? But looking at your assignments you used "THROTTLE1_SET" and "THROTTLE2_SET", not the normal AXIS_THROTTLE1_SET and AXIS_THROTTLE2_SET controls. Why? Those old FS98 controls are the ones FSUIPC normally uses to get reverse thrust on the same axes, and are, by default, excluded in the 4 throttles page as you will see by the checkbox at the bottom. And did you manage to actually calibrate them? It seems unlikely. [Yes, that's good but wasted when you assign to wrong controls. Please assign to the AXIS controls in the first place. All the "UseAxisControlsForNRZ=Yes" does is avoid changing them into the THROTTLEn_SET controls which you chose instead. Also, I see from your calibration values that you've not actually bothered to calibrate any of your axes properly at all. Apart from Aileron and Elevator (which are only partially calibrated in any case), all the others are still completely set with default values. If you aren't going to calibrate in FSUIPC it's a bit of a waste of time using it for your controls, really. Regards Pete

Don't know why, as FSUIPC is not dependent on either of those two files, only the DLL.XML file. And ASE doesn't use FSUIPC4. But it doesn't matter re-running the Installer, it won't do any harm. The installer doesn't touch the INI file, and in fact it won't even replace the FSUIPC4.DLL unless the one you have installed already is older. you always need to run the Installer for major updates in any case, else you don't get up to date documentation. It wouldn't be nice of it to destroy your configuration now, would it? :-) Regards Pete

So very few switches for Process calls per second? Only switches etcetera operated by the pilots? so very infrequent, in fact? So, there should be nothing happening most of the time! I'm afraid you'll need to work out what is causing your problems, then, probably by a process of elimination. Try without one thing at a time. From what yoyu say it cannot be anthing to do with the IPC interface or the Lua plug-in. Most of the time they are idle, from what you say. Regards Pete

Are you accumulating all the reads from offsets and doing just one FSUIPC_Process call per cycle? If not you should. If you are using Process for each and every item it will be trying to switch back and forth between the processes furiously. That's the main reason most folks add-ons are inefficient. Similarly with Lua. If you are reading a lot of stuff every time it changes that could be far too often. Best to use a Timer event and just poll information at intervals. How frequent is the cycle you are using? An ACARS system should only need a fairly infrequent update, like a second or even several? You should interleave data extraction and file activities to even out the processing load. Regards Pete

There may be a few reasons. Please close FS down and show me the FSUIPC.LOG file from the FS Modules folder. You can paste it into a message here. Regards Pete

If you weren't using 4.733 when you had the problem, no, it won't really make any difference. There was a small glitch in the 4.733 update which is why I replaced it within a few hours. Unless the pdeals are giving totally erratic readouts, provided they give some regular change of values from released to fully pressed, whether increasing or decreasing, then proper calibration in FSUIPC will always work. All FSUIPC is doing for you when you follow the calibration steps is to record a safe and consistently attainable "brakes off" (minimum) input value, and a safe and consistently attainable "brakes full" (maximum) input value, and converting all the intervening values it sees into the complete range acceptable to FS. That is "calibration" -- matching whatever your pedals are doing to what FS actually needs. If you follow the numbered steps in the calibration section of the User Guide, ensuring that numbers increase left-to-right on screen (and as you press the pedals), then there's really nothing that can go wrong. If you think it isn't working for you, note down the "IN" and "OUT" numbers you are seeing on screen with feet off, feet pressing slightly, and feet pressing fully. Let me know. And also tell me what you've set under the minimum and maximum "Set" buttons. Pete

4.734 is the version number of the latest interim FSUIPC4 update available in the Download Links sub-forum. Regards Pete

Sorry,then. It has got to be either hardware -- memory or network/ethernet controller in your PC -- or a driver, possibly the network driver. There's no way an idling WideClient can get into trouble. All it is doing is sending and receiving identical "I am here, are you there" type messages at regular intervals. Memory seems the most likely as each new message will claim a little buffer in memory, probably different from the previous, till it wraps around. Regards Pete

What 'feature' is it they refer to here? If they've designed an aircraft which specifically only likes throttle increment and decrement controls, as provided by mouse clicks, and behaves badly when using any sort of axis conttrol, then I think you should abandon the aircraft as being very very badly designed! I can't say whether FSUIPC can possibly do anything because i can't believe that anything could be designed so badly. I really wouldn't know how to deal with it except to look for something better! Sorry. Regards Pete

Do they come off if you depress them fully? If so you need to reverse the axis. Most pedals have the high numbers feeding in when released, decreasing to zero as you press them. You also always need a good dead or null zone on pedals so you don't press the brakes unintentionally when using the rudder. That certainly sounds like one of both of those problems. Reversed and/or non enough of a dead zone. you are certainly getting something wrong, then, unless those pedals are faulty. The sensitivity slider should be as far right as possible in any case. Those are both the same to FS and FSUIPC. Really? Never heard of that. In any case calibrating in FSUIPC would ignore all that. If you do try it in FSUIPC, make sure you don't assign in both FS and FSUIPC, only one or the other. In FSUIPC, on the calibration page, you should be able to see clearly what is happening, as you can see the numbers themselves. You should be able to get values calibrated to work, no matter how bad the axis/slider. Regards Pete

I've moved this to the general Support section. Where are you seeing "2" noted? They've always been 0 or 1, being standard BOOLeans. Regards Pete

You can run 9 initially (run1 - 9), another 9 when FS is "ready to fly" (runready1-9) and another 9 on assigned KeySends (runkey1-9). I can only suggest you run some initially and some when FS is ready. And appeal to that gauge maker to provide some sort of umbrella application which handles their starting and ending. I really don't want to mess with all that old code in WideClient at this time. I am planning a new Lua plug-in library for FSUIPC and WideClient which will be much more flexible, allowing programs to be started, stopped, brought to the fore, minimized, etc etc. This is planned but currently delayed by more pressing matters. I hope to include it well before Christmas though. ;-) Regards Pete

Unfortunately "latest" does not define the version. Do you really mean FSUIPC 3.998c or 4.733, and WideClient 6.899, as available in the Download Links subforum? I've no idea from "latest" if you are using FSUIPC3 or FSUIPC4 -- though I see you provided logs which do give me version numbers. Thank you. Why "admin rights"? You shouldn't need that. Google translates that to The instruction at 0x0000004 referenced memory 0x738a3f1d. The operation could not be performed in memory. Click on OK to terminate the program which is certainly very odd because no programs have instructions at memory address 4, even virtually. I don't know. It could be. WideClient is quite good, but not perfect, at protecting itself from bad data from applications. Look at the FSUIPC interfacing programs are you using. The log shows just these three: 2636 New Client Application: "ASv6" (Id=5908) 13915 New Client Application: "FSRealTime" (Id=4624) 18486 New Client Application: "FSC" (Id=2380) We need a process of elimination. Try not running one of them, and use three runs to see whether it only happens when a specific add-on is running. Then we can switch on more logging to find out more.. But first go get the latest Wideclient from Download Links so we are looking at the same code. Regards Pete