Pete Dowson

Ah, yes. FSUIPC has to deal with that situation in any case. It must have been in the INI file -- it would have automatically created the [AxisCalibration] section. If there was nothing in the INI file doing it, then deleting it wouldn't have had any effect, now, would it? ;-) Pete

Hi again, Just as extra information on this matter, I have a PFC 737NG cockpit, and the trim indicator scale in that is marked in units going from 0 (full nose down) to 19 (full nose up). What is effectively happening on this is that the full trim scale (offset 0BC2) of -16383 to +16383 is being maped, linearly, onto the sale of 0 to 19. If you are trying to drive a separate indication somewhere, I'd use the 0BC2 indicator, a 16-bit integer, rather than the 64-bit floating point value at 2EA0. Simply scale -16384 -> 16383 to the needed range 0-19. In other words something like: Aircraft Trim Set = ((FStrim +16384) * 20) / 32768 Here I am assuming that the aircraft scale is actually linearly proportional to the trim position. I cannot imagine that it might be otherwise. Regards, Pete

It sounds like you have edited the FSUIPC.INI file and set the "AxisCalibration" option to "Yes" at some stage. This facility was added to allow hardware devices implemented without their own calibration facilities, which had drivers interfacing to FSUIPC, to be semi-automatically calibrated by FSUIPC -- the only example still existing that I know of being the Aerosoft (Australia) Piper Arrow cockpit, GA28R (of which I am a proud owner! ). The facility is described in the Advanced User's documentation. I don't know why you may have enabled this -- it cannot be enabled by default nor through the in-sim options. Edit your FSUIPC.INI file, delete the AxisCalibrations parameter, and the entire [Axiscalibrations] section, and you should find it is all okay. Regards, Pete

The units on the aircraft scale are not radians or degrees of trim angle, which is what 2EA0 represents, with 0 = Neutral. In your picture the actual 2EA0 value is not the factored one but the small value (.076) in radians. I assume the factored one is a conversion to degrees. I suspect aircraft trim indicator units are rather arbitrary, and used simply in relation to the performance tables which show correct trim values for different circumstances (mainly safe take-off trims for different weights etc). The values are arbitrary I think, as I said. You'd have to find out for the specific aircraft -- when 2EA0 reads zero, see what the trim indicator reads. Well, I would have thought that would be obvious. It must relate to the panel. That's what the pilot would see. On a real aircraft you don't actually have offsets like 2EA0 visible through FSUIPC, and the folks who made the panel are trying to simulate the real aircraft. No offsets whatseover. It's purely related to the markings on that particular aircraft's trim indicator. Pete

I've made some substantial improvements to the way the initial connection checks work, and also found a way to allow the COM port in use to be changed during a session without reloading FS. The improved version is 1.998 and is available above now. I could find nothing wrong with the quadrant assignment mechanism, and am loathe to fiddle with it as it has been working well for many years. I did check to see when and why the "assign to aircraft" button is missing, and this can only happen if (a) There is no known name for the current aircraft (yet). This can happen if the options are entered whilst FS is still initialising or loading a Flight or Aircraft. The solution is to quite the PFC options and try again when FS is settled. (b) The 737NG cockpit hardware has been selected as the 'console'. In this case most of the other options are inhibited and access to re-assignments is restricted to trained PFC personnel. To get out of this you would need to close FS and delete the PFC.INI file, i.e. start again. However, in the current version you cannot inadvertently select the 737NG console. Note that (a) also explains the occasional delay whilst the automatic assignment of a quadrant occurs. This is not an error or even a problem. The assignment may take a second or two to activate after any Flight or Aircraft load, or after any change in the PFC options. Regards, Pete

