Pete Dowson

That's what I thought, and was waiting for the Log to confirm. but I'd also need to see the log to see if there's anything I can do to help. It seems to be forever coming! ;-) No no no no! JUST do the things I ask. Enable button logging. That's it. Then OK out. I've said exactly this several times now! It's so damned easy. If in any doubt why not read what I write? Or even look in the user documentation supplied with FSUIPC? :-( Did you try the mouse thing yet at all? Pete

Yes, of course. That's the button which when released on the switch releases it from Start, right? Not the centre button or the right button? This is why I said (3rd time now?) "with the mouse far away from the switch, preferably somewhere innocuous like in the outside view, click and release the left button.". See? Mouse was the operative word there? I am trying to see if me sending a Mouse Button Up message might work. I thought I said that way back? No not nearly, really, but it shouldn't have mattered: As I asked, just enable "button and key logging" -- then and click OK as usual to get out. Nothing else. Why start a new log? Anyway, the log renamed FSUIPC.1.log is the OLD log, the NEW log, with the button logging in it, will be FSUIPC.log as always. Each time you start a new log it will keep the old one like that. But there's no need at all unless you want a proliferation of files! The "display to normal log" checkbox in on the Monitor side of the logging tab and is completely and utterly irrelevant unless you are entering offsets in the table there for monitoring. Why not just check the things I say? Or peruse the user documentation. There's a section on each Tab. Anyway, another day now. It's late here (02:35 am) and I'm off to bed. Looks like this may take a few weeks! ;-) Regards Pete

If it isn't huge you could just paste it into a message. If you put it in as "Code" it will be in a scrollable section of its own, if big enough. Otherwise you can email it, ZIPped please, as an attachment, to petedowson@btconnect.com. Hmm. Interesting, but not really useful for me as I'm not using the mouse itself. What I suggested trying was, to repeat with emboldening: "Use the button to set the APU to start, then, with the mouse far away from the switch, preferably somewhere innocuous like in the outside view, click and release the left button. See if the starter releases." Sorry, it may have been ambiguous. If the switch release only works by the gauge using mouse capture, then there's no way I'm going to be able to do anything with it. We'll see. I suppose you can't get any help from the aircraft makers themselves? Maybe they've used unpublished tricks in FS and want to keep them quiet for competitive reasons, but on the other hand it may just be something I've missed! Regards Pete

By changing the PollInterval, an optional parameter for the main [buttons] section, as described in the Button Programming section of the Advanced Users Guide. The default has been arrived at over many years, so shouldn't be changed on a whim, but by all means experiment if you must. Hmm. Odd.You should be able to do it singly quite easily. Are the button signals from the device getting delayed? Won't decreasing the refresh from the device make things worse rather than better? You want the button release signal to get to FS/FSUIPC as soon as possible, not delayed by another 100 mSecs (for 10 Hz). Maybe the slowish refresh rate of 50Hz at the device is the main cause of the problem. Add to that the potential delays through Windows and the queueing system. I think the default poll interval in FSUIPC is 25 mSecs, so if the delay of the release is often at least 20 mSecs (from the 50Hz rate) I can see there being occasions when at least one repeat would occur. If FS is very busy, more maybe. Have you tried increasing the device's poll rate? Of course if the MFP has buttons-a-plenty, or a "shift" arrangement for doubling them, you could assign two different buttons, one fast and the other slow. Incidentally, what FS control are you assigning to for this? Sometimes FS accelerates these as well, as when, for instance, it receives two or more controls of the same type within a certain time. That might be responsible for some of it too. Regards Pete

Thanks. I see you are using Aircraft specific settings, not "Profiles". It looks like FSUIPC is not, initially at least, overriding the generic key assignments (in [Keys]) for those keypresses which have aircraft-specific settings. The double assignments I see (there may be more) between the [Keys] section and the [Keys.PMDG747-400] section, occur for these Keypresses: 72,11 90,11 97,8 98,8 99,8 100,8 101,8 102,8 103,8 104,8 105,8 189,10 I suspect it is these double assignments giving you the problems you describe -- looking at them some do seem to be combinations like, for example, 97,8 operating both PANEL 1 and Panel ID toggle 30. I'll look at this and fix it as soon as I can -- it must be related to the changes I've added recently, maybe those for Profiles. I'll check those too. Strange how it corrects itself on reload -- there's obviously some parameter or flag I'm not initialising properly on first load. I don't know how long it'll take me to fix this, maybe a day or two. If you are mostly using only the PMDG747 then you could continue okay by temporarily disabling the [Keys] section (e.g. by renaming it [xKeys]). Regards Pete

