Pete Dowson

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

My hopes were dashed, I'm afraid. Even precisely following your instructions for getting the "super fog" effect, I can't make it happen here. I checked and double checked. I suspect even just small differences in timing of events are having an effect here. I've examined your logs and one from Alex, and in both cases, every time FSUIPC sees a METAR setting with 0000 visibility, it changes it to the previously-reported non-zero value and sends the METAR back. This is the "corrective action" I mentioned, and the logs show it is still doing what I programmed it to do. ... but obviously it isn't managing to undo the zero vis which has somehow been set from other WX station METARs. I believe this is the same bug as was in FS8 and FS9, which, though rare, did occur more and more with external weather setting and for which, because on those FS versions I did find a way of getting the real visible fog effect controlled, I fixed automatically in FSUIPC3. Anyway, since you can reproduce it at will, if you have the time and patience, could you do some further experiments, please? To get more data, that is. TEST 1 First, still using 4.253 repeat exactly the stuff you've just done, but first enable SimConnect logging too. You do this by making a little text file containing: [simConnect] level=Verbose console=No OutputDebugString=No file=\SimConnect%01u.Log file_max_index=9 where you can set the to wherever you want. Save this in your "Flight Simulator X Files" folder as 'SimConnect.INI'. Do the test as before. Do not let it run on past the point where you get the Super Fog. ZIP both the FSUIPC4.LOG and the SimConnectN.log (the N will increment 0-9 cyclically each time you run FSX). The SimConnect log will be huge. TEST 2 Then, please download the version 4.254 I provided yesterday, and repeat exactly the same with no other changes to any parameters. TEST 3 (provisional) If TEST 2 does NOT produce the Super Fog, please close FSX, add these lines to the FSUIPC4.INI [General] section: RewriteSavedMetars=Yes FixBadMetars=Yes and repeat the test. If it still does not produce the super fog, then I'm completely lost, because these two parameters put back what I've taken out, by default, in 4.254 and make it the same as 4.253! TEST 4 If TESTs 2 or 3 do produce the super fog, add yet another line to the [General] section of FSUIPC4.INI: PatchVisibilityValues=Yes and run the test yet again. Does this stop the super fog? Depending on the results of all these tests I will configure defaults for FSUIPC4. I will also decise whether to spend many more hours delving into the innards of FSX to locate the real values I need to be 'fixing'. Thanks! Best Regards Pete

Sorry, I don't quite understand. Is FSUIPC connection working from the client PC? What are you running where? I'm not sure what you think this has to do with it? Not without more information. How do you activate and deactivate WideFS? Where are the FSUIPC, WideServer and WideClient log files for me to see, please? Make sure FS is not running. Find the FSUIPC.LOG and the WideServer.Log files in the FS Modules folder and post them both here. NOT extracts, the complete files. Also make sure WideClient is not running on the Client PC and paste the WideClient.log here. With information I may be able to help. Without information I cannot tell anything. Regards Pete

Ah, good. Have you sent the weather log and FLT + WX files for me? No no! JUST the "weather logging" entry in the Logging page please. Nothing else. Extras should be off or 0 as well. I'll have enough to plough through as it is! No, just weather logging, as I asked a couple of days ago. Sorry, I thought you were doing this already, as you never know when the zero vis is going to happen! :-( Please do NOT use "Extras" 67 -- those numbers do completely different things now. The Extras stuff is all designed for specific purposes and is never likely to be the same from one version to the next. Regards, Pete

No need to say sorryyou did nothing wrong. I wasn't criticising, just pointing out the obvious, that I can't help with no information. Oh, you use VB. Ugh. That has lots of number problems to catch the unwary. The IPC logging facility would have immediately shown you that your C024 gets converted by the daft VB compiler into FFFFC024 which is masked (by option bits in FSUIPC) to something like 1FC024. Certainly not what you want. I think you can tell the compiler NOT to do sign extension by adding another & at the end. I know folks have tried &h0000C024, but it still replaces the 0000 by FFFF. Daft! Regards Pete

The only value which causes any problems is zero, real zero. And it is that value which FSUIPC deliberately seeks to eliminate. I don't understand why it isn't. that's why I need at least a Weather Log showing it, and better both a log and a saved FLT + WX set. That's 4.25. A couple of weeks old. A lot has happened since then -- don't you check the Announcements here at all? Once we sort out this zero vis problem out I'll release 4.26 on the "Schiratti" site. Regards Pete

No, sorry. I can't actually see what you are doing from here. Why not enable the IPC Read logging (see Logging options page), then look at the Log? Show me it if you like. You can also check all this stuff using FSInterrogate, provided in the SDK just for such purposes. Regard Pete