Didn't you find the documentation in the ZIP? It's called "WIDEFS.DOC". It does explain the parameters there -- you can tell the Client the name of the Server in the ServerName parameter. Anyway, I thought you said you had it working in FS2002 but not in FS2004? Why not simply use the same INI files for both? WideFS isn't bothered by what version of FS it is -- it leaves all that to FSUIPC. Is your client PC not running WinXP or Win2K? If it is, are both PCs in the same workgroup? It is a little odd that the Server is broadcasting its details but the client isn't seeing them -- the broadcasts use the Windows Mailslot facilities, which only work in Win2K and WinXP (and seem to need the PCs in the same workgroup). Otherwise you have to specify the server to the client, as in earlier WideFS releases such as the 6.47 you were using last time -- you did specify the ServerName that time, it was just wrong. Regards, Pete

Eryou would have to enter the serial port details first. And then it goes through the connection checks. I'm investigating a problem with that at present (in 1.997 -- are you still using that?). Please tell me how you got past the checks. After that, what was shown as the assigned quadrant on the first screen? It should have been the default, single prop, as you stated always happened before. There is never no quadrant assigned, it cannot operate that way. It sounds like you have not enabled any of the levers in the default quadrant, that's all? I really think there's something fundamental we are misunderstanding each other about here. I really cannot fathom why you, out of all the thousands of users, see something so different. Maybe, if I were standing behind you whilst you do these things I would see immediately what was up, and probably also perhaps see how you are interpreting what you are seeing. As it is I simply cannot understand anything -- it is almost like you aren't even using my program! Eryou must have deleted the FSUIPC.KEY file as well, as there is absolutely no relationship possible whatsoever between any PFC files and FSUIPC registration. On top of that FSUIPC registration is not needed at all for PFC to work. Perhaps you were getting rather confused and deleted more than just the PFC.INI file? No, actually, that is not interesting at all ;-). The Test tab only deals with switches and knobs, not axes. Only the assorted axis pages deal with axes. Just one other thought. Are you sure you never renamed a PFC.DLL version and either left it in the Modules folder or copied it someplace else in the FS folders? I really understand almost nothing of what you report. Most of it simply makes no sense to me at all. Sorry. Regards, Pete

Yes, of course. You can assign them as you like. This is in FSUIPC? Why not simply assign them as you want in FS? If page 3 shows that throttle 1 is mapped to all the others, that is only because on page 1 you have selected the option to map the single generic throttle so. Uncheck that option! Then go to FS and assign the axes to the separate throttles. You can assign axes as you like. In FS select Options-Settings-Assignments. The "manual" you should be reading is Microsoft's one for FS (or more likely the Help). There are axis assignment facilities in the latest interim version of FSUIPC, available here, but for such simple assignment FS is fine. Use it. Regards, Pete

