Pete Dowson

It isn't the same -- the earlier problem was a "Connection Refused" not a "Connection Timed-Out". I haven't seen Windows report that before. However, you are using very old versions of both FSUIPC and WideFS. Sorry, but I cannot possibly support those. Please first upgrade to the current released -- 3.48 for FSUIPC and 6.47 for WideFS. Don't forget to change both Client and Server parts of WideFS. If you still have a problem you need to show both logs -- WideClient and WideServer. Regards, Pete

That's true on the 9-pin connector at the PC. You should also link to the common or ground pin -- pin 5 and/or pin 1 (pin 1 is usual for the shielding if any). I'm afraid I've no idea about Ipag connectors, but if you use a proper Ipag serial port sync cable you shouldn't need to know. The normal sync operation must have the correct lines hooked up. GPSout doesn't need FSUIPC to work with FS2004. Regards, Pete

I'd need to reproduce it first, and it is behaving correctly here. You are now using 3.48, aren't you? I can't possibly check older versions, and it isn't worth it in any case. If you are getting odd behaviour with FSUIPC 3.48 please show me the Joystick Calibration section of the FSUIPC.INI. Also read out to me the Aircraft name and flaps increment in the FSUIPC options page. Please also try several different default aircraft and see what results you get for each. When I'm trying to find something I can't reproduce here I need as much information as I can get. Thanks. Regards, Pete

And do they work with the flaps gauge in the default FS panel? Test in FS first. PM's flaps relationships are defined in its own aircraft files, which you may need to edit. Regards, Pete

This is the window with only Name and Key, right? The correct entry for gauges is the complete name including the .gau part -- you only omit .exe. There are some others who have had problems with this gauge. I think it is written in a most unusual way. I cannot make it fail here on any of several machines, and most find it works. One person who had a problem found it was something else interfering, but I'm sorry I don't recall the details. The threads about this are all here -- search for F16 and see what you come up with. There are some other Freeware TCAS gauges which work flawlessly -- the Lee Hetherington ones, for example. (ILH_TCAS I think). It will with a registered FSUIPC 3. The problem is in the initial access method being used by this specific gauge which seems to cause problems in certain circumstance which have never been nailed down I'm afraid. Regards, Pete

Those are serious errors. The data blocks are getting corrupted. The last time I had anything like that happen it eventually turned out to be a failing Ethernet interface card. You need to do a process of elimination to find the culprit. Software causes could include simple things like a shared IRQ -- I don't know how good Win2000 is at doing this, but most Windows versions until recent XP updates were pretty bad, especially when you got an Ethernet adapter and a video card on the same IRQ. To get a different IRQ you may need to move the card. If it's a motherboard chipset interface then that's a problem. My source of help in matters Network is Katy Pluta. You can find here over in the FS2004 Forum. Else all I know is already written in the WideFS document. Regards, Pete

Actually, you are quite welcome to write a replacement for FSUIPC -- I need to consider retiring one day. Interfacing other sims to the FSUIPC type of interface has been done before, for instance there's one for the 747 PS1 sim, and it was partially done for an earlier version of X-Plane. The latter interfaced to the FSUIPC interface to WideClient on the X-plane machine, to a free-standing WideServer replacement called IPCserver, whose job it is merely to maintain the store of data for Wideclients (and local apps) to handle. IPCserver effectively contains WideServer, an FSUIPC interface, and, as a bonus, GPSout as well. For more details of IPCserver you'd need to contact Enrico Schiratti at Project Magenta, as the program was his idea and developed for him as a one-off job. I don't know if he'd be interested is some sort of licensing deal. You can do it like that if you offer an interface compatible with FSUIPC, but this would only serve programs on the same PC. You'd then presumably be interested in a networking variant, which is effectively what WideFS provides for FS. Regards, Pete

Well, that narrows the change in which the error occurred a little. Thanks. I should get to it next week. Sorry about the delay. Pete

I understand, but if it works in FSUIPC I can add it to WideClient. If it doesn't work, there's no point. See? In that case nor would MINIMIZE or MAXIMIZE -- the program evidently doesn't use the initial window state provided. Well, frankly too, there's not going to be those extra keywords since you've now confirmed that it won't work in any case. :wink: Regards, Pete

