Pete Dowson

Hmmm. How odd. Certainly the calibration in the software cannot just 'deteriorate' like that. The only things affecting the response from the potentiometers in joysticks are physical -- dirt, temperture, low voltages, poor contacts, et cetera. But re-installing FS won't make any difference to those. Cleaning the joystick insides and the plugs and sockets and things might, but not just re-installing FS. That doesn't make any sense to me, I'm afraid. I'm sorry, but not knowing why your joysticks are deteriorating in such an odd fashion I couldn't possibly say that FSUIPC can do anything. All it does it provide more exact full on and off settings (and centres where relevant). I wouldn't want you to pay for it just for that then be disappointed. I think you need to determine the cause of the problem and fix that. Sorry if this is a disappointment. Regards, Pete

I don't know the Elite driver, sorry (they've never contacted me about anything), but if they control the throttles by directly writing to the locations in FS, then this bypasses all FS and FSUIPC assignment and calibration processes. Sorry. You'd have to ask them to modify their driver. Regards, Pete

3.129 should fix it. Regards, Pete

This is a question for PMDG and PFC. PMDG say there will be an SDK to allow third party control over PMDG aircraft, but I don't think this will be free, so some licensing agreement will be needed between PFC and PMDG before I can do anything. Regards, Pete

Yes, thanks. since then I have had other reports and details (see appropriately entitled threads), and solved the issue, and I've actually released version 3.129 which I think will fix it. The anouncements tell the reason. I don't think it is quite on the Schiratti website yet, but I'm sure it will be by tomorrow. Thanks & Regards, Pete

I posted here about it too -- please see the announcement about version 3.129 above. Version 3.129 is released, it is just awaiting the kindness of Mr. Schiratti to put it on the website. Regards, Pete

It just says things may go wrong with 3.128 if you start FS with any complex panel or aircraft needing FSUIPC access. If you load FS with a default aircraft, then load your desired airc raft, it should be okay. Or wait for 3.129 as you say. It is nothing to do with programming, it is to do with how FS is being run. Pete

never any need to uninstall anything. Just copy FSUIPC.DLL into the modules folder. Sounds like there's a TCAS program trying to read data before anything is set up for it. Please check the Release notices above. I think it may cover your problem. Get 3.129 when it is on the Schiratti site. Sorry, Pete

I think it's the same problem as reported with A/P and A/T by a couple of PMDG 737 users. It is to do with the way FSUIPC now more safely doesn't start up fully until FS is completely operational. Some DLLs and Gauges are getting in a request to FSUIPC before this and are getting the wrong answers back. I am fixing it now -- I'm trying to do it in a way which still stops any attempts to access non-ready parts of FS (like SIM1.DLL) but without stopping access to those areas which aren't a problem. It only seems to affect folks who either have such complex aircraft as default or who select it from the initial "create a flight" dialogue. Reloading the aircraft concerned fixes it as by then the access restrictions are lifted. This is really all down to me being rather over-zealous with adding more safety code to FSUIPC. When I have tested the fixed version it will be released as 3.129. Sorry about the hassle. Regards, Pete

I've talked to my contact in PMDG and he says this problem may be to do with the safer method FSUIPC now employs to check that FS is truly ready before accessing certain parts of FS. I am looking at this now to see if I can fix it, but meanwhile it seems it may only be a problem if you go straight into the PMDG aircraft on loading FS. The cockpit may be getting the wrong signals from FSUIPC if it asks for them before FSUIPC is officially "running" on this new, safer, basis. Can you try re-selecting the aircraft afterwards and see if it cures the problem? As I say, I cannot make it happen here so far, but then I am loading the PMDG aircraft whilst in normal FS, not as initial load, as default, or through the initial Create a Flight menu. Let me know please. Pete

Okay, I've not tested this and can find no problem. The A/P won't engage on the ground, of course. That is right and proper. Similarly the A/T will only engage when the Generators are running (see overhead). Provided I operate the cockpit properly all is well. Maybe either your version of PMDG, or mine, is not fully up to date? I'm not sure how to tell as there are so many parts to it. I am asking my contact in PMDG to see if he can find any difference between 3.125 and 3.128 to explain this, but so far it seems to behave identically here on both! Regards, Pete

Are you sending decimal 16211 to offset 0330? It sounds as if you are simply incrementing it instead. But I don't understand whayt you are doing since you don't tell me anything. Sorry. Write the 2-byte decimal value 16211 to the FSUIPC offset 0330. This will set the barometer to 1013.2 (16211 = 1013.2 x 16). It is surely clear enough? Have you looked at the Programmer's Guide in the SDK? I'm afraid I don't understand what the problem is. You asked which offset to change for the altimeter setting. I told you. It is 0330, as documented. If you write values to 0330 it affects the altimeter setting. The units are 1/16ths of an hPa. Just as it says in the document. What more can I say? Sorry. Regards, Pete