Buggy? In what way. The quadrant system in my driver has always been the most praised part of it, and has remained pretty much totally unchanged for years with no other bug reports. What quadrants do you have enabled? By default the basic Cessna one is enabled if you have no others. I have never encountered any case where FS can be started with no quadrant active, because even if you have enabled none it auto-enables the first one, the default. Please ZIP up the INI file, then delete it and start again. It sounds to me as if you have something completely screwed up in the file somehow. Maybe you have an explicit assignment to a quadrant you haven't even enabled? P2 is the twin-engined prop qadrant. The entire set are as follows: P1N = single prop, non-carburated P1 = single prop, carburated P1H = single prop, high performance P2 = twin prop P2B = twin prop, Baron style (centre throttles) T2 = twin turbo J2 = twin jet J2N = twin jet, 737NG cockpit type (detented flpas, spoiler, twin reversers) J3 = triple jet J4 = quad jet U1 - U15 = User-defined arrangements Really, the first thing you should be doing after receiving your kit is simply enabling each quadrant you have or want to use. For non-specific automatic assignments the driver then uses an algorithm to try to match the best quadrant of the ones you have to the aircraft you choose. If you switch off automatic assignment you select one only (it has to be enabled), and you can do that on the front page, in the drop down. That way you merely change it when you manually mount a different one. The driver remembers the one which was assigned when you close FS, so it would start off with the same one next time you run FS. The other way is to associate specific quadrants with specific aircraft, but that really has much more application when you make your own assignments in any of the 15 user-defined sections. If the quadrant isn't being remembered, then possibly the PFC.INI isn't being updated? You have to close FS properly (FS does the same with its FS9.CFG file). After you close FS make sure it is really closed -- look in the Process list in the Windows Task Manager, make sure "FS9.EXE" isn';t still there. If there's no quadrant enabled, or none which anywhere near match the loaded aircraft, then that is correct -- that is the default selection. But you just said that NO quadrant was active! You cannot be correct in both statements! Please clarify. You are the only one of thousands, then. Please delete the INI (send it to me first) and try again. I really don't know what you've done, but I'll check it here. As I said this quadrant system has been working flawlessly for many years now, and has not been changed. The INI file is evidently important for me to look at, before you delete it, please. If you are enabling lots of logging it is best to keep the session short. Huge logs are no use to anyone, and if the ZIPped size is too big to attach here (> 240k or so?) then it is truly enormous. I just wouldn't be looking at all of that. What sort of logging? Why have it logging a lot during a long flight? Sorry, I've no idea. Maybe it was the huge logging that was causing the errors, if they are errors. Errors would be logged in any case, even with no logging options selected. Anyway, you have my email address now if you want to send me anything. Just make sure it is Zipped please. Regards, Pete

It isn't a "mode", it's a facility. As documented, clicking on the selection button at the bottom of each calibration column rotates between three settings, one being Automatic. Have you looked at the documentation? Try the section headed CALIBRATION -- it does explain it all there. There's a section with steps to calibrate manually, followed by another on Automatic. It is all there -- there's no point in me reproducing it here! What's a "throttle type"? Do you mean quadrant? Are you using automatic quadrant assignment (front page)? Have you made sure you have only enabled those quadrants you are actually using? Each quadrant calibration page has an enabling checkbox (top left). Only those you enable can be used. If you want specific quadrants with specific aircraft you can enable them and click the "Assign to Aircraft". From what you've just been saying it sounds like you've lost the documentation. Please re-download the ZIP and look inside. You'll find a document called "PFC DLL User Guide". Please read that, especially the calibrations and quadrants sections. All the questions you are asking are answered there for certain. Sorry, I'm not getting them -- I think you need to do some reading first. It will be a waste of my time trying to help by analysing logs from a completely incorrectly set up driver. In any case they most certainly shouldn't be very large -- the INI file only contains the settings and is small. Are you logging additional things to make the LOG file large? From what you say, your best bet is to delete the INI file and start again, following the instructions after you get the documentation. Well, not from what you've said so far. But show me an extract from the log and I'll tell you -- it certainly sounds like you may have a serial port hardware or driver problem! When you think you have understood and applied the correct setting, if you are still having problems, ZIP the files (most important) and send them to me at petedowson@btconnect.com. Regards, Pete

Well that's the name it is getting from the registry there. Are you sure you are getting the Logs from the right places? There really isn't anyway I know for the Server to get the Client's name before any connection in any case. What does the FS2002 one come up with? Well, there's not much to them, so I don't see the point. But certainly make sure you are using 6.51 or later all round, not a 6.47 client as now. and if it works on your FS2002 why not simply copy the INI files over from that? WideFS doesn't really care what version of FS it is and that certainly doesn't affect the connection part. The line ... Okay, IP Address = 172.16.1.34 in the Client log shows that it is finding "BobMichele", but the error Error on client pre-Connection Select() [Error=10061] Connection refused implies that access is blocked. You usually get that with a firewall problem, or maybe FS wasn't ready then. The two logs aren't for the same attempt (unless your clocks are wildly different) so it isn't easy to tell. Regards, Pete

