Pete Dowson

If you are using default Network settings in your WinXP installations there should be no problems, it should just work, "out of the box". ARE you using WinXP both ends? I really don't know why Windows should report All it says in the Windows help for this is: "A connection attempt failed because the connected party did not properly respond after a period of time, or the established connection failed because the connected host has failed to respond", which is obviously not very helpful. Well, you could try bypassing that just as a test (though to connect two computers directly together you'll need a crossover cable). Compare the assorted settings on both PCs too. Are they both WinXP? If not the default protocol settings may be different. Can you share files and so on both ways okay? Regards Pete

What version of Windows is this with? I know that in Win98 the USB devices got assigned different device numbers each time you booted, if the configuration had changed. I thought that was solved in WinXP -- though it may have not been dealt with till SP1. The numbers I use are the IDs required by the joystick interface I am using. This is the "joyGetPosEx" API which has been supported continuously in Windows for many years. I do not use the DirectInput interface as used by FS since version FS2002, for several reasons -- mainly because it is far too complicated and involves me learning a whole new type of programming, but also because it is at a much more abstract level than the basic API I use, and I have never liked to get very far from the hardware. If you want to play with the older API, please try the attached program, which was produced by Thrustmaster to check their own devices via the same interface. It is general purpose though. It gives you complete access to the "raw" data which I use. Regards, Pete joyview.zip

Okay, the answer is simple then. Your Sever PC is not visible to your Client PC. Either one or both isn't connected to the network, or they are in different Workgroups (check the Workgroup name in each by right-clicking "My Computer", select Properties, then Computer Name), or the IP addresses are in different subnets (http://www.xxx.yyy.zzz doesn't match to the level of the subnet mask, usually 255.255.255.000 -- meaning the http://www.xxx.yyy parts must be the same). Those are the 'elementary' reasons I can think of, but there may be others. It is a Network problem for sure -- if you can't solve it then ask Katy Pluta over in the FS2004 forum. Regards, Pete

Okaythere's nothing showing wrong in the Logs of either Server or Client. However, it does seem that something is preventing the broadcasts from the Server reaching the Client. One thing here is extremely odd -- both your Server PC and your Client PC appear to have the same names! From the Client log: From the Server log: Now, possibly the difference in capitalisation may make it okay, but I would be very suspicious of this. Having the same name for two PCs will give problems. Anyway, assuming either that you resolve that, or that it doesn't matter (because of the caps differences), try adding ServerName=HAMMER to the [Config] section of the WideClient.INI file. This will get around the fact that it isn't getting the broadcasts and may then even work, though I doubt it. However, it should at least give you an error saying why it doesn't work. The most likely problem is a firewall. Not sure how that can mess up your Network settings at all. Regards, Pete

Are you only making one request? This is a lot of trouble for just one request -- you could use the gauge interface, documented in the Microsoft panels SDK, to get most trivial things, like MagVar and Heading. If you are making many requests you should be bunching them for efficiency if possible. in any case you only want to Open and Close once -- Open when you start, Close when you finish. Well the Open2 reads and writes are processed by the Process call also inside the Open2 code, and the buffer pointer reset to the start again before exit, so those operations are not adding to yours. However, 54 bytes won't be enough. I think it writes the library version nmber, and reads the FS version and the FSUIPC version. Altogether that might need about 62 bytes (maybe only 58 actually, as the Write header takes 4 bytes less than a read header). However, since those reads and writes call the FSUIPC_Read and FSUIPC_Write routines themselves, and there's a check in there against the size, to make sure there is space, one of those should have failed and closed the link, returning a "FALSE" to the Open2 call, and an error (set by the failing Read or Write) of "FSUIPC_ERR_SIZE". Seems that there's something wrong in your conversion. Doesn't Delphi have a step facility in its debugging facilities, so you can single step through your code and see what is going on? The other thing to do is compare your translation with that for the Delphi package for external programs. Much of the code for Reads and Writes and even Process will be comparable. The only big differences are the use of provided memory instead of the 31k memory mapped file and the SendMessage. Well it is easy enough for you to check that. But the code you've translated should have checked that and returned a local error in any case, way before any attemnpt to talk to FSUIPC. It's a good idea to be so "mean" with memory whilst testing, in order to highlight problems, but in the end you may as well just allocate more than you'll ever possibly need (in one Process) and forget about it. Regards, Pete

