Pete Dowson

Yes, that's good code to do what you want. But it has to be executed -- i.e. initiated, and kept running in some way. Not quite. And you did not need to pre-compile it. FSUIPC compiles source on loading it. First, you need to know that Lua programs can only be used by Registered FSUIPC users. If your add-on needs to be used by all I'm afraid this may be a stopping point for you. Second, I'll explain Methods of Running Lua Just placing the .Lua file into the FS Modules folder makes it available and assignable in FSUIPC's drop-downs, so it can be executed by button or keypresses. It can also be started in other ways, by programs (via an offset), or by placing a macro call like: ipc.macro("Lua ") into a file called "ipcReady.lua", also in the Modules folder. This file is executed when FS is ready to fly. For Lua programs relevant to specific aircraft only, the [Auto.] INI file section can be used to call Lua programs. Third, I'll explain how to keep your program running so it isn't merely executed once then terminated: The easiest way to make it run forever is to put it into an everlasting loop: while true do visibility = ipc.readSW(0x0E8A) if visibility<=300 then ipc.writeSW(0x0DDE, 999) end ipc.sleep(100) end Note I've used a Sleep of 100 milliseconds to avoid it wasting time looking too often. You don't want it hogging the system for nothing! The cleverer way, which wastes no time at all, is to use the event library to get your program run each time the offset you are interested in changes: function checkvis(offset, visibility) if visibility<=300 then ipc.writeSW(0x0DDE, 999) end end event.offset(0x0E8A, "SW", "checkvis") This loads up and simply registers your interest in offset 0E8A, so that function "checkvis" is called whenever it changes. There's one slight bother with that. If the visibility is less than 300 to start will, your offset 0x0DDE won't get set. So a fully working one would be like this, with an extra call to initialise things: function checkvis(offset, visibility) if visibility<=300 then ipc.writeSW(0x0DDE, 999) end end checkvis(0x0E8A, ipc.readSW(0x0E8A)) -- initialise for starting value event.offset(0x0E8A, "SW", "checkvis") Regards Pete

"Mouse" macros are merely ordinary macros which contain lines generated by mouse traps. The system of macros was developed long before that and contain strings of controls in any case. However, repeated assignments in the INI are the easiest for speeding things up -- but with things like Heading don't forget this may stop you setting it precisely at odd or even numbers. Also consider assigning to both press and release. And also consider using, for the VRInsight MCP, fast and slow assignments -- many of the knobs gives 4 button numbers, two each way. Program the slow with singles, the fast with doubles or quadruples, or even use Offset Word Cyclic Increment to step in 10's. actually I was so much focussed on not editing the ini and doing it through the drop downs, I forgot about the 'easy' way, mt :D You can assign to Press and Release in the options dialogue. That doesn't need INI editing. Regards Pete

How is this called? If it is called on a repeating button press, then it won't crash because each call waits for the previous one to complete because exceuting another. All that happens is that if the repeats are too fast, you lose some. If it is called on something which is repeating fast but does not set the "repeat" flag because it is not being "held down" (as, for instance, for a rotary), then, yes, it could crash FS because it will be trying to Kill and restart the Lua program faster than it can be done, resulting in a big bulid up of threads until the system breaks. There is most certainly NEVER any need to have such a Lua program. You can program any button to send a control once, twice, as many times as you like. Just duplicate the assignment lines in the FSUIPC INI file. Furthermore, if it is a rotary you are programming, or a VRInsight button, don't forget you should program both the Press and the Release -- you get an altrernate press and release for each press or click. Inserting the sleep makes it MORE likely to crash, not less, because now the Lua program takes longer to finish and so more copies will build up more quickly, waiting to be killed! Yes. you seem to be forgetting that any button can operate any number of controls, simply by INI file editing. Or you could use an ordinary macro for your list of controls. You are misusing Lua, using it for things which are far beneath its capabilities unnecessarily. Up is "on", down is "off". On is "pressed", off is "Released". You are missing the obvious again, looking for the complex instead! On the Buttons page there are TWO places to assign things -- press and release. You are forgetting the release! Pete

