Pete Dowson

No you do not! Just go to the Modules folder and check it. That message doesn't even exist in the current versions, and hasn't for a long time. That message is from a version of FSUIPC preceding the FS9.1 update. It is merely telling you that it doesn't recognise 9.1 and so cannot run. you either need to uninstall the 9.1 update and go back to the stated original release of FS9, or, better, update your FSUIPC. The only supported versions of FSUIPC3 at present are 3.81 and later. Your "Captain Sim" install is overwriting your later FSUIPC (quite wrongly, it is evidently a very poor installer), and, as the Captain Sim package is much older than FS9.1 it has a very old version of FSUIPC packaged with it. Please ALWAYS check your version of FSUIPC before asking for support. It is easy enough to do -- find the module in the Modules folder, right click on it and select Properties-Version. Pete

I don't know how it can be "from time to time"! Either it checks or it doesn't. A DLL doesn't alter itself back and forth -- perhaps you have some sort of intermittent hardware problem, like dodgy memory? Sorry, I really know nothing about that valueI just quoted some help from elsewhere, from Lefteris of PMDG I think. You may need Microsoft support if it isn't a hardware fault. Regards Pete

Can you save that copy of FSUIPC4.INI (so you can go back to it) and change them all to use the FS controls (you should still find everything you need, unless you are using FSUIPC's separate Reverser axes which don't exist in FSX). Then see if you still get the crash with both processors in use. Phew! That's some system you've got there! Do you get the crash with affiinity mask set to 1 instead of 2? (Just to eliminate a processor problem as such). Regards Pete

Hmmm. where do you find that info? I suspect mine is older. I don't think I have access to their downloads system at all, so I'd need to ask them. Maybe they have changed something and never thought to re-check it in turbulence. Pete

You may like to know that I've devised a way for multiple axes assigned to the same FS function via FSUIPC4's axis assignments, direct to FSUIPC calibratiion, to be arbitrated just like those using the special control number assignments facility. The maximum deflection is the one which is used, but the check is only performed when a change occurs on an axis. So once one axis is used instead of another, it remains in use for that function provided that the others assigned to the same function are either quiescent, or only provide values of less significance than the last one from the current axis. This avoids the need to assign larger "delta" values to stop jitter interference from the axes currently not being used. They simply need to stay "parked" (centred for control axes like aileron, elevator, rudder and their trims, full off for axes like throttles, spoilers, flaps, mixture and prop pitch). I've also changed the way the "Direct to FSUIPC" assignment works, to avoid using simconnect altogether, on the assumption that this is responsible for some of the problems reported in a parallel thread near here. Look for a new release in the FSX Downloads announcement above in a day or two, after I've tested it thoroughly. Regards Pete

Are you saying this is also only with axis assignments in FSUIPC "direct" to FSUIPC calibration, and not otherwise? Otherwise that sounds like a completely different thing altogether, and more likely related to a problem with your processor or motherboard. What about an affinity mask of 1 (to force the other processor to be used)? Maybe one of your processors is flakey? Only if the Intel microprogramming which handles the processor switches is broken or the hardware is flakey. I really wouldn't think there's anything in FSX which'll be having anything to do with that. The use of multiple processors in FSX is enabled by multi-threading, but its up to the hardware and microcode behind it to deal with the complications. Regards Pete

Yes, its the divisors which control the speed of the changes -- they set the number of increments approaching each computed target. Well, with 100 it should take 5 times as long for the computed targets to be reached -- the increments will be that much smaller. I can't really control that exactly as it has to be in-line with the FSX SIM code, not in a separate thread, and I am dependent upon SimConnect calls for synchronising. The timing is only controlled by assuming I'm being called often enough and then limiting things based on elapsed time since the last update. The evenness of the updates is then obtained by altering the increments according to how long it was since the last. You can see this in operation in the FSUIPC4.LOG if you enable the Smoothing logging. To do this add: Debug=Please LogExtras=512 to the [General] section of the INI file. The log will become pretty big, but it will log the increments it is using, as they are computed. Maybe, but it is odd consdidering it was they who most thoroughly tested my algorithms for me, and approved them. Maybe something got chasnged their end in some recent update? Has there been one? I've not purchased the thing myself (no use for it in a hardware cockpit) but I have one version they supplied for my testing only. But it is also odd that it seems fine here. but as I say, my version of the 747 may be out of date? Is there any way I can tell? Well that would be the same as FSUIPC3 wind smoothing + FS2004. Regards Pete

