Pete Dowson

Yes, from Michael's description it does sound as if it MUST be hardware in origin, as I think the calibration displays are showing the raw inputbut maybe the "slope" tables come into it. I need to check. What is so odd in Michael's case isn't so much the wrong deflection (which can, I think, be a little "dead" spot on the pot or something else electrical in the controller) but that, by his testing, it only happens when he has mapped the throttles! I need just to be sure there's no corruption occurring internally to the driver. Once I have checked that here and found no sign of it, then I will have to ask Michael to turn on some Comms logging to check the raw data arriving from the PFC controller. May I ask, in your own console repair, what did you actually do? Was it a change or clean of potentiometer? Or something electronic? Regards, Pete

Could you Zip up and send me the PFC.INI file from the FS Modules folder, please? (petedowson@btconnect.com). I'll try checking this out tomorrow -- if I can't reproduce it here I may ask you to do some tests for me with different options. Seems odd that no one has reported it before if it is in the old version too, so maybe it is related to specific options, slopes, etc. Thanks, Pete

Hmmm. I'm not at all sure how to interpret the information you've provided. Are you actually saying it ONLY occurs with the PMDG 747? The Flight Controls page in the PFC driver Options should really only be reflecting what is being input from the hardware, so I would first suspect the pot on the yoke -- a dirty section perhaps. But then you'd expect to be able to see this no matter what aircraft you are flying. Certainly, whilst in the PFC options the current aircraft loaded in FS shouldn't matter at all -- unless for some reason its activity is interfering with the PFC link to your PC, but I really can't see how that could be. Even if it were, you'd expect that to play rather random havoc, not a specific type of error. So you are possibly deducing that it is related to the mapping of the throttles, independent of the aircraft itself? Can you verify that with, for instance, the default 747? Is it only since you purchased the PMDG 747 that you have been mapping the throttles linke this? I'm not set up at present to conduct experiments on this here, but I will within the next few days. Meanwhile, any further information you may find will be useful. Oh, could you try the current "official issue" PFC.DLL (from http://www.schiratti.com/dowson) just in case it is some problem introduced over the last year or so. Thanks. Regards Pete

There's no difference in the handling of any one throttle over another in FSUIPC. Re-chack your assignments, calibrations, and in particular the FS sensitivities and null zones. Make sure you have a good "idle", as without idle you cannot engage reverse. Check that the lever itself is okay be swapping assignments over, say, between Throttle 1 and 4. Lastly, check and report the "INPUT" values for that lever, as shown in FSUIPC and compare them with the others. Pete

Sorry, but I think you are rather confused. FSUIPC 3.53 does not assign axes at all, that is done in FS -- go to Options-Controls-Assignments and check the FS settings. FSUIPC only does final calibrations, completely optionally. Do not use it first, get it working in FS first. Pete

I'm afraid I can't advise on hardware programming it -- SimKits needs to do that, but the three reds and greens can and should be operated easily from the three indications in FSUIPC offsets 0BEC, 0BF0 and 0BF2, as documented in the FSUIPC SDK. You don't need any artificial delay -- the gear positions in those offsets show when the separate gears are fully down (16383) = green, and fully up (0) = off, else they are in transit, = red. Regards, Pete

Yes, of course. FSUIPC does not (cannot) operate FS's menus. When FS is in any of its menus, the User is in control, not the program. Automatic facilities provided via FSUIPC are for automatic use. User facilities via menus are for real users, on keyboards and such. Regards, Pete

Sorry, you are losing me now. If you know what the indicators actually mean, then surely you know what values trigger them? How else are you going to know what they are for or what to do about them? I really don't know what you are doing, but I am assuming they are warning lights for low levels of oil or fuel, or high temperatures or pressures? The levels, pressures and temperatures are available 9they are displayed on gauges, for instance, and are listed in FSUIPC's lists of values). The warning levels will vary from aircraft to aircraft -- that's for you to determine from aircraft spcs etc, surely? Pete

