Pete Dowson

Thanks for coming in here. Tell me, is what you've said any different from what you do if you only have one PC and want to run it on the FS PC? That was what was confusing me about the questions -- why would it be any different? Regards, Pete

Sorry, that had nothing to do with anything else and the word "subtle" doesn't have any meaning in connection with it. It was just good advice, which I thought you wanted. You are asking me questions which I really either cannot answer or have no business answering, especially as I would be biassed towards my own flight interests (737NG). If you want to know what gauges and aircraft and other programs are available for FS you need to browse, take a look. For example, if you want to know more about PM go to the PM site. And so on. This is not "technical" advice, it is surely common sense? It was in no way meant to be offensive as you seem to have completely misread it. I do try to support my own programs to the best of my ability, and I really cannot support and sell other people's or advise on their use to a wide variety of different interests. You know what interests you, please go and take a look at what is available. I am always here to help with FSUIPC or WideFS or other of my programs, should you need such. Please just ask. But I honestly cannot tell you much about programs I don't use and often haven't even seen. Sorry. If you have general questions and just need advise about where to go, what to look at, the FS2004 Forum near here would probably be the most appropriate in the first instance. Regards, Pete

Surely, since the whole point of WideFs is to allow programs which interface to FSUIPC to run on another PC, you do exactly as the tutorial says but on the WideFS client PC instead of on the FS PC? You must surely put it on the PC on which you want to run it? That is the point of having the program, so you can run it on the PC of your choice. There's no point putting it on the FS PC if you want to run it on the client PC. As for IP addresses, why should any of that be any different? I don't understand why the Google linking and so on is changing simply because you install programs on PC2 instead of PC1. I don't know, I haven't a clue what this question means I'm afraid. What is different about having it on PC2 instead of PC1 which gives rise to these questions? I think you need to ask questions about MyGoogleEarth of the MyGoogleEarth author, please. I really don't know how to answer -- should I reproduce MyGoogleEarth's long website instructions here? No, of course not. But what else? I don't understand what you are seeing different about installing it and setting it up on a different PC. Just pretend your client PC has FS installed in it and do the same as if it was. I'm at a loss. Sorry. He doesn't support his programs? Not even on his website? Really, if I knew anything about all this I would maybe be able to be more excplicit, but I am not the author, I tried it but once, a few weeks ago. I don't actually get time to play with such niceties so I don't learn that much about them. But his instructions did seem to be clear enough. I am not sure how I help. Regards, Pete

Sorry, I was simply illustrating that I didn't know what you were asking. Yes. FS is only running on PC1. Though I wouldn't use the Baron with the Boeing Glass Cockpit set of PM modules I have. I think they do a GA system based on a Garmin glass display which may suit the Baron. I only fly a 737-700 on my 6-screen setup and I am not an expert on all that PM provides. Yes, of course. That's what they are for -- though I don't think you'd get a good looking result for a Prop on jet aircraft instruments or vice versa. It works the other way too of course -- the PM's MCP/Autopilot and FMS can control the aircraft -- given matching PM and FS aircraft settings. All this sort of information is really best obtained from Project Magenta. You can check their entire range of products. I am only using the Boeing stuff. Well, I'm afraid your sarcasm does you no credit and has no place in intelligent discussions. I thought it was obvious that it was your original question which was not answerable without further questions that I was illustrating. Please do go and do some investigations, explore things that interest you THEN come back for technical assistance as and when you actually need it. I am not a sales executive for PM or any other programs, I can simply explain that WideFS links programs NOT part of FS to FS via FSUIPC. That is its function, which I am sure I have explained in completely non-technical terms many times in this forum, to you as well I think (in another thread). I suggest we stop this thread now and I let you go some research elsewhere. Okay? Regards, Pete

Of course it is. "Question about WideFS and multiple screens". I didn't know which thread you were in here -- that's the reason I don't like Private Messages for non-private one-off things, there's no threading there. You broke this thread unfortunately. Pete

