Pete Dowson

Weird. Thanks for letting us know! Pete

Greatnice to read good news once in a while! Thanks! Pete

Sounds like a typical video driver bug -- either switch to Windowed mode (ALT + ENTER), which generally works much better with FS in any case, or look for a better video driver. This really isn't a function of FSUIPC and it has no control over Windows displays. Regards Pete

Please tell me which FSUIPC version you are using. All of the weather features have been undergoing a lot of changes since Christmas. If you are not using it, try the current interim release, 4.255 from the FSX downloads Announcement above. Please never post a report or question about any of my programs without also saying which version number you are using. Regards Pete

It isn't related to what's in the libraries. It's the difference between running in the same process as FS, or running in a separate process and so facing process switches for each information exchange. If you think about that you could expect faster response times with an internal gauge or DLL than with an external EXE -- after all the latter has to post a message onto the FS message queue, wait for it to be processed and answered. All that is internal for a DLL or Gauge (but the library still uses messaging to avoid problems with FS's threading). However, writing a DLL or EXE isn't the best course necessarily, for two good reasons: 1. A program running internally in the FS process must take great care to avoid performance degradation, pauses, jerks and so on in the simulation. It has to be designed specifically to run cooperatively with FS in all its facets. With an external program you leave time sharing worries to the operating system. 2. By making it a DLL or Gauge it cannot be run on a separate PC across a Network via WideFS, so wasting one of the valuable ways of off-loading work from the FS PC. By the way, never use the external library for a DLL or Gauge. Although it may seem to work, it is very inefficient (using memory-mapped files for inter-process communication within one process) and is dangerous because the memory-mapped file identification process uses the Process ID, which of course is the FS Process ID, and therefore may not be unique. Regards Pete

Er, sorry, what do you mean? FSUIPC only runs internally to FS. Pete

That's all okay. I can see absolutely no reason why your programs won't connect. The only thing I can think of to get more information is to enable IPC read and write logging in the FSUIPC Logging options page, left hand side. Let's see if the log shows any attempt by any programs to talk to FSUIPC. Regards Pete

Thanks. That looks just right. Okay. So it sounds as if, in your case at least, the FSUIPC re-writes on zero vis did manage to catch the condition before it became visual. Unfortunately, I just got an email from Al where he gets no improvement -- still the "super-fog" in exactly the same place. So, I don't think my recent improvements really help in any useful way. From analysing the logs, especially the SimConnect ones (which include all the METAR settings from ASX as well as FSUIPC4, I think it is related to the fact that, unusually, ASX is setting two visibility layers. I've always avoided doing this, because it used to give problems with previous versions of FS. I've written to Jim and Damian to ask about this. If we could possibly get a test with only one visibility layer, just to see, it might be useful. I'll think more about what experiments I might be able to do as well. It is rather infuriating that Al can reproduce the problem at will and I can't ever get it to happen, despite logs showing dozens of bad "zero visibility" reports when running ASX. Meanwhile, if you just want to fly for fun till I think of something else, you can turn off the "allow changes to FS weather" option -- the wind smoothing and so on will still work, now, in 4.255. Thanks & Best Regards, Pete

Sounds like it isn't installed! There's no anti-virus or firewall problems with FSUIPC3. Is there a Modules menu entry with FSUIPC listed? Does it open? Run FS9, run something to show the problem. Close FS9 down. Find the FSUIPC.LOG file in the FS Modules folder. Paste it into a reply here. Pete

Could you show me the [General] section of your FSUIPC.INI please, just so I can feel it I've not missed telling you something. Also, are there still "ZERO VIS" warnings in the FSUIPC Weather Log? There should be, as I think the changes should make the fix for it work, but it doesn't actually stop the bug starting in FSX. Regards Pete

"Outdated" meaning "not working" or "not supported", or perhaps both? ;-) Of course, for 540C it's a direct write of a value rather than an INC or DEC, though I suppose that programming a button you can use FSUIPC's offset word inc and dec controls. You'd need to see if you can do the same from fs2phidgets. Well, they are all MCP values you can set and change, yes. As I say, it depends on the facilities in the interface program you are using. At the very least, assuming fs2phidgets doesn't have the facilities needed, you could make it operate an FSUIPC virtual button (in offsets 3340 ff), then simply program the button in FSUIPC's options. Regards Pete