There's one other mention, discussed in the thread "Winds" oddly enough. As I said there, I think possibly that part of the PMDG installation does not work with 3.125, which may explain the difference. Try removing the PMDGoptions.DLL from the Modules folder, and using 3.128. If this seems to "work" the same as in 3.125 with PMDGoptions, then it is that DLL, now allowed to operate again, which is making the difference. It is a bug in 3.125 which I suspect you are probably "taking advantage of" to bypass some operations needed which are coded into PMDG's more sophisticated cockpit. Let me know please. If what I say is not true, I'll try to check it again here. All 3.128 does is correct a bug in 3.12 and 3.125 which can actually stop some add-in DLLs working correctly. FSUIPC doesn't touch the A/P nor A/T except on request of applications. I have no webpage. Do you mean Mr Schiratti's "Dowson" page? I'll check. But it is nothing to do with me. I shall have to notify Mr. Schiratti. Thanks, Pete

I think that part of the PMDG installation does not work with 3.125, which may explain the difference. Try removing the PMDGoptions.DLL from the Modules folder, and using 3.128. If this seems to "work" the same as in 3.125 with PMDGoptions, then it is that DLL, now allowed to operate again, which is making the difference. It is a bug in 3.125 which I suspect you are probably "taking advantage of" to bypass some operations needed which are coded into PMDG's more sophisticated cockpit. I've not heard of the SSW A310. Regards, Pete

Yes, that's what I understood. I have added it to my list. Unfortunately, it isn't as trivial as you make it sound. Simply blanking them does not do enough -- the AP LEDs will still be turned back on if the AP is enabled, the radio displays will still show changes if you make them, and so on. It is very different from the avionics actually being OFF, as it is with PFC avionics switches. I have to have a flag saying the avionics are off, and refuse to send anything to the displays whilst they are, and also actually IGNORE any switch, rotary or button signals from them too. It is quite a lot to do and needs to be scheduled to be done when I have enough time to make sure I don't miss anything. (* or perhaps almost all - I believe that autopilots are not wired through the avionics switch in GA aircraft, so perhaps that section should remain lit as it does on the GoFlight MCP autopilot module whenever the Master switch is on.) Really? Seems unlikely? Not so sure about that as you are. The avionics include the very NAV radios which some of the A/P buttons connect to and operate from. If the entire stack is a Bendix King, as simulated, then I think you'll find it all gets its power through the same switches. Well, it's on the list. It'll get done. I just can't promise when at present. Ah, Right! Yes, you are correct. SorryI was only reading the COM sections, not the others. Thanks a lot! I've fixed it here, but it'll have to await another version before it goes out. Exactly the same, if you have that option selected and you are using an Avionics stack and don't have Jetliner selected as the console. The only difference now is that by "selected into FS" is meant "selected as COM1", as the other one is also now selected into FS, but as COM2. Really, for more realistic use of the Avionics stack you should turn the option off and just use COM1 as COM1 and COM2 as COM2. I only left the swapping business in in case folks were using COM2 as a sort of storehouse of additional standby frequencies for use with, say Radar Contact or Squawkbox. Don't I explain this well enough? What, what? Please tell me how to make that happen -- it must be a bug!Here both standby and active frequencies are always both displayed, except in the "off" part of the loop where neither of them have anything displayed. There should NEVER be a case where only half of the radio is on and the other half off! I will need exact steps to reproduce this please, as I doesn't happen whatever I do here. Maybe I shall need your PFC INI file too. :cry: Pete

Okay, the key for manual entry is 1U1O LKXY GP8Z. If you can test it and confirm, I'll add it to the FreeWare Key list. Regards, Pete

No need. As far as I know you have access to all the facilities. But maybe the list in the Advanced User's guide is out of date? I'll check and add new codes next time, but to keep up with Enrico it's best to get his FSUIPC interface guide from the PM site. Regards, Pete

It isn't in FSUIPC. It was a suggestion for weather programs. FSUIPC cannot decide what a "decent direction" for winds in, it is only passing on data on behalf of the programs which have the database and know the locations of the weather they are setting. The only possible change which may affect PMDG aircraft is that the PMDGOptions DLL should now be working fine as it would have in 3.11. It's possible that in 3.12 and 3.125 the options it provides may not have worked after loading the aircraft. FSUIPC itself doesn't touch the autopilot or have anything to do with it. Regards, Pete

Okay, so what I said wasn't wasted. Yes, which says it does work for all weather in FS2004. Yes, and global weather too. As it says, and as I repeated, it works for ALL weather. It isn't applied to the weather inputs at all, it's applied to the end results. I'd like to be able to do the same for winds and pressure too, but I can't find a way to do it (yet). Well, no, not strictly correct. Certainly I cannot impose the altitude you select for the top of the visibility layer for F's own weather - this is one of the filter actions. It can apply filters to data passing through its own interfaces, but it can't get into FS's existing settings and change then. This doesn't mean to say there is no such altitude, it only means that the top of the FS visibility layer is whatever it is set to be in FS, not in the FSUIPC options. However, if you set the lower altitude of the graduated visibility option to zero, FSUIPC will automatically start the graduation from the FS value for the top of the surface visibility. Please look at the visibility page in FSUIPC Options, on screen. You see the three facilities asterisked? Thoise are the facilities which apply to AL weathers. I thought I made that clear. Overcasts are clouds, not visibility. You are mixing up two differet weather aspects. You need to set maximum density clouds in the display settings. I run with all the sliders there set to maximum, and it looks okay to me. Neither. It can't do it at all, with anything. FSUIPC cannot do anything at all about cloud graphics. That is not a weather function so much as a graphics image function. Sorry. Regards, Pete