That would only be the case if your autothrottle program is using the joystick control to operate. I didn't know anything did that and it isn't very clever when you think about it,unless that software also intercepts the real joystick and stops it operating (like FS itself does, for instance). For such an implementation there's no easy answer. You need to ask the authors how they expected you to use their A/T. Of course, your real joystick should not be interfering if it isn't being moved and isn't jittering, because both FS and FSUIPC only use the joystick inputs if they change. If they are jittering you need to park them in a dead position -- make your idle or max zones bigger and park them there. Regards Pete

It isn't really important. Yes, merging them would be efficient -- unless the assorted offsets you are handling are likely to be all changing often and at once, in which case separate files would probably be more efficient. But I don't think that's the case. Regards Pete

0020 is the ground altitude. Only 0570 contains the aircraft latitude.

No, it isn't the best one as an example. I really meant scan through the GF exapmles provided. By now I'd hoped to have produced a really good, well commented example, for something like the GF-MCP Pro. But I need the device to do that. GoFlight promised to send me one -- in January -- and it hasn't arrived yet! (I'll remind them when I get back from holiday). Hmmm. Shouldn't have crashed then. You started "GFPower" more than once? Ouch. Whilst it shouldn't crash FS (I'll test that), it isn't the thing to do. GFPower should be run once, at the start of FS (load it via a macro call in ipcReady.lua). It sits there watching various events. One of the events is a change in battery voltage, which, once you switch things on, will be changing all the time. I'm wondering if that would do it, especially if you are running the thing more than once. I'll have to do some tests on that -- when I come back from holiday. Note also that the GFdisplay plug-in does NOT terminate. You need to kill it, or reload FS. It sits there monitoring GF buttons and knobs. If it happens again, please see if you can get more details. The module name and address or offset would be useful. For offset references I find a printed copy rather difficult to use. Keep a copy in your Documents folder. Then you can get it up on screen and use Search. That's how I found 04FE, by searching for "Seat". Odd. That looks right. THat sounds very familiar. I'm sure it was a bug found and, I thought, killed. I'll have another look. Don't change anything else yet. But 04F4 doesn't operate in "bits", it uses numerical values. You should be using Offset word set. Setbits OR's in the bits in the parameter into whatever was there before. That only works if there was zero bits set before. Only use "setbits", "clearbits" and "togglebits" with offsets which have different bits assigned for different things, not when there's a numerical value to be written instead. Yes. That might be me. I'm checking now ... [LATER] Stupid me! I should take my own advice and look things up! I use the C language everyday, almost constantly, and I am so used to the way it works that the differences in Lua sometimes escape me for a while. The problem is that in C anything non-zero is "true" and zero is false. But in Lua everything except "false" is "true"! Statements like: logic.And(val, 256) return a number: 0 if the bit isn't set, and 256 if it is. It logically ANDs the two values. So I need to test for them being non-zero, that's all. Sorry! Here's the correct code: function operatelights(off, val) if logic.And(val, 256) ~= 0 then -- 256 = 2^8, bit 8 = no smoking gfd.SetLight(GFP8, 2, 2) -- Smoking Led else gfd.ClearLight(GFP8, 2, 2) end if logic.And(val, 128) ~= 0 then -- 128 = 2^7, bit 7 = seat belts gfd.SetLight(GFP8, 2, 3) -- Seatbelt Led else gfd.ClearLight(GFP8, 2, 3) end -- you could add tests for more bits in 04FE here end event.offset(0x04FE, "UW", "operatelights") It was doubly disconcerting because the symptoms were almost identical to a bug I thought I'd fixed months ago. Regards Pete

A DLL? It would be easy to do as a Lua plug-in. I'm afraid I'm very rusty with FS DLL coding. Not been involved with that for a few years now. Have you used a debugger to see what is happening? These lines: DWORD IsLowVisibility; FSUIPC_Read(0x0E8A, 2, (DWORD*)&IsLowVisibility, &dwResult); if (IsLowVisibility<=300) { seem to be at odds. You read 2 bytes into the low end of a 4 byte DWORD then check if it is ever less than 300. The top end of that DWORD could be any old rubbish, whatever was on the stack at the time. You either need to initialise it to zero each time, before reading it, or be sensible (as you have with your LowVis variable) and declare it as a WORD in the first place. I don't know why you've cast it as a (DWORD *) in the call either. Since it is declared as a DWORD the cast does nothing, but doesn't it generate a compiler warning? Should be a (BYTE *). Regards Pete

Only by switching aircraft to one without those assigned. Far better surely to simply use the ready-made facility to disconnect and reconnect throttles? Assign a button or keypress or two to "Throttles Off" and "Throttles On" in the FSUIPC assignments drop-down. You could even make those execute automatically when enabling or disabling the A/T -- program "AT on" and "throttles off" on the same button (as press and release if you don't want to edit the INI file), and similarly for "A/T off" and "throttles on". Regards Pete

Sorry, I don't know this hardware at all. What driver does it use? Don't they supply something for FSX? I doubt that would be possible, but it really depends on how those functions are sent. Not exactly. You can detect when any control arrives and act upon it, but currently you cannot stop the control also being passed to FS. If you can find enough FS controls which don't do anything (or anything serious) in your cockpit, then you would be able to do it using a Lua plug in and the "event.control" function. In fact, if the Elite assignment program allows you to assign a parameter to the control you could just find and use one control which had no effect and use the paramter to differentiate them all. Then in the Lua plug-in you'd determine the action, like sending the keystroke. Such a Lua program should be run by a "ipc.macro" call in ipcReady.lua so that it gets to run when FS is ready to fly. FSUIPC and WideFS realte to only one PC running FS. WidevieW is the product for connecting multiple copies of FS, but I don't think it deals with instrumentation, only views. You'd need to inquire on their website. Regards Pete

FSUIPC won't do that, but it might certainly mess up any programs using it if the registration appears to be invalid. There are only three possible reasons I can think of for that. One of: 1) Your system date is earlier than your registration purchase, making it look impossible. Fix the date in Windows, or 2) You are using an old version of FSUIPC but purchased your Registration in 2010. Always make sure you are up to date. 3) You really do have an illegal pirated registration key. I doubt it would be (3) or you wouldn't be writing to me, so check 1 and 2. Pete

It's only a test program, sent to all my GoFlight Beta testers to make sure all the displays GF offer can be handled. At the time I had no GF devices with displays. I only have a GF-46 now. However, if you look at the Lua code inside you'll see the lines which send stuff to the display. That's why I quoted it as an example. One minute? No idea what it could be doing then. It will only do things when something changes (battery on/off, avionics on/off, or electrical failure, Can you tell me, please, what version of FSUIPC you are using (i.e. the version number)? Because the only time I've ever known any Lua program to crash FS was when one is repeatedly called faster than it can be executed. That bug was fixed a few versions ago. If you aren't using the latest (see the Announcements above for details), please update. Where did you get that syntax from? Are you looking in the examples or in the documentation at all? It should of course be in the form: gfd.SetLights(model, unit, on, off) exactly as shown in the document called "FSUIPC Lua Library". Please do refer to that. This command can set and clear all 8 lights at the same time, so it is probably not the one you want. To change only one light you'd use gfd.SetLight(model, unit, id) Even well-practised programmers have to refer to documentation. There's no point ever in guessing what to write! ;-) The form "x = y" is an assignment. It assigns the value y to the variable x. The line "gfd.setlights=GFT8, 1, on" merely changes the gfd.setlights function to be, instead, a variable with value "GFT8". The other two values, 1 and on, are discarded as you provided no other variables for them to be assigned to. Apart from the fact that you are assigning values to what was a function before you messed it up, instead of calling the function, you should note, if you refer to Project Magenta's documentation, that offset 04F4 does NOT contain "1" for any seat belt or other such value. 04F4 is where PM commands are WRITTEN -- writing 1 sets MAP mode on the ND. And, yes, I had to refer to PM's documentation for that -- why don't you please look these things up yourself? I never remember any of these offsets, and for PM I have to go to their website to check. Also it says 04F4 is 2 bytes, which being 2 x 8 = 16 bits, makes it a Word (W) not a DWORD which is 4 bytes. Your read would read 04F4 and 04F6 together. 04F4 doesn't tell YOU anything about PM, it is used ONLY to tell PM to do things. There's no point in reading it at all. It's "write only". I just did a search through the PM offsets (on their website) for seat belts and found this: [b]04FE [/b] 2 PFD Various ([b]Read Only[/b]) Bit 0 Windshear 1 Below G/S 2 Caution 3 Warning 6 Eight Mode ND Active [b]7 Seatbelt Sign[/b] 8 No Smoking Sign 9 Weather Radar (Captain) 10 EGPWS/Terrain (Captain) 11 TCAS Active (Captain) 13 TCAS WARNING 14 TCAS ALERT So if you are testing it you'd need the read the WORD at 04FE and test it for bit 2^7 (value 128). The whole Lua program for monitoring that offset and changing the seat belt and no smoking lights would be: function operatelights(off, val) if logic.And(val, 128) then -- 128 = 2^7, bit 7 = seat belts gfd.SetLight(GFT8, 1, 2) else gfd.ClearLight(GFT8, 1, 2) end if logic.And(val, 256) then -- 256 = 2^8, bit 8 = no smoking gfd.SetLight(GFT8, 1, 3) -- assuming light 3 is your non smoking switch light else gfd.ClearLight(GFT8, 1, 3) end -- you could add tests for more bits in 04FE here end event.offset(0x04FE, "UW", "operatelighhts") I've assumed you really do mean GFT8 unit 1? If you have two the first will be 0, the second 1 and so on. This Lua plug-in, unlike one which you call when pressing a key or button, simply sits and waits in the background for the offset to change. Save it as, say, "myt8.lua", then create an "ipcReady.lua" program (which will automatically run when FS is ready to fly) with only this line in it: ipc.macro("Lua myt8") which will run the T8 lights program for you. If you want to do more "event" driven programs, with different offsets, just run these from the same ipcReady.lua file. Regards Pete P.S. I can't test that Lua program here for you, but if you do get any errors logged they should either be obvious, or ask. Note I'm away on holiday from this Thursday for a week or so.

It's on my list to do. If I get time I want to do something with volume, loops, sound device selection, and sound positioning too (left/centre/right/rear etc). But I won't get to it till May this year I'm afraid. I'm on holiday from this Thursday and then again late in April. If you don't see any mention of it in late May, give me a reminder. I might have mislaid my list! ;-) Regards Pete

I'm not sure from the picture whether there are any spaces at the ends of the GUID lines or not -- my editor seems to highlight a bit past then ends of lines in any case. But the variable number of spaces at the ends of the CH names are rather strange. Are you sure they are spaces, not tabs or something? Shame you only posted a picture, not the file extract so I could see exactly what was going on. Seems that the CH USB data is messing things up somewhen. I'll change FSUIPC to remove all non-printable characters from the end, so it'll deal with tabs and spaces. Look out for an interim update in the Announcements this week, (It will have to be before Thursday since I'm then on holiday for a week). [LATER] Okay. Done. Please try the updates available in the Announcement and let me know. Regards Pete

If you've done it correctly it would be EXACTLY as it was before. Sounds like you still have it assigned in FS too, so the two are conflicting. Either that or you have something really wrong. No. Why are you assigning axes in FSUIPC in any case? Why not assign in FS and merely calibrate in FSUIPC? Pete

Have you looked at the documentation I supply and the GoFlight examples? Have you bothered to try the GF display test Lua plug-in I supply? DON'T install anything!!! Everything you need is built into FSUIPC! The only thing you might want to visit the website for is to read the manual on the Lua language, but for the very simple things you want to do this is really not necessary. The examples in your FSUIPC package should easily be enough. I don't understand why you ignore everything supp;lied with FSUIPC and already installed into your system and go off half-cocked. Can you tell me how you decided to do such a thing please? Lua details have been supplied and installed with FSUIPC for well over a year now and no one else has done this! Have you read nothing I've done? :-( Look at the GoFlight examples, try the GF display test. To light one LED on a T8 would be one line. To read one offset would be one line. The whole thing might be 4 or 5 lines. I can help, but not if you don't even try. It is MUCH simpler than GFDisplay, and much more flexible too. But if you prefer GFDisplay, I wonder how you gauge complexity -- evidently oppositely to me! Pete

Sounds like one of the more usual video driver bugs. Try a newer or older video driver, or change to Windowed mode first. The FSUIPC options are in a standard Windows dialogue and there's nothing FSUIPC can do about video symptoms. It has no control over anything once the call's gone to Windows to open the dialogue. It then merely responds to the button and keypresses. Regards Pete

Yes, it does here, 100%, never fails. The only thing that was wrong before was that it wasn't saving them unless you closed the window using the HotKey. I fixed that by saving it whenever you move or close the window by mouse/key too. Sorry, I've really no idea why it doesn't work on your system. It will go back to default if the values it reads aren't valid -- I think that's an FS function as I don't check validity. Pete

Is your T8 on the same PC as FS? If so it would be easier with a Lua plug-in. since implementing GoFlight display support in the Lua libraries I'm not really wanting to support GFDisplay much. It's parameter files are pretty difficult compared to the nice easy flexible Lua system. Regards Pete

But GFConfig is NOT the driver. All that does is allow you to configure the GF devices. I've just checked. The driver for FSX is a program called GFDevFSX.exe. It must have been installed in your GoFlight folder (the same place as GFConfig) when you installed the GF package. That needs to be running to allow the settings you make in GFConfig to be used! I'm on holiday soon for a week. If you do go that way contact me after April 7th. But I'm sure everything you want to do can be done with GFDevFSX. Regards Pete

Okay, but then, if you plug one in later or for some reason it is still asleep when FS loads, try simply entering FSUIPC options, select the Axes tab, then OK back out. FSUIPC re-scans when you enter that options tab. It's always a good idea with USB devices to give them a good waggle before using them in any case. Think of it as a normal pre-flight check, or part of the wlk-around check before boarding! ;-) Regards Pete

You most certainly have a faulty PC or USB hub, because all connected USB devices should be readily recognised by any software using the standard Windows interfaces, as both FSUIPC and FS do. If you truly have disabled the power management then you have some other problem on your PC. The FSUIPC generated part of that merely shows the alignment of the USB names and the Windows IDs. This merely means that FSUIPC has found the devices assigned to those numbers. It looks in the Registry for these. There's your first problem. Neither FS2004 not FSUIPC will see any devices not plugged already when you load FS. Simply either keep them plugged in, like most people, or at least plug them in BEFORE starting FS! Of course not. They are only scanned during load time. But at least FSUIPC, unlike FS, will re-scan if you go into the FSUIPC Axis options tab. It does it automatically when you do that. That's a complete waste of time and effort. Those lines are merely a record of what it found in the Registry. Their absence cannot make it behave any differently. They are there for YOUR information, not its information! Yes, because it has found the details in the Registry again. It will be re-writing those lines EVERY TIME you run FS, not only after you've deleted them, as it doesn't care a fig whether they are there or not. Deleting them makes absolutely no difference whatsoever -- they are not USED by FSUIPC, they are used by YOU when deciding how to relate your Joystick Letters to real devices. Please yourself, if you enjoy doing such things. But the proper answer is to plug in joysticks BEFORE running FS. It always has been, whether you use FSUIPC or not. FS has never been able to handle devices being added after it has started -- but FSUIPC can, if you really want to do such odd things, and that is by simply going into the Axis (or Joysticks) options after you've plugged them in. Regards Pete

Inside the ZIP file which contained the FSUIPC Installer there was a document explaining how to install and register the program. At the beginning of that there are details explaining the files that would be installed and where they could be found. Did you not even bother to read what was provided? It wasn't too long, and this information is all in the first half-page, so it wouldn't have taken you long! Why skip it and then spend time instead asking here? All current versions of the Installer, those which install a Supported Version of the program, place all the documents and examples into a folder called "FSUIPC Documents" inside your FS Modules folder, next to FSUIPC itself. The instruction would have told you this if you'd read them, and the name of the folder isn't really too obscure. Pete

I don't really know the GoFlight software, and don't use it. The LGT is actaully supported by FSUIPC if you want to use it, but if you aren't programming it in FSUIPC then really it isn't involved at all. There's absolutely no difference in FSUIPC support for GF devices between FSUIPC3 and 4, but your FSUIPC3 is well out of date and unsupported. The current version is 3.98. Ah, in that case you cannot be using FSUIPC to program your LGT. So whether you way "works great with GF-LGT" you cannot be referring to fSUIPC because it is irrelevant. Sorry, I think you need to check with GoFlight support. Sounds like the GoFlight driver for FSX isn't getting loaded. It's an external EXE program. Have you tried running it yourself -- maybe it simply isn't loading automatically because of an error in your EXE.XML file? Well, you can program that in FSUIPC too -- via a little Lua plug-in program. It would be pretty easy to put together. I could do it as an example for you when you've got all the rest done. Regards Pete

The basic interface to FSUIPC is in C and there are examples in the SDK. Pete