How strange. I'll need to see the FSUIPC logging for that, with button & keys logging enabled. It certainly sounds like you have the same key programmed twice, or even once by still for keyboard. Maybe you should also post the all the [Keys...] sections from your FSUIPC4.INI file. Then I can see what you have done. No idea. I wouldn't have thought so -- they are used for two functions by FS itself, depending on NUMlock (views and flight controls). I think you still have the olde key-ress assignments in your configuration, you've not deleted them, only added more, so things are getting into a mess. It just says please wait whilst settings are being loaded. I added that because some folks have large complex sets of settings and, what with the Profile lookups and JoyName matchings, it is starting to take enough time that it can look stuck. All that using the reload buttons does is repeat what FSUIPC would have done when first loaded. Certainly, it wil revise profile listings, so if there's something tangled up in your INI file it could get into a mess still. Maybe you sohlud actually ZIP your FSUIPC4.INI file and send it to me at petedowson@btconnect.com. It sounds like you've got into a bit of a mess. Logging options "stick", so if you enabled the Button and Key logging and closed FSX down, the logging would stil be there next time. Regards Pete

Er, yes, of course, if you edit the INI file you need to use Reload to get FSUIPC to scan the changes. It saves having to close FS and restart it. Are you using Profiles? What version of FS? What version of FSUIPC, please? In this case I'm afraid it is I, not understanding you. What exactly is the problem? Can you spell it out, please, step by step. All you've said so far seems to be that after making changes directly to the INI file you need to tell FSUIPC to reload them. There's nothing special or different about the "Panel" controls. As far as FSUIPC is concerned they are indistingishable from any other FS control - they are merely posted off to FS to be executed. Note that if you are using profiles there are some fixes in the latest update, 4.421. Regards Pete

It doesn't matter to me either way. All I need to see is the log of you making them! It occurs to me that the gauge might be actively looking for a "Mouse Up" event -- trapping the actual Windows message for this, because, as far as I can see, FS itself does not provide such a call in its mouse operation armoury. I'll look further when I see your log, but if some gauges really do trap the real mouse actions as well, or instead, then the mouse macro facility I'm providing cannot work with those actions. If it is simply a matter of seeing a "mouse button up" message, and it doesn't care where from, maybe I could provide an extra assignable control to just send Mouse Up messages. That's another thing you can try. Use the button to set the APU to start, then, with the mouse far away from the switch, preferably somewhere innocuous like in the outside view, click and release the left button. See if the starter releases. Regards Pete

No different FSUIPC versions will help with random button operations. FSUIPC doesn't actually press buttons for you (though other programs can, through FSUIPC), so unless you are pressing them, something else is wrong. Possible causes would be faulty joystick, bad cable, lousy connection, USB problems on the motherboard, interrupt conflicts in Windows (though the latter should be almost impossible in WinXP and later -- it used to be a problem with Win98 and before). Maybe some buttons are now assigned incorrectly and you are simply getting wrong things assigned to wrong actions, and this is confusing you? When you re-install Windows, or drivers, or re-connect USB devices, or update their drivers, the equivalence between the joystick devices and Windows' own numbering of them can change. Why not enable FSUIPC's Button logging (options, Logging tab), and see what the log shows -- first without you pressing any buttons (to see if button presses are being received incorrectly), then to check that each button is doing the action you expect? The log will be in the FSX Modules folder. If you run FSX in Windowed mode (albeit temporarily) you can also enable the Console Log (in the Logging tab), which will allow you to immediately see on screen the entries placed in the log as you press the buttons. The latest FSUIPC interim versions (in the Updates folder above) have facilities to make dealing with changes to joystick connections a lot easier, by assigning letters (A-Z, or your choice) to joystick devices by name, instead of using the Windows-assigned numerical ID directly. So you could do better with an update again rather than a retreat! Regards Pete

Yes. No. All of FSUIPC's logging goes into the FSUIPC log file, which is ALWAYS produced. The options just add more stuff to it, that's all. The log file is a text file and it is in the Modules folder along with the DLL and the INI file. Yes, I would need to see the Log to see if there's anything I can do. Pete