But 4.285 also had that same change, so FSUIPC wasn't interfering with FS's weather when ASX was running, and therefore its "suppress cloud turbulence" shouldn't have had any affect at all on ASX's options. Yes, but that wasn't relevant to the difference with FSUIPC trying to manipulate ASX's weather. So you've not actually tried or had any wind turbulence? The point is, if you look up through the thread, that folks have been saying the wind turbulence is okay, it's only the cloud turbulence with a problem. and this is where is gets silly, because they are not differentiable anywhere in my code! They are the same, the same code, the one entry point from both causes. The changes underlying the ones you see are at about 3-4 times the frame rate and the 2 knots changes, whatever, will be arrived at through many small increments (as per the parameters). When you say "changing rapidly" how do you mean? If they are slow enough to be seen on screen, they are probably as they should be. Let me play with these (in addition to trying the 4.287 build) and see if I can't conjure up a better result. Okay, but it worries me that the parameters I ended up with were the result of a lot of testing and feedback from PMDG, and they were very pleased with the end results which they said were realistic. I really would hate to mess that up for the majority for the sake of a few who seem to have problems for, so far, unknown reasons. I would like to know what is affecting the few so adversely. The fact that they see a difference in cloud vs wind turbulence is the really mysterious part. Regards Pete

Phew! That is restrictive! Thanks Pete

In that case it is almost certainly going to be your firewalls. Try disabling them both as a test. If that fixes it but you need the firewalls up then you'll need to get Wideclient and FSX permissions. Sorry, I'm not sure how to do that -- I have a router protecting my Network from the outside world and don't like firewalls stopping me talking to me! ;-) Pete

Do you have the option in FSUIPC checked to allow FSX's weather to be changed? It sounds as if you must, because otherwise it cannot inflcuence ASX's weather. This issue would be rather clearer for me if you were to first update to the current FSUIPC increment (4.287 at present, above), as this automatically suppresses FSUIPC's interference in ASX's weather when the latter is running. But the turbulence modelled by FSUIPC is identical for Cloud and Wind turbulence -- in fact it IS the exact same code. The changes are not "sudden" but spread using a Gaussian ("Normal") distribution. The maximum range of change is computed first, then random targets are computed. The targets follow a Normal distribution about the mean. Then the distance to that target is divided by a value (adjustable in the INI file) to provide an increment, and the values are changed by that increment at a frequency also adjustable in the INI file until the tasrget is attained, at which point another target is computed. This rather complex sounding system was derived from studies made by academics on how turbulence behaves, and the default parameters were tuned in cooperation with the PMDG 747 test pilot, as it was the PMDG 747 which seemed to be most sensitive to the results. The FSX turbulence was described by the 747 test pilot as rather unrealistic. In any case, the only reason I added the emulation in FSUIPC4 is that the wind smoothing removes most if not all of FSX's own turbulence. This was the same in FS2004 -- with FSUIPC's wind smoothing enabled you never ever got any turbulence. I was trying to do better in FSX, but I am starting to wish I'd never tried and left it as in FS2004. :-( Well, the 747 seems to cope reasonably well with it here except when it gets to "severe", and the effect is identical for cloud and wind turbulence (as one would expect with the same code operating it). As for "throttling" it, the parameters for this are as originally described in the release notes and now in the Advanced Users guide (see TurbulenceRate and TurbulenceDivisor). Although these are only listed under "Winds" they apply to both Cloud and Wind turbulence, as there is no difference internally -- the only difference is where the trigger comes from, a value in the Cloud parameters or in the Wind parameters (if both together the maximum of the two wins). Regards Pete

