Pete Dowson

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

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