Pete Dowson

You can edit the INI file in any of the sections for Buttons, Keys, Axis assignments, or Joystick Calibrations, even with FS running still, and then, in the FSUIPC options, press the "Reload" button in the appropriate section. Editing the INI section for Keys and Buttons directly is actually the only way to implement things like multiple actions on one button/key, and conditional actions -- conditional upon either FSUIPC offset values (Keys and Buttons), or on the state of other Buttons or settable flags (Buttons only). This is why the Advanced Users document, supplied with FSUIPC, goes into some detail on the format of those parameters. Regards Pete

Are you sure there was any action detected to be recorded? Did you test it with "TAB"? Did you close the macro creation mode when you'd finished doing all of the mouse recordings and tests? Version 4.52 is out of date and unsupported, as noted in the Announcements above. Please update. Pete

Have you actually calibrated them in FSUIPC? Assigning is only part of the job. You should be able to calibrate them as you wish. Not sure what you mean by any of that. Just assign them to Throttle 1 and Throttle 2, then go to the Joysticks page for 4 throttles, make sure it isn't set for "no reverse range" (there's a checkbox for that), and follow the steps outlined and numbered in the user guide to set minimum (one position), idle (two positions) and max (one position). That's it. Job done. No fuss, no bother. Regards Pete

Yes, correct. The event function call causes the Lua program, ready compiled, to be sitting in its own thread waiting for the events. It would only ever terminate then if you expressly used the ipc.exit() function. However, as a matter of convenience, you might want to retain the Lua as a separate file, and only put a call into an ipcReady.lua file to start it. Then, if you have other Lua actions to add later, you can keep them separate (better as they all run in their own threads, and easier to keep track of and debug etc). To do this simply use the ipc.macro() facility. i.e. in an ipcReady.lua file just have a line like this: ipc.macro("Lua xxxxx") where "xxxxx" is the name of your Lua file (without the .lua part). Regards Pete

If you mean for FSUIPC, then all of your option settings are stored in the FSUIPC INI file in the Modules folder. It doesn't use or create any CFG files anywhere, and certainly no files in the main FS folder. There's also your registration details, in the FSUIPC.key file. Finally, if you've created macros or Lua plug-ins you might want to back those up too -- all files of type "mcro" and "lua". Regards Pete

Yes, I think it is but I don't remember what nor how at present and I don't have SB3 nor its documentation. Please check your copy -- it is most certainly in there somewhere. If you then need help implementing them, do come back and I can help with that. Regards Pete

If you have the exact same settings and cable, and your GPS is set the same, then it can only be that your COM port is suspect. Are you sure you have everything correct -- correct COM port number? check in the Windows Device Manager. If it's a hardware problem there's no way I know to find out without specialist equipment and a test program, running on a DOS-booted system. You can see if GPSout is sending stuff using a utility called "PortMon" from www.sysInternals.com, but I'm pretty sure that doesn't work with Vista or Win7. You might be better off getting a USB/Serial adapter, one with a Vista/Win7 compatible driver, and going the USB route. Such adapters are quite cheap these days. Regards Pete

