Pete Dowson

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

Yes, certainly. Sorry. It was added a lot later (versions 4.40 and 3.85, last November) and hasn't yet made it to the SDK documentation. It is documented fully, however, in the History document, installed in the FSX modules folder or included in the FSUIPC3 Zip. The same facility can be used to execute macros (by name) and Lua plug-ins. Look for offsets 0D6C and 0D70. Regards Pete

Ah! Don't bother with a Log then, Slopey, unless you still can't get it to work! Thanks Paul! New Year's Resolution: I should remember to ask for logs to check before rushing into premature diagnoses! Regards Pete

Is that what it is doing? Sorry, I only read the words, not the code. Don't know anything about this new-fangled managed stuff! ;-) If this might be happening it would certainly be best to check BEFORE reporting any SimConnect problem to MS. I could tell from an FSUIPC log file. Slopey, could you enable IPC write logging in the Logging tab and show me what you get for a non-working sequence? Pete

After some intensive investigations, it looks to be certain that this is due to a SimConnect bug. It could actually happen with almost any SimConnect client and the MindStar G1000, but is more likely with FSUIPC because it is the most common and most intensive SimConnect user available. It also depends upon the ORDER in which the SimConnect clients initialise their links to SimConnect and the MindStar gauge initialises itself. It seems that if the SimConnect processes precede the Mindstar G1000 processes in the internal FSX chains, the latter causes FSX to crash as soon as it attempts to file a plan. Apart from FSUIPC there aren't that many intense SimConnect users likely to have active SimConnections before the gauge is initialised. The proper fix must be in Microsoft's hands, but that won't affect FSX (or ESP1). However, because we now know the order is important, there are workarounds. The first workaround which seems to work 100% from our tests is to have the aircraft with the MindStar G1000 loading as part of the default flight. This gets it initialised before FSUIPC connects. This should work with any version of FSUIPC and the G1000. The second workaround is to somehow cause FSUIPC to re-SimConnect AFTER the Mindstar G1000 gauge has initialised. This can now be done with the FSUIPC version 4.419 or later, using a new additional assignable control called "Re-simconnect". This method should work with any version of the G1000, but only with FSUIPC 4.419 or later. However, it is inconvenient because it requires an extra keystroke or button press by the user, and if he forgetscrash. So, the third and best workaround is being implemented and tested as I write this, and that is where the Mindstar G1000 gauge forces FSUIPC to re-SimConnect, using a mechanism I've supplied them. This will work with any recent (4.40 or later, please) version of FSUIPC, but obviously needs the updated G1000 from Mindstar. This method will be automatic and the only noticeable side-effect will be some extra FSUIPC log lines saying it is reconnecting to SimConnect. In 4.419 and later this will log as "by request", but in older versions it will log as if SimConnect stalled and had to be restarted. Note that I only support current versions (4.40 or later at present), so no-one should now be without a solution to this problem. Regards Pete

Ah, good. So FS9 and FSX match. Thanks. I'll update to dox to make it clearer. And this is with FSX, right, as per your original message in this thread? 3 seconds is one helluva long time! Set - Process - Sleep, you mean? There's no point in waiting between set and process. This most certainly sounds like a SimConnect bug! SimConnect runs asynchronously to both FSUIPC and the rest of FSX. It sounds like after SimConnect is asked to write one value it instigates the appropriate processes to re-compute things (overall weights, changed flight characteristics -- meaning re-populating tables -- and so on), and when it then immediately processes the next station it instigates the same processing which turns out to be non-re-entrant. The final value gets used by the non-reentrant code because it loses the previous by the re-entry. I've seen code like that before (probably written some myself before now! ;-) ). Could you report this, with the gory details, via tell_fs@microsoft.com please. You can quote my "analysis" above too, as it should help. There's no chance of a fix in FSX, but we should try to stop it promulgating to ESP2 and FSXI. Regards Pete

In your example you are setting 10 stations. Does the aircraft you are using have 10 defined stations? I have the feeling, from what I've seen, that the numbering can wrap around somewhat and give misleading results. ALWAYS limit the number you use to the number declared -- you can read this from offset 13FC at the start. Incidentally, in FS9 these changes don't appear to affect the overall weights, flight characteristics, and so on. I don't know if they do in FSX. Since you are using FSX, can you confirm or not whether these changes work correctly, so I can update the documentation? Regards Pete