Yes, and the answer is staring out from that. Look: Date (dmy): 23/04/06, Time 07:12:46.984: Server name is BOBOWABO and Date (dmy): 23/04/06, Time 13:42:48.984: Client name is BOBOWABO 515 Attempting to connect now 2625 Trying TCP/IP host "BobMichele" port 8002 ... Don't you notice anything odd? Both Server and Client are named "BOBOWABO"! Uh? And the client INI is told to connect to "BobMichele" which is neither of them. Also you are using WideServer 6.51 but WideClient 6.47. Please make sure you update both parts, not just one! Regards, Pete

Whilst I was re-checking the FS98 gust setting facilities (the offset 0F78 you are/were using), I re-discovered an old improvement I made back in FS2000 days, documented in the FSUIPC Programmer's document thus: Whilst it does say "FS2000" this actually, for onward compatibility, applies to FS2002 and FS2004 as well. So, in addition to merely setting gusts on or off (1 or 0) you can easily actually set the gust limit value rather than leave FSUIPC to compute a random one for you. In checking this mechanism, by the way, I could not make it produce any odd or extreme amounts such as those you mentioned, so I am still dependent upon logs from you to tell you what was going on. Regards, Pete

Well, things do go both ways of course. In my case, the PCs running the MCP and CDUs will be just as much feeding into FS as getting and displaying data from it -- especially in automatic pilot modes (PM's MCP is not only the control program for the hardware MCP, but also an advanced autopilot, using LNAV and VNAV route information from the CDU). And of course the weather program (ActiveSky), pmSystems, fsRealTime and AIsmooth are more about feeding data into the simulation than taking it out. Not at all. Regards, Pete

Yes --- flying independently, as I thought first time? Yes, that's what I answered first time. WideFS can do it, but you'd need two copies of each such program, one of which is altered (internally) to connect to the WideClient with the changed ClassName. You'd have to apply to the authors of the weather program and Squawkbox to ask them to alter their programs so this could be done. You may also find, of course, that for other reasons they don't run more than one copy at a time, so that would be further alterations needed. Ereven if that were possible, what happens when your friend is flying in one part of the world and you in another? You'd need the weather program adapted to detect two locations and supply weather for both. Similarly, Squawkbox would have to be altered to provide the ATC folks the details of both separate aircraft. It really is a big re-write. No, each client connects to one server. If it connected to more, what position, identification, airspeed, altitude, etc etc does it convey to its local applications? Please think about it. There's only one set of data provided by one WideClient. How could it possibly deal with multiple Servers? The Server can deal with multiple clients because it can send the same data to each. There's only one User Aircraft, one position, etc. I don't know what he is using, but I typically use 10 PCs with my cockpit. There are 6 inside the cockpit itself, all Clients, as follows: 1 for MCP (Project Magenta MCP software connected to a PFC hardware MCP) 1 for Pilot's PFD/ND, running PM's PFD/ND and using a 17" TFT screen 1 for CoPilot's PFD/ND, similarly 1 for the main (pilot's) CDU, running PM's CDU on a PFC hardware CDU 1 for the second (co-pilot's) CDU, running PM's RCDU on another hardware CDU 1 for the EICAS screen, running PM's EICAS on a 10" TFT. Outside the cockpit there's 4 more PCs: 1 real fast one running FS2004, this is the Server 1 running pmSystems (for the overhead), pmSounds, ActiveSky, AISmooth, AI_WxR, FSRealTime and Radar Contact 4 (for Air Traffic Control). This is also quite a fast PC. 1 sometimes running PM's Instructor Station 1 running Jeppesen Flitemap in "moving Map" mode. It is also used for flight planning, feeding the plans directly to the CDU and Radar Contact. For Project Magenta information look at http://www.promagenta.com. Tale a look at some of the cockpits pictured in the gallery there -- most if not all use multiple client PCs. My cockpit is the 737NG by PFC -- you can see it on http://www.flypfc.com. There's also a cockpit-builder's Forum here you may wish to browse. Regards, Pete

You'd need two copies of each such program running in any case, as I mentioned. Then the problem comes with how they identify which server to connect to. As far as they are concerned, the FSUIPC interface is the FSUIPC interface, there's no more than one on a PC. Multiple Wideclients can actually be run on one PC, by changing the Classname -- there's a parameter for that in the INI (it is documented). The Server to which they connect would be declared by the ServerName parameter, and you'd need to select a different Port for one pair 98002 is the default). However, the programs would only actually connect to the one running copy of WideClient which is still using the original Classname, because that's how they identify it. You'd need to apply to the programmers of those programs for versions which allowed you to change the Classnames used in their code. I really don't think it's going to be feasible, apart from which I doubt that your Notebook would stand the strain of 6 fairly heavyweight programs, especially two moving maps even if the screen were wide enough. Erbut how are either of you flying if the only single copy of FS is not being used? Or am I misunderstanding something here. That proposal seems to make no sense. What are the Clients being used for? If you only have one copy of FS you only need one Squawkbox, one moving map and so on. And a laptop screen is unlikely to be very suitable for two of you to view the cockpit and scenery so well even if you were actually flying. Why a laptop in any case? They are very expensive and far less flexible for what you need. If there are two of you flying independently I can't see what you are linking the PCs for in any case, except by Multiplayer so you can see each other's aircraft. Have you tried running Squawkbox in the same PCs as each of your FS's? There seems still to be something here you aren't explaining, I think. Regards, Pete