This is in answer to a message sent privately by mistake: How do you mean? Just plug the monitors into the Parhelia card and switch on. I don't know what you mean else? I three 18" TFTs on a shelf about 3 15" TFTs. The upper ones are showing only the outside view from FS as one 3840 x 1024 screen. The lower ones are the instrumentation. Project Magenta Boeing glass cockpit -- Pilot PFD/ND -- EICAS -- Copilot ND/PFD. There are no outside views connected by WideFS because all the outside views are on one PC, the only one running FS! WideFS has nothing whatsoever to do with views. If you want multiple outside views on different PCs you need WidevieW. If is a different program entirely, not mine. Regards, Pete

I don't understand. Are you writing a program to interface to FSUIPC, or is this all keyboard stuff direct into FS (or FSUIPC's "Keys" options) without FSUIPC's programming interface being involved? It makes quite a bit of difference. Programming you would simply test your engine select switch position and then use the appropriate engine offsets in FSUIPC to start the selected engine. If this is all just keyboard codes, then you probably don't need FSUIPC anyway. Just make the engine selector send the engine select sequence (E then 1, 2, 3 or 4), and your starter the normal generic starter operation. Sorry if I misunderstand the problem but you don't give enough information for a definitive answer. Regards, Pete

Sorry, I only know as much as you can read about the GoogleEarth link. What sort of tutorial do you want? The documentation by the author seems excellent and I'm sure he'll answer questions if you have any. If you mean WideFS tutorial, it is unnecessary. Don't use any IP addresses, just put the ServerName into WideClient.INI, as per documentation. If you download the Beta WideFs from this Forum you don't even need to do that providing both PCs are running Win XP. It sorts it automatically. Pete

Please, please do read the documentation a little more thoroughly. It isn't that obscure! Offset 0020, which you are reading, clearly says that it is the GROUND altitude, in metres x 256. The ground beneath you is NOT going to be going up with you when you climb, nor down when you descend!!! The ground altitude depends on the mesh underlying your scenery! 33474/256 = 131.73 metres or 432 feet. That's the ground altitude above sea level at the spot beneath the aircraft. Pete

Without more details I'm afraid I can't help. Pete

With nVidia and Matrox, at least (not ATI I think) you can configure the two screens as one larger screen. If you do that you can have a much larger FS screen which is all hardware accelerated. I think, since DirectX8, and on WinXP, more than one 3D window can be accelerated at once, but it doesn't matter how you configure it, FS runs really slow with more than one 3D window open. Yes, it is okay for panel parts undocked though. Regards, Pete

Yes. But it wouldn't suit all planes. There are various parts to PM. You can purchase a complete Boeing or an Airbus set, including an excellent FMC, or stuff for a Regional Jet, but I don't think you'll find anything completely suitable to props and light aircraft in general. But it isn't me you should be asking. Go look at their website. For light aircraft like the Cessna, or even the Baron, the better route is the hardware one. The Real Cockpit do nice gauges (under their SimKits banner) and even supply complete cockpit sets. For VFR flying I use a nice hardware panel (for a Piper Arrow III) made by Aerosoft Australia -- but the don't make them any more. Regards, Pete

FS panels, no, Project Magenta, yes. In fact PM was designed for use on several PCs. I actually use 6 PCs for it in my cockpit, though two or three are quite adequate. There's a freeware set of panel programs too, FreeFDs I think it is called -- check the links on http://www.schiratti.com/dowson. Regards, Pete

