Pete Dowson

You cannot use the SAME port for both programs! Only one program can own the port at one time. GPSout will be using it to OUTPUT stuff on, your other program will need to be set to use another port to INPUT stuff on. You's then need to link the two ports with a "NULL modem" cable. Please read the little bit of documentation I do supply. If you are using WinXP then you could use a pair of "virtual" ports instead. There's a freeware virtual port driver included in the latest GPSout ZIP for just such a purpose. It creates a pair of ports and links them together internally -- you don't need to then use any "real" ports, nor a cable. Regards, Pete

No. It really never was. As I said earlier, crashes in Weather.DLL are usually due to corrupt WX files. You didn't say where you were getting your weather from, but sometimes downloads of weather by FS can create corrupt weather data. Once you have a bad WX file stored as your default then it could mess up every load thereafter. Unless you are really attached to any particular weather files you've saved (they are saved automatically by FS when you save a Flight), try deleting ALL of the .wx files, or at least moving them out so they don't get loaded, as a test.... Regards, Pete

The AWI was added in FS2000 days to provide more control over the FS weather than was possible in FS98 (FS98 not having such extensive facilities). It applies to global weather in FS2000 and FS2002, and it is implemented for FS2004 -- but it really isn't much good in FS2004 because global weather is so temporary in FS2004. It al becomes localised pretty quickly. For FS2004 I devised a new interface for local weather control called the NWI (New Weather Interface). That is used by almost all the weather programs for FS2004 -- FSMeteo, ActiveSky. I really don't know what WidevieW uses at all. The message about the AWI being activated in FSUIPC's Log is really only a hangover from the original transition from FS98 to FS2000, to confirm that the intrusions needed into WEATHER.DLL were in place. In FS2004 it is nearly all procedural in any case. In FS2004 all three weather interfaces supported by FSUIPC (FS98-style, AWI and NWI) actually do the same things to FS -- there's only one interface at the lower level and FSUIPC translates down to it. All in the name of backward compatibility, which was what FSUIPC was always about in the main. But only the NWI can set/read localised weather. Regards Pete

No, but corrupted weather files can easily be. What is your weather source? Incidentally, you don't even say what version of FSUIPC you are using, nor even what version of FS it is! These are very important items of information! Most of those messages are simply confirming normal actions. The "Clear all weather requested" initially would have been simply a call made by FS to Weather.DLL's "Clear All Weather" routines internally -- well before the Advanced Weather Interface is enabled. FSUIPC has to detect when the weather is 'officially' cleared in FS, otherwise it would immediately try to reset the last weather recorded from external programs (not that there would be any this early, but there might be at other times). The "Clear Weather" button is the one labelled "Clear All Weather" in the first tab of the FSUIPC options, bottom left, below the version information stuff. If you didn't press it on the clients, why should it show in their logs? I assume the weather in the clients will have been copied from the Server by WidevieW. Isn't that one of the things it does? There's no magical way FSUIPC in the Server can control the Client unless WidevieW is doing it! Not if WidevieW is doing its job, surely? Why not ask Luciano such questions? If WidevieW is not copying the weather perhaps you have some of its options set incorrectly? Regards, Pete

You misunderstand! I did read that you wanted to use buttons. The FS controls I mentioned are Axis controls, but you can use them programmed on buttons in FSUIPC. Just use the parameter facility to set a fixed value which does the job!!! Did you not even try my suggestion before rejecting it so? Regards, Pete

No. Sorry, I barely have time to keep up with my own support work without investigating other people's. I have good relations with PMDG and if they thought they had any sort of problem with FSUIPC they'd have been in touch with me. I am sure this is just one of the usual cases of "clutching at straws", and FSUIPC is always the first thing folks blame. Regards, Pete

If you want to use IPX/SPX in WinXP you have to instal it from the CDRoms. It is not installed by default. But try TCP/IP first, it is a little easier. Regards, Pete

Sorry, I kmow next to nothing about Delphi. But surely Delphi 2005 isn't completely different from the Delphi provided in the Delphi package in the FSUIPC SDK? I hope they don't completely re-invent these languages every year! Regards, Pete

There are no commands provided by FS to do that. You'd need to use the Flaps axis instead. Try assigning FLAPS SET or AXIS_FLAPS_SET controls in FSUIPC's dropdown, with a different numeric parameter for each flap detente. You will have to work out the numeric values for the best results for each flap position. The range will either be 0 (up) to 16384 (down) or -16384 (up) to 16384 down. Divide the interval into equal parts to give the correct number of intervening values for the total flap positons -- e.g. for 5 in total you's have full up, full down, then three intervening ones, so you need to divide the interval into 4. For 9 in total you'd divide by 8. Regards, Pete

