Pete Dowson

This can only happen if the values are decreasing. Each successive detente must have a pair of values higher than the preceding pair. Most axes need reversing before using as flaps, unless you want the lever working in the reverse direction to those in the aircraft. Are you sure you did this? You cannot set notch #2 with lower values than notch #1. It would do that if the values were impossible, but certainly not otherwise. Show me what you tried to set. It does sound to me exactly as if you are trying to assign everything in reverse order, of values, which cannot be done. flap values must increase from up to down. I've just tried exactly what you said you did here, but with the Rev option selection first, to get the orientation correct, and it works fine. If you still cannot operate it, please show me the values -- the ones you tried to set manually sshould tell me where the misunderstanding lies. BTW if you want to make editing changes in the INI file, for any of the Buttons, Keys, Axes or JoystickCalibration sections, you can do so without closing FS, and then just tell FSUIPC to reload that section -- there are Reload buttons for each. Regards Pete

Does FS actually simulate that? I didn't know that. I assumed the "Toggle Alternate Static" control just operated the Engine ones, according to the currently selected engines. Hmmm. Looking now i see there is, in SimConnect, a separate value I can read: "ALTERNATE STATIC SOURCE OPEN". It must be the one controlled by that toggle control. So I could add this to FSUIPC4 as a new read/write offset. However, I cannot do it in FS9 and before, as there's no obvious sign of it in the data I've already "hacked out" of those older versions, and I'm not going to start again on that sort of thing now! ;-) Regards Pete

Well if the client log hasn't changed since the last one you posted, the broadcasts from the server still aren't reaching the client. For an otherwise working network the only cause of that I'm aware of is that they are in different workgroups. You have an INTERNAL firewall on a router? Phew. Never heard of one of those. Why use the Server IP address? Use the ServerName -- it is much easier and more flexible, in case your server IP address changes (or is masked by your very clever sounding router). If that doesn't work then I'm sorry but you will need some expert help from someone who knows about Networks. There's absolutely nothing special or clever about how WideFS uses the network, it is a direct copy of Microsoft examples. You do actually need to have a working network first. Evidently at present neither port 9002 (for Broadcasts) nor 8002 (for data exchanges) can connect between the two PCs. I assume you have other networking needs sorted? Regards Pete

Yes. My own systems run FSX on Vista SP1 and all my clients are on XP SP2. Make sure the workgroup name is the same on both -- I always name mine "PETES" in any case, but if you leave them to default I think Vista chooses a different name tp XP. It doesn't affect networking except in a few places, such as Broadcasts, and WideFS uses Broadcasts from the Server to save you having to configure the Clients. Regards Pete