Why use FSInterrgogate when you can get detailed logging, including the source SimConnect values being used, directly in FSUIPC's Monitor, as I suggested? All this to'ing and fro'ing in FSInterrogate is completely unnecessary if you used the monitor as it will show all these changes, all the ones you'd be missing too -- and live on screen if you wanted. Anyway, that's exactly the same as in 4.416, so it will probably have been the same since 4.000. At least it isn't something I've mucked up recently. I know. We've been through this before. I am also reading another value into it. Because SimConnect only supplies values when they change, this works perfectly when one value is changed in some aircraft and the other in others. I thought this to be true of these values for 0898 -- but it evidently isn't -- but only for the 206! I don't want to mess the values up for al the other aircraft, which is why I've done what I said. Yes, you explained that too. There's no need to repeat things, I do remember! ;-) Ah. I hadn't spotted that one, or thought it not the relevant one. I'll see if that works. Regards Pete

Okay. Fixed. Please download the update now available. Regards Pete

Show me the results in the [Joynames] section and I can discuss it with you, but I think you will find it blindingly obvious. Have you even downloaded the update and tried it yet? I can help you sort out specifics but I'm not going to translate my English into another language. Sorry. You have to actually do something too! I'm out now for a few hours anyway. Why don't you simply have a go. Run it, Look at it. Do as I said! Pete

With 4.40, you mean, to make sure I've not messed something up between 4.40 and 4.416? I don't want logs now for 4.416. Please try 4.421, just posted in the Updates announcement. I now don't overwrite 0896 and 0898 with other values IF the aircraft type (0609) says "Helo". That didn't seem to matter with the other helos. I can find no SimConnect variable which supplies any varying ITT or TIT in any units for the 206. I can't see where the gasuge is to even check it. Are you sure this aircraft is so equipped? Is the value in FS9 the same as one of the newer upper-offsets -- maybe I can get it if i knew which it was, but there's nothing named in SimConnect as a "temperature" which seems to work. If you do find it, please let me know. Regards Pete

No, sorry. The Firewall is irrelevant, as should be the anti-virus. If both FS9 and your applications are running at the same user level, not "as administrator", then there will be no problem. Jim suggests that the programs may require you to update your very out-of-date copy of FS2004 -- the 9.1 update Microsoft released later in 2004 was really an essential error fix release. Otherwise I'm afraid you'll need to talk to the support guys for the programs you are trying to run. I don't know what they are checking, but if they say they can't even see FS/FSUIPC it suggests a privilege level difference. What is this "ac-av" program anyway? I don't know it at all. Regards Pete

Unfortunately, I think Vista reports itself as XP to non-Vista aware programs such as FS9. Very annoying. Possibly, though not many programs are dependent on that. Rgards Pete

Even reinstalling Windows or simply plugging things in differently on the same motherboard can do that. There have been lots of changes in FSUIPC recently to assist in this very problem, but now you are in the mixed up state you'll need to do some work on it. These changes have not made it yet to an "official" user release, and so the User Guide is not yet updated. But please take a look at the Updates announcement near the top of this Forum. Scan down to the item starting You will find that this should assist you enormously. You can get FSUIPC to automatically covert all of the parameter entries for you -- they will then still be incorrect, but then, after closing FS and looking in the FSUIPC INI file you'll be able to swap things merely by changing the letter assigned for each of the named joysticks in the [JoyNames] section. From then on, any changes will be tracked UNLESS the name of the joystick changes (which can actually happen if you update a joystick driver). There is an exception, of course, when more than one joystick has exactly the same name. you'd need to check which was which experimentally then, in FS. You'll need to download and install the interim update using the link provided. Note that both FSUIPC3 and FSUIPC4 are being updated again tonight, so you may wish to wait until tomorrow, or at least replace it again tomorrow. Regards Pete

You have to read it from FSUIPC first, then test it in an if statement, obviously. Same as anything you want to read and deal with from FSUIPC. If you don't read it you can't test it. Sorry, I'm not about to learn VB.NET. If you aren't a programmer someone else will have to program it for you. Regards Pete