Gauges are small library routines, just DLLs, than have to be run inside FS as part of a panel. They do not run through the FSUIPC interface to connect to FS so they cannot use WideFS, which is only a Network extension of the FSUIPC interface. If parts of FS were dependent upon FSUIPC for interfacing to FS I think Microsoft would have written it in the first place, don't you? ;-) Any programs (not modules or graphics or aircraft or panels or scenery) which interface to FS via FSUIPC. That's all. Nothing else. Why weird when FSUIPC was written explicitly to link things NOT part of FS to FS? FSUIPC would not be needed to link parts of FS to FS, now would it? THat would indeed be weird. I think you are thinking things backwards? ;-) Interfacing any program which connects to FS via FSUIPC from another PC on a Network. That's all. Go look at ActiveSky, FSMeteo, Radar Contact, Project Magenta, FreeFS, FS Real Time, FlightTracker, Flight Keeper, FDC, TrafficBoard, FSMetar, AFCAD, etc. There's a list of some on the download page at the Schiratti site. If you have no need of any programs other than FS and add-ins like scenery and aircraft then you don't need WideFS and don't really need FSUIPC unless you ant to make use of some of its additional user facilities. (Although of course some panels also use FSUIPC for some things too). Regards, Pete

Please try different aircraft, and always say which aircraft you are using. Don't you have FS2004? I think all FSUIPC does is pass this on to FS, which may not care what value it is when it isn't applicable but may force a change else, hence the needfor checks on appropriate aircraft. Try switching it in FS and seeing what values you get back. I didn't obtain that list, it was provided by someone else who did such tests. Pete

That DLL is an essential part of Windows. It contains nearly al the Windows interface along with USER32.DLL and GDI32.DLL. There may be others, but between them they cover most of what is known as Windows as far as application programs are concerned. You don't really need to "know" about the DLL to use standard Windows interfaces, they should all be documented in your VB package and you should be able to use them without any explicit links. The ones used for serial ports and other devices are also the standard file access facilities. Pete

This is why I always ask those who say they don't understand to be much more specific, so that the wording in the documentation can be improved. And it has been. The stuff on calibrations was improved a great deal in that way in its first few months, but that was about five years ago, and considerng the number of users the number of folks still not understanding it are very very small and those are the ones who are never explicit. It is no good people asking me to explain things any better than I have done because I have done my best there given the feedback I've received. What would be the point of repeating here what is in the documentation? The only sensible process is to get to the real reason someone misunderstands and then trying to word that differently. Quite honestly, users who are computer literate and aircraft literate enough to understand how to use MSFS and fly aircraft with it must be pretty intelligent to start with, so I assume 99% of misunderstandings are simply because my documentation is in English. Why are you looking in FS9.CFG and Devices.cfg? Are you so computer literate you now want to mess in FS's technical files? Why? Anyway, the answer to your first part is that I haven't a clue and I don't think it is at all relevant, and to the second is that FSUIPC doesn't know and doesn't care anything about any devices, joysticks or CFG files. It is only dealing with FS controls, NOT joystick axes themselves. It is FS's job to deal with its CFG files. It is in FS where you make assignments, set sensitivities, and so on. FSUIPC only sees the controls resulting from all that, it doesn't know or care how they get that way. I've really no idea. It was simple enough before FS2002. Since then (when FS changed to DirectX for its joystick inputs) everything changed in that area. I never delved into it because it isn't relevant to anything I do. If you wanted to find out you'd need to experiment. I think the SCALE value is set by the Sensitivity slider and the NULL by the null zone slider. I assume they are axis numbers on that device. But which is which I have no idea. I used to know before DirectX came on the scene. To find out more you really need a programming book on DirectInput. But I cannot imagine what it is you are needing to know this for, unless you are trying to program something? No idea, sorry. Please see if you can look this stuff up in a book on DirectX. Programmers count from 0, it is the first number. Are you programming then? What's all the earlier stuff about computer literacy? What does "offsets" have to do with any of the rest of your questions? If you mean "FSUIPC offsets", then the answer to "what they are" is really simple. They are "hexadecimal numbers relating to the positions of values in FS98's GLOBAL.DLL data area -- they are the number of bytes offset from the beginning of that area, offset 0000", The answer to "what they do" is "nothing, they are just numbers". Applications use them just as addresses in reading and writing this "memory" via FSUIPC. Since FS98 I have maintained the same offsets for values for compatibility in application programs. Before FS2000 they were different for each FS version and so applications had to be modified for each FS version before they would work. In order to maintain the same offsets and add more as things grew more complex, FSUIPC has to work a bit of magic -- there's really very little such data in FS's GLOBALS.DLL these days. So the memory area implied by these offsets does not exist, it is all smoke and mirrors. Regards, Pete

