Pete Dowson

Unless you've somehow got a corrupted copy, I really don't think it can possibly be an FSUIPC problem. Changing the module is merely changing the order in which all the modules are loaded in the Modules folder, and therefore causing a slightly different memory arrangement. It sounds like something is going wrong in any case, but not always in such a way as you get a crash. ATC.DLL is not anywhere near anything that FSUIPC has anything to do with in any case, and the changes from 2.972 to 2.975 are trivial. Possibilities are sound card problem, Traffic BGL or AFCAD problems (have you added any aircports or AI traffic stuff at all?). If you are using Win95 or 98 or even ME, you can, if you like, try to get a DrWatson dump and I'll take a look. Please see the "If FS crashes ..." section of the FSUIPC User Guide. With Win2000 and XP I'm afraid the dumps are pretty useless to me. You should know that I get the odd report that version x crashes FS whilst version x-1 does not EVERY SINGLE TIME I make a new release. In the 40-odd months it has been continually updated there's been only about one of these which turned out to be an FSUIPC problem (two counting the recent one where I fogot about FS98 in one release, and FSUIPC tried to do FS2002 things on that simulator which a nasty result!). Not long ago I went through an extensive (and intensive) exchange with one user who swore blind that the only thing he changed was FSUIPC -- until after over a week of this he suddenly realised he'd also installed a new aircraft or something too. when he de-installed that his problems disappeared! I'm not saying this applies to you, but it is nonetheless wise to consider everything when faced with problems. Regards, Pete

Okay. In the Server INI you have: UseTCPIP=Yes but in the Client INI you have: UseTCPIP=Yes ServerIPAddr=192.168.0.1 UseTCPIP=No I expect the second copy of "UseTCPIP" will win over the first! Rather than use an IPAddr you may find it easier to use the ServerName, unless it is hard to spell correctly! Regards, Pete

Please tell me why you do not understand the documentation. I keep adding more comments to help, and even examples now. What else can I do? How can I explain any better here when I fail so miserably in the proper places? Please help improve it, not try to bypass it, it doesn't help. Thanks & Regards, Pete

That's because I managed to hack into their programming interface (which they provided but then did not publish for reasons best known to themselves), no other reason. If it can be controlled by keystrokes you can program that yourself. There is no programmable interface provided by the DF folks, so there's no other way possible. Using PFC.DLL in combination with FSUIPC Button programming facilities you can actually re-program almost every switch, knob and button on the console. But if there's no way to control the panel other than using the mouse, you are stuck. you could try the freeware program "key2mouse" or whatever it is called. Sorry, I don't have a URL. If the DF folks don't use the standard FS anti-ice controls for their de-ice, then that is not surprising. The standard FS light switches are already well catered for in the PFC driver, I cannot support others -- but you can program switches if there are keyboard codes for them. There's no APU simulated in FS. No. I do not mind adding code pecially for some of the more popular cockpits, if the designers provide a programming interface and tell me about it, but most do not. There is no way I can hack into the innards of every gauge and special panel out there. Life is too short. Sorry. >> When I link the APU+ to the APU-switch of the console within the menu << What APU switch of the console? Sorry, you've lost me. How are you linking them? Regards, Pete

I am using Win2000Pro on one PC, WinXP on two others and Win98SE on two others. WideFS 5.41 is running using TCP/IP with never any problems. There are no problems if your Network is working. I have absolutely no other protocol enabled on the Network. You need to get the network working well, then it is easy. Regards, Pete

This is ALWAYS because the protocol you are asking WideFS to use is not installed. At least I've never yet seem such an error which wasn't because of this in the 6 years WideFS has been around! May you should use the "UseTCPIP=Yes" parameter? There is no "TCPIP=Yes" parameter. Regards, Pete

Most are both, but FS won't necessarily respond to them all being written. Things used to be a lot clearer in FS98, but times change. Use FSInterrogate and experiment, that's the way to find out. Actually heading roll and pitch are normally only settable in paude or slew mode. Certail Lat/Lon/Alt are always settable. Engine/Sim derived values are calculated and overwritten constantly by the simulation engine, so don't expect to be able to change stuff like RPM, N1, N2 -- except maybe in slew mode where it means nothing. IAS is a derived value. If the aircraft is at rest it has to be accelerated to achieve a speed. In slew mode, or with the simulator actually stopped some other way (such as setting the Sim Rate to 0) you should be able to affect most things, but whether you can do everything is a matter of trial and error. Most of this changed between FS98 and FS2000 when the sim engine was rewritten to be completely dynamic. Regards, Pete