Were you assigning Axes in FSUIPC for "direct to FSUIPC calibration"? If not then I think it was a different issue, probably related to a SimConnect mis-installation. The thing in common with all these here is direct assignment. As soon as folks simply change the assignment, still in FSUIPC, to an equivalent FS control, it stops the problems. Regards Pete

Okay, yes please. I'm going at this full time as of now and need information. Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce the crash, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please? Also, as I've said elsewhere here, I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue. Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less. In the [Axes] section, set PollInterval=100 This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second). If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second). Thanks! Regards Pete

No, that's a crash. A hang is when nothing happens and you have to forcibly close FS using the Task Manager. Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce it, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please? I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue. Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less. In the [Axes] section, set PollInterval=100 This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second). If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second). Thanks! Regards Pete

It is under "Settings", but in the Options menu: see Settings then Controls then Assignments. Click the "Control Axes" tab and you'll see at least 5 throttle controls you can assign to, one generic one and one for each engine. The assignments system in FS should be far easier to understand than FSUIPC's as it was designed by professionals in the User Interface field, and has withstood the test of time over many FS releases. If in FS you cannot find out how to scroll down the list of controls you can assign to and select the throttle for each engine then I'm afraid FSUIPC will be a step too far for you. User Interface design isn't my strong point and it is not going to be anywhere near as easy to do as in FS. Pete

I need to see the WideServer log file from the FS PC and the WideClient log file from the client PC. That will tell all. That is a bit extreme and most certainly not advised if SimConnect is running okay. No connection for WideFS is nothing to do with SimConnect -- if the FSUIPC log shows no errors, and you have an FSUIPC menu entry in "Add-Ons" then SimConnect is fine. You'll do more damage than good messing about with SimConnect files unnecessarily. Didn't you once even think of looking at the Log files, which for all my programs is always where details of what is going on are placed? That is what they are for! I am using Vista64 Ultimate for FSX and my 8 clients are all on WinXP, and there certainly are no issues. You need to make sure the Network is working correctly first, and that you've either disabled the firewalls both ends or provided WideClient and FSX the needed permissions. It is also best if both (all) PCs are in the same Workgroup (i.e. the same named Network workgroup) -- if they aren't then you have to tell Wideclient the Server name and protocol to be used, as it will never receive the FSX PC's broadcasts. Regards Pete

These are hangs, not crashes like before? And only in missions, not free flight? I am trying to figure out some way of getting to the bottom of this, as I've been using direct assignment for everything since FSX started and cannot reproduce any problems. And I know the direct method is used by a lot of folks, so there must be something more to it than just that. some other factor. Pete

Can't you do it in FS itself? It provides the facilities too. For FSUIPC the best place to find out is in the User Guide. If you really don't want to use FS but FSUIPC instead, at least try to follow the instructions. By all means ask specific questions if you get stuck or don't understand something specifically, but i really cannot give more general instructions here that i do in the documentation, which is far more extensive and even has illustrations and simple steps! Pete

Sorry, I cannot support any such hardware directly. FSUIPC isn't a hardware driver. You need to use the driver for your phidgets board. Pete

Ah, right. 64 buttons is the directInput limit i'm aware of, so it is just using directInput I assume. FSUIPC could manage the same if I re-wrote all the button code to use DirectInput, but I fear most current users would need to reprogram their assignments. (things look different through directInput). And it is a very big job, not trivial, and something so seldom needed (very few devices ever have more than the 32 buttons I support in any case) that I really cannot justify the time involved, let alone the possible consequences in terms of reliability if it were not subjected to many months of alpha and beta testing. Regards Pete