If disabling your joystick fixes everything then it sounds like you have an uncalibrated joystick and/or other joystick inputs enabled in FS. Go through all the axis assignments in FS and make sure there's only one assignment per control (if you have more than one joystick connected FS will attempt to assign them all). Then, when you are sure there's only one of everything, calibrate all the axes in the standard Windows way. Check the wind -- which direction is it from? If you are veering without the joysticks enabled then it's either wind or an excessive "P-factor" -- reduce realism to about centre for such aircraft. If it is caused by sidewind, either find a runway which has less or use rudder and into wind aileron to compensate. If you have a user-registered FSUIPC you can use the taxi wind option instead. Regards Pete

Ah! That simple, eh? Yes, if it doesn't intercept the main throttle it cannot map them to the other four. In fact, I thought I hid the "Map to 4 throttles" option when the throttle isn't enabled there, but maybe that change was later than 2.97. Regards, Pete

For Project Magenta there are FAQs and hints on their website. Apart from that and the documentation with WideFS (which you can read in the ZIP whether you buy it or not) I don't know of anything else specific that way. You can always ask questions here, or, better for PM, in the PM newsgroup. Regards, Pete

Project Magenta needs WideFS for sure -- it is theoretically possible to run it all one one PC, but not advisable. You can buy FSUIPC and WideFS keys from Project Magenta at the same time as you purchase their software. The GPS units included with FS are FS gauges and will not run on a second computer. Frame rates of FS are dependent upon the FS configuration. WideFS doesn't affect that, though it is often better to limit FS rates to a value which suits the other PCs on the network, so they all run at similar rates. This really only applies if one or more of the PCs are running near their limits, or the Network is slow -- modern Ethernet networks should give you 100 mbps which is fine. Regards, Pete

I assume the throttle is already calibrated and can be seen working in the single throttle page? If the input from the throttle through FS isn't working you cannot calibrate in FSUIPC in any case. In particular check that the sensitivity in FS is not zero. Since there have been no changes in 2.9x, and never will be, this can only be a case of corruption -- either the program (restore from backup) or more likely the INI file. For the latter either delete the INI file and let FSUIPC make another, or edit it and delete the joystick entries for throttle, or possibly all of the calibrations. If you keep a safe copy of the INI and simply delete it and check again it will prove where the error lies. Regards Pete

Why is that? Isn't the documentation clear enough? Well, that is more a button or FS control type thing. The FSUIPC interface allows you to read and write radio frequencies, both active and standby, so you could of course read them (as you would need to to display the settings), increment/decrement or otherwise change them as you want, and re-write them. That's one way. Otherwise, INC/DEC controls are provided for all these things. These ask FS or FSUIPC to make the changes for you. You can send any controls via offset 3110. FS controls are listed in the list of FS controls (in the SDK), and FSUIPC controls are listed in the FSUIPC Advanced User's guide. Either. In general you would be better off incrementing and setting into FS the value you last displayed locally, only re-reading it from FS when the rotary adjustment has stopped for a while (half a second or so). That way you would get much more responsiveness. You can merely send a stream of INC or DEC controls, but you'll get queuing and therefore latency in the resulting values and displays. Regards, Pete

Does that work with the programs you are needing to do this with? I think those short-cut initialisation options only work if the programs themselves tell their window to use the default setting -- Windows supplies the default to the program's WinMain() function as the 4th parameter. I think it would work if all programs used that, but most I tried don't. If it does work with the one's you are needing, then maybe it would be worth putting it into FSUIPC/WideClient. When I was experimenting I found it so inconsistent (because of varying practices in the applications) that I didn't go further because of the support implications of this variability. Oh, one other possible reason it wouldn't be useful -- the option to set this only applies to the first window created by the new process -- it won't be useful in cases like the PM modules where the first window is a trademark/banner graphic. Have you tried using the "HIDE" option in the FSUIPC Run options? If that works, then so should MAX and MIN if I add them. With Wideclient it would need an extra keyword immediately after the = I think. Regards, Pete