Sorry about all that. It was going to be 2.974 and I rounded it up before release. Seems like I changed one part but not the other. Thats the trouble with haste. And I've not been well. Don't worry about it. Just assume 2.975 == 2.974! Regards, Pete

Assuming you mean a .dll for the Modules folder, there is no published information. Why would you want to do such a thing? It is a lot of work and really unnecessary -- what do you hope to gain? GAUges are DLLs. the only difference is that they are loaded by the PANELS system instead of loaded initially by the FS main code. Learn to write Gauges first, then you are half-way there. But ask yourself what you want to be doing running inside FS's process? What is this needed for? Is the FSUIPC interface, especially extended across Networks via WideFS, not sufficient for your needs? Regards, Pete

Er, no, sorry. I learned programming from the hardware up, starting in 1963. Getting into other folks' code without their help and their source first means learning assembler code, then using a disassembler such as IDA Pro (which I use) and a debugger such of Soft-Ice (which I also use, at least a very old version of -- can't afford updates to this expensive item!). It is not likely, at least for gauges, no. You can get the memory address from Windows. Use LoadLibrary. In the 32-bit windows world the handle that returns is actually the base address of the DLL. If indeed it is stored withon that space. It may allocate memory and store it there, in heap space. You'd need to find a pointer to it then instead. It takes a lot of work analysing disassembled code. I have to do this sort of stuff all the time, to make FSUIPC work inside FS, and it takes many many hours -- months and months for complex things like the FS weather. Regards, Pete

Sorry, you can see I'm new at this forum stuff. I seem to have managed, somehow, to have replaced your original message with my reply! I hope it is still useful, but it does make this thread look a bit silly now! Regards, Pete

I assume this means you solved the problem yourself already, Tony? Was it simply the ServerNode you forgot to add to the client INI file? This wasn't needed in all Win98SE setups, but WinNT/2K/XP complicates things, unfortunately. Best, Pete

You need a centre "null zone". In the PFC calibration section, select the rudder so it it highlighted (has a frame around it), then press the rudder a little one way to set one of the centre limits (see the buttons to the left), and then the other way to set the other limit. It is all explained in the documentation. While you have that selected you can if you wish also adjust the response curve (the graphic on the left) to suit your needs. Seems like you are looking for the wrong thing. It isn't a "sensitivity" adjustment you really want in the centre, it's just an area of no action, a "null zone". You can adjust the slope, viewing the graphic on the left, to change sensitivity, which is a different matter. But if it is less sensitive in the centre (flatter) it has to be more sensitive in the extremes (steeper) to allow full deflection to still be attained. FS's own sensitivity doesn't operate in the same way. In that case it probably isn't providing the same level of resolution as the PFC connection. Some small amount of jitter is qite normal, though it shouldn't be much. Variations in temperature and other factors cause the resistance through potentiomenter coils to change slightly, so any system measuring it with any accuracy will usually see some variation. If you have a lot, you need assistance from PFC or your suppliers, though, not from software. Maybe there's a problem with the controller card in the throttle system, or possibly it has an inadequate power supply? Regards, Pete

Something suddenly occurred to me, from an earlier message. One question, Joshua, before this goes possibly way off in the wrong direction, when you say: Can you tell me exactly what modes you have set for the FD to direct? The values you quote sound suspiciously like the exact values which a non-directing FD would show -- the non-bank because there's no heading mode selected, the 0.2 something is a normal default pitch when there's no climb or descent involved. Is this merely a case of misunderstanding what the FD does? Make sure you set HDG mode on the A/P and adjust the heading so that the FD indicates a turn -- does the Bank still stay zero? Set ALT mode and adjust the Altitude to indicate a climb. Bank is +ve for right bank, -ve for left, pitch is negative for pitch up, +ve for pitch down. The values are not NEEDLE positions, they are the pitch and bank values which the needles should direct the pilot towards. How they actually do that, graphically, then depends on the current aircraft pitch and bank, the IAS (probably), and of course the type of inidicators used -- crosshairs and chevrons operate slightly differently. You aren't expecting these values to tell you specifically WHERE to draw the lines, are you? Please confirm that you HAVE tested all this with an actively directing FD? Regards, Pete