That's okay. Sorry, no. It's going to be down to some combination of things which is causing this older SimConnect bug to activate. The log would show the details, I think. You could try a process of elimination, dropping one SimConnect component at a time. Start off with whatever you have running remotely, as that will certainly be using TCP/IP. Pete

"Any device" is far to broad a description. What you say cannot be true. I could go and build a device now, with any sort of parallel or serial interface, and unless I told the clever program how it worked, how to read it, how to interpret the signals, it could not read any buttons I connect to it. As a case in point, take the EPIC USB card -- it would most certainly not be able to read 112 of its 512 possible buttons unless it had specific code in to deal with the EPIC protocol. Perhaps you mean any standard xxxx interface device, where "xxxx" would need to be specified? Just a quick browse for "Mjoy16" in Google reveals comments like "Has anyone used the MJoy16 and the assiciated keyboard devices for their cockpit. I know I will need more than this (mainly for displays) but it looks like a great product at a great price combining 8 axis, 64 buttons, 16 toggles and 4 rotories in one USB device (and you can connect up to 4)." Now 8 axes, 64 buttons and so on is what I know as the DirectInput limit for a HID deviceare you perhaps getting to 112 by somehow adding up all these separate aspects? Even then, counting rotaries possibly as 2 each, I can only see 96 "things", not 112. Another site lists the capabilities of the MJoy16 application as follows: Main features of this MJoy16 Application C1 are: - 64 pushbuttons support - 16 double-action toggle switches support - 4 double-action rotary switches support for convenient frequency control - 1 8-position hatswitch - 2 controls mapping modes - Axes centering disabling possibility - Auto calibration - Additional support options for multiple MJoy16-C1 controllers on one computer Again, the 64 is the DirectInput limit I'm aware of. FSUIPC, of course, currently uses the standard Windows API where the limit is 32. It is possible, of course, that since I looked at DirectInput (DX8 times, for FS2004), the limits have been changed or even abolished. I really don't know. If this MJoy16 program states a specific need for a particular version that might be a clue. Regards Pete

Tried what too., exactly? You need to be more specific. You only described what happens in the FSUIPC dialogue, which is completely irrelevant. You have not once said you programmed it for the same action for both press and release, as I suggested, and nor have you stated anything about any results of doing so. If the dialogue detects the Click turning the button it sees from off to on, as you say it does, then FSUIPC, whilst running normally, will most certainly also see the "on to off". It cannot actually detect one without the other -- you will notice that it is a logical absurdity for it to be otherwise. Therefore, if you have, as you say, "tried" something, it most certainly cannot be what I suggested you try. You say "that knob works perfectly on other add-ons...", and it sounds, from what you've said, that it will work perfectly in FSUIPC. It is just that, unlike most other add-ons, FSUIPC is much more flexible, providing more options -- in this case a separate capability for switching off to that for switching on -- , and these are evidently confusing you! I'm sorry that I only do support in English, as I feel sure that the problem here must be one of communication, and perhaps English is not your natural tongue? Regards Pete

Not with EXE files. Most all email systems will filter them. This is a first -- no one else has ever not actually been able to extract the EXE from the ZIP in the 11 years of WideFS! Are you also saying you cannot see the EXE in the ZIP of WideClient (only), in the downloads announcements above? If so there is something seriously wrong -- it sounds like you have a virus checking package which is interfering severely with your downloads and removing EXE files it doesn't like. Maybe it sees part of the binary as a virus, that has been known, yet all my modules and EXEs are codesigned and guaranteed secure and free or such infections. Regards Pete

The WideClient.exe file is most certainly present in the WideFS.zip on the www.schiratti.com/dowson page (of Enrico Schiratti, not "of Pete"). I have just double-checked this myself. Maybe you are not recognising it because you have windows hiding filetypes? There is also no difference in the two WideFS 6.75 zip files presented there -- it is duplicated in both the FSX and FS2004 section precisely because there is no difference. There is also an updated WideClient available in the Downloads announcements above. Regards Pete