Every firewall? How many did you have? Well, almost. The current official release of Wideclient is 6.78, and has been for a couple of weeks or so. There's also a later one in the Announcements above. But no matter, the differences won't affect this. The logs show that the Broadcasts from the Server are not reaching the Client. This is usually because you have the two computers in different WorkGroups. Make sure you name the workgroup the same in both machines. After all, you want them to work together, no? Working together should mean they are both in the same group. See? Alternatively, but not the best solution, you can do as the documentation suggests (you didn't think of looking there at all, perhaps?), and that is: add parameters to the WideClient INI to tell it the name of the Server and the Protocol you want to use. This obviates the need for the computers to be on the same workgroup -- but it isn't the best way to do it. Regards Pete

Which offset is it in the FSX offsets list, then? That control seems to appear in the FS2004 list as well as the FSX list, so why do you think it is new? I simply searched for the word "alternate" in both the FS2004 offsets list ("FSUIPC for Programmers", and also in the FSX offsets list ("FSUIPC4 offsets status") and found Engine 4's alternate air at 35C0, Engine 3's at 3680, engine 2's at 3740 and engine 1's at 3800. What method of searching are you using that failed so well? FSInterrogate only lists what the documentation lists, at best. The FSI file is, sadly, often out of date. What were you expecting it to do extra? Even when there is no working offset, if there's a control you can always send that, using offset 3110. That's what it is for! Regards Pete

Good. Carry on programming, then! ;-) Pete

Sorry I don't understand the question. What DLL and what CFG files? What links? What do you mean "declare aircraft"? I'm lost. :-( If you have general questions on how to manage add-ons in FS, I think it will be better for you to post them in the general FS2004 or FSX Forum. I really can only help specifically with the use of my own programs. That's what this Forum is for. regards Pete

Using anything of mine? Sorry, I'm not clear whether you are still asking for my help or not? Regards Pete

Thanks for letting me know. I'll get it changed before the next Release. Regards Pete

Those versions are really very very much out of date and totally unsupported. Please update before asking for support. If you look at the Announcements at the top of this forum it does keep you abreast of these things. Regards Pete

I hope that's just a mistype for "Windows\WinSxS"! Er, you said "SxS" again, so not a typo? The correct folders are like this (maybe not exactly like this, but this general form: WINDOWS\WinSxS\x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.61259.0_x-ww_fb842f5a That's my one for the SP2/Acceleration version. There are two others. All three each contain just a "SimConnect.dll". It sounds like somehow you've got the SimConnect.dll(s) moved out of their correct folders. That's a big no-no. You also don't want any copies outside, even if they also in their correct places. Regards Pete

You evidently have windows set to hide the filenames from you when it thinks it knows what type they are. It classifies LOG files as text files (I think) and INI files as "configuration settings" or similar. If you really ever want to understand more about files you really need to turn that option off. Yes, it is, which is good. and it shows what the problem is: That's the first time I've seen this check triggered, and I see the message is not quite correct (you mustn't delete the FSX.EXE, but the SimConnect file incorrectly placed somewhere where Windows is accessing it instead of via the Side-by-Side library system, as it should. That is probably one of these three places: 1. FSX folder 2. FSX Modules folder (unlikely) 3. Windows folder(s) -- in the main Windows folder or the System or System32 subfolders. Please check these places at least, or posssibly do a complete file search for "SimConnect.dll" or anything ending with that. There should only be three, in WinSxS folders, and possibly some in your SDK folders if you've installed the FSX SDK. No where else, and most certainly no where else where it may be picked up by FSX and used! Ouch. That probably explains it then! How did they get into your Windows System folder? They must ONLY be in their respective WinSxS folders, the ones with very long names. You've defeated the fiendishly clever side-by-side library system Microsoft are using! Meanwhile I'll do some experiments, see if I can identify the folder more accurately when this error occurs again. It looks like when I try to ask Windows for the folder containing the SimConnect.DLL file it has loaded it gives me FSX.EXE instead (i.e. the folder of the process I am in). That's not what I wanted at all! :-( Regards Pete

Whoa. Let's go back on that first. There are TWO (2) central values but you only give one here. Are they both 0? They should not be the same! You should always calibrate with a little bit of leeway in the centre. i have not yet found a yoke, and few joysticks, which always give exactly the one same value every time they are allowed to return to their central position! Similarly you should always set the minimum and maximum calibration values to something less than the full extremes you can reach with the yoke, just to be sure that, with some variation, you can still get there. I'm pretty sure it does clearly tell you to do these things in the numbered steps in the User Guide. They are quite important for good calibration for consistent use of any analogue input. Why? Filtering is a last reort for badly behaved controls, ones with lots of jitter brought about, usually, by poor unsmoothed power supplies in far off places. In fact the filtering was first added specifically for a user somewhere in the wilds of some South East Asian jungle I seem to recall! . Filtering does tend to slow response down a tad. It shouldn't be noticeable, but I suppose it could sometimes become so depending on other things. It works be reading several values and trying to eliminate blips. The values you get out are actually computed based on the last so-many values. If you are assigning axes in FSUIPC and have the default "Delta" set then filtering could be worse because the Delta stops similar values being sent through to the filter mechanism, so it cannot smooth so quickly in any case. Tell me why you enabled filtering and I'll maybe suggest an alternative solution for whatever problem it was which caused you to do it. Not sure why that would create "sluggish" controls (after all, the range 28553 is a good 89% of the full range 32000 you had in any case, surely hardly enough to make then feel "sluggish"). So maybe there's more than one thing going on -- few or feeble data arriving from the device. Not so extreme, no. All devices give some variation, and you should allow for it in the calibration (which i fear you have not). Certainly do that, and turn off the filtering, and try again. But I can't see how any of the things you can do in software can deal with such an extreme variability. The "IN" values you see are the actual values being read -- or they would be if you turn off the filtering. So the cause has to either be the axis, the device, or possibly the USB port -- or its power supply? Most analogue axes are measured using a DtoA system which is very voltage sensitive. If you are using a hub, could that be a problem? If it is a USB port on the motherboard, could your loading, from all the simming and graphics and cooling fan activity, be pulling down any of the voltages? And when you pause, relieve the loading, they creep up again? Do you have any way of checking it? Outside of the device itself, the PC's power supply would be my first thoughts. Maybe as the voltage drops slightly some things are affected first -- maybe the aileron axis is affected first or more than the others simply because of the order and timing of things. I'm guessing here, just trying to suggest things that might be worth looking at. Okay, so that makes some of what i say above less severe, but possibly more puzzling, as the filtering should therefore not have such an impact. Switch it off in any case when measuring, so you KNOW the IN value is the value you are truly getting (in this case, from FS, not from my readings). Also, of course, make sure FS's sensitivity slider is at max (full right) and its null zone slider at min (full left). Regards Pete

Repeating things rarely changes them. Something almost always needs fixing or changing first. As you surmised and stated, the install was perfect. No problems there. First we need to ascertain whether FSUIPC4 is even being run. Is there an FSUIPC4.LOG and FSUIPC4.INI file in the FSX Modules folder? If so, please show me the FSUIPC4.LOG file. If not, then FSUIPC4 is not being run, so it isn't being loaded. That would either mean some sort of SimConnect problem, or that you've somehow placed my name on the 2untrusted publishers" list. Let's take the first step first. Pete

Are you reporting a new problem here? Seems odd to start off simply saying 2here are all the logs". Version 4.40 is the currently supported version. The FSUIPC4 log is incomplete. NEVER send logs when FS is still running. Please ALWAYS close FS first. Valuable information is added to the end of the logs when you close FS. Is that IP address correct? The client is receiving Broadcasts from the Server, but it is unable to transmit anything back. I strongly suspect you have a firewall blocking it. Why have FSX on the Client? You cannot use WideFS between two copies of FS. Why are you re-installing when nothing is changed? Replacing a copy of a file by an identical copy makes no difference. you have to unblock your network. Regards Pete

Hmm. Maybe some of the UDP transfers are actually faulty but since there are no checks on UDP those are simply ignored, whilst TCP is all thoroughly checked so any faults would generate a failure. It may appear to be working most of the time. Maybe you don't notice the times when it is missing bits. Regards Pete

It certainly sounds like your problem was due to Vista's default firewall then. Evidently you didn't switch it off or enable WideClient to receive stuff on port 8002. There is no protocol "TPC". Maybe you are thinking of "TCP"? The TCP/IP protocol set includes both TCP and UDP. They work identically except that UDP has a little less "red tape" (administrative information) and has no checking -- packets sent by UDP are not guaranteed (unlike TCP ones) and can arrive out of order. Otherwise UDP is recommended as being faster and applying less load on both PCs. I use it all the time -- it is fine on a good network, as the problems of lack of checking only arise when something is wrong. With WideFS you should not need to specify either the Server name, or IP address, nor the Protocol, as the Server provides all that information in its broadcasts. ("ProtocolPreferred=" in the Server's INI). If you could only get it working by adding parameters to WideClient.INI then you have something else wrong -- probably you are not using the same WorkGroup name in both PCs. Regards Pete

What "SET boxes"? There are 6 boxes showing values for every centred axis. I've no idea which ones you mean. IN/OUT, Min, Centre/Centre, Max? That sounds like you are talking about the "OUT" value. But that doesn't relate at all to what you say next: Now this is totally confusing, meaningless without saying where tyou see what. If "after calibration the deflection was +-16something" why did you expect it to be "0,0", wherever you might be looking for that? Where are you reading these values and ranges? Sorry, I still cannot imagine where you are seeing either of these pairs of values. If you could describe them rather more accurately than "SET boxes", which is meaningless -- there are 6 "set boxes", or rather boxes with values in. Each has a defined purpose, a defined name or heading. Can you find that and use it, please? Thanks. Regards Pete

If you write a program which runs under Windows, you are a Windows programmer. Your program must be littered with things that call Windows API's, surely. Even the interface to FSUIPC is solely composed of calls into Windows. Just type SetFocus in your help or MSDN or whatever, or in Google if necessary. I'm sure it is accessible in any language you might use to write programs under Windows. Regards Pete

You simply change any of the 288 bits in the 9 32 bit double words starting at offset 3340. Each of those bits is a virtual button! That's it. That is ALL your program has to do! When you change a bit there from 0 to 1 that button will turn "on" and you can program it in FSUIPC's "Button and Switches" options, in FS. They are seen as joysticks 64 to 73, buttons 0 to 31 on each. 32 x 9 = 288. I have told you most of this before. You seem not to be reading what i write! If you don't understand why not just say so and say what it is you don't understand rather than merely repeating the same thing all the time? Macro numbers? What are "macro numbers"? I have no "macro numbers" and there is no such list. And what is a "virtual example". That makes no sense. There are examples of using the FSUIPC interface to access FSUIPC offsets, to use FSUIPC read and write actions. Please tell me what you are looking at, because it does not sound anything like the FSUIPC SDK I publish! The FSUIPC SDK contains documentation for all of the offsets, plus sources of the C interface library, and examples of interfacing to FSUIPC in Visual Basic and several other languages. If you don't see these things you are looking at the wrong file completely. I'm afraid have no idea what you mean by "macro numbers". Regards Pete

Maybe. I'll have to think about it. Something for after Christmas, possibly. [LATER] One of the complications I foresee is how to store the relationship between aircraft name and the assignment/calibration class you want for it. Probably a parameter line in the INI file for each one. Otherwise the FSUIPC "class" could be added to the aircraft config file. Ugh. Pete

If they are all assigned in FSUIPC, disabled in FS, then the aircraft-specific option will do the trick, because FSUIPC will only scan those devices you've specifically assigned for each aircraft (or group of aircraft if you use the ShortAircraftNameOk option as described in one of the documentation appendices. It is actually possible to have several controllers connected and assigned for the same functions, but two problems can then arise: 1. As you suspect, one might interfere or override the other, especially if they do not give rock-steady values (inputs are only used when they change, except for POVs). One way around this is to calibrate them with wide enough space in the natural "parking position" (idle for throttles, centre for aileron, elevator, rudder). 2. FSUIPC only offers one set of calibration values for each FS control input, so if you have two aileron controllers, for example, the calibration settings, if they are both assigned) would be the same. If there was a lot of difference in the input values -- particularly the centre, as min/max should be sorted okay by Windows calibration -- the you might get horrible results when using one or the other. Calibrating for two completely difference input ranges is not possible, obviously. Aircraft-specific assignment gets around both of these problems as FSUIPC will simply only be scanning the axes assigned for the current aircraft. You'd also be amking aircraft-specific calibrations too, and presumably button assignments. Well it is covered by documentation. It is surprising how much quicker it usually is, for most products, to simply read the supplied documentation rather than going to the products technical support. Sometimes I wish I could find some time to enjoy flight simming! It is why I try to make sure the documentation is complete, to reduce the technical support workload. And it does work, but not as well as I might wish. :-( Regards Pete

First thing wrong is that you are using an unsupported version of FSUIPC. Version 4.20 is two full user versions out of date. The current one is 4.40. Please review the Announcements at the top of this forum. Secondly, you've posted a lot of files (or, rather, several copies of the same two files), most of which were not requested, but unfortunately you did not post the most important one of all, the "Install FSUIPC4" log file, which is certainly there (as you listed it), and I did explicitly ask for it. Lastly, whilst without the Install file I cannot be sure, but from this: It appears as if you've not updated FSX from the original release (and I'd advise you to install both SP1 and SP2 as they fix a lot of problems in FSX), but you have some SimConnect installation error in any case. Have you had occasion to re-install FSX at all? That does seem to be rather precarious, and messes many folks systems up. OR have you been copying a "SimConnect.DLL" file anywhere? I've seen that error when folks have attempted to fix Windows side-by-side problems by trying to move files. It doesn't work. I'd recommend four things, in order: 1. Follow the instructions given in the "FSX Help" announcement above to repairing SimConnect (not logging). 2. Install FSUIPC 4.40, to get yourself up to date there. Then check that everything is okay, before: 3. Install FSX SP1, and check okay again. 4. Install FSX SP2, and check okay again. If you intend to get Acceleration, then do that and install it instead of steps 3 and 4. Regards Pete

I don't deal with sales, but there are plenty of ways to pay detailed on the SimMarket website - and, in fact, printed on an early page in the FSUIPC user guide. Regards Pete