It uses a special non-supported call to FSUIPC, to do a "lookup_var". It was an original experiment to try to make external gauges using the same sort of system. But it is far too inefficent. FSLook can bring FS to its knees. It was never followed up for that reason. Worse, it cannot be used through WideFS -- WideServer needs to keep scanning values for changes, this method is too slow. I kept FSLook available just as an assist for gauge makers, not for real time use. Certainly, they work fine. That's what I don't understand. These values are used by others quite successfully. FS2002 under WindowsXP, another on Win98SE and another on Win2000Pro (I need multiple setups for testing). Try using FSUIPC IPC logging (see the Technical page) -- you can ask it to log Reads or Writes from your program. Use FSInterrogate also to verify what you are seeing. It doesn't sound right at all. This is not a problem area, not something that ever didn't work. the values are simply there, they don't need processing or coaxing or anything. Did you confirm which version of FSUIPC you were using? Do you think you may have any other add--in modules which could be interfering with this? Regards, Pete

... and the same in FSLook? They are both simply reading the same thing the gauge must be reading. I cannot make it go wrong here at all -- only in pause or slew mode do the values stop being updated. This is with the default 737-400. It seems to be behaiving just fine. I really can only pass on to applications what FS passes on to me, or in this case also to the gauges. FSUIPC isn't doing any calculation or derivation at all here. It is merely the "window", not touching anything. And FSLook does not do it from the locations you mentioned, it actually reads the gauge token values in EXACTLY the same way as gauges do! Regards, Pete

HmmmI don't know those fields, personally. I'm just providing what FS provides -- as you have detected with FSLook, it is in fact what FS provides to allow the FD needles to be programed in gauges. In the cases where they are not correct, are you saying that the FD bars in FS's gauges are not the same? If you are checking this on an aircraft not equipped with a flight director, then I don't think you'd expect the needle values to be updated. You don't need it to have a gauge with FD, but the AIR or Aircraft.CFG file must show it to be so equipped -- for instance, the [autopilot] section will have "flight_director_available=1". Did you check this? Also, of course, the FD should be active, else the needles won't be updated either. I've just checked all this with the default FS aircraft with FDs and they seem fine. Regards, Pete

"Sorry sir, I hit a mountain I did not know was there"! :D What a story to tell the authorities! When you planned your trip you should really have noted the "MSA" (minimum safe altitude) for each section passed through. I use the relatively cheap TPCs or ONCs which you can get for virtually anywhere in the world -- I think the TPCs for the USA are equivalent to the WACs. Unfortunately, nothing in FSUIPC tells you about mountains ahead. It really isn't much use just reading the ground elevation directly below the aircraft. In England with it's mostly rolling countryside maybe the ground rising slowly beneath you is a warning or something dangerous ahead, but that isn't going to be the case most of the time. In parts of the USA in particular, mountains have that annoying habit of sticking up out of an otherwise very flat plain! There's no way to predict that from the ground level beneath you. No doubt something somewhere in FS knows about the shape of the country side around you, otherwise it couldn't draw it. But I don't know how to access that to proivde a terrain view ahead. Sorry. Programs that do this make use of their own terrain data files, I think. Meanwhile, all I can suggest is set up AutoSave to save your flight at intervals, so when you come back to the wreckage you can go back in time a tad and change the course of history! Regards, Pete

Well, I don't know if they'll be able to help, either, but with that information I said to gather, we should stand a good chance between us! It's just that there's no data for us to determine what is happening yet. Regards, Pete

Hmmm. What can I say? Version 2.972 most certainly has exactly the same weather interface as 2.95 and it implements the input from those programs in exactly the same way. There's been no change, and it is working everywhere else as far as I know. Have you any logs to show me? -- go to the FSUIPC Technical Page, and switch on Weather and IPC Write logging. Keep the session very short, just to know for certain that you should have weather. Save a flight, zip up the FSUIPC.LOG, the saved FLT + WX files, and I'll take a look -- you should really be talking to the weather program authors too of course. BTW the version number is 2.972, not 2.97.2. Version 2.975 will be released this weekend. Regards, Pete