The lights are indicators of something. You need to detect the condition which makes them light. Apart from "emergency battery" which I don't think is simulated in FS, you can find values providing the amounts of all these things. If the warning lights are to operate when the levels go below (or above) a given limit, that's what you'll need to check. Regards Pete

Ha ha. It would be if it worked literally like that, but it doesn't. ;-) Reading and writing are two different operations and actually use different buffers in any case. The illusion that FSUIPC provides access to a memory space with those offsets is confusing you a little in this case. It is only an illusion. writes to 3380 over the IPC interface actually get sent to FS's display routine, not to FSUIPC's memory. This is why you'd need AdvDisplay running to intercept them and put them into FSUIPC's memory, where you can actually read them "at 3380". Offsets in FSUIPC are really "tokens" identifying variables rather than truly offsets. They started out as offsets in FS95 and FS98 days. The illusion is maintained for compatibility. Texts intercepted by AdvDisplay and placed in 3380 behave identically to the displays they are meant to show -- ie. they stay for the number of seconds specified, or scroll off to the left one character at a time, or stay till the next message arrives. Just like the display itself. It will be reading it quite frequently, looking for changes, yes. When used across WideFS this is no load really as WideServer only sends out changes. You have to hook a particular procedure in FS. It is in a different module and in a different place for each version of FS. If you know how to hook FS procedures I can tell you which they are. Hmmm. Possibly. Regards, Pete

Yes. You need to run AdvDisplay to trap the messages and route them to FSUIPC's offsets. As an example, the freeware program "Showtext" provided in the AdvDisplay package does exactly what you are asking. This is actually documented in the description of offset 3380 in the FSUIPC SDK's Programmer's guide. Note that Advdisplay doesn't monitor such messages, it actively diverts them, so if you wanted them visible too you'd need to display them yourself, or use AdvDisplay's window or ShowText. Regards Pete

