Pete Dowson

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

Yes, so you do NOT assign NUM3 to the Shift+3 keypress & release, as you said, but direct to the Panel_3 control! Fine, same thing. No, no. For panels with non-standard (i.e. not FS pre-programmed) control, like Panel_1 to Panel_9, you need to use the general ID panel selector controls. There are three in the assignments list: Panel id close Panel id open Panel id toggle You probably want the toggle. You assign this, and set the parameter value to the ID of the panel you need to toggle. You can find the panel ID in the PANEL.CFG file for the aircraft. For example, in the PMDG 747X, you'll find this for the overhead: [Window02] // PMDG_OVERHEAD_PANEL //file=747400_Overhead_Background_1600.bmp //file_1024=747400_Overhead_Background_1600.bmp size_mm=1600,1200 position=4 visible=0 ident=24 zorder=2 window_size= 1.000, 1.000 window_pos= 0.000, 0.000 so you use parameter 24. No, it is nothing whatsoever to do with speed. It is a tangle of mesages confusing the KEYDOWNs and KEYUPs arising from real keypresses and "pretend" keypresses all overlapping. There is no way possible to overcome that. Just NEVER assign a keypress to a keypress. It makes no sense and will not work. Regards Pete

I'm rather surprised that a sophisticated new add-on aircraft is provided without keyboard shortcuts for such additional switches. Do you click in different places on the APU switch for the three positions, or is it a sequence, or is it left/centre/right clicking, what? If three different places, then you should be able to create a macro for each of the three positions. You say "if I assign the switch release to center, nothing happens." Are you saying that you cannot create a macro for this, or that you CAN assign a macro for "centre" but it doesn't work? Tell you what. In FSUIPC's Logging tab, enable Button logging. Then enter the mouse creation mode as if to make the macros (use a temporary filename, like "test"), OK out of the options, and use the mouse to create the macros for this switch as best you can. Then go into the options and end macro making mode. Show me the Log of the button/mouse actions, please. If the centre mode is sprung-to from both up and down and actually has no mouse "press" action associated with it, it may be I need to intercept mouse button release actions too. I'm not sure about that. Let me see your results first. If it is easy, I'll add it. Regards Pete

