Pete Dowson

Can't be done like that. Run WideServer on the FS with the traffic, not on the other one. The only parts of Radar Contact you won't be able to use are the automated bits like copilot and auto-tuning. Does WidevieW copy the weather from the Server or are you providing that locally? If the former then it will need to be copying all the localised weather so that RC's ATIS reports and runway allocations are correct. I don't know if it does that or merely copies weather at the aircraft. It all seems a very strange arrangement and a huge waste of processing power. Why have no views on the main FS PC? Surely the only point of using WidevieW is to get more views, not to transfer the only view -- you aren't really gaining anything at all, just wasting a PC. Regards, Pete

I investigated this a bit further. When I first wrote the code for FS2004 weather control I knew less about it than I do now. I have found a way to apply the minimum to FS's own weather, both local and global, so I have included it in version 3.51, due out this coming weekend. There is one oddity though. If the specified minimum is being imposed on FS’s own weather the current visibility will not be reported correctly in weather reports such as those read by external programs and ATIS in FS. This is because the only way of imposing the visibility minimum is by changing the effect at the end stage, the rendering at the aircraft, and not in the weather system as such. BTW, you also said: The limit before you got the grey skies (even de-texturing the clouds above) was around 4 nm in FS2002, but it was raised to 10 nm in FS2004, so in fact FS2004 is a lot worse in this respect -- almost any misty conditions gives you a grey bland sky. You would need to set the minimum to 10.5 nm (1050 as the value in FSUIPC's dialogue) in order to prevent it altogether in FS2004, which is a shame as this also eliminates all reasonable misty conditions. I am one who'd prefer no minimum so that I get the weather pretty much as it really should be, ognoring the grey skies and hoping that I clear the murk quickly after takeoff! ;-) Regards, Pete

You are probably reading into a different place than you think, then. I'm sure it will be -- check with FSUIPC IPC logging, or FSInterrogate. The problem will be that you are passing over something which is NOT pointing to where you want the information to be placed. did you look up "varptr" (or whatever it is called -- look at the examples in the SDK). It really does look like you are passing over the contents of the places you want to read into, NOT the address (pointer) of (to) them. Yes, but you changed a variable called "dwBytes" which wasn't a string. You declared an FSAircraft string but didn't use it. How would the MsgBox call print a Byte array? But I'm pretty sure that, at least in VB (I don't know if it changed in the .NET version), "FSAircraft" is not going to be a pointer to FSAircraft. You need to make itr into a pointer to where FSUIPC is to place the data! Didn't I say this before? Did you bother to look up "varptr" or "VarPtr" or whatever it is called? You seem to have ignored half of my suggestions. Pete

Sorry, I don't know VB, nor do I know the number 29... (are there more digits? The full number may give a clue?). I see you define a string called FSAircraft but then don't seem to use it. What does "ReDim" do? It seems to be applied to dwBytes not FSAircraft? Apart from those oddities (to me at least) I think I see at least wo things wrong with your code: 1. I don't think you can pass "dwBytes(256)" as anything meaningful in that parameter position. 256 is presumably the length of the array, but isn't "dwBytes(256)" then simply the 256th or 257th (depending whether VB counts from 1 or 0) byte in that array? I have no idea what it has in it, but passing it over to FSUIPC isn't doing any good. You need to pass a pointer to the first element of the array, something to do with "varptr" I believe. Please look it up in your "VB for Beginners" book. 2. I don't think that "bytes" and "character strings" are the same thing in VB as they actually are in the real machine (and in C). You have to do something to make a string with the array of bytes you receive. Do you have any books to help you with VB? It is not easy to jump straight into something sophisticated like the FSUIPC interface without knowing the language first. Regards, Pete

Well, I didn't get persuaded ;-) but it was so easy to do, it will be a facility in version 3.51 of FSUIPC, being released this coming weekend. However, the facility is not in the on-line options. You will need to edit a MinIce parameter in the FSUIPC.INI file. It will only be documented in the Advanced Users documentation. Regards, Pete

I wouldn't have thought MixW would be able to get hold of COM1 and COM2. These would normally be already used -- or doesn't your PC have any COM or USB ports? This is merely because COM1 to COM4 are evidently already taken. It will be different on dsifferent PCs. MixW just adds two more ports. The numbers the are allocated depends upon Windows and what ports it has already assigned. Always check the devices you have already -- Start-Settings-Control Panel-System-Device Manager. Regards, Pete

I'm surprised it needs FSUIPC. What is the actual message? Not "FSUIPC is wrong" surely? What program gives the message, the installer? Have you checked the documentation for this add-on aircraft? If it needs extra things, then it should say someplace. And where "in the modules folder" does it say that? Can you be more precise? Just looking in a folder doesn't usually tell you such things. Did you look in a file, perhaps? If so which, and what did you actually read? If you want to purchase FSUIPC all the information you need is available in the announcements above. Regards, Pete

Another possible cause of Weather.DLL crashes occurs to me. Well two, but related. Clouds of types not supported by valid cloud files. FS98, 2000 and 2002 seemed to map unknown cloud types to those it did know. They even allowed type 0 ("user-defined"). FS2004 seems to crash if a cloud type is specified for which it has no graphics. The only reliable ones are 1 (cirrus), 8 (stratus), 9 (cumulus) and 10 (cumulonimbus -- storm cloud). In the older interfaces I actually made FSUIPC map other types onto these according to a table of all sorts of other cloud types (cirrostratus, stratocumulus, etc) which were actually assigned and listed in some of FS's SDKs but which were, apparently, never implemented. For the AWI, though, I provided weather programs with a transparent route through to the weather, on the hopeful assumption that the cloud types could be expanded by adding more graphics and parameters pointing to them. I didn't want to restrict experimentation. So, that's one, rather unlikely, possibility -- that something is setting a type for which you have no graphics. With standard weather sources I think this could only happen if you have some files missing or renamed. The other is that one or more of your cloud graphics (BMP files) are corrupted. I don't know whether this would cause WEATHER.DLL to crash though -- it seems more likely, then, to be G2D or G3D. But I don't know. If you have disk space enough, rename your main FS folder and install a complete fresh copy. Check that. If it is okay, gradually re-install (copy files) over from your original one. This is a method I have used many times over the years to recover from corruption or bad add-on installs. Regards, Pete

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