Strangely enough, dragging is how you copy or move a file. Why quibble about the words being used. What do you think "copy a file into ..." means? :o You either have a bad registration or you are making a mistake. I am constantly amazed at how many folks can't even spell their own name the same way twice! :roll: If you are in doubt, copy and paste all three parts: name, email address and key. Don't guess! Don't even copy by hand if you can't read it properly! Pete

Sorry, I can't see it! Well, that is why FSUIPC.DLL cannot load! If it isn't there, it will NEVER be loaded! You've not actually installed it! :roll: There's only ONE step to do to install it, copy the FSUIPC.DLL to the FS Modules folder!!!! Pete

It's not specifically FSUIPC which is confused, it's the whole keyboard messaging system. When you press a key messages are send. FSUIPC translates those into "pretend" keypresses, so more messages get sent. FSUIPC and FS are looking for these messages and trying to deal with them. You are effectively setting up a little loop. The start of the converted sequence (DOWN DOWN UP UP) overlaps with the DOWN and UP of your "real" keypress. You can see what a mess that can create. No!Why?You are making it complicated when it is so so simple!!! Simply assign your keys directly, in FSUIPC, to the controls you want FS to obey. What on Earth is the point in programming a key to press a key to translate into a control? Don't you see that is daft? For example, assign your NUM8 key to the Panel 8 control, instead of to the FSUIPC "press and release key" control, and it will be fine. They are both in the same dropdown list in FSUIPC, so what is the problem? You don't have to look far!! You'll be assigning keys in FSUIPC just like FS itself assigns them. What is really the problem here? Didn't you understand anything I said before? Please explain why you are ignoring my suggestions. Why do you only want a complicated solution rather than the obvious simple one? :( :( :( :?: Regards Pete

Erthe log shows lots and lots of keypresses. Do you expect me to understand what you've done from just the one line "I have just pressed NUM8"? It does not relate. Please, from the moment you start logging till you stop, list every single keypress. Erwhat? OUCH! I think you'd better show my the Keys sections, as I asked. Or delete it all and start again. By assigning NUM8 to send keypress 56+9 you are making it look as if you are pressing Shift 8. Why? It makes no sense to use FSUIPC to convert one keypress into another. I've no idea what that would make happen, but it won't be nice -- the whole sequencing will get totally confused with keypresses and releases from you getting entwined with those from FSUIPC. The control facility to send keypresses which you are misusing was to allow Buttons to be used to send keypresses to those Add-Ons which do not recognise controls. FS itself actually recognises FS controls! Wonderful, no? USE THEM please. Never ever program FSUIPC to send keystrokes when there are perfectly good controls to be used. All that happens is that FS will look up the keystroke and convert it to a control which you could have used in the first place! Don't you see that? To find out what controls to use, if you don't know which ones, enable Event logging in FSUIPC, operate FS in the way which uses the control you want, then look it up in the Log. The name in the log is the one you'd use in the Assignments drop-down. For the panel selections the controls are (obscurely?) named "PANEL n" where "n" is the number -- so Panel 8 for your 8. Try it and see! There's also a list of all FSX controls installed in your FSX Modules folder, sorted numerically and alphabetically, so for the less obscurely named ones you should find them quite easily. Oh, incidentally, in FSX windowed more you can enable a console window for FSUIPC's logging and see the results of your actions in real time, on screen. There's a checkbox for this option in the Logging options tab. Regards Pete

Why are you using FSUIPC for such keypresses? FSX itself can surely handle such things. What FS controls are you assigning? Are you sure NUM lock isn't getting changed? Those keys are different depending on the numlock setting. For keypresses, if FSUIPC intercepts them FS doesn't see them, so unassigning keys in FS is irrelevant. They aren't like buttons. Such as? I think you need to be more specific, show me the [Keys] sections of your FSUIPC4.INI file. Also try Button/Key logging (FSUIPC Logging tab) and check the logging for yourself to see what is happening. No, not any problem I know of. Are you perhaps assigning keys to be aircraft specific then changing aircraft? BTW please always make sure you are using the latest version, just in case things have changed. Latest is 4.418 (in updates above), with 4.419 due later today. Regards Pete

Thanks to hints by Tim Gregson (Beatle) which you have already seen, I can now read (but not write) the G1000 "Kohlsman" setting, using SimVar "KOHLSMAN SETTING MB:2". To alter it you need the KOHLSMAN INC/DEC events/controls with a parameter of 2, to read it, read the offset 0332 (same units as 0330). Supported with effect from FSUIPC version 4.419, available later today from the 2Updates" announcement above. Regards Pete

The fixed 737 fuel planner, which reads the complete set of payloads from FS, is now available, thanks to quick work by its author. Get version 1.5a from http://www.volny.cz/fs2002/B737FPL/B737FPL.htm Regards Pete

If the FSUIPC.DLL file is present in the FS Modules folder, then it simply has to load, and if it loads it creates the Modules menu entry. There's no way it cannot. Please list for me exactly all the filenames you see beginning with "FSUI" in the Modules folder. Don't "guess", read then in Explorer, without the filetypes (like .DLL) being hidden. You don't set any windows to "see the fsuipc.dll". It doesn't set any windows, only the options presented when you open its menu entry. If the menu isn't there it isn't being loaded, If it isn't being loaded it isn't in the FS Modules folder. It is that simple. Are you saying you haven't even tried installing it before deciding to pay for it? You never had it installed before? Incidentally, please also make doubly sure that you only have one installation of FS, or if you have more, that you are looking in the correct Modules folder. I've had folks before swearing blind that they had the DLL installed, only to find after many exchanges and directory searches that they actually had two installations and were looking in one but loading from another! It is FS which examines and loads all DLLs it finds in the Modules folder -- FSUIPC is not in control of its own loading. Even if you put a DLL from another program entirely into the Modules folder, FS will examine it and see if it can be loaded -- it gives an error if an invalid DLL in placed there. Of course, this all changed with FSX. But you must be using FS9 or earlier, right? Oh, one last thing. There have been some programs, in the past, which mess about with the way windows looks. Windows Blinds was one of these. There are probably others. The way they manipulate windows can sometimes mess the menu up and prevent additions to it. If you are running anything like that, stop it before running FS. Regards Pete

Yes, thank you. I understand now! ;-) Pete

Unless you programmed the hat in FSUIPC there is absolutely no interference with its operation with or without FSUIPC installed. Merely installing FSUIPC changes nothing whatsoever. If you want to assign the Hat in FSUIPC you have two choices: assign it as a set of 8 discrete buttons. This is how a lot of folks like it. Or, use the Axis assignment and assign it to "Pan view". This is the same as how the FS operation works. Regards Pete

Okay. I'm sorry, but I really do not understand much of this still, and would have no idea how to go about changing anything for it even if it could be fixed in FSUIPC. Maybe Wilco can help more, or else some other users. If you do come up with anything, please do let me know. BTW I googled "donats" and it doesn't seem to be a term listed anywhere, except as a Saint (St. Donats). I do have Mike Ray's A320 Simulator/Checkride Manual and i can't find such a term in their either (though I admit I've not read every word). Regards Pete

What do you mean by "tag/bar"? The FSUIPC menu entry only ever appears in the Modules menu, which is in the main menu bar when in normal flight mode. It is the right-most entry. View and Instrument panels are nothing to do with FSUIPC. I don't know why you mention those. What's the joke? Won't you let us into it so we can all laugh? Or are you simply here be be insulting? Pete

It sounds as if that gauge isn't loaded when the aircraft is loaded. If the code isn't in memory it cannot be used. FSUIPC will not, itself, load gauges just to call them -- think what would happen in other aircraft. The mouse macros only work for modules actually loaded with the aircraft. Best load it up and save a flight with it visible. Use "W" or whatever to remove the panel on first loading. Maybe even a flight saved in "W" mode would be okay too. I don't know. More memory might help too? Possibly FS is running short so doesn't preload it? Regards Pete