Since your reads are "passive" in FSUIPC4, merely reading whatever was last provided by SimConnect, there is actually no way possible for the read of one location to affect the value read from another. The code fulfilling your requests merely copies the values in its memory, which are replenished by SimConnect, asynchronously, when they change (and only when they change). Hmm. Shame you provide no logs to show this. it is easy enough to see values in real time -- simply add them to the monitor in FSUIPC's logging tab. You can show them on screen ("FS display" checked) and in the "normal log". With the log option checked, fSUIPC will actually show the relevant SimConnect variable being read, the raw value from which the offset version is computed. Here's an extract of the logged results, with the 206 loaded. I don't pretend to know what these values mean when it comes to helos -- FS is notoriously odd in how it simulates them. Sometimes they are like prop planes, sometimes not. Trying to map the right values to the old FS98-compatible offsets (the 08xx-0Axx region) is well nigh impossible to do consistently. I've annotated the log entries for you. Maybe you can advise me what SHOULD actually be provided in each of these offsets, for the 206, and how I can make that work for other helos too when they all differ? 348110 \\LEFT\G\FSX\SimObjects\Rotorcraft\Bell206B\Bell_206B_JetRanger.AIR 349078 SimRead: 0896="TURB ENG N2:1" [also 2008] FLT64: 99.9853181016 [i]<<<<<< offsets 0896 and 2008 populated from the same SimVar "TURB ENG N2"[/i] 349078 SimRead: 0898="TURB ENG N1:1" [also 2000] FLT64: 79.0117452359 [i]<<<<<< offsets 0898 and 2000 populated from the same SimVar "TURB ENG N1"[/i] 349078 SimRead: 08F0="TURB ENG ITT:1" FLT64: 15.0111111111 [i]<<<<<< offsets 08F0 populated from SimVar "TURB ENG ITT"[/i] Okay so far, but then: 349078 SimRead: 2400="GENERAL ENG RPM:1" [also 0898] [also 08C8] FLT64: 394.900097939 [i]<<<<<< offsets 0898, 08C8 and 2400 populated from the same SimVar "GENERAL ENG RPM"[/i] 349078 SimRead: 2408="GENERAL ENG PCT MAX RPM:1" [also 0896] [also 0898] FLT64: 0.999853181016 [i]<<<<<< offsets 0896, 0898 and 2408 populated from the same SimVar "GENERAL ENG PCT MAX RPM"[/i] Note how both of these would change the value for 0898 already read! (Actually it isn't quite like that. Some of those links are used to compute the RPM scaler, again to match FS98 offsets). Now as far as I knew, only one of these would be actually CHANGING for any one aircraft. I thought this was the case for the original helicopters investigated. If the 206 model is actively changing both, this would explain the varied values you read -- not the fact that you also read 2000. That cannot have anything to do with it! The end result of the one cycle you see above is: 349594 Aircraft="Bell 206B JetRanger" 351625 Monitor IPC:0896 (U16) = 16382 351625 Monitor IPC:0898 (U16) = 12945 351625 Monitor IPC:08F0 (S32) = 245942 351625 Monitor IPC:2000 (FLT64) = 79.0117 which seems okay, though I do see that the ITT value in 08F0 isn't changing after this initial reading. Does the 206 sport an ITT read-out? You compare it with FS9 -- is the same aircraft in FS9? One thing, though. Some of this stuff got changed in the recent interim updates to suit another facilty I put in (the one to "spoof" the engine values) and there may be bugs in it in any case. You say you are using FSUIPC 4.416. Could you just try the release version, 4.40 (delete the FSUIPC4.DLL from the FSX modules folder then re-run the 4.40 installer, please). Let me know if you see the same there. But please, please, do use the logging facilities. That's what they are for. If there are conflicting values being used to populate the same offsets, I'd need to try to resolve those somehow. But how do I tell which to choose when they are all or both changing? Testing the name to be the "206" isn't enough, and it doesn't appear to be enough to detect helo against prop against jet. Any ideas? I think much of this problem arises from the need to try to force-match all the new model types onto the original FS98 offsets. I wish I could get away from that, but too many cockpit hardware setups and gauges depend on them. Probably for helos, because they were not supported in FS98 in any case, folks should use the newer variables, and I can add other new ones if more are needed and available -- for instance the ITT equivalent on the 206. Regards Pete

Whoa! Which tab? The option is provided in 4 tabs and each operates on its own subsystem. The Keys and Buttons tabs allow generic keys and specific keys. Erwhich answer to which question, please. I need you to be specific. Only if whatever answer you gave cancelled the option, which it may have done. That's why I need to know specifically what answers you gave to what questions, please. Ah. That most certainly shouldn't happen. If the profile selection was cancelled somehow (even unintentionally) the entries wouldn't have been made. So there is certainly something wrong. I'll try to reproduce it here, once I know exactly what steps you are taking to make this occur. I've been using the Profile system quite a lot, as have others, and I haven't met this one yet. I won't be able to get to this until tomorrow (Monday) now, and I'll look later to see if you post more details. Regards Pete

FSUIPC doesn't detect mouse button releases. What aircraft is this? If it is something like a 737, then the mouse should be able to select "off" and "on" as well. The "on" position would be the centre position as you describe it. If you then create macros for "off" and "on", as well as "start", then you can program your switch or button to do the same. For a button just program the "press" for the Start macro, and the Release for the "on" macro. Regards Pete

Hmm. I have seen that error before, once, but I don't really know what it means. Basically it seems that Window or Winsock cannot translate the computer name "BOEING747" into an IP address. Tell me, have you explicitly set this name as "ServerName=..." in the WideClient INI file? If so why? Didn't the connection operate automatically? Are both PCs in the same WorkGroup? (Vista by default names Workgroups differently to XP). I don't know how to fix the problem that Windows has in translating the name -- doesn't this stop you acceing the Server by that name via Explorer too? But there are two things you could try: 1. Make sure both PCs have the same workgroup name, that port 9002 is not blocked on the Vista PC, and then delete any 2ServerName" and "Protocol" parameters from the WideClient INI file. or 2. Delete the ServerName and use the ServerIPAddr parameter instead, giving the server's IP address explicitly. You need the Protocol parameter too, then. Regards Pete