Eryou will have 3 PCs on your Network, and want to run two separate copies of FS on two of them with one client linked to both? Can I ask why? Are there two of you, or are you flying two aircraft simultaneously for a bet? Obviously a sinlge copy of Squawkbox or a moving map won't deal with two separate aircraft at the same time -- the Controllers via SB will want to see each aircraft separately, and I how does the map independently move to continue to show both aircraft? Please explain what you want to achieve. It doesn't sound sensible at present. Regards, Pete

Not my FSINN! I don't have one. ;-) Okay. They know they can contact me if they need advice in that area. Regards, Pete

That sounds completely wrong. What interface to FS are you using? What timer facilities are you using? The standard timer tick is 55 mSecs, so that's the granulation you'd see, and it also applies to the Windows "SetTimer" and TIMERPROC system. For timings accurate to a millisecond you need to use the performance measurement API calls (QueryPerformanceFrequency, QueryPerformancecounter). If you wanted to drive something more frequently than every 55 mSecs you'd need to use a separate thread sending you a message at other intervals. In the thread a Sleep(n) can be used to sleep for n milliseconds, and that time isn't abiding by the 55mSecs granularity. It is all to do with some of the many FS chains you can hook into. There are chains related to frame rates, to gauge updates, to all sorts of events. It used to be easier to hack into -- CHAIN.DLL used to deal with it all. It's now all inside the main FS9.EXE. You might find it easier to hack into FS98 or FS2000, work things out, then track down what you found in FS2004. Or wait for FSX where it will all change again. Yes, the chain appropriate to the sort of thing you are doing. There has been discussions here before about all this. You may find it profitable to search on the word "chain" or similar, here, or over in the program development forum in Avsim. Regards, Pete

Ah, in that case it is a built-in FS function. Yes, the addition I made to FSUIPC was not intended to remove those, only those from application programs. Okaythis will include FS's scrolling ATIS message too. But it won't be "all messages" -- multiline messages are controlled by the other two options. So it will be "Hide all single line messages". Okay? Regards, Pete

Is this a message from FS's multiplayer routines, or from a program using FSUIPC to display it? I am only suppressing the latter, assuming that option is selected. If it is from an IVAO module installed in FS which uses the FS facilities directly, then FSUIPC doesn't see it. Unlike AdvDisplay, FSUIPC isn't currently hooking the FS display routines. I don't have any programs which produce such messages except through FSUIPC. I could possibly add the intercept to FSUIPC and make it remove the others too, assuming AdvDisplay used to, but distinguishing between those from add-ons, add-ins and FS wouldn't be possible. It would be all or nothing. Please clarify. Regards, Pete