Yes, though any similar filtering option would likely do as well, or simply including these two parameters: RewriteSavedMetars=Yes FixBadMetars=Yes: though whether the "super-fog" would always occur at the same time without the turbulence suppression is anyone's guess. The result of that option in your scenario is an immediate write-back of the first METAR read, because it includes one wind later with turbulence. Anyway, to progressI've now uploaded version 4.255. Please try that for me, with these lines included in the INI: RewriteSavedMetars=Yes FixBadMetars=Yes: and, yes, your SuppressWindTurbulance=Yes included. If this doesn't help, I'm going to have to leave it for a while and look for a way of conquering the visibility on my return from holiday in late March. I'm still here until the end of next week, but I need to get a load of other stuff done too. So, as I say in the Release notes, on the assumption that my changes in 4.255 don't fix the "super-fog" problem, version 4.255 also has the "Allow changes to FS own weather" option separated from the wind smoothing, wind effects simulation, and QNH and Temperature smoothing options. This will allow these options to be used without FSUIPC4 re-writing any METARs at all. All the other weather filtering facilities still need the "allow changes" option. But please don't disable the "allow changes" option for the tests. That's the "get out clause" for when I temporarily give up. Best Regards Pete

Okay, so you are on the right track now? Pete

Well that explains your 29.91 (16208/16 = 1013.0 hPA). Not exactly a side note -- that is a definite clue. The problem must surely be down to the software which is changing 5418 bit 15whatever is reading that change has no way of telling whether it was changed by a Button press or by some other software. Earlier you said so this latest finding must presumably point quite definitely to the fs2phidget side, as PMRJ will be the same no matter how you set the bit -- or is something in PM reading the hardware directly as well? Regards Pete

