Pete Dowson

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

You didn't calibrate them properly then. Not directly, FSUIPC calibration will give it to you. You can do that easily in FSX. Look at the Options-Controls-Assignments facilities. Again you can do these things in FSX. For FSX assistance there's the Help built into the product, and there's also an FSX Forum near here. Regards Pete

No weather log, no saved flight? I'm withdrawing the "visibility" page in FSUIPC4, because though I've tried and tried none of the visibility control options really ever work as intended. No, it's got to be a function of the "Allow changes to FS weather", the option which has always been there but which is now used more because it is needed for Wind Smoothing. My problem is that I know about the zero vis problem and thought I'd fixed it about 15 months ago. I've checked the code and the fix is still there. I would understand if it was a combination of what ASX and FSUIPC is now doing, but some reports are saying it happens without ASX running (ah, but I wonder if it's with weather saved in a flight in an ASX-using session?). I really need to be able to repro it here, or at minimum see a weather log with it occurring. Else I'm a bit stuck. This last weekend I had 5 good complete flights with FSUIPC 4.253 and ASX SP3, and no similar problems at all. It probably needs some special combination of weather conditions and/or WX stations. So saved flights with weather are likely to be a must. Regards Pete

The parameter value "14" comprises of bits 1, 2 and 3 (14 is 0x0000000E in hexadecimal -- "E" represents 1110 in binary -- 2^1 + 2^2 + s^3 = 2 + 4 + 8 = 14). None of those will do what you want. The PM documentation gives BIT NUMBERS. You need the parameter to provide the 32 bits all zero except for the chosen bit. Bit 14 is the 15th bit up (bit numbers count from 0, because 2^0 = 1). Bit 14 is therefore operated by a parameter x00004000, or decimal 16384. You can also compute the decimal value as 2^14, or 2 multiplied by itself 13 times. Please use PM support or the PM forums ( http://www.mycockpit.org ) for help with PM. If you are messing with PM offsets you do need to learn a little about number representations I'm afraid. It uses bit numbers rather than straight values a lot. Regards Pete

I've checked the code in FSUIPC4 for axis readings and consequent actions, and it most certainly does not do anything with any axis value until it actually READS one from the joystick driver. Then it applies it according to your calibrations and so on. After that it only takes not of CHANGES to the value. I can only think that when first initialised the driver's interface sometimes supplies a spurious value. It must vary as I've never experienced this. Anyway, to counter this possibility, in FSUIPC 4.254 (and 3.784) onwards I am discarding the first 10 readings from an axis when first read. This should take care of the first half-second, approximately, of scanning. Regards Pete

Yes. Yes, that is at it always has been, in FSUIPC3 and in FSUIPC4. I don't know how you got the odd results because there's never been any code in there to compute any proportions for the airline slider. Never! Yes, that is absolutely correct, exactly as documented and intended. The same applies to the GA slider. Only the Airlines one is 'absolute'. FSUIPC attempts, as far as possible, to keep the others in proportion. That's the whole point -- if you set them to get only a fifth of GA traffic compared to Airlines, it should stay that way. It depends on what your Airlines value was -- as I keep repeating and repeating, the guide is the airlines slider. Everything else is subservient to that. There's nothing "wacky" whatsoever. You seem to be expecting something entirely different to what is intended and documented, and repeated by me here over and over. There's no such thing as too many changes. I think you are not realising that it is the AIRLINES SLIDER which rules the rest! Absolutely right. But it is only 60% because your airline slider started at 100. 60/100 = 60% If your airline slider had started at 50 you'd get a different result. "Percents" are only because of the 100's you are using. The proportions are maintained, See? 100:100:20 == 60:60:12. Exactly right, exactly as documented and repeated by me here many times in this thread. You are confusing a VALUE of 100 with "100%". If you had started with 80 instead, it would be !/80ths, not a percent at all! No, that's simply wrong. Only the airline slider is being set directly -- the other two are maintained in proportion to their original settings. Look: 50:50:20 == 60:60:24. Correct! They are all in the same proportion to each other still, as documented, as intended! You are confusing yourself constantly by using the same values for two of the sliders. If you had 50 as the parameter and started with 30:20:10 you'd get 50:33:16, the Airline value changing to 50 as requested and the others staying in correct proportion. I really don't know how many more ways of saying exactly the same thing I'm afraid, so I'm giving up after this: THE AIRLINE SLIDER IS CHANGED AS REQUESTED, THE OTHER TWO ARE MAINTAINED IN PROPORTION AS FAR AS POSSIBLE. So that if you want a quarter GA compared to airlines, it stays that way, in proportion. PROPORTION, see? Not percentages, there are no percentages involved. Your results are ALL explained by this -- the only oddity which was occurring was when you started off with Zero in the airline slider, as then it is impossible to compute a proportion for the other two (you can't divide by zero and get a useful result). :cry: :cry: :cry: :cry: :cry: Sorry, it seems I cannot explain things to you at all. It all seems so easy and obvious to me, designed to be simple to use and understand. I cannot understand how you see it in such a complicated fashion. The airline slider is the one you 'toggle', the other two are just maintaining their relationship with it. I'm sure this is of the most use -- as i say, if i want half as much of one as the other, I still want that afterwards. Pete

Maybe I should change my Installer to check for FSCopilot, and put FSUIPC4 before it if it is there? Regards Pete

It can't really help me at all because it must be a function of the PM software. I really am not part of PM and have no idea of the software internals. You need to post your PM support problems to PM support. Possibly also ask on the PM forums -- there's a lot of helpful people there. I won't get the chance to actually try it to see if I get the same until next weekend, but a friend of mine and I had several flights over the weekend without seeing any problems. This is with the MCP in the PFC 737 cockpit. Regards Pete

I didn't say it was -- there is most certainly a bug in FSX which occasionally spuriously sets zero visibility. I know this because it was occurring quite a lot even with the FSX RTM build when I was using ANY program (FSUIPC included) which was writing weather through SimConnect. When you had FSUIPC's option "allow changes to FS weather" turned off, as it is by default, FSUIPC isn't writing any weather to FSX at all. When it is enabled, it is. And of course you've had to enable it to use wind smoothing. BUT I did place measures in FSUIPC to detect the zero visibility and not re-write it - way back in about version 4.06 or so. Right, which is precisely why I didn't recognise the problem when you said all panels were being obscured. FSX weather dialogue, possibly? I'd like a log with Weather Logging enabled too if possible. I can make the wind smoothing work without re-writing METARs to fix errors, but I'm not yet sure I should. I'm going to do some experiments here -- as I say, I know about the FSX zero vis bug (as does Microsoft, because I told then 18 months ago), but I have code in to fix it, and this is also logged (with weather logging), so I need to see how it can happen with that in place. Regards Pete

Where is the WideServer log? FSUIPC 4.152 is a long way out of date, and not supported. Wideclient 6.72 is also very much out of date. Why not try to get everything up to date when you have problems? Your system is not supporting the broadcasting of data from the Server to the Client, so the client cannot automatically connect. You probably have the two PCs in different workgroups. If you've left Windows to name your workgroups for you that is almost inevitable when using different versions of Windows. Please see the user documentation which tells you what to do -- basically if you don't want to fix your PCs to be in a single workgroup, then you have to explicitly tell WideClient the name of the Server and the Protocol you want it to use. Regards Pete

Well, it isn't just for you. I'm using you as a sounding board (sorry). I need to program it so that others won't be surprised so much about what happens. Yes, that part is okay and I've really got to do that anyway. Well, it is only the airline descity really, as it is that which tells FSUIPC that it needs to save the values so it can restore them. I mistakenly assumed this is any case. I am fixing it so you DON'T have to ensure any of this, but I want to also ensure that the results you then get aren't a surprise. Thus my current proposal (the 0/Y/Z -> X/Y/Z -> 0/0/0 -> X/Y/Z system, where those are Airlines, GA and Ships). I don't understand this part at all. If I want my airline leve to toggle between 0 and 60 (which I do), then I would prefer to specifically set 60 as the parameter. Why would you only ever want 100? Please, can you explain? Regards Pete

Even if it did run it wouldn't work correctly, because of this: Either your copy of FSUIPC4.DLL is corrupt, or there is a disk or memory problem (hardware), or, as it says, some essential service isn't available, or, just possibly, you have at some stage rejected Peter L. Dowson as a publisher and got me listed in Internet Explorer as untrusted. Right click on FSUIPC4.DLL and selection Properties-Digital Signatures and see what it says there. Well, maybe. Is SP1 actually released or are you Beta testing? Regards Pete

As well as this, I'd like to be able to repro it (without ASX), so could you also include a saved flight (FLT+WX) set please? Save stuff as soon as the problem occurs. Note that the wind smoothing experiments went on here for two weeks before I released 4.25 ten days ago, and today is the first time anyone has mentioned this problem to me. Regards Pete

ASX, like FSUIPC, cannot actually cause such things as you describe. It might be related to specific weather settings, but everything ASX and FSUIPC does (excepting for the recent wind smoothing actions in FSUIPC) deal with SimConnect only through a very awkward (to me) interface involving sending and receiving METAR strings -- basically the same sort of stuff that FS gets from its own downloads for weather. There is, indeed, a bug in FSX where a zero visibility value can be reported by SimConnect. In fact FSUIPC detects this and logs it when weather logging is enabled. I had to include special code to discard the zero visibility and use the previous or global value instead if I am in the "allow changes to FS weather" mode. This isn't a new phenomenon. It has been happening in the METAR data from FSX since RTM. However, when the visibility is truly allowed to be set to zero, whilst there are indeed some odd graphics effects which don't look right, I never actually saw any case of the panel graphics being obscured too -- though maybe you are talking about the Virtual Cockpit? I must admit if I have panels showing they are almost always the 2D ones. In order to have those smoothing options on you have to have ticked the "allow changes to FS weather", so, yes, FSUIPC will be writing corrected METARs back to FSX when it sees layers with multiple spurious wind or temperature layers. But it should be detecting the bad cases where SimConnect reports zero vis, and never send zero vis back again. Maybe you could enable Weather Logging in FSUIPC4, and when the problem occurs, immediately Zip up the log and send it to me (petedowson@btconnect.com). I am working on some more changes to FSUIPC4, so I'd appreciate it as soon as possible, please. I am not sure what ASX does these days -- it isn't using FSUIPC, of course, but writing METARs directly itself. Possibly it may not be detecting and removing the zero vis cases like FSUIPC4 is. The only way really of identifying it in ASX would be to enable SimConnect logging and searching the METAR write strings. Sorry, I really don't have time to go elsewhere to find things to do! Regards Pete

Okay. I've checked all this out, and everything you stated is actually explained by the initial setting of 0 for the Airline density. Since everything operates according to that one slider, it uses the initial value as the guidance -- in fact it only saves the values (for re-storing on the Toggle) when the value of the Airline density is non-zero, because it is designed to toggle to and from a zero value. The other sliders just follow from that, so when the airline density is zero, it is expected that the other two would be zero as well. I'm really not sure how to cater for your case, where you start with it toggled off. I can of course make a special case of it, but I'm not sure now what you would expect to happen when you toggled a 0/0/20 setting. Do you expect it to go to 0/0/0 or X/X/0 (where X is the parameter value)? In other words were you hoping to switch ships off when switching airlines on and vice versa? That's really contrary to the purpose. I've had a look at this with various options, and I think the only "toggle" that makes any real sense in your case is if I save the values on first entry even if the airline density is zero, then do this: 0/0/20 (airlines/GA/Ships) Toggled with parameter X (if X is non-zero) ---> X/X/20 Toggled again --->0/0/0 Thereafter it would toggle between those two sets of settings, so you never again see them as 0/0/20. Regards Pete

Strange. The original version of FSUIPC4's installer use to insert itself at the top of the list, but that created problems for some other DLLs (I thought FSCopilot was one of them, actually), so I deliberately changed it, after first trying experiments with an initialisation delay to make it initialise last even if loaded first. Regards Pete

No, sorry. I've never heard of anything like that which can affect panels, and certainly there's nothing in FSUIPC which deals with graphics or panels. It does sound like a video driver problem, or possibly one of the many incompatibilities folks are finding between some add-on aircraft panels and FSX's SP2/Acceleration. Regards Pete

Sorry, you need to refer to PMDG documentation. I've no idea how they implement it, but I think it very unlikely that there will be "bits" you can access -- PMDG don't do that. There many be keystrokes you can assign for them, and you can program keystrokes to your buttons. Settings? Options, do you mean? It comes with quite a lot of documentation which describes all the options -- a User Guide and an Advanced User Guide. If you need inside (programming) information, that's in the SDK of course. But information about applications which may or may not use FSUIPC is only available from those who make the applications, exactly like your Mode C switch business. Regards Pete

Yes, I think you need to. Your DLL.XML file looks okay, but then I expected it to when you confirmed that FSCopilot was, in fact, running. Regards Pete

You can't. And why would you want to use an OLDER version than it asks for, when it specifically says 3.48 or later? The current version for FS9 is 3.75 and it is available as usual from http://www.schiratti.com/dowson, as all my stuff has been for the last 10-12 years. No earlier version should be used, no earlier version is supported. No, but you don't need to pay for what PMDG needs it for as they have a license. Pete