Are you really sure you want to take that route? If it works through FSUIPC then it also works through WideFS and so can be used on Networked PCs. This is a big advantage of external programs, and the only reason I don't use FSNavigator at all -- that is an FS Module and cannot be run on other PCs. If that's the first problem, then you must already have worked out how to make your program into an FS Module? There are facilities provided in FSUIPC for programs or modules to add an entry to the Modules menu. If that is not sufficient you have to start doing things like subclassing the FS window procedure and adding your stuff to FS's menu every time it is redrawn. It gets quite complicated. There's no such thing as a "name of a menu handle". Menus have handles, and you get them by "GetMenu". But the problem in FS is that, unless the user has opted to have the menu displayed all the time (most distracting), it doesn't actually exist. In its so-called "hidden" state in fact it doesn't exist. It is rebuilt from scratch each time it is called up. You have to detect this and add your entries every time. Regards, Pete

Not at present. I can make a note to add something like that, but I can't see why you would want it. Surely not all clouds cause icing? Isn't the weather-creating program in the best position to decide, based on things like temperature, cloud type, thickness, and altitude? Please persuade me;-) Pete

If you mean the FS ATC text, no, I'm afraid AdvDisp cannot intercept that. It was originally designed, in FS95/98 days, to intercept text from Adventures, which were scripts folks wrote for ATC before MS added ATC to FS. I did try to find ways of getting into and diverting FS2002/2004's ATC messages (and voices) but failed disnally. Sorry. These days the main use of AdvDisp is for ATC produced by external programs, Radar Contact being the prime candidate. If you want really good, realistic, ATC for IFR flying then I suggest you check it out. I use it all the time, have done for years, and it somehow keeps improving. See http://www.jdtllc.com Regards Pete

Well, for WideFS there's only the logs from Server and Client -- unless you've been changing anything in the INI files, but in the latter case I'd ask you to revert to default values first and re-test. The underlying problem causing FS to crash is not something I can diagnose I'm afraid. When I've had such problems it is most a matter of trial and error. If your system has been good for ages then suddenly starts misbehaving, then, assuming no rogue programs (worms, viruses) have got in (check that, of course), then some sort of hardware fault or deterioration is the major suspect. Software doesn't deteriorate or develop new faults with no changes being made to it. There is of course the possibility of software corruption (files not being right) though that would also normally only arise from a hardware glitch -- though maybe something you've installed is responsible? For FS the usual things causing such hangs are corrupt texture files, corrupt gauges, corrupt weather files. But these are not likely to be the cause of the errors seen on the Network. As I said, the only common thing I can see would be memory and interrupts or, worse, something intermittent on the motherboard like a hairline crack in a track. With as much as 2Gb of main memory the system may perform perfectly for many things. It takes something which really does use a lot of memory, such as FS, to hit it all and hit it enough. Try removing each memory stick in turn (I assume the 2Gb isn't all on one stick? ). Give each variation a good run, only passing the removed stick if you still get the hang. One other thing to check is the temperature of your processor and video card. At this time of the year (in the Northern hemisphere) with most folks turning their heating on and cutting ventilation (draughts) out more it is surprising how much hotter PCs can get. However, in my experience most such problems tend to result in either a solid PC hang or a spontaneous hardware reset and re-boot. Regards, Pete

I don't know the Addon Manager -- the one I have is definitely called FlightSim Manager. See http://www.ranainside.com. Whilst unused aircraft add to the clutter on disk and may slow down the opening of the aircraft selection menu, none of those will be contributing to the lack of stability in your installation. That log shows a sorry state I must say. Much more worrying than the disconnections are the Sumcheck/Length errors. This is actual corruption of data coming across the network! That is really really bad and should never be seen! These are the lines you are not looking at: 195437 **** ERROR! Sumcheck or length fails on received socket 14840 block, len=370 (time=0) They are occurring sporadically through the log segment you sent. The **** ERROR! part is meant to draw your attention to them, so I'm surprised you picked out the disconnections instead, which are never causes but results. The disconnections logged as: 10397984 Error 10053: client socket disconnected at Client: removing (skt=22776) may have rather more relevant information in the Client Log, as it is the client that did the disconnection, as it says. The fact that these errors are spread sparsely over the 4 hours 36 minutes shown in the log, and not simply bunched up after several hours, may be more indicative of something else wrong other than the memory leaks which I hypothesised before. Unfortunately the performance reports from WideServer are missing, presumably because FS hung and not closed? Did you end the FS9.exe process via the Windows task manager (Ctrl_Alt_Del)? If so, and WideServer still did not summarise and close the log, this means that something serious in FS's main message processing thread was hung. Perhaps, if you closed the WideClient end the performance log from there would show something. With stuff like data corruption in the blocks being received by WideFS I would normally suspect the Network -- hardware or driver. But this alone would never hang FS. Combined with FS hanging I would instead suspect the PC itself -- interrupt conflicts or the memory chips failing intermittently. If the system always used to perform well and has only started playing up recently, then I would certainly suspect something on the motherboard, with memory being the most likely. If you have more than one memory stick try without one at a time to determine if it is memory and if so which stick. If it has always been a problem on this system, then also check the interrupt assignments (IRQs). In particular check that the video card is not sharing the same IRQ with the Ethernet adapter. Anyway, as I said, I don't think the FS hanging is at all related to the WideFS problems. It looks like they are both results of a common cause, however. Regards, Pete