Ooops! I'm sorry, I edited your question with my reply, instead of adding myreply. One button difference! Apologies. Here's the reply. Sorry but your original post is unrecoverable! :-( The problem is that the section shown stops the program ever exiting. It loops forever continually adding the function "fnident" as a routine to be called whenever keypress 122,0 occurs. It would be eating up your memory at the rate of something like 16 bytes per 20 mSecs until it crashed FS, eventually (it might take a long long time, though). Nothing will ever call "fnident" because when the event occurs (i.e. you press the key), the Lua program is already running and the "fnident" function is not directly accessible. It seems that you are mixing up two different ways of programming Lua for FSUIPC. One is to have the program looping, testing something at intervals, as in: while 1 do if then end ipc.sleep(20) end This loops, never ending, and checks on some condition at intervals. That is not the best way for many things, especially if the thing you are waiting for is a rare occurrence. Better by far is the Event system, in which your program merely tells FSUIPC what it wants it to monitor and what to call if it occurs, then ends. In your case, simply this: event.key(122,0,"fnident") In other words, just replace your entire while loop with the event.key call only. Regards Pete

Have you used FSUIPC's logging facilities to check? You can even display the value of offset 0D0C in real-time, using the Monitor facilities and the FS display option.There's also FSInterrogate which you can use to compare against your work. I don't know about that. Always test FSUIPC interfacing against default aircraft first. The lights denoted by the bits in offset 0D0C are those defined in FS. Whether or not a particular add-on implements them all is another matter. Sorry, I've no idea what they've done with the MD-11. If you just test your programming against the logging or FSInterrogate, and then find you are doing everything correctly for the lights, then if a particular add-on is doing "its own thing" you know it isn't your programming in error. Regards Pete

Do you have any information at all regarding the FSX crash? Like module name and offset? Turn on FSUIPC4's weather logging and ipc Write logging, and enable SimConnect logging (instructions in the FSX Help Announcement in this Forum). Generate the crash. Try and obtain more information on that -- if Windows shows a crash message there's usually a way of seeing the "APPCRASH" details on screen. ZIP up everything and send as attachments, with an explanation, to me at petedowson@btconnect.com, and I'll see whether it helps. Note that it may have to wait a couple of weeks -- in a few days I'm off till December 14th. It should not be possible for PM to crash FSX no matter what weather data is supplied, because FSUIPC4 has to process all the binary data in the weather structures and turn it into one of FSX's extended METAR structures -- a character string. In the process it should eliminate any bad data. I'm mostly concerned there might be some previously undetected error in my processing in FSUIPC4. That's really why I want to see all of the data. On the other hand it may well be a bug in SimConnect or FSX weather -- this is why locating the actual module in control when the crash occurs is so important. Regards Pete

Great. Even better! Sounds good, but that's not Lua (?). I'll have something for you tomorrow. Best Regards PEte

Please refer to the last line in my previous reply. You seem to have missed it. Also, there are lots of useful Announcements at the top of this Forum. They give you all sorts of useful news and information. Please do make use of what is provided. Pete

If you are using any keyboard or mouse inputs then presumably these must be spurious buttons or axis settings you've made? There's not much point in removing the program as reinstalling would just put it back. All of your settings are stored in the configuration file, FSUIPC4.INI, which you'll find in the same folder (FSX Modules) as FSUIPC and all of its documentation. (There is an uninstall section in the User Guide too, by the way). Once you delete the INI file, without FSX running, then next time you load FSX, FSUIPC4 will be back to defaults and not do anything you previously told it to do. It is always worthwhile also making sure you are up to date. For FSX the earliest supported version is currently 4.53, and there's a much more recent version availbable in the Updates announcement in this Forum. Pete

But of course that is absolutely not true! It works with SP1 and SP2 only, not the original RTM version of FSX. I've been using SP2 ever since it first went into Beta, years ago! Surely everyone with any sense is using SP2 or Acceleration. It is so much more efficient! As documented, Mouse Macros can only operate on gauges built using the standard FS C/C++ gauge SDK. It relies on the mouse rectangle structures that provides. It cannot possibly work with XML gauges as they are either interpreted or compiled on-the-fly. There's no way to discover where to place hooks even if there were any places for hooks! My guess is that without the help of the maker of your add-on cockpit there's going to be no way to do it other that a real mouse emulation like Key2Mouse. Unless, that is, you want to delve into the XML and re-program it yourself (assuming you can work out how to influence the MDL side of it or trigger the fx file if that's what it needs). Regards Pete

LOL! Sounds as if you're as old as I am! Pete

Okay. Understood. On the 737 only the outboard landing lights are retractable and have the three way switch. If the landing lights are handled completely internally, not using anything in FS internals, and the L:vars are only its memory of the switch position and not it's activation to change the graphic results, then I really suspect there's no answer. Maybe the add-on makers have a suggestion? I wish panel makers would always add Key Event processing to every switch and option they implement outside of FS's internals. It would be so easy to do. The Key Event systems has hundreds of events which wouldn't have any other adverse affect on any specific aircraft so could be re-used (as some implementers do, in fact), and really there's nothing stopping additional ones, unnamed, just numbered, being used. I did try to pressure Microsoft's FS team (the gauge SDK designer, actually) to automatically generate Key Event processing for any Mouse Rectangle defined, and I think it would have happened in FSXI ...). Alternatively, if they don't feel at home with Key Events, provision for Keyboard assignments would do -- but I think that's more work because they then need an interface for assignment. Regards Pete

Great! Thanks! What about the TQ6? The Lua facilities will be able to read the levers and buttons on that too. Is a 166A different, operationally, to a 166? I don't have any different information for that. They did send me an LGT2, and I've just found out that they forgot to export direct support for it to GFDev.DLL -- even the latest copy, July 2009, doesn't have it! I've written to them about that. I also have the RP48, T8, P8, and EFIS. They all work fine except there's a problem with the EFIS in GFDev.dll -- I've written to them about that too. The two dials, top left/right, return +1 or -1 constantly once turned, even if you stop turning them, until you press or change something else. That means you can't use them with a polling loop (i.e. looping around reading them), as you can't tell when they aren't turning. As a result of this I'm adding a new Event function to the libraries so you can program it to respond to changes rather than being forced to poll. I already have your email address, right? (You sent me the latest GFDev.dll). When it's ready, this week, I'll send a revised FSUIPC together with one or more Lua plug-in test programs for it. If I get time I'll also do some draft documentation and maybe a conversion of your MCPPro GFDisplay script into Lua. I hope to get it all done this week, as then I'm away -- from Saturday 5th to Sunday 13th inclusive. So there'd be no rush for feedback. I'd talk to you again when I get back. I may get it all done by late tomorrow or Wednesday if nothing else serious crops up. I still need to know which FSUIPC you need -- are you using FS2004 or FSX? And I assume you either have those GF units connected to the FS PC, or don't mind connecting them there for testing? (These facilities are only in FSUIPC at present. I've no short term plans to add Lua support to WideClient). Thanks & Best Regards Pete