Please only ever use latest versions -- FSUIPC is 2.972, WideFS is 5.41. I don't support old versions. Please refer to the announcements here about this. This problem is a well known but thankfully quite rare problem of weather caching in FS2002. It was reported to Microsoft over a year ago, but they could not reproduce it. I only ever managed to get it to happen once, never again. Some folks get it a few times a week, most not at all. It have never been reproducible to order. Also it doesn't just apply that way around -- sometimes surface winds get stuck when you climb, but not many would notice this so much. It is also not actually dependent upon FSUIPC or external weather. It has occurred also with downloaded real weather and no FSUIPC installed. There is no known cure. The stuck cache IS cleared when you reload a flight or even just an aircraft (originally it was thought you had to close and reload FS, but that is not true). Anyway, you should change FSUIPC to the latest version -- the timing system used in FSUIPC now is far better than it was way back in 2.95 and it has been reported that, whilst this does not stop the cache sticking, it seems to make it much less likely. Regards, Pete

Hi Fabrice, It isn't available from FSUIPC generally. There is a complex and obscure way to get a best guess Metar station identity through the AWI (Advanced Weather Interface) of FSUIPC, for FS local downloaded weather only, but that isn't foolproof and can be misleading -- FS interpolates weather from three METAR stations in a triangulation system which isn't always easy to determine. ActiveSky and FSMeteo of course actually feed the data from the METAR stations (which they know, as they are reading them) into FSUIPC -- FSMeteo uses the AWI, ActiveSky uses the FS98 system at present. But neither tell FSUIPC any of the METAR data itself. They are in fact controlling global weather, not local weather, in any case. If you merely want to determine the nearest METAR station to a particular location, such as that of the aircraft, you can search through the ICAO POS.BIN file (in FS's Weather folder) and choose the entry closest to that position. The format is easy enough -- 16 bytes per entry: a 4 byte ICAO, then three 32-bit floats -- Latitude, Longitude, Elevation. Regards, Pete

2.72 does not exist. The only correct and supported version is the current one, 2.972 at this time (2.975 soon). FSUIPC (like all my modules) is developed with backward compatibility maintained. Each new version supplements, corrects, builds upon the previous one, it doesn't destroy what the previous one did. You should ALWAYS use the latest one, especially before asking for support. If any problems do arise in new versions I try to correct them as soon as possible, but there really are no errors which can do such weird things to your Dash 8! It seems many folks are under the illusion that FSUIPC does just about everything in FS (why use FS at all then? ), but in fact mostly it does nothing much at all. It is sitting passively waiting for programs to ask it for information. It knows nothing of gauges nor of moving parts -- all that sounds like an aircraft installation problem. You need to seek the help of the author or supplier. Regards, Pete

Sorry, can you explain a little more about the problem, please. FSUIPC doesn't as a rule generate any weather at all. You either need to set weather in FS's weather dialogues, or download FS "real weather", or use one of the excellent external weather programs such as FSMeteo or ActiveSky. In the last two cases, FSUIPC is used to actually set the weather into FS. There are some minor weather filter facilities in FSUIPC, but in general these are operating on the weather from the external programs. There has been no specific changes in the weather filtering facilities for some time, though you can and should review the changes which have been made -- please refer to the History document which is included in the ZIP. For 2.972 you will see all the changes in the versions you mention. Regards, Pete

Hi Stuart, >> I have set the AllowShutdown=Yes in all the INI files, but when I send 0xABCD to the address in FSUIPC (or use the PM CDU) to shutdown, all the PC's just log off and sit at a login prompt. << That was a problem with an older version of WideClient, it used a "ShutDown" call to Windows (which I thought would do -- the PM CDU actually uses it) -- but in fact the "POWEROFF" call is the one which works. It should therefore be okay with WideFS 5.41 -- provided, of course, your Win98SE mobos do allow shutdown completely too. If the PC does power down from the "Shutdown" options. then it should work. Regards, Pete