No. What CTD problems? None have been reported here, and if there are it most unlikely to be at all related to FSUIPC. Please contact PMDG support about this. Pete

Sorry. It never occurred to me that was so ambiguous. When it says "allow changes to FS own weather" that is referring to FSUIPC making changes to weather set in or downloaded by FS. It's turned out to be mostly a waste of time (and code) even trying to do that, because, having failed to find the correct place to modify local weather 'on the fly', I only implemented it for global weather. And, as it then turned out, in FS2004 no weather stays 'global' for long. Each weather station which isn't explicitly set with weather will initially be populated with the global weather, but it remains dynamic and within minutes (typically 20-30) it is local weather and again not changed 'on the fly'. The weather setting facilities implemented for external programs actually set complete weather at specified weather stations, but this isn't suitable for gradual changes 'on the fly', as it would cause noticeable hesitations (stutters) even for minor incremental changes. I hope to be able to do a lot better in future versions of FS. As it is, with FS2004, it is best to leave that option unchecked. For complete control of weather use an external weather program. Regards, Pete

WideFs needs its own registration, it doesn't actually need a registered FSUIPC. What do the WideFS logs say? That's the first place to look. WideServer.Log in the FS Modules folder, and WideClient.Log in the same folder as your WideClient.EXE. Show them here, and also the INI files for those two. Also, please always state version numbers. If not the latest (6.50 or later for WideFS) please update first and try again. Version 6.51 will be released within two weeks. Regards, Pete

That must be a name invented by GoFlight, as there's no FS control by that name. The fuel cut-off for jets is the same control as the mixture adjustment on props -- usually, for all engines, assigned to CTL+SHFT+ F1 to F4 (full lean, decrease, increase, full rich). I'm pretty sure that FS's own Help covers jet engine starting and stopping? How have you done it before, or is this your first venture into jets? You enable the fuel by full rich, which for just Engine 1 would be MIXTURE1_RICH, and you cut the fuel by MIXTURE1_LEAN. Obviously you really need a toggle switch for this, just as on the real aircraft -- for a push button you will have to use an FSUIPC button flag to program it as a toggle, which means editing the FSUIPC.INI file. Regards, Pete

No, not as it is. It isn't a gauge. It is relatively easy to make gauge windows transparent. Gauges use FS's graphics systems. I suppose I could make Advdisplay into a gauge, but it would then need installing as a gauge not as a module. And it's a lot of work which I realy cannot undertake at present. I can actually make the current AdvDisplay transparent on some systems, depending upon the operating system and the video drivers and whether FS is in Windowed mode or full screen. Most things are easier in windowed mode assuming WinXP SP such-and-such, and decent recent video drivers. But it is a mess. If I had left in the facility I developed I would have been inundated by support requests, asking why it doesn't work on such-and-such a setup, and so on. And the demand for transparency in AdvDisplay really has been pretty much negligible over the years. Regards, Pete

The timeout settings should really be left to default. The current values have endured many years will good service. If you start dabbling in some of those numbers you'll find it a never-ending job trying to balance everything. The timeouts are not the cause of anything. They are merely a safety valve, to try to recover from lost connections. I hope you haven't changed anything unnecessarily in the WideFS INI file config settings? Generally only the protocol and (optionally, now, with WinXP systems) the ServerName is needed. Regards Pete

If I may clarify that a bit. Since version 3.0.4 of Squawkbox 3, it has included similar support for a separate PVT channel operation from FSUIPC/WideFS, using similar internal methods for my program to talk to it. Another button can be used which operates just like a normal PTT button, but instead it uses this PVT channel. In FSUIPC I call it PVT instead of PTT to avoid just the confusion we seem to be likely to get into. What I didn't understand about Daniel's original question was what he was trying to do with some, as yet anonymous, offset in FSUIPC, merely to have some way to select between PTT and PVT when he presumably presses the one button he wishes to use. I suspect there are better/easier ways to do what he wants to do, when I find out what that really is! ;-) Regards Pete

