Pete Dowson

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

That's from your FSX.CFG file. I didn't want to see that at all. Only the DLL.XML file which is in the same folder. However, I do notice that FSX seems to think it is loading both FSUIPC4 and FSCopilot: X\Modules\FSUIPC4.dll.zqlwhweqrliokbczhiotiuuriaebcklrnlcerioo=1 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\Modules\FSCopilot.dll.uuallbheqrrraequbanlklraletqtkaqqowakhnk=1 But isn't that only an installer? The "FScopilot" I am aware of is an FS DL, it can't be "run" by you, only by FS. Okayso FSUIPC and FSCopilot are both running. That is entirely a different matter. In that case, none of this is really anything I can help you with. There's obviously no problem in SimConnect, and FSUIPC has nothing at all to do with Internet or chat or any of that. I'm afraid you do really need to get support form the FSInn folks. Regards Pete

sounds like it should be! ;-) Thanks & Best Regards Pete

Yes, goodbut of course it is impossible to derive anything from that which points to whatever it might be causing the problem. I really hate that sort of thing! Best Regards Pete

That is something impossible to imagine if the files were identical. If they are not, what could possibly be changing them? Okay. That sounds more reasonable. I'll keep it open. Regards Pete

How do I tell? Not sure. If you haven't assigned fixed IP addresses to each PC (recommended), so don't know what you are using, then I assume you should be able to find out by looking in the Network configuration of your Server PC? Pete

I'm afraid, then, it becomes a matter for Microsoft support. Regards Pete