Ah. I'm afraid whatever is doing this, a GAUge or DLL, is using an incorrect way to interface to FSUIPC. Internal programs such as gauges and modules are provided with an efficient direct interface to FSUIPC inside FS, and they always have been right back to FS2000 nearly six years ago. The way this program is accessing FSUIPC is rather inefficient, and it can cause problems with other internal programs too. There is no way I can determine what it is because the interface it uses doesn't tell me -- it looks like an external EXE program but it isn't, so I just see FS9 itself as the caller. Sorry. This may work okay with a fully user registered FSUIPC, provided you don't get any other conflicting add-ons or add-ins, but there's no way at all to get it registered as a freeware or even payware application. If it is a maintained product I suggest you ask the author to look at changing it to use FSUIPC correctly. If it is long dead, as I suspect, then all I can suggest is either find an alternative which is written correctly, or purchase an FSUIPC user registration and hope that no conflicts with this program will arise in future. Regards, Pete

Do you know how I could do that? I did do lots of experiments with that when I first designed the options. Applications seem to start either they way they are programmed, or configured, to start, unless they are specifically programmed to start in the mode Windows 'remembers' them from before or has set in the shortcut (where applicable). I think the only way for me to override that is to wait until they produce a Window then send a minimise message. The problems are then rather considerable, because (a) programs take an enormously variable time to produce their Window and be ready to minimise (should I keep checking every few minutes?), and (b) very often the first such Window they produce is not the one which needs minimising. All the PM modules are like that, for example. Can't you configure them to start minimised instead? Regards, Pete

Versions "under 3" never needed a "code" (I assume here you mean 'key'), so that cannot be right. Registration was not introduced till version 3 of FSUIPC. The keys for Version 3 apply to ALL version 3's, from 3.00 in July 2003 to 3.48 now. The key for that gauge is listed in the freeware keys list in this Forum in any case, as I said before. You seem to be getting yourself rather confused -- please review the earlier messages. Regards, Pete

No, if this is all on the FS PC it is all automatic. The only problems which occur that way is when the user key you registered with isn't right or possibly expired. Please load up FS, reproduce the problem, then close FS down. Find the files FSUIPC.LOG and FSUIPC.KEY in the FS Modules folder, Zip them up and send them to me at petedowson@btconnect.com, and I'll check things out. Regards, Pete

Does it? Even with the name and key entered correctly? The FSUIPC.LOG file (also in the FS Modules folder) is a text file and may contain messages indicating what exactly is not functional -- maybe there's another part of that panel which needs registration? Last time I checked 1 US$ = 0.777 Euros, 1 Euro = 1.286 US$. At least you don't have to pay the V.A.T. on top if you are outside Europe! :wink: Regards, Pete

It is really Eric's job to support his software. He could, if he wished, change his code and build in the key so that his users don't have any hassle. Most freeware authors do. Then FSUIPC remains pretty much invisible to them and it all works smoothly. For those who don't, you have to enter the key manually. Look near the top of this forum for the Freeware Keys list. That gauge is there. In FS, go to FSUIPC options (Modules menu, FSUIPC), find the "register an application" button (bottom right), click it, enter the name (F16.gau) and the key. If you still have problems and Eric won't help I suggest you find a freeware TCAS gauge which does do it automatically, such as those by Lee Hetherington (ILH ...). Sorry but I cannot really undertake to support users of all programs which use FSUIPC. I don't even know most of them. Regards, Pete

I don't supply any old versions, let alone version 2 (which won't run on FS2004 BTW). In any case, you do not need to pay for FSUIPC to run applications. Freeware programs have free access, payware programs normally have a license. You pay only if you want to make use of all of the extra user facilities. Please download Version 3 and read the User document, or at least browse it. Maybe you'll then see how the scheme works a bit better. FSUIPC never went truly payware at all -- the original FS6IPC function (developed for FS95 and FS98) still operates in FSUIPC on the original principles, it just offers more powerful application facilities year by year. Regards, Pete

All the Windows Sockets documentation says about that is: So it sounds like either the Server wasn't running, or it isn't registered, or the Client is addressing the wrong server or the protocols don't match or there's some blockage between them. That's about all I know. It becomes a matter of eliminating each possibility till you find it. Regards, Pete