This phenomenon is clearly described in the WideFS documentation. The freezing (or slow running) of FS is likely to be the cause, not an effect. What happens is that WideServer isn't able to respond to your client(s) often enough, if at all, and they timeout and attempt to re-connect. The count increases because the Client's timeout is shorter than the Server's -- eventually the server will time each inactive connection out and the count will decrease, but for that to happen the FS freeze or whatever it is has to clear. You missed it in the documentation for WideFS. One possibility, if it occurs after a number of hours of running FS, is that you have a memory leak. Once the real memory gets used up through such problems, things get continually swapped out to disk. When this happens it also happens to the Winsock buffers used for the Network, and that clogs up too. It will gradually get worse until FS freezing is possible, if not an outright crash. The most common cause of memory leaks is related to LandClass files in sceneries. I had such problems for a while and had to move a load of landclass BGLs to their own Scenery folder with no Texture folder. I think there's a program which will help you do that automatically -- FlightSim Manager or similar. Also, if you are running the original FS2004 still, update now to FS9.1. That fixes a load of other possible memory leak problems (but not all, unfortunately). Regards, Pete

Aren't the IDs declared in the Panel.cfg file? In the line "ident= ..."? For the FS-supplied default panels FS seems to understand names for the IDs. like "MAIN_PANEL", but these must always translate into the same numbers. For additional panels numbers are used in that declaration -- I assume these are the IDs you need? [LATER] Just found the built-in panel ids (they are in the Panels SDK): // Panel identifiers #define IDENT_MAIN_PANEL 0 #define IDENT_THROTTLE_PANEL 10 #define IDENT_RADIO_STACK_PANEL 50 #define IDENT_COMPASS_PANEL 75 #define IDENT_MINI_CONTROLS_PANEL 100 #define IDENT_ANNUNCIATOR_PANEL 125 #define IDENT_ANNUNCIATOR2_PANEL 150 #define IDENT_IFR_MAIN_PANEL 175 #define IDENT_COLLECTIVE_PANEL 200 #define IDENT_GPS_PANEL 225 #define IDENT_OVERHEAD_PANEL 250 #define IDENT_USER 10000 #define IDENT_USER_MAX 19999 #define IDENT_AIRCRAFT_HUD_3D_PANEL 20000 #define IDENT_HELICOPTER_HUD_3D_PANEL 20001 #define IDENT_CONTROLS_HUD_3D_PANEL 20002 #define IDENT_TEXT_HUD_3D_PANEL 20003 #define IDENT_DAMAGE_HUD_3D_PANEL 20004 #define IDENT_SCORE_HUD_3D_PANEL 20005 #define IDENT_LSO_WINDOW 22000 Regards Pete

Sorry, I don't quite understand. You want one PTT button which lets you talk simultaneously to ATC and on the PVT channel? Does SB3 allow that? I'm also confused by the mention of an FSUIPC offset. Where does that come in? It sounds as if you have a genuine need for something and have devised a solution, but without knowing what the need actually is I don't seem to be able to understand your solution. If you could elaborate perhaps I could help better -- it may be a lot simpler than you are making it. I assume "COM1" is the normal SB3 PTT option? (Sorry if I appear ignorant here, I'm not an SB user). How and why is this (yet to be allocated?) offset set? If it is simply another button or switch, there are better ways without resorting to offsets. Regards, Pete

How odd. It sounds like the hook into FS to allow PFC.DLL to scan the inputs at regular intervals is being destroyed. Do you have any other complex add-ins? It might be worth your while trying the latest PFC driver, which has a whole raft of improvments -- 1.989 in the top Announcement above. It only hasn't got into a General Release state yet because I'm well behing with the documentation, and I'm still developing some of the 737NG cockpit parts of it. Have you tried doing a PFC.DLL restart instead? You can assign a Hot Key for that in FSUIPC's Hot Keys page (of course you need a user registration for that). Since you are still seeing the controls in the PFC calibration and (presumably) Test screens, it cannot be related to the lnikage to the controls or the serial ports. It must be something internal to FS which is destroying the frame-based scanning. I use PFC.DLL on two separate (complex) systems all the time and have never seen this problem, so there's something odd going on. Perhaps I will ned to know a little more about what you have installed in FS, please? And try the latest version. If it happens again and you are FSUIPC user-registered, see if the PFC restart hotkey helps. If it doesn't happen again then maybe some of the changes I've made over the last year or whatever have fixed it. Let me know. Regards, Pete