All assignments are currently handled by FS, not FSUIPC -- go to Options-Controls-Assignments. I think you will find that all those axes are assignable there, with multiple devices (there's a drop-down to select the device for each set of assignments). I am currently working on facilities in FSUIPC for assigning axes directly, without involving FS. Hopefully I will be releasing a Beta version here later this month. Regards Pete

I'm afraid I don't understand. "Text of any resouce" -- displayed in FS? How, where? Where do they appear? FSUIPC/AdvDisplay is only able to grab texts sent to the standard FS message line, the same one used for FS's own ATIS messages. Regards, Pete

Most really great add-ons for FS2000 did also work fine in FS2002, and even some in FS2004. I can reproduce the odd crash when the menu is hidden, but I could not find the reason. It is hidden too deep in low levels of FS's use of DirectX. I suspect it is something forgotten in FS over newer generations of DirectX and Windows. I cannot make the same problem occur when the menu is not hidden, so I am sorry, I do not know of any way to help, except by registering in FS2002 or FS2004 on the same PC, and copying over the FSUIPC.KEY file to FS2000. How did it fail? There's no sign of failure in the log. Only S-Combo being started three times. I am fairly sure there are some extra steps you need to take to make S-Combo work via WideFS -- you will need to contact the author I think. Sorry, I don't know. This is purely an application thing. I don't know why they would "point to" an FS installation. Doesn't S-Combo come with any documentation for use on WideFS? If that is the case, you would have to point them to the copy of FS you are actually using -- i.e. the Network path to FS on the Server. Make sure that the FS folder is set for sharing on the Network. I think all those run fine on a client, but, yes, I think they do need to know the path to FS -- possibly excepting Radar Contact. I don't really know S-Combo, but Flight Keeper needs to generate its database from FS files. I'm reasonably sure there are instructions for all this in the individual program's documentations or websites. None of this is really related to things I know, where WideFS is reproducing the FSUIPC interface for them to use. All the other stuff is specific to programs which need access to FS files, often the scenery installed. Regards, Pete

Not pressure as such, but the relative amount of application (relative to full pressure) is available in the control offsets -- 0BC4 and 0BC6. Unfortunately these don't operate for autobraking. Regards, Pete

What sort of explanation is really needed? The format of the frequencies is explained in the Programmer's guide. They are all simple 16 bit words -- i.e. type "unsigned short" both in C and C++. Read then into such (length 2). They are in binary-coded decimal, which simply means that each group of 4 bits represents one decimal digit. For display it is easiest to simply convert them to hex character form, using the printf "%X" facility. For instance, if the frequency is actually 112.75 the value you get, in hex, is 0x1275 (the 100 digit is assumed). To print that you'd simply do a printf with "1%02X.%02X" (to put the decimal point in correctly), with parameters (val >> 8) and (val & 0xff). None of this is complex programming, just basic C. (I don't know C++, sorry). If you can say why you cannot understand then maybe I can see what is wrong with the documentation, but having someone do the code for you doesn't help anyone in the long term. Regards, Pete

Windows Help and documentation. If both PCs are running Windows XP, then it should be pretty easy. I wouldn't be able to tutor anyone on Netwroks as I know little, I just let Windows do what it needs to do. The only thing you may need to do for WideFS is to turn the Windows XP firewall off, or at least do something to let WideClient (on the client PC) talk to WideServer (on the FS PC). But this applies equally to any program using the Network for anything. An Ethernet twisted cable for Ethernet connection, or a USB 2.0 cable if you want to connect via USB, or a Firewire cable if you want to connect using Firewire (IEEE 1394). I think links also work with serail and parallel cables, but avoid those as it will be clunky and too slow. Windows supports many ways of linking PCs. Doesn't matter. WideClient doesn't need much installing in any case. Depends if you want FS to download things from the Internet too. Whichever it is connected to, Windows can share it over the Network in any case. See Windows help. It would really be better (safer too, from attacks over the Internet) to replace your modem with a modem/router, and connect both PCs to that. Then both PCs have Internet access even if the other is switched off. Ethernet links are best for this. That's because it isn't either WideFS's nor FSUIPC's business to make Networks work. That's all in the realms of Windows. Look in your local bookshop. There are hundreds of books about this -- you surely don't really think that every program which uses a working Network should tell you about Networks? It just really isn't feasible, even if I knew it all, which I most certainly don't. Please, get your Network working as per Micrsoft instructions, then and only then buy and install WideFs. Regards, Pete

If you have a valid registration for FSUIPC 3 or WideFS 6 then it is valid for the life of FSUIPC 3 or WideFS 6. Sounds like you've moved to a different PC, or reinstalled Windows or FS? You'll need to re-register in FSUIPC with the exact same details as originally. Regards, Pete

Check your arithmetic. P = 37, following W? I think not. Try 27. Likewise 29 for R. Also you don't need to multiply the last result by 38 as there is no more to follow. 34 x 38 = 1292, +20 = 1312, x 38 = 49856 + 27 = 49883, x 38 = 1895554, + 29 = 1895583. 1895583 in hex is 1CEC9F, shift left 5 (x 32) = 039D93E0 You say you found 039D93E1, but obviously the '1' at the end comes from something else as it cannot result from a shift left of 5 bits. As your extract says "Bits 0 .. 4 of the resulting DWORD are frequently used for other purposes." Regards, Pete

I'm afraid I know of no other way but to take the Latitude and Longitude and find the nearest airport from a database. There should be an easier way, for sure, but if there is I've never found it. A value for this was added in version 3.53 of FSUIPC, as listed in the History document (and above, in the details of recent releases. Here's the relevant entry: Note that this is metres per second x 256. You will need to convert it for feet per minute. (x 3.28084 x 60 / 256) Regards Pete

Only the lower 17 bits constitute the FS control number. X1041B is decimal 66587 which is listed as "ROTOR_BRAKE" in my FS controls list (packaged with FSUIPC.ZIP). Control 71023 is certainly outside the range of FS controls known to FS's own CONTROLS.DLL, which is why it is logged as "unknown". I don't know what panel you are using, but it may be an internal addition used only by specific code. There are also probably losts of WM_COMMANDs which are nothing to do with the assignable FS controls. FS controls are not always posted or sent as Windows messages. FSUIPC itself sends most of them directly to the SIM1.DLL module using the "SendEvent" call it supports. I expect many panels do the same. You cannot discover everything internal to a program via Spy because that is only able to see Windows messages. By hooking the controls calls, a facility offered to modules and gauges for just such a purpose. Check the FS panels SDK. Regards, Pete

Not at present, as the assignment of functions to your levers is done in FS, not in FSUIPC. But I am currently working on facilities in FSUIPC to make assignments completely independently of FS. Such facilities have been on my "list of things to do" for some time, but have only just reached the top. They will certainly be able to be set as "aircraft specific". With the new facilities you will actually be able to switch FS's joystick facilities off altogether and use only FSUIPC to assign axes and buttons, and do the calibrations, and all of this can be for all aircraft or be specific for each individual aircraft or group of similarly named aircraft. I hope to provide a test version of FSUIPC with these facilities, for general Beta testing via this forum, within the month of February, so keep an eye on the top announcements here. Regards, Pete

I fully agree, if you were doing so -- which I didn't say. But unfortunately that's the way it reads. Hence the word "seems". I have to somehow get folks to read what is written rather than what they think should be written. How many ways can I emphasise "forget WidefS and the Network, interface to FSUIPC"? Maybe much bigger fonts in red? Regards, Pete

I don't know FSHost or Ventrilo I'm afraid. There are, I know, on-line flyers who have Squawkbox running on a client PC, talking to FS on the other via both multiplayer and WideFS (multiplayer for other users aircraft, WideFS for the FSUIPC connection for weather and user aircraft radar reporting). FSUIPC and WideFS are only of use to programs using the FSUIPC interface. Whether yours do or not I don't know. Regards Pete

Okay. So FORGET WideFS for now. That is where you are totally confused. You do NOT interface to FS through WideFS but through the FSUIPC interface. For that you need the FSUIPC SDK. Do NOT mess about with ports and TCP/IP or anything like that. All that will be handled for you by WideFS WHEN AND ONLY WHEN YOU HAVE A PROGRAM INTERFACING TO FSUIPC! No, absolutely not. You will NEVER get that working. Go download the FSUIPC SDK. Forget WideFS. You obviously totally misunderstand the whole concept. WideFS just provides a Networked copy of the FSUIPC interface. It is that you need to deal with. Do not use TCP or anything to do with the Network. That is handled by WideFS. Write your program to talk to FSUIPC, following the examples provided in the SDK. If you want to do your own Network linking program, that's fine, but it is absolutely nothing to do with either WideFS or FSUIPC. That's all your own affair. You'd have to do both client and server ends of your own link. That's not relevant to anything of mine. It is NOT only "the intention". It is what is implemented, and it has been so since FS98 days. It is well established and heavily used. WideClient "pretends" to be FS running FSUIPC. Any program written to interface to FSUIPC will run okay on the FS PC without WideFS even installed, or on the Client via WideFS. The interface is reproduced exactly. That's all you need to use. No network stuff at all. Of course not. It responds only to the WideFS protocol, which is not published and which will not be. Please FORGET the Network, write to the FSUIPC interface only. I'm sorry, but this is getting no where. If you insist in talking about TCP streaming and so on then you may as well continue talking to yourself. I cannot help you. You seem to be deliberately misinterpreting me. IGNORE NETWORKS, IGNORE WIDEFS, use the FSUIPC SDK and interface to FSUIPC, like hundreds of other programmers have done before very successfully. Pete