Thanks. I had a brief look. You seem to have some editing errors: for the WieClient parameters KeySend1 and KeySend2 are entered twice for the same key, F11. I assume they should be 3 and 4 for F12? Regards, Pete

All my programs are in C (even with some ASM on occasion) which compiles into native Intel Pentium code. It can be very compact and efficient when optimised. No, it isn't anything to do with the number of variables. I suspect that even if you read the whole 64k address space yours wouldn't expand significantly. C# is not a native Intel program, it is what I call interpreted (Microsoft calls "Managed"). Basically that means that most of the code in the memory occupied is part of the interpreter/manager, not really part of your program. I really doubt you could even write a simple "Hello world" program in C# which didn't take oodles of memory. This is just my opinion of course. I may well be proved wrong. I've not even moved to C++ because it's too far away from the machine levels I understand better (or used to). I've been a nuts and bolts programmer now for 43 years so I'm entitled to such prejudices! ;-) Regards, Pete

This is the problem using generic calibration systems on such a huge variety of axes as supported by FSUIPC. Since the whole thing is based on numbers, I had hoped Min and Max was obvious. Sorry. With all axes the orientation (left/right/forward/backward/pull/push etc) is all relative and dependent upon both hardware and driver implementation. This is why both FS and FSUIPC have "reverse" options. Spoilers/speed brakes for instance are off when pushed away from you, completely opposite to throttles. Flaps are the same. It all has to be configurable. Yes, I was trying to be helpful where I thought that confusion was less likely. Well, that would doubly confuse folks whose control was the other way around. Also I need headings for pairs of controls (or change the design considerably), so it is difficult to fit that in. On top of this, the interface has been like this for over five years and this is the first such complaint. Seems most folks do manage to dollow the documentation -- I do provide steps there which should be clear. For instance the documentation most definitely doesn't tell you to start in the middle as you said you did. ;-) Unfortunately I had to make the aircraft-specific system for axis assignment work differently to that for buttons and keys. The "general assignments" do not apply to aircraft which have specific assignments. I did have it the way you are thinking, but that gives really terrible problems if on some aircraft you don't want one of those to apply. The reason is that connected axes are never inert. Unlike buttons and switches, even if they are not used they are providing inputs when polled, and those when enacted on an aircraft for which you didn't want cause havoc and utter confusion. In the current implementation I simply only poll those axes assigned for the current aircraft, which solved a lot of weird problems. Sorry that the interim documentation wasn't explicit here (it only shows when you compare the wording of that option for axes with that for buttons and keys). Here is my proposed User documentation paragraph replacing it: Your best bet now, to save time, is to copy your generic settings from the general [Axes] section to the specific sections in the INI file. Just be sure to renumber the left-hand values to retain a complete nummeric sequence. When you confirm by pressing Ok. You can do all sorts of things throughout any of the FSUIPC option pages, but if you then cancel, close or escape they are all wiped and previous settings restored. Then buttons, keys and axes are written to the INI, but many options are not written till the session is closed -- this emulates FS quite closely in its practices (we both use the same sort of mechanisms). No, as it certainly says someplace in the documentation, you can always do that whilst running FS by simply using the Reload button -- there's one on each of the Axes, Buttons and Keys pages. Regards Pete

Actually that document was submitted by someone else. I don't include it these days as it was for Roger Wilco / Squawkbox and the mechanism for those has been built into WideFS without the need for parameter changes in WideFs now, only assignment of buttons or keys to the PTT/PVT controls in FSUIPC's dropdowns. Actionkeys is redundant completely now in any case -- all WideClients look for keys without needing that. As far as I know the gentleman (whose name I've lost) who submitted the original help was only trying to help others in any case and would not object to the continued use of it in any form for similar purposes. Regards, Pete