This is for an unregistered copy of FSUIPC, yes? If your FSUIPC is registered then it needs no codes for any programs. Really codes for freeware programs should be obtained by their author. Is this a freeware older program no longer being maintained? If so, I can publish a code but I need information: 1. It's exact EXE name 2 The Product Description text from its "Version" information. 3. The "Company" name from its Version information. You get the Version information by right clicking on the program in Explorer, selecting Properties then Version. Pete

Actually, no! Not all all correct! I will assume you are talking about FSUIPC installed in FS2004? If not, tell me because all this will be wrong otherwise. What you say is true for the wind and pressure smoothing only. All the other filters work with any global weather, including FS's own if you enable that in the Technical page. It says this in the documentation, and tries to imply it in the comments on screen. The problem really is that in FS2004 there's not really any such thing as "global" weather. Before long anything set globally becomes localised in any case. It's a better atmospheric simulation than in previous releases and never really stays still. The big exception to this deficiency in FSUIPC's attempts to control things for you are, in fact, the main three visibility features deliberately marked with asterisks (*) in the options page to bring them out. As the documentation says, and the screens imply, these three apply to ALL WEATHERS. These features are the visibility maxima, the smoothing and the graduation. They work best together. No, not correct. Those three main facilities work with ALL weathers, as I thought I clearly stated in several places. No. That is not at all true. FSUIPC works with all the weather programs I know of. Take out FSUIPC and none of them can do any weather control whatsoever! If what you really mean is that the FSUIPC weather filtering options don't work with localised weather setting programs, then, yes, that is most certainly true of many of the other facilities -- just not the main three visibility features. Of course you can, I believe, set FSMeteo to apply only global weather. But as explained at length both in the FSUIPC documentation (near the end) and in one of the Announcements in this forum (see above), global weather doesn't last long as global in FS2004, so really I would say that none of the global stuff is of long term interest in FS2004. I have tried to explain all this stuff in the documentation, yet you seem to have come out with almost the opposite impression!! Can you tell me how you arrived at this? It makes me think my powers of English have diminished considerably. Even in the limited space of the FSUIPC option screens I try to show what applies to what, yet you have the opposite results, almost. How is this, please? Regards, Pete

Hi Hugo, Sorry to have taken so long over this, and I know we've discssed other ways of solving your original problems now, but I just came to fix the problem you found, and I cannot find it. I think it all works as intended. Just to refresh: I think you are misinterpreting two things which are happening: 1. If you tell FSUIPC to use a different control name, say "TESTME" then a number of filename changes are assumed: The INI file is now TESTME.INI The LOG file is now TESTME.LOG The KEY file is now TESTME.KEY I think in your cae you didn't make a copy of your KEY file with the new name, so that load of FSUIPC wasn't registered. Because it wasn't registered you got no key and button mapping. 2. The [FSUIPC] section isn't being deleted from the FS9 CFG file. All that's happening is that other sections are being re-written after it. If you do a search you will find it still, buried amongst other FS stuff. Finally, for all this, I have only tested it with the default FS9.CFG in the C:\Documents and Settings\\Application Data\Microsoft\FS9 folder. I haven't had to to check the /CFG: facility for loading FS9, but I would think it would still look for the CFG files in the same folder? Regards, Pete

Yes, but this is "Real-world weather". I am assuming that the original post was really referring to this, not "dynamic weather" which is just a slider on the same page, that determines the speed at which whatever weather is being used is changing. Thanks for clarifying the issue of Internet connection problems, it does indeed seem the FS is not very resilient to these at all. Regards, Pete

In Visual Basic the form "&HE000" will be taken to mean the offset "FFFFE000". This will be invalid in FSUIPC, but it will create a valid Advanced Weather request of something like 1FE000, which will fail in any case because the AWI needs a special data structure. If you used the FSUIPC IPC logging as I suggested you would see that the offset you were sending is wrong, immediately, saving yourself a lot of time. Please use the tools available. You will find them useful, honestly. I am not a VB programmer, but I understand the VB compiler is even nasty enough to change &H0000E000 into &HFFFFE000 before it is used. Apparently you have to add another & at the end to stop this stupid behaviour. In other words &HE000&. With such a crazy behaviour you'd think it would be spelled out in big bold letters in all the VB books. Regards, Pete

Sorry, I have no idea what would do that. However, 3.125 does fix a problem which may possibly have stopped something working correctly in the aircraft when used with 3.11 (see the History). Anyway, just in case it is something in 3.125, I am emailing you a more recent test version to try. Please let me know. If this doesn't fix it then I'm afraid you'll need to seek advice from PSS. Regards, Pete