It is impossible in any case. Those are results of FS's simulation, not inputs -- effects, not causes. You can influence them via thrust (throttle) and pitch of course (directly or via the elevator), and also to some extent by managing the assorted accelerations and forces. But you cannot directly tell FS to "set the aircraft speed to x". Pete

Button marked "pm". Pete

It means the data format in the data passed to FSUIPC is in error. This willl be a problem with the request type (read or write normally), request block length, offset value or data length, or terminator (a zero DWORD at the end of the data). You can program a sequence of known reads and writes, enable IPC read and write logging in FSUIPC's Logging, and try it. If all the reads and writes operate okay (as shown by FSUIPC logging) but you still get the error, then it is "running off the end of the data", so you've omitted the zero terminator in your Process routine. That's the most likely problem in fact. If it stops anywhere else you know it's a problem there. I wouldn't expect you to do that in any case. Just put a breakpoint on the SendMessage, and dump out the data you are trying to pass to FSUIPC. I can check it if you like (make sure it is in hexadecimal bytes please), but the structures are easy enough to follow, they are the original structures designed by Adam Szofran for FS95 and are defined by the "structs" in the header files. Regards, Pete

When you say "coordinates" what do you mean, please? Doesn't the "IN" value change as you move the throttle? If not, it sounds like either it isn't assigned in FS, or the sensitivity in FS is set to minimum. Check both. Get it working reasonably well in FS before calibrating in FSUIPC (press the "Reset" button in the Throttle section of FS's Joystick options). When FS responds okay you can go back to FSUIPC and press "Set" (top left in that section), and then set the values left-to-right by following the steps laid down in the documentation. Regards, Pete

He shouldn't need to do that if both PCs are running XP. The current version of WideFS sorts itself out on its own. I suspect this user has only installed FSUIPC on the Server and hasn't installed WideServer. Either that, or one of the PCs is using Windows 98 or Windows Me so the automatic server detection won't work. You don't do that manually. That list is made up by WideServer automatically, as Clients connect. It does this so that if it receives any button presses from Clients it can consistently assign the same button numbers, so button programming will work no matter what order the Clients log on. Regards, Pete

And where is the log from WideServer? You'll find that in the FS Modules folder, where you put the WideServer.DLL. (You DID install WideServer too, didn't you?). Are you using Windows XP on both Server and Client? If not then you need to tell wideClient the name of your Server PC. This shouldn't be needed if both PCs are running XP. Regards, Pete

What you download is just a ZIP which contains documentation and the FSUIPC.DLL module itself. All you need to do is copy the DLL from that ZIP into the Modules folder of your FS installation, no matter where it is. The DLL itself is less than 250 kb in size in any case. You can write it to a CD or even just to a diskette, anyway you like to transfer it. There is no installer, there are no hidden parts to it. What you see is what you get. Don't delete anything on your FS PC, just copy the update in. Keep an eye on the Announcements here -- there are later versions available here and a list of current version numbers. The next update here is only a few days away, probably Monday. Regards, Pete

Okay, good. In the next version of FSUIPC (for which there will be an advanced interim release here, in the Announcements above), you won't need AdvDisplay at all if you prefer the FS-type translucent windows. FSUIPC will support a new Window especially suitable for RC4 directly. I'm hoping to release the interim version by Monday, with a view to a formal user release in the usual places around mid to late April. Regards, Pete

No idea. That's why I asked for the heading value to be monitored too. Once that is included in the Log maybe we can see the whole picture. Regards, Pete

The lines in the Log are wrapping, so the descriptions of the EVENT are appearing in the next line, and you are compounding this by dividing up the samples in the wrong place, in a line. Can you make the samples a little wider to avoid this please? So, what is Button 16? It appears, clearly, to be programmed for a HEADING_BUG_DEC. FSUIPC cannot influence the button numbers being reported. It looks like there is something unreliable going on with your device. The decoding of direction in many encoders is by phase differences. I have noticed that many such encoders give the odd (sinlge) spurious incorrect direction, but not usually a continuous stream like this. Maybe there is some interaction between the pollling and the USB driver for your device? You could try fast and slower polling rates. What operating system are you using, by the way? If it is not XP SP1 or later it may be the USB drivers. Regards, Pete

