Pete Dowson

Well, there's no error other than the fact that the WideServer is never told about the Client, and the Client is told there's a timeout. Is the IPaddress correct? Why don't you use the Server name instead (GLAVNI), it is easier and avoids mistakes? Something is evidently blocking WideClient -- it isn't being allowed through to WideServer at all. The Windows error 10060 "connection timed out" is simply described in Microsoft documentation as "the connection failed because the connected party did not properly respond after a period of time". Fat lot of good that is! :( Check your settings for the Ethernet adaptors and the TCP/IP protocol. Check you have no third party firewall or other program interfering. There's nothing WideFS can do if the Windows software won't connect the two parts of the program. Really all I know is in the documentation -- have you been through all the possibilities listed there? If you cannot get anywhere with this I would advise seeking help from someone who knows about Networks. Try Katy Pluta over in the FS2004 Forum. She's always been helpful in this area. Regards, Pete

It's actually "Dowson" not Dawson. But either way I'm afaid I know nothing at all about Java. I hope someone else here may be able to help. Regards, Pete

Well, that's the trouble. It reflects more the state of the switch or lever -- its either zero or 16256. It doesn't appear to offer any intermediate values. Pete

No. Sorry, I've got that down for Tuesday. I'm working through a list! :wink: Pete

All I've managed to find is a value which indicates whether the water rudder is up or down. And you can write to it to operate it too. But I cannot find anything which shows it moving. That animation may be part of the modelling rather than a simulation engine value. I've mapped it in FSUIPC to offset 2A9E. It is a 16-bit wordk. When the rudder is raised it returns 0, when lowered it returns 16256 (an odd amount -- I wonder if it is aircraft-dependent?). Writing 16256 to this offset will lower the rudder, any other value raises it -- but I would recommend sticking to zero for this. This change is in the attached interim test version of FSUIPC, 3.481. Regards, Pete FSUIPC3481test.zip

I think I found a bug which could have made these co-pilot controls not work. I haven't time to test the fix here till later this week, and it will take a bit of setting up to get the extra inputs, so I wondered if you would like to try it with your configuration and let me know, please. The fix is in the attached test version 3.481. Regards, Pete FSUIPC3481test.zip

I assume they are not using the FS autopilot. FSUIPC has no way of detecting when some alternative A/P programming is controlling the aircraft. If aircraft developers choose to develop their own autopilots they need to take care to disconnect the trim axis themselves when it is engaged. They have probably overlooked the fact that FS does provide an analogue trim input which some folks take advantage of, whether through FSUIPC or otherwise. Regards, Pete

To reset the Zoom to 1x use the Zoom 1x control (this is assigned by default in FS to the backspace key). To reset the eyepoint, which is what you may be looking for, use Eyepoint Reset, which FS normally assigns to the Space bar. There is a View Reset control which should restore everything to actual view direction and zoom, but it doesn't appear to be connected up inside FS. Regards, Pete

There are no such functions in FS. Some add-on aircraft may have them, and certainly Project Magenta does, but they've never been part of any version of FS itself. You couldn't have done that in FS's assignments. The PMDG software provides its own assignments facility. You must have used that. The PMDG software is better than many add-on aircraft panels in that it allows keyboard assignments -- with some you can only use the mouse! Presumably the LDS767 also has a keyboard assignment facility -- the 767PIC product did too. Regards, Pete

Okay. Run the GFConfig program and set the Flaps lever to undefined. Run FS, check in Options-Controls-Assignments and if necessary allocate the lever to Flaps there. Go to sensitivities and set maximum sensitivity, and zero null zone. THEN go to FSUIPC and calibrate. It behaves perfectly here. In my GFConfig I have all six axes undefined and assign them all in FS and calibrate in FSUIPC. I can reproduce your symptoms by assigning Flaps in GFConfig and placing the GFdev2k4.dll in my Modules folder. What is happening is that the GFconfig program sets the DLL to read the axes and change the flaps directly. Obviously the points at which is does this conflicts with FSUIPC's calibrated points and you get nonsense. You have to use one or the other, not both. By de-assigning all axes in GFConfig you leave all the assignments to FS and all the fiddling to FSUIPC. I expect that will solve your reverse calibrations too, assuming you don't want to use the TQ6 button-levers for that (I don't think they work too well -- I did try them once). BTW I would hope that GoFlight support would be able to give you similar answers. Let me know if they don't and I'll copy Doyle. :wink: Regards, Pete

Sorry, the value is a 32-bit DWORD. You have to write all 4 bytes,so 15*65536 in your case, as documented. The control used to change the fuel does not accept 16-bit values. Almost all the values listed in the SDK have a length which is significant. There are some exceptions, for instance for BOOLEAN values which are either 0 or 1 -- you can usually then get away with writing just the low byte in those cases as the rest are all zero in any case. The reason for this is that it is the first byte, i.e. 0B7C in your example, which is the "token" for the variable you want to change, and it is this which triggers the action from FSUIPC. Regards, Pete

I have no record of an ILH_TCAS2 gauge. No one has ever applied for a key for such a gauge. The Lee Hetherington gauges which have been issued keys, and which have them built in for automatic access as far as I know, are: ILH_TCAS, ILH_TCAS_B1900D, PAD_ILH_TCAS, and ILH_TCAS8 Yours is possibly one of these but re-named, which would be why it won't register correctly. Because I cannot possibly know all of the freeware that is out there, and most of it which does access FSUIPC has keys built in which have been supplied on request. There is no way I can take responsibility for every one else's software. I have enough to do as it is! Please address your concerns to whoever made your panel and presumably incorrectly re-named the gauge. Regards, Pete

You don't "order" them, just download them from http://www.schiratti.com/dowson. Pete

Yes, there are also another set at offsets 1244 to 1260. They deal with Cenre2, Centre3, External1 and External2 tanks, for any aircraft which may have them. You can write to the levels to change the content. 100% is 128 in the high word, or 128*65536 (hex 0x00800000) in the 32-bit double word. Yes. Thanks for replying. I only added to it. :wink: Regards, Pete

You will have some difficulty with weather. It is dynamic and depends more on the settings at local weather stations. You cannot set the weather at the aircraft directly. Weather changes with time no matter what you do, so they'll never be exactly matched, especially with regard to clouds. Winds, temperature, visibility and pressure should be easier, but the viual impact is mainly clouds and that's next to impossible to synchronise visually. With traffic that depends what traffic you are talking about. If you mean AI traffic, then whilst you can read thraffic data through FSUIPC, you cannot write AI traffic data into FS for it to obey. AI traffic follows the routes and timings and rules local to its own pre-compiled traffic files. Ordinary dynamic traffic are just moving scenery, and are controlled precisely by scenery files. The only type of traffic you can actually create in FS and control is multiplayer traffic, but that uses the FS multiplayer interface, not FSUIPC. I suppose you could read AI data from one PC using FSUIPC and send it as MP data to the other. I'm afraid I know nothing about the MP interface, but there is an MS SDK. It writes some weather. I think this is optional -- some folks prefer the more sophisticated weather from ActiveSky or FSMeteo. It certainly does not input other traffic via FSUIPC. It uses the MP interface for that. It isn't that easy. You have to write complete weather sets for all the individual weather stations around your position. You can write just "global" weather instead, but that just sets initial defaults -- to stop it changing or to control it you have to keep re-writing it at intervals and this is likely to cause cloud re-drawing (flicker) and hesitations. The only interface for setting all weather in FS2004 which makes sense is the New Weather Interface which is defined in a separate package in the SDK. Programs like ActiveSky and FSMeteo use that. As I said, there is absolutely no way for creating and controlling AI traffic in FS other than via the TrafficToolBox from MS or using one of the traffic compilers like TTools to compile new routes and aircraft assignments. You will have to think in terms of Multiplayer. If you move the aircraft so far to cause that you need to send a Refresh Scenery control afterwards. It will then load the scenery -- you see the scenery loading bar on the screen. You don't pass anything. That message is produced by the version check FS makes on the version number in the Linkage structure. See other DLLs and Gauges and you will see. I cannot possible tutor on writing DLLs for FS. Sorry. You can add your module to the [OldModules] section of FS9.CFG to suppress the message. There's no such thing as an "external DLL". DLLs have to be part of the process of the routines which call them. Gauges are DLLs loaded and unloaded by FS, but they are far from being "external". There are no facilities for running EXEs from FSUIPC. Just run them (using the Run Programs options in FSUIPC.INI if you like) and program them to wait for a signal through the FSUIPC interface -- for instance one of the virtual buttons. Much of what you want to do is done by Luciano Napolitano's WidevieW. I'm sure he would dearly like to synchronise clouds and AI traffic too. He has over six years experience with all this stuff on versions of FS starting at least with FS98. I'm sure if it were possible to do it all, he would have done it by now. I think you should check his programs out before you do too much. We've been pressing MS for facilities to do this sort of thing better in the future, so maybe, with luck, things may improve in the next release, or maybe the one after. Regards, Pete

Aha! I have a TQ6 here. I think its GF driver does the flaps handling itself. I'll connect it up again and check it tomorrow, but I've a feeling you can't have FSUIPC trying to control the postions at the same time as GF's program does it -- they even provide an attachable notch set to match their own calibration, don't they? Mine had one but I couldn't get it fitted correctly. Are you using their reverser levers? They only operate buttons, they aren't real axes. It sounds like you need to check the GF documentation. The TQ6 is meant to be self-contained -- you shouldn't need or want to do anything for it in FSUIPC. If the documentation isn't sufficient maybe they have a forum or support site you can check? If I don't here from you before tomorrow I'll check the flap assignment here and see what it does -- what I've said above is from a vague memory from last year some time. Regards, Pete

Have you got FSinterrogate? It is in the FSUIPC SDK. To "activate" it you simply run it. It is a program! Regards Pete

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