Pete Dowson

No way I know, sorry. If you find out how to hack it in FSX code let me know. Regards Pete

Well, except that it doesn't total up more than the first 5 payload stations. This is not enough for the default 737 in FS9 which has 9 stations. In order to use the fuel planner are you setting the other stations to zero payload? I've written to the B373FPl author about this. Hopefully he will correct it soon. I wouldn't mind using this for my FSX 737. ;-) Regards Pete

I've downloaded and tried this program. It looks to be very old, designed for FS2002 or before (but FS2002 and before provided no payload setting facilities -- folks had to fiddle it via fuel loadings). Under FS9 it is reading the payload fine using 3.862 -- excepting that it only ever reads the first 5 payload stations, even though, for example, the default 737 declares 9 of them! I ran it using FSUIPC 3.802 (the closest I could find to 3.806) and it is exactly the same. It doesn't seem a very useful option, reading the payload from FS, if it only reads some of the stations. If the author is still maintaining it perhaps you should write to him and ask for it to be fixed? Anyway, on the original matter, I am now suspecting your User Registration for FSUIPC. Try removing the FSUIPC.KEY file from the FS Modules folder. If it then works okay, you have a bad key. Zip up the FSUIPC.KEY file and send that to me. Regards Pete

Not much of a clue there I'm afraid. There were several major releases and many many incremental releases between those two. Please first get the current increment so that you and I are looking at the same thing. Version 3.862, in the Updates announcement above. Then, before running the fuel planner, please go to FSUIPC's options, find the Logging tab, and enable IPC Read logging. (I am hoping here that you don't have any other FSUIPC-using programs or aircraft running. If you do please stop them, and choose the default 737 first, otherwise the Log will get full of irrelevant material). Run the fuel planner, get the problem, close it and FS, find the FSUIPC.LOG file (in the FS Modules folder), ZIP it up and send it to me at petedowson@btconnect.com. It might be helpful to repeat exactly as above with 3.806 too, then I can compare them to see where the difference lies. Be sure to name the ZIPs appropriately, please. No Regards Pete

A400? What's that? That is checked by default for the very reason that some aircraft use those controls internally. Did you uncheck it? Still trying to use the "no reverse zone" facility? Sorry, I don't understand "donats"? Is this a word for detentes? What is "ED"? Are these all Airbus technical terms? If so, sorry, but I am totally unacquainted with Airbus, so you'd need to explain things better. If even using FS normal assignments, no FSUIPC involvement, doesn't work with this aircraft then certainly there is no easy way that FSUIPC can fix it. It does really sound like Wilco need to do something to make it work properly, doesn't it? Well, I still don't know what these "donats" are, but certainly if it were a Boeing, considering N1 idle is between 20 and 30%, I should think the 50% position on the thrust levers to be well in excess of 50% N1. Typically on a 737 the N1% readout for a mid-thrust lever position is certainly 65-70% in my experience, so if I understand you correctly your results are correct. What are these "axis_throttle_1/2" and "throttle_1/2" you are ticking? You have lost me completely now. Sorry. Surely you don't mean that you are assigning both controls to both axes? That's crazy -- they use different scales, as I explained, and will certainly conflict! It certainly sounds like it is rather a mess. Are Wilco doing anything about it? Regards Pete

The keys are tied specifically to one user, one person, and he/she is identified by name and address/email. The email doesn't have to be your new one, it could have been your old one. It does mention this restriction in the section on Registration in the FSUIPC user guide. You really needn't to mention the correct email address when ordering the key. You can probably get SimMarket to sort it out for you by raising a problem ticket. Or else ZIP up your working FSUIPC KEY file and send it to me (petedowson@btconnect.com) along with your new WideFS key and name/email details, and I can sort it here. It'll be tomorrow now -- bedtime beckons. Regards Pete

Actually it should be fine for ALL apps -- the format is called UNC where "U" is for Universal". That's the whole idea -- it doesn't matter whether you are on a different PC or the same PC, the path is correct. I doubt that is anything to do with the UNC pathname. Check with PFE support, because all standard Windows-supported file access facilities handle UNC path names properly. No, FSUIPC supplies UNC path names so that any program anywhere can access the files they need. No. And are you saying "\\XP64FS9\XP64 FS9 (L)\Program Files (x86)\Microsoft Games\Flight Simulator 9\" is not a valid path? This is provided by the Windows installed on that PC, so it most certainly should be the correct path. Which part is wrong? It is no different for any app. The name of the current PC is the same whether you are running on that PC or not. Many many applications use UNC paths and do not know or care whether they are local or remote. That is the whole point of the system! Regards Pete

Yes, FSUIPC supplies the full path and filename of the AIR fie currently loaded. the CFG file is in the same folder. Offset 3C00. On FSX or ESP you can also get the same thing through SimConnect. Regards Pete

What have the "x86 files" got to do with FSUIPC? The only files anything to do with FSUIPC are all in the FSX modules folder, which is not access protected but available to all. You don't need to run explorer "as admin" to access or delete things from the FSX Modules folder. And you don't need to delete FSUIPC4 to reinstall it. Just run the installer. If you are ever asked to run something "as administrator", you should right click on the program itself, or its shortcut, select "Run As administrator". This runs the program in what is called "elevated administrator mode", which is the same level as an installer gets. It is more than your normal user Admin level and provides access to places otherwise denied. What three files are you talking about? Are you talking about SimConnect, not FSUIPC after all? Please clarify. Regards Pete

Not related to SimConnect. Or at least, not that I'm aware of. The whole of the side-by-side library system is a bit of a mystery to me, though. Oddly, despite being involved in the Beta testing of FSX and its updates, and as a consequence repeatedly uninstalling and reinstalling versions on at least three different PCs (XP, Vista32 and Vista64), I've never had any SimConnect problems, so I have always had to try to help folks in theory rather than practice, and the theory is, er, either unpublished or hard to find/understand. Unless you reinstalled Windows that is correct. Internet Explorer is charged with the maintenance of the certificate store, and consequently the trusted and untrusted publisher lists. You can view them and edit them through its internet Options menu somewhere. Regards Pete

"legacy interface folders"? What are they? If it didn't find the two in the two remaining WinSxS folders (one for the Base, one for SP1), your repair didn't work. Are you searching including hidden and system files and folders? Otherwise it won't find them. You may need to go into the Explorer folder options and tell Vista to stop hiding extensions and system files from you. Theoretically, yes. but virtually all the problems folks have ever had with SimConnect have been due to uninstall/reinstall attempts. I think the whole "side-by-side" system in Windows is very, er, flakey! Standard uninstalers just don't uninstall any side-by-side libraries their installer installed, which is why we revert to manual deletion -- otherwise the installer/repairer won't touch it. Ugh. Certainly. There should be two, the base one and the SP1 one. Repair or re-install should have put them back, assuming you deleted the folders (not the DLLs -- it is the presence of the folders which is checked). Regards Pete

sorry, I've not really any idea why that should be. Have you tried tracing through your program and the FSUIPC _Open call (the source is provided)? Just in case it is actually getting connected but receiving bad data, please enable IPC read and IPC write logging in FSUIPC's Logging tab, and try connecting again. Then close FS down and show me the Log file. Regards Pete

Are you using FSUIPC 4.40 or later yet? Anyway, the issue is not in changing aircraft, but in the different instrumentation. The "Kollsman window" is applicable to 'real' altimeters. The G1000 is actually a GPS, an additional instrument. Check the standby altimeter (surely there is one?). The clue was actually in your log, but I missed it: 312437 *** EVENT: Cntrl= 65883 (0x0001015b), Param= 2 (0x00000002) KOHLSMAN_INC I've never seen that before, but it seems to direct the change to the knob on the G1000 and changes the pressure reading there. SimConnect does NOT supply FSUIPC (or anything else) with an updated altimeter reading. Conversely, the normal Kohlsman INC /DEC controls, those with a parameter of 0 (it never had a parameter before) does alter the altimeter setting internally, and SimConnect does supply the update value, but the G1000 is not affected. It looks as if the G1000 is a completely separate, independent system, unrelated to the usual FS instrumention. For most of its functions whey invented new controls (G1000+ ...") but it seems for this, instead of doing "G1000_KOHLSMAN_INC" and "DEC" (which would have made it obvious) they re-used the original control with a parameter value to direct it to the G1000 instead. There's no information supplied by SimConnect for G1000 stuff, so FSUIPC can't supply it. Regards Pete

I'm rather surprised that any aircraft specifically processes old FS controls THROTTLEn_SET as if they are the same as the later and more normal AXIS_THROTTLEn_SET controls, when they've always had this important difference. It doesn't really make much sense to me. Have you asked them about this? Without the retention all this time in FS for the old THROTTLEn_SET controls it would have been much more difficult to support proper axis-based reverse control. Aren't there any other Wilco A320 users using FSUIPC for multiple throttle calibration, or this a very recently released aircraft? From what you say, if you do NOT check the option for no reverse zone, you would actually get more range -- still not full because the reverser tends to only go back as far as -4096. But I think you could make that get to -16383 by setting the Aircraft CFG file to say the maximum reverse is 100% instead of 25% or whatever it is. Assuming Wilco have implemented reverse by button control only, in any case, such a change should not affect it. Regards Pete

ASX seems to work fine with FSX SP2/Acceleration here. When you uninstalled SP2, how did you remove the SP2 Simconnect? It isn't easy. The side-by-side library system is very sifficult. This is ASX's client, you mean? FSX doesn't have a Modules menu entry in any case. It has an "Add-ons" menu instead, which is where FSUIPC will appear, if it connects okay to SimConnect. Ah, right. Did you repair from the FSX DVD first, then SP1? There's the clue. Looks like you have a SimConnect.dll in the wrong place -- in the FSX folder or in the Modules folder, or possibly in one of the Windows folders. Apart from normally unaccessed folders, like the SDK, it must only be in its correct WinSxS folder. Do a search for SimConnect.dll and remove any outside the WinSxS folders or the SDK. Ugh. That's a daft line -- that should say "SimConnect.dll". I'll need to fix that ... ... Ah, looks like I did already. The current message (in 4.418) is: Anyway, the result of the bad copy of SimConnect being there, somewhere (probably in D:\FSX) is this:

Yes, for the standard AXIS_THROTTLE_SET control, used there (the same as the single FS assignable throttle), forward thrust runs for -16383 (idle) to +16383 (max thrust). There is no reverse range for that control. Ah, you mean you are not using the axis input to FS for reverse? Why not? The multiple throttle control does NOT use "AXIS_THROTTLEn_SET" controls at all. They have no reverse zone either. It uses "THROTTLEn_SET" controls which do run from 0 (idle) to +16384 for max thrust. Values below zero provide reverse thrust. This is how FS works. But it is the full range for the specific control being used! Because for THROTTLEn_SET controls the idle is always at 0. That's the way those specific controls work. All the "no reverse zone" facility does is remove the ability to set the -ve range. The facility does NOT change the whole way the multiple throttle system works -- it still uses the same FS throttle controls, the ones with the reverse range. Regards Pete

First, I cannot support old versions of FSUIPC! Please update to at least 4.40 and try again! Here 0330 reads "16212" when I set the Kollsman to read "29.92". One INC from that, to 29.93 gives me 16217, and one decrement gives me 16207. What aircraft are you using? The value "16210" is the "STD" value (1013.25 hPa), maintained for flying Flight Levels, and on a real airliner cockpit, adjusting the altimeter whilst in STD mode does NOT change the setting, but changes the reading in a sub-scale. Are you sure the aircraft panel you are using isn't operating this way? Have you tried pressing the STD or BARO button on the EFIS? Always test things with default aircraft in the first instance. And please make sure you are using supported versions next time you ask a question. Regards Pete

Ah, yes, a Mr. Poulos. Sorry. That was all done on my side back in October. I forgot the product name. He even sent a copy of the software to and debug, but this showed it crashing in FSX in some routine they use to retrieve some waypoint data. Here it crashed in the same place both with and without FSUIPC4 installed, but only with the debugger running. That was in Windowed mode. In full screen mode their software locked up my entire PC needing a power re-cycle. Without the debugger there the problem was reproducible here, but that is of no use as there's no information. There certainly isn't anything at all which points at FSUIPC, except that it occurs far less frequently, if at all, without it. With the debugger loaded I could get no further than a particular point deep down from their Gauge code, someplace in Windows GDI. Again, there was never any sign of anything to do with FSUIPC being involved. Here are my conclusions, exactly as stated to Mr. Poulos, The stack on the crash shows it deep in Windows, from their Gauge, as you can see in the attached screen grab. Well, see above. My last exchanges with Mr Poulos ended with him saying that they had taken it up with Microsoft, but the latter have no time to support FSX at present, so he needed to reproduce it with ESP. I sent him ESPIPC and he has managed to reproduce it on ESP too, now. That was a week or so before Christmas. The ESP support team have been away on their break until last week, so Mr. Poulos was going to take it up with them again "in January". I've not heard any more yet. Regards Pete

If that is truly the value you are adjusting, to set the altimeter correctly for the prevailing pressure (QNH), then why, as you say, do you never change it? That makes no sense to me. The FSUIPC output of this value is used in many third party cockpits (e,g, using Project Magenta, Flight Deck Software, etc) including my own, and has always worked fine, no problem. Please go into FSUIPC's options, find the Logging tab, enable Event logging (on the left) and add 0330 to the table on the right, as type U16. Check the "normal log" and "fs window" (or "advdisplay window" for FS9) below. Now adjust the altimeter reading. See the value of 0330 on screen change. Show me the resulting Log (from the FS Modules folder). BTW please ALWAYS state FSUIPC version numbers. Regards Pete

Why? Are you running FS in elevated privileged mode too? You shouldn't have to do either. I assume you are using Vista? It seems that it prohibits memory-mapped file sharing between programs at different privilege levels. There should be no need to do that. Regards Pete

That's usually either a problem with video drivers, or possibly a conflict with another add-in module in your FS9 Modules folder -- possibly "actigate.dll". I've really no idea how the latter does this as it only happens on a few systems. Try putting FS into Windowed mode first -- ALT + ENTER. That should avoid the video driver problem. If it's another module, you may need to remove it temporarily, before loading FS. Regards Pete

How are you changing this value? are you sure you are not changing the actual barometric pressure? If you have never needed to adjust the altimeter when how on Earth are you flying with the correct altitude shown. Except when flying Flight Levels you always have to adjust the Kollsman setting on the altitmeter to match the QNH value, otherwise the altitude will read incorrectly! It sound to me as if you are changing the wrong thing. Pete

Sorry, I've no idea at all what you are talking about. If folks want to accuse me of sloppy programming they ought to appear and show the evidence. Pete

Captain Sim have told me they know about the problem, that it is nothing to do with FSUIPC, and that they are working on it. Pete

Who supposes that? FSUIPC may well be used by the aircraft (I don't know), but I've certainly never even heard of "ft733.dll". As Jim says, you need to deal with the support folks for your aircraft. Pete