Okay, that is better ... But that is worse again. :-( That error is being returned by SimConnect. The scan didn't find them even though they were there? You had the search set to not look for system files by the sound of it. Well, SimConnect is loading but it is now failing. This is a different problem. Googling on 80004005 brings up a whole host of stuff, but they all seem to have one thing in common -- read/write access problems, often to do permissions on files or folders. Most of those related to FSX seem to be about activation problems after re-installing FSX. Sorry, I'm out of ideas. This is in Microsoft Tech Support country now. Or bite the bullet and re-install Windows etc. :-( Unfortunately the tell_fs email address is not there for you to get support, but to keep the FS team informed so that they can (a) do better in future -- i.e. fix bugs in new versions, and (b) assist MS tech support with anything that eventually manages to get through their filters. Regards Pete

I think you have to be sure to restore all those ownership and security settings afterwards. Evidently SimConnect is stil not installed correctly then. Where's the FSUIPC4 installer log? Didn't it report an error? No, NOT the same! You didn't have that error 0x80004005 before. Not sure what that means though. :-( Incidentally, you cut off the top of the Log file so I cannot even see which SimConnect it was first trying. Ah. Fatal! I agree. The side-by-side system seems half-baked. The biggest part of the problem appears to be that uninstallers cannot uninstall Side-by-Side library installations, so if they somehow foul up they cannot be repaired. Or it is worse than that. The act of uninstalling does not fully uninstall side-by-side libraries, but somehow makes a mess of whatever way Windows has of linking to them. Something to do with those horrible long GUID values I suspect, but the whole system is shrouded in mysteries like that. Please do consider submitting a full account of the trials and tribulations you've had to go through over this tpo Microsoft, via tell_fs@microsoft.com. Maybe Windows 7 will have this subsystem sorted? Let's hope so! Regards Pete

Okay, that looks fine, as far as it goes. I really need to see a complete log, after FS is closed, as there is important information at the end too. I see that you let FS install in its default folder: C:\Program Files\Microsoft Games\Flight Simulator 9\ This can be a big problem on Vista because Vista protects "Program Files" from non-privileged users and programs. Vista actually recognises FS9 as an older, non-Vista aware program, and puts the files elsewhere with Aliasses in the places you see. I think this can confuse add-ons quite easily. It isn't anything to do with FSUIPC but to do with how the programs are checking things and attempting to connect. So, EITHER your problem might be because of the different privilege levels I already mentioned -- did you check that? Try running your add-on programs using right-click and "run as administator" (or possibly changing their program properties so this always happens). OR it could simply be all due to this business of protected Program Files folders. I think that, if neither of these suggests a solution which works, you will need to contact the authors of the individual programs for a solution -- maybe they have a Vista-aware version by now. Alternatively, you could uninstall FS9 and re-install it somewhere more, er "sensible", like C:\FS9. Regards Pete

Okay I can reproduce it and will fix it directly, but meanwhile there is an easy work-around. Start again with a fresh INI file, or at least delete the profile entries you've accumulated. In the Axis assignments tab, when you select "Profile specific", then create the New profile, etc, the check mark does disappear. It's a silly bug -- it loses the flag through the prompting about copying the existing assignments. But if you immediately then check the "Profile specific" box again, it works and is all set to do what you want. I think you only get the real problems you got if you immediately start trying to assign stuff and go into other Tabs or exit, etc. Just re-setting the checkmark seems to fix it (for now). I may get to releasing an update with a real fix later today. I'll see how I get onkeep an eye on the Updates Announcement for a Date change in the title! ;-) Regards Pete

I'm not surprised. Offset 0814 isn't used. In FS2000 and FS98 it used to be the "flight analysis mode", and was always 1 if you'd asked FS to analyse your landings -- but it never ever meant you had landed. It isn't supported in FS2002, FS2004, FSX or ESP. The only way to detect when you land is to watch the "on ground" flag, offset 0366. Pete

And have you confirmed that it is running, by seeing if there is a Modules menu entry, with FSUIPC in it? Okay, so the error is from those programs. Have you registered FSUIPC as a User? If so, try temporarily removing your FSUIPC.KEY file from the FS Modules folder, then run FS again, and those programs. If they now work, there is something wrong with your Key, or the System Date on your PC is wrong, preceding the date of your registration. The problem can also arise, on Vista, if you are running FS at a different privilege level to those applications. If you have set FS to run "as administrator" then you must also run any programs "as administrator" too, and vice versa. This is because Vista prevents data sharing between programs with different privilege levels. Another possible cause is that the code signature on the FSUIPC.DLL module is wrong, or cannot be checked -- the Log file would tell you. There's a section in the User Guide about that. But if you want me to help further, please find the FSUIPC.LOG file in the FS Modules folder and show it to me. It is a text file, you can paste it here. Regards Pete

Sorry, I don't understand any of that. Please answer these questions: (a) What is the version number of FSUIPC? If not a currently supported version (see the Announcements) please update it FIRST. (b) Is FSUIPC actually installed? (i.e. Is there an FSUIPC menu available?) © What is actually wrong? You say "the programs that use the file error message: ipc", but what does that mean? I can't figure out what you are saying from that, it makes no sense. If you are getting an error message, what is it, and what program is producing it? (d) if you are using add-on programs which need FSUIPC, what are they? Have you asked their support. I cannot support other folks' programs! If there is an FSUIPC Log file in the FS Modules folder, show me that too. It might help you explain what it is you are talking about. Regards Pete