Erit is all pretty meaningless without knowing which button is which. Can you list your button number assignments please? Also, Monitor the heading bug offset as I suggested. It may look meaningless to you (I will have to do calculations to convert its units to degrees), but at least it will show the results of each INC and DEC control being sent. Pete

I've no idea. What exact window is this? How is it configured? Which program is sending this information (i.e. what are you using advDisplay for?). There is a problem in FS's window if programs are trying to display messages containing multiple lines, and the symptom is exactly as you show. But this is when AdvDisplay is NOT active, so that the messages are therefore simply going straight through to FS's own green translucent display. When you go to the Modules menu, is the Advdisplay entry ticked to show it is active? If not, you've installed it but you aren't using it! Regards, Pete

Well, FSUIPC polls by default at 40 times per second, so a 20 pulse per second rate is going to go a bit wrong. You could try adjusting this in FSUIPC (it's the "PollInterval" parameter -- see the Advanced User's documentation. Well, you are saying that the simple code, adding or subtracting 10, implemented in FSUIPC, doesn't work for you. I don't know why you are getting what you are getting, and I've no way of telling as you don't show me any information. As I said, it works fine here. It was originally tested with Goflight USB knobs with slow/fast capabilities and worked perfectly. But I've not got those devices now. Yes. There's certainly no point in continuing this exchange until some decent information is available. Please make sure you test it on a default aircraft please. Regards, Pete

I don't think so. I'm sorry, but I don't know enough about WidevieW to advise. I'm not sure where it gets "spot plane" information from. You need to go to the WidevieW support site. Regards, Pete

Based on that information? No, none at all. Check your VERSIONS -- always needed. Then check the WideServer and WideClient logs. You have "something wrong" is the only conclusion from the minimal information you provide, I'm afraid. Pete

But doesn't this indicate more that there's some interaction between the button combinations on your joystick? Please use the button logging and maybe the event logging in FSUIPC so you can see what is happening. I know of no reason whatsoever for any relationship between braking and reverse thrust. It seems more likely to be a button problem, but you need to investigate with the tools provided. As a cross-check you could also try using brakes on the keyboard whilst using your reverse thrust system. Test all this with a default aircraft, mind. Some more sohisticated add-on aircraft will disable manual braking whilst you have any significant thrust set -- in an airliner you'd normally expect autobraking to be operating during reverse in any case. Regards, Pete

The "call" instruction is calling the next instruction, the one popping eax and labelled "next:" (that is merely a label). If you can use a value like "$" or similar, to represent "this place" (a standard Intel method), then you could get away with leaving the "next:" label off and calling the next instruction by "call $+5" (the call should compile into a 5 byte instruction). Regards, Pete

Hi again. Okay, I managed to find a way around this anomaly. There are two controls FS offsets to set the V/S in the A/P: AP_VS_VAR_SET_METRIC and AP_VS_VAR_SET_ENGLISH Now I always thought that the first uses Metres/Min and the other Feet/min. But that isn't true! They BOTH use feet! The difference between the two is only in whether they round to 50 metre or 50 feet intervals! Duh! So I will use the METRIC one when the altimeter is working in metres. I've changed it here and it works. Look for it in the interim version I shall release over the weekend or so, maybe Monday. Regards, Pete

That is very strange. According to all the documentation, the autopilot V/S supplied to me by FS is in feet/minute. I didn't think that was ever different. I simply change the sign, I do no conversion whatsoever, but for FS2002 and above I have to send it back to FS, which of course assumes fpm still. Upon checking, I find that FS does still provide the value internally in feet even in metric altitude mode. For instance an indicated AP VS of 300 (metres) is read internally as 984. If I change the sign I would send -984 back to FS. I do not round it to 100's of feet, or 50's or anything. I do no changes to it whatsoever except for the sign. So it seems it is FS -- possibly only the gauge display? -- which is doing the rounding. Sorry, I cannot change the innards of FS to operate in 50 metre increments instead of the usual 50 feet. Regards, Pete