Test4 is a test of a first attempt I am making to control the visibility by writing direct to some values I found when implementing the wind smoothing. In previous tests I made with these, those values did influence the reported visibility, but didn't change the visual effect -- I probably need to find routines to call to make that happen. What I was hoping though (and it was only a thin straw), was that the same value changes might just fix the "super-fog". However, Alex also ran the Tests and his Test4 still gave the super-fog, so I don't think it is a solution at all. :-( This is more or less as I expected. FSUIPC4 still has to write back the METAR strings it reads if you have any of the wind filtering options enabled -- wind smoothing itself isn't such, now, as that is accomplished by writing directly to the wind component values. The difference between 4.253 and 4.254 is that I suppress all the non-filter related weather writes (this is what ReWriteSavedMetars=No and FixBadMetars=No affect). However, with you still having a filter in operation (suppressing turbulence), you were effectively still running 4.253. Sorry, I should have spotted that from the FSUIPC4.INI in your earlier ZIP. No. It is something to do with the FSUIPC4 METAR write-backs, possibly interacting with those from ASX or other sources. [Minor Update:] It seems that the super-fog will only set in on startup if SupressWindTurbulance=Yes. No, it should also happen with ANY filter option enabled, or if you set FixBadMetars=Yes and/or ReWriteSavedMetars=Yes. That was why there was a specific sequence of tests outlined, to narrow it down in this way. For now I will probably separate the "Allow changes to FS weather" option from the wind smoothing and related weather effect facilities, so that you can uncheck the "allow changes" part and still use the smoothing. This will effectively make it run as most everyone has been running it for the last 18 months, except there will be wind (and pressure and temperature) smoothing available. Enabling the "allow changes" option will make the other weather filtering work, but, unless I can find a solution to the super-fog bug in FSX, will have to come with such a warning. Meanwhile I'll examine the SimConnect logs to see if I can determine any specifics which may be involved. I cannot understand why I can never get any super-fog to occur here, for instance. Regards Pete

Okay. Thanks. Unfortunately, it looks like my 4.254 changes made no difference for your settings, because you have some weather options other than wind smoothing set - you opted to suppress wind turbulence, so despite my changes to stop FSUIPC writing METARs at all (as a test), it has to write back those containing turbulence, in order to remove it. It might be a good idea to retry test 2 with the turbulence suppression removed. It would help to see if ASX can cause the problem all by itself, or whether it does need FSUIPC4 writing METARs too. Anyway, meanwhile this does give me some SimConnect logs to see if there's anything in the sequence of ASX and FSUIPC4 weather settings which might be casing the problem. I am now even more interested in the results of Test 4, when you have time to finish the sequence. The "PatchVisibilityValues" action is my only hope at present. If that fails I probably have an enormous amount of code hacking to look forward to. :-( Meanwhile, whilst I await the finish of the sequence of tests I will look at these logs -- tomorrow, now. Thanks & Regards Pete

What are you reading? Not my documentation! Please do refer to the actual "NewWeather ReadMe" text document. You seem to have everything completely wrong. Even your extract of the sequence for writing is actually part of the Area 2 description, so why you'd even think of the read-only areas for writing is mystifying. Area 0 as documented is C000-C3FF, and is the read-only weather at the aircraft! Only area 2 (C800-CBFF) is writeable and is used for setting weather. Also as written in the documentation, there is only one area for setting weather -- all the other areas are read-only. The weather setting area is Area 2, as it clearly says. It does even says "read-only" for the others! Writing global weather is EXACTLY the same as writing any WX station weather except that the ICAO ID code is "GLOB". It does also say this is the documentation. Pete

It is explained. Your FSUIPC key is valid, but your WideFS key seems to be invalid -- either a pirate-generated key or one whose issue date is latter than your system date. This also correlates with the registration receipts -- you obtained a valid key for FSUIPC on 26th April 2004, but there is no record here of any WideFS key officially issued. Regards Pete

In FSX the trim wheel is usually part of the throttle quadrant graphic, Shift 4. Pete

Well, that's the idea, really -- trim wheels should give you very tiny amounts of trim change at a time. The movement is based on the WHEEL_DELTA set in Windows, but it does accumulate if you keep "spinning" it. The only easy way for me to make it faster is to make each click of the wheel send multiple TRIM UP/TRIM DOWN controls to FS, instead of just the one, and really that would lessen its value as a really sensitive trim for accurate trimming. I would have thought if your trim was so far out you should use some other method first? You might want to visit the FS2004 Forum and discuss trimming there with Francois -- it was a thread in that Forum which got this idea started. Theoretically FS should be accelerating the change in any case after a few changes -- have you by any chance got the "fix control acceleration" option set? With some of the add-on aircraft that may be preventing it accelerating, which is possibly why you have a problem. If you keep the NumPad trim keys pressed (1 or 7), doesn't the wheel in the panel change at the same speed as when using the mouse? It does seem to here, at least with default aircraft. Pete

That might be related to rounding during conversion -- the internals are all in 1/16ths of an hPA. Monitor offset 0330 (FSUIPC logging options page, right-hand-side, offset 0330, type U16). Standard 1013.2 should be something around 16210-16212. Well, those bits are odd, yes, but you'd need to see what other PM offsets were getting written in the logs. Regards Pete

Sounds like you are operating the "STD" BARO push button instead -- 5414 bits 18/19 seem to be assigned for that (but only on the Airbus?). Hmm: 5414,185418,14. You haven't got some digits mixed up in the details to your driver, have you? There is none in FS. To set STD on the BARO setting an application would have to send the value, in 1/16ths of an hPA, to the Kollsman offset, 0330, or send the FS control "KOHLSMAN SET" (MS spelled Kollsman incorrectly) with the parameter set to the same value. Pete

Oh, right. Weird. The Console option gives you a real-time display on screen. Not much use for sending to folks like me! The file I asked for is no doubt similar, but it is not an addition to that one. Just be sure, please, that it is producing a log file. You may wish to see the console (though with FSUIPC4 alone running it is too much. Must be pretty awful to make sense of with more running). Regards Pete

Not with the Pipe method used by FSUIPC4. But ASX is still using TCP/IP (FSX SP1 based I think). In any case, pipes across the Network connection will be in a TCP/IP carrier. No, no. For the client stuff you have a SimConnect.xml in the same folder as your FSX.CFG on the Server, and you have a SimConnect.CFG file in your "My documents" on the client. The SimConnect.INI is neither of those, and it goes on your Server, alongside your Flights and Plans and so on. I am only wanting to keep the SimConnect log as short as possible. Just close FSX when you can see it has gone wrong. I don't think that is not possible? Thanks, Pete

No. I am pretty sure PM doesn't support X-plane these days. They did try a couple of years ago, and were getting somewhere, but I think Austin changed his code too often and they couldn't keep up with the changes so called it a day. But don't take my word for it, you should inquire at Project Magenta. Regards Pete