That's the device name you need then. It isn't a function of C but of Windows so it is language independent. All of the routines you need to call arre in KERNEL32.DLL, part of Windows. Surely you have some documentation on reading and writing files in VB? You want the CreateFile(), ReadFile(), WriteFile(), CloseHandle() routines. Other calls applicable to serial ("Comm") devices include SetCommState(), ClearCommError(), EscapeCommFunction(), SetCommTimeouts() and PurgeComm(). Regards, Pete

Sorry, I've no idea how to handle USB ports, let alone one with a PDA on the end. If it is merely a named device I would assume you open it as a file ("CreateFile") then WriteFile to it, and CloseHandle at the end. As for any device or file. Regards, Pete

What is the "FSUIPC-Joysticks-Slew Axes-Slew Heading"? I don't have such a thing. If you are talking about the slew calibrations on page 10 of 11, none of those are operative if the top left button in each reads "Set". If it reads "Reset" then calibrate, or press it to switch FSUIPC calibration off -- it then turns back to "Set". Pete

Sounds like you've not calibrated your controls in Windows at all well! Just calibrating them in FSUIPC isn't ideal, as FSUIPC is only manipulating the end results. With bad Windows calibration you are likely to get less resolution and even asymmetric sensitivities on either side of centre. Best to go back to Windows, calibrate everythnig as best you can there, then load FS, check that it all works reasonable well, and also ensure (in Options-Settings-Controls-Sensitivities) that you have max sensitivity, min null zone, and then go into FSUIPC for its refinements. The slew mode calibrations in FSUIPC do work but they are only a recent addition -- really you should be able to use slew in FS without FSUIPC, indeed, as most of course do and have had to for years. Which joystick screen? Slew controls are only on Page 10 of 11. When you say "Set" mode, do you mean you've pressed the 'Set' button so that it reads "Reset"? That's when you can calibrate. In Slew mode you cannot calibrate the normal controls, only the slew controls -- which have their own page. I don't provide calibration for all of them, only the main four. The normal controls don't get through FS when in slew mode, nor vice versa. You should bear in mind that the FSUIPC facilities are not calibrating joysticks but FS controls -- the things that FS is using internally. FSUIPC has no idea what actual axes are being used at all. Regards Pete

Well, I've not done this in a program, but you could easily check for yourself using FSInterrogate (you can WRITE to FSUIPC in FSInterrogate as well as read and observe, you know). Anyway, for just a simple percentage increase/decrease you don't need the actual capacities -- you'd only ever need capacities if you wanted a fixed number of gallons or litres or pounds of kilograms of change. You just need the fact that 100% level is known to be 128 * 65536, or 8388608. In "pseudo-code" (i.e. no known language): Read the levels for all tanks (in one Process call) For each tank, assuming its level readout is now in 32-bit integer 'L' For 1% increase: L = L + 83886 (which is (128 * 65536) / 100, thus 1%) Check L <= 8388608 (this is 128 * 65536, representing 100%) -- if not set L = 8388608 (100%) For 1% decrease: L = L - 83886 (which is (128 * 65536) / 100, thus 1%) Check L >= 0 -- if not set L = 0 (0%) Write L back to level offset for this tank Loop for next tank Do the Process call for all the tanks written Pete

Strange. I don't insert the checksum, that goes through a routine to generate it. Maybe I didn't re-initialise it for the second sentence of the same type, though in that can 2.581 should have been wrong too. [Later] Yes, there was a statement missing. The sum provided was including the complete preceding GSV too. The same applied to the previous one I sent -- most odd that it didn't fail. Try 2.583 attached. Sorry, I've not had time to test any of these myself. Pete GPSout2583test.zip

"Groan". :wink: Attached 2.581. Pete GPSout2582test.zip