Sorry, the last message from you in this thread was that you had found a place to put the GFDev.dll and everything was working? That would work no matter what version of FS or FSUIPC you are using. However, on my Windows 7 64-bit system I have GFDev.dll in the C:\Windows folder. I'm certain it doesn't need to be in any "system32" or "WOW" type folder. For FSX there's actually no problem putting it in the Modules folder, next to FSUIPC4.DLL. You can't do that with FS2004 simply because the Modules folder can only contain FS-loadable DLLs and a non-FS DLL would crash it. Regards Pete

There will be lots of cases like this, where the variable only keeps track of the switch position. That's its purpose in this case. You can see from the XML that the switch merely operates the standard default FS landing lights: The "K:vars" are the standard KEY EVENTS which I call FS controls and which can be assigned in FSUIPC's assignments drop downs (or, indeed, in common cases like this, in FS's own keyboard and button assignments). Before venturing into more complex possible solutions such as mouse macros and L:vars, one should always first try the obvious, like normal controls. You can always determine if a normal control is used by switching on FSUIPC's Event logging, operating the swtch or button, and checking the FSUIPC log file. Regards Pete

You cannot. There is not and never has been any facility to connect axes via WideFS. I experimented with it once (with an EPIC card and EPIC drivers, not FSUIPC) and concluded the latency, even if only 20-100 mSecs, was enough to make flying very difficult and unrealistic, except perhaps for an ultralight or other very slow aircraft. I'd advise you to always connect axes direct on your FS PC. Regards Pete

Use the scaling option, as described in the Advanced User's guide under the heading "Additional parameters to scale input axis values". Pete

Let us say we are going from 3000ft to FL390, if using the FSUICP input "PM MCP Alt Inc 100", one have to turn the knob many many times and keep it running beacause only a few detents are "stored"! (Encoder wired using BU0836x to FSUICP as button assignment) Besides using the "PM MCP Alt Inc 1000" can one do anything to make "PM MCP" or "FSX" or "FSUICP" understand that fast dial or many detents will result in faster increasement of ALT? If you cannot program it in FSBUS or whatever, you would need to use another program, possibly a Lua plugin. You'd need to get the knob incrementing or toggling a user offset (e.g. one in the range 66C0-66FF, available to users for any use) for each "click", and detect the changes in Lua, checking the time between each change -- do one increment anyway, but if another change comes within, say, 100 mSecs, doing the remainder of the increment (say 999 from 1) and thence stay in fast mode till you detect a gap longer thanm, what, 500 mSecs perhaps? There must be many ways of doing this with different times. You can adjust it to suit your needs. Regards Pete

Sorry, I don't understand. Where do offsets come into it? How will you signal the fast or slow modes? What's "fast dial"? Are you sure this isn't a question for PM support? I do not control their offsets nor do I know anything about FSBUS. Possibly. I think there are several makes of encoder. Yous seem to give one complete pulse per clcik whereas the GoFlight and others I've used go on and off alternately, a click for each. Presumably yours stay off except when being turned? Pete

Yes, and I already answered that, here: Please do browse through the documentation some time. It is all explained for you. You can assign FS controls OR keystrokes to any buttons, knobs, whatever. There is no problem, you only have to look. I don't know how you manage to use the "mouse macro" facilities, which are much more complicated, yet ask questions like how to assign a keystroke? What is it you don't understand? Pete

Sorry, you'll need to explain that in much more detail. And could you possibly, please use separate sentences (use the full stop '.' and spaces) and perhaps new paragraphs (new lines) now and then? Whilst I can understand that you cannot spell English well, you surely know how to make sentences and paragraphs? It would make talking with you far easier. It is very laborious trying to extract any meaning from what you write! No, not yet. Just explain yourself more first. I cannot picture what you are doing. Sorry, I don't understand a word of that. You seem to be mixing up key assignments with FSUIPC offsets? Why are you introducing offsets? If you simply want to assign a keystroke to a button, just do so. The facility is there in front of you, on the left-hand side of the Buttons & Switches tab. Have you looked? Pete