Pete Dowson

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

I've been trying this and I simply cannot make it go wrong. Maybe I am not able to do it fast enough? Maybe your "fast" is actually moving so fast it is going up from 90 right round to 15 again? I've checked the code. Of course for the simple INC/DEC FSUIPC is not involved -- your request goes direct to FS. For the fast version, FSUIPC reads the value of the Bug, adjusts it by 10 degrees up or down, and sends it back to FS. If you are SEEING the value increment slowly, then that value is what FSUIPC is reading, to add or subtract 10 from it. There is no other being "held" for seconds so it can come back as you say. I really cannot see how anything could result in what you say you are getting. Please re-check, AND use the logging provided. Log buttons and events (two checkmarks). You should also Monitor offset 07CC as type U16 (right-hand part of Logging page), checking the normal log option at the bottom. Regards, Pete

Ibcidentally, the rounding problem seems intermittent -- usually 360-010 works. So it may be more of an FS quirk. Using which controls please? The "Fast Inc/Dec ones (FS's) or the Dec/Inc Fast ones (FSUIPC added)? I need to know. I cannot re-code FS but I can FSUIPC! Hmmm .. that sounds impossible, as there is no "memory" of what it was before. Is this occurring with the default 737 (the "bug" being the numerical display on the MCP)? Does it occur when there's a delay (pause) between the slow turning and the subsequent fast turning? what about the more usual adjustment method of fast turning followed by slow turning? It isn't anything like scripting or programming, but you do need to understand words like "set" and "clear". For the lights you will also have to be able to work out the hexadecimal number corresponding to a bit among 16 bits, because all of the light switches are in one word at offset 0D0C. You don't need to edit any files, it can be done in the same Button assignments screen you use for other things. It is only a matter of selecting the right control, then an offset, then a parameter (for simple on/offs this is usually 0 for off, 1 for on -- the lights are different as I say. You want Offset setbit for on, and Offset clearbit for off, with the parameter showing the needed bit for that light. Regards, Pete

RightI've tested these two controls here and the ONLY oddity I've found is when incrementing through 360 (000) a rounding error occurs -- the step from 360 to 010 actally gets to 009. Otherwise it works perfectly here. On the other points: FSUIPC added those called "VORn Obi Dec Fast" and "VORn Obi Inc Fast". The others (with the Inc/Dec at the end) are FS's and I didn't think they worked as you'd expect. (The list of all FSUIPC added controls can be found in the Advanced User's document). Can you be clear please about exactly what you mean? I cannot make the added FSUIPC ones go wrong at all. They are much simpler than the Heading ones as the units in FS are degrees in any case -- the heading one is made complex because it uses FS's angles (360 degrees = 65536 units), which is why rounding can play a part. So, please be rather more specific so I can help. I'll certainly try to fix the rounding (360 -> 009), but I need to understand more about what you are saying. I also need the version number of FSUIPC -- if you are not using the latest, please update it first. Note that you can always check that it isn't something in your button hardware, or programming, by assigning keystrokes to the same controls and testing them. They use the same code in FSUIPC. And also, if you look in the Logging section of FSUIPC, you will see that you can use button and event logging to check things even further. Regards, Pete

Sorry, can you explain what "only switching within two places on gauge" means please? It sounds like an FSUIPC bug -- the "fast" controls are added by FSUIPC, they are not FS controls. I'll investigate here and get back to you. Well, if you are using the normal INC/DEC controls, it is FS which accelerates them to operate in 10 degrees -- I only added the FSUIPC facilities for more precision. Have you got something else running which is defeating the acceleration perhaps? Look at your options in FSUIPC's "Technical" page. Anyway, if it is a problem in FSUIPC, I will have it fixed within a couple of days. If I added new controls for all such things my add-on list would be veryt long indeed. I suggest you download the FSUIPC SDK and find the offsets for these things in the tables. You can make your own controls then using the "Offset ..." controls in FSUIPC. Come back after you've looked if you need more help with this. Regards, Pete

I've found this -- it is a long-standing bug in FSUIPC! In fact, decreasing from 400 here goes to 559! It is a silly small error in my code. I have fixed it here and the corrected version of FSUIPC will be available in the Interim Versions announcement above within a day or two, by Monday for sure. Thanks for the report. Oddly, that makes two very old bugs reported in this one week, whereas none have been for a long time. I am expecting a thirddon't things always come in threes? ;-) Regards, Pete

Actually that's wrongwith the same option settings it cannot work with any Version 3's at all, nor even version 2's. In fact you've found a bug that has been there since the "Enable A/P Altitude Fix" option was first provided! Well done. ;-) Yes, for the time being go to the Technical options page and turn off "enable A/P altitude fix". That is reading the altimeter value from FS and assuming it is in feet. That's the trouble. I'm amazed that no one's discovered this for what must be around the five years it has been this way, but the fix is quite easy and the next interim version, up in the Announcements in this Forum, will include the fix. Have a look over the next few days. Thanks, Pete

I thought I was clear? WideFS links one PC running FS (the "Server") with any number of other PCs not running FS (the "Clients"). That is its function. WidevieW is not the same at all -- it links one PC running FS with others running FS too. WideClient effectively REPLACES FS+FSUIPC on the Clients to support FSUIPC applications. WidevieW runs WITH FS and FSUIPC on each machine, Server and all Clients. You can mix both on one Network with a common Server, but not on one Client. All the ways of linking multiple FS installations include WidevieW and Multiplayer, and probably others, and of course you can have different views and so on visible on each one. But none of that is anything to do with what WideFS does, and it isn't an area I am at all involved in. You may want to talk to someone in the WidevieW area instead? Sorry, but that sounds rather confused. I too have a Matrox Parhelia, and, yes, it runs three screens showing one very wide outside view very well. But that is all one one PC running FS. WidevieW doesn't really come into it at all. I have one setup with two fast computers, both with Matrox Parhelias, both with three screens. The one running FS shows a widescreen outside view across the three screens, no panel. The other PC shows all the glass cockpit instrumentation from Project Magenta -- pilots PFD/ND, EICAS+Standby instruments, and Copilot PFD/ND. I also use a lesser PC to run the PM CDU. These are linked by WideFS. I don't use WidevieW. If you want to link multiple FS's I really suggest you try the WidevieW support site and get advice there. There's also a system called "FsXPand" (sorry, I've lost the link -- search on Google) which may be more what you are after. Regards, Pete

WideView's server presumably runs here? The external view will be the main FS view, not one produced by the Wideview link. It is not possible for WidevieW to run without FS being installed on the same PC, and if FS is installed here you cannot use it for WideFS clients. You need to re-think. Doesn't WidevieW come with any documentation? You should certainly have a look at the WideFS documentation. You don't list FS as being on #2, but it must be for WidevieW, and cannot be for WideClient. Yes, of course. Run WideClient ONLY on PCs not running FS, as it says in the documentation. Regards, Pete