Pete Dowson

If you tell it to carry on, what happens? Usually this is a result of a bug in SimConnect, which was severe in the original release, but lessened in the updates through a sort of work-around MS implemented. It was never completely cleared. It is a clash of trust/permission checks made by SimConnect before it even loads FSUIPC -- please see if FSUIPC is generating a new Log file each time. I expect that it is not, which means it is not even starting up. Once FSUIPC is loaded successfully and you've told FS to trust it, it works forever after. It is just getting over that part. Do you have any other DLLs or EXEs being started automatically by SimConnect? If you don't know, please find your DLL.XML and EXE.XML files and let me see them. You can cut and paste them into a message here. If you cannot find them, please show me the FSUIPC Install log and I can point out the path to them. Alternatively, if you can find them, you can temporarily rename them (say DLL.XMX and EXE.XMX), then re-run the FSUIPC installer, and load FS. Once that works, exit, delete the new DLL.XML and rename the other two back to their correct names. There is one other simpler thing you can also try, perhaps first. Download the current interim FSUIPC (4.642) from the Download Links subforum, and see if the slightly different load timings that will give will get over the SimConnect bug. Once FSUIPC manages to become 'trusted' the glitch in SimConnect won't occur. Regards Pete

So you don't want to enable it just because of any turbulence at any altitude, only where the aircraft is? That isn't how you've written it so far. The way you've programmed it, you have no checks for aircraft altitude, so it wouldn't matter even if it was on the ground. But first things first -- I think the problem you have in your program is that you test "sndflg == 0" when the variable "sndflg" has not previously been declared. Therefore it is actually "nil" (a sepecial Lua value signifying nothing ot undefined). This is not a number and is never equal to zero, or 1, so neither parts of your function are ever executed and sndflg is never set. You can fix that by simply putting "sndflg = 0" as a line on its own before your function. As a general rule, in Lua, all variables to be used are best defined in this way at the beginning. The other problem, only having the sound when the aircraft is actually IN a turbulent layer, can be worked out too -- but check this change first. Pete

No idea. What's changed since yesterday? I'm afraid that without any further information I cannot possibly guess what has happened on your system. Maybe a wire has come out? Have you checked your network? I didn't even realise SB4 could use WideFS, or FSUIPC for that matter. I thought SB3 did that but SB4 was for FSX using SimConnect. Regards Pete

You'd need to use the VRI interception techniques published in my documentation, to prevent the VRI driver writing to the display, and do it yourself. The MCP example provided handles the speed display so that it can operate in IAS or Mach mode according to the MCP C/O switch setting. You'd extend that ot do similar things for altitude. I have no idea in this case, but normally PMDG do their own autopilot. The fact that you have to resort to using L:Vars to get things done make it seem likely that the only way to get the values out is by reading LVars too. Without the aircraft I can't really look at it for you, but you can read L:Vars in Lua -- and in fact log them with a simple FSUIPC assignment (List LVars). Pete

There are lots of bugs in the original edition. you do really need to update with both FSX SP1 and SP2 free updates. Regards Pete

I cannot find anything in your supplied code referring to altitude, so I don't know any way to help. I don't have that aircraft and have no way to find out anything about what it needs. Your Lua program seems all to do with sending stuff TO the aircraft, I see nothing related to any display control. So how are you doing that? Have you referred to the thread "PMDG J41 commands" in the User Contributions subforum? Seems quite a lot done there. In fact if you have queries it would seem best posting there I think? Regards Pete

The "off" position is only a visual thing in the simulator, being the samecas Up to all intents and purposes. it is a safety thing, cutting off power/pressure to the mechanism. If its visual position is settable in the PMDG aircraft, see if there's a keypress you can assign to set it. If so you can use the right-hand part of the FSUIPC axis assignments tab to assign that keypress to a part of the range of your lever -- basically just an extension of the lever-as-gear-control example given in the FSUIPC documentation. It would be a good idea to have it only operating when bringing the lever from the "gear up". position, as that is when you'd normally use it. If PMDG haven't provided a way of doing it without the mouse, you could investigate whether it is susceptible to the mouse macro facilities in FSUIPC (which work with the overhead), or even the L:Var access. You should also check the thread about "PMDG 747X commands" in the User Contributions subforum. Asking there might give results. Regards Pete

Okay. Good. Operating the A/T should be okay by normal fSUIPC assignment. Pete

Er ... sorry, that does not make sense. What is the difference in operating the A/T light from the offset to what we've been discussing for the autopilot? I really thought once oyu'd learned to do one LED from an offset you would be able to transfer this to any? If I have to show you how to do every single light and offset I suggest you give up now, because I will not do that. you have to be prepared to learn and try things out, not expect me to do it all for you! Do NOT post screenshots please. Just tell me why you cannot adapt everything you should have learned by now to another offset and light? Just add the code to your current file. Pete

Sorry, I can't make sense of that question. Can you explain any better please? Pete

Does it tell you to get 4.634? We are up to 4.641 now, soon to be 4.642. It should say "at least 4.634" not "only"! All interim updates are provided in the Download Links subforum. Regards Pete

You've called it "apRight" but you are testing for all three Autopilots (0x2003). Is that what you want? Sorry, I don't know off-hand how the RP48 LEDs are numbered. When I had some GF stuff connected I had to find button and LED numbers by trial and error. You'll probably have to do the same. Yes. But if you want 3 LEDs from the same offset you would be best treating them all in the same function, so: function set_apAll(offset, value) -- Right if logic.And(value, 0x2000) ~= 0 then gfd.SetLight(GFRP48, 0, 5) else gfd.ClearLight(GFRP48, 0, 5) end -- Centre if logic.And(value, 0x0002) ~= 0 then gfd.SetLight(GFRP48, 0, 6) else gfd.ClearLight(GFRP48, 0, 6) end -- Left if logic.And(value, 0x0001) ~= 0 then gfd.SetLight(GFRP48, 0, 7) else gfd.ClearLight(GFRP48, 0, 7) end end set_apAll( 0x04F0, ipc.readUW(0x04F0)) for setting lights 5,6, and 7 Sorry, you'll need to find out the LED numbers yourself. You can't do any harm, and you can edit and save the Lua file whilst FS is running. You just need to re-run it afterwards (assign a button or keypress in FSUIPC to "Lua " followed by the name of the Lua file (e.g. Lua ipcready). It'll be in the drop-down assignment list). Regards Pete

Sorry, it is bit 13, not bit 9, so it should be 0x2003 -- typo. I edited my original now to avoid confusion again. (It was late last night!) The BINARY number 1101 is decimal 13 or hexadecimal 0x000D. Your 0x1101 is 4096+256+1 = 4353 in decimal! You've obviously confused BINARY (where you only get 1's and 0's) and hexadecimal, where you get 0 to 9 the A B C D E F representing 10-15 decimal! Bit 13 is the 14th bit from the bottom end, the bit 0 meaning '1'. Look at 0x2003 in BINARY: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 This has bits 13, 1 and 0 set. Count them yourself, starting from 0 at the end. The first, or "top" bit is bit 15 -- it is a 16-bit value. Bit 0 is just 1 (0x0001). It is included in the value 0x2003 as you can see above. Please read the FAQ again! Bit 0 means "2 to the power 0" which = 1. Bit 1 is "2 to the power 1" = 2 x 1 = 2 Bit 2 is "2 to the power 2" which is "2 squared" which is 2 x 2 x 1 = 4 etc. It's all about multiplying by 2. Computers are that simple. They aren't really as clever as you, who I assume uses decimal. Binary ias simple, in only contains 1's and 0's, not 10 different digits like decimal. Hexadecimal is just a convention we use to shorten numbers like 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 to 2 0 0 3, by representing each group of 4 bits by one digit, 0-9 then A-F (16 digits because 4 bits holds decimal 0-15. 2 to the power 4 = 2 x 2 x 2 x 2 x 1 = 16). Sorry if my typo was the source of your confusion. Regards Pete

Does it generate a Log file in the FSX Modules folder? If so, show it to me please. If not, please show me the Install log file instead, in the same place. If there's no run-time log file produced then FSUIPC isn't even being loaded, so it is probably a DLL.XML problem -- though it sounds like a SimConnect problem. FSX does not take kindly to re-installation -- it often seems to make a complete mess of the SimConnect part. The problem stems, I think, form the fact that the SimConnect side-by-side library doesn't get completely uninstalled, and this stops the installer re-installing correctly. In general it is better, if reinstalling FSX, to start with reinstalling Windows from scratch. Of all the problems I hear of in SimConnect, they almost all occur after attempted re-installation of FSX. It's not a good move without also reinstalling Windows, especially on Vista or Win7 where there seems to be no work-around to fix SimConnect. On WinXP it is easier -- one can delete some WinSxS folders and reinstall just the SimConnect parts without too many problems. That doesn't appear to work, even if you could do it (which is difficult) on Vista or Win7. Even if there is a SimConnect problem causing FSUIPC not to be able to connect to FSX (and the Log, if any, will show that), there is really no excuse for a separate program, as I assume FSACARS is, to 'freeze'. That cannot be directly to do with FSX or FSUIPC but more of a poor programmed response to non-connection. It should simply report that it cannot connect. Regards Pete

Yes, of course. ALL names of values ("variables" as they are known) used in the documentation are simply chosen to be suggestive of what they represent. The same applies to "offset" and "value" in the function parameters. There are some reserved names, like those for GoFlight devices (GFRP48 etc), and of course all of the library function names and Lua "reserved words", like "function", "then", "if" and so on. Just try to avoid clashes with anything that might be so mistaken. Please name variables to be meaningful to you, always. Same with your own function names. Pete

I can't say I understand the rest of your post, so I'm only going to answer this part. First, FSUIPC (for sure) and FS (I think) do not act on axis inputs unless they change. So if your spoiler axis is "quiet" (not jittering), then by simply not moving it it will be ignored. If it is jittery and assigned in FSUIPC you might want to increase the Delta to stop the jitters being seen. If this is no answer because the axis HAS to move, then: Second, yes. you can disconnect the spoiler axis via offset 32F8. Are you writing a program? If not you could have a Lua plug-in which monitors the "on ground" flag at offset 0366 and connects or disconnects the spoiler axis at the appropriate times. Regards Pete

The Lua program is an EVENT driven one. You simply get it loaded once and it runs forever, monitoring the chosen offsets as declared in the event.offset functions you use. You should definitely NOT call is "RP48.lua" and run it via a button. You CAN call it "RP48.lua" and run it from a Lua called "ipcReady.lua" which runs automatically when FS is ready to fly. Or you can simply rename your RP48.lua to ipcReady.lua. The function is only called when the offsets you declare events for CHANGE. If they do not change nothing happens. That's the whole point of events -- an "event" is something happening, something changing. If you want to initialise the LEDs to some initially loaded values from the offsets you need also to add to the plugin lines to call the function explicitly, like: set_brake( 0x0BC8, ipc.readSW(0x0BC8)) set_ap( 0x07BC, ipc.readUD(0x07BC)) All these lines are doing is making your functions operate according to the initial values read from those offsets. [Note here that this is such a common need that I am now seriously considering making the initial function call automatic. This should save a lot of this confusion]. Your subsequent message: Why bother when you can execute the Lua by assigning it to that button? I don't see the point of making it event driven if you are using the button in any case. Of course you can. Please see the ipc library functions "read.." and "write.." for accessing all sorts of offsets in plug-ins -- and see the red examples above. You seem to want to make this much more complicated than it need be. If you only want lights changing when you press buttons then you can do it by, as you say: However, if you do that then the LEDs won't necessarily relfect the state when, for example, you start FS or load a new flight, or use the mouse to change the A/P instead of a button ... etc. Really you are best leaving the Lua function to reflect the FS state, no matter how it changes. Regards Pete

Er ... if ANY one of those is changed to non-zero the sound will start, but if any one of them is changed to zero, the sound will stop. Are you sure that's what you want? Perhaps you need to explain what it is you want to achieve. Events are only triggered when the offset value changes. If none of them actually change the function will never be called. Are you testing by setting turbulence on and off somehow, or are you just loading up FS with initial turbulence at the start -- which won't be triggering anything of course? If you want to initialise things for start-up settings you'd have to call the function explicitly too, like so: turbulence( 0x0ED2, ipc.readUW(0x0ED2) ) [Note here that this is such a common need that I am now seriously considering making the initial function call automatic. This should save a lot of this confusion]. but for every offset you are checking? No, that seems wrong -- it would keep turning the sound on and off according to each value, probably too fast for you to hear anything. If you'd like to explicitly describe what it is you want to really achieve, maybe I can offer more constructive suggestions? Pete

Did you read the details for PM offset 04F0? To start with it says it is 2 bytes. 2 x 8 = 16 bits, or in other words a "WORD", so the type is 'UW'. Second, the A/P indication in 04F0 are separate bits, one for each of up to 3 autopilots (for Boeing) or 2 (Airbus). So you need to say which you want to "light the LED" for. You would need to test just those bits, so you'd need to use the logic library to AND the bits out for testing. For example, the test for any set of the three Boeing A/P bits would be: if logic.And(value, 0x2003) ~= 0 then The value 0x2003 is simply the bits 13 (0x2000), 1 (0x0002) and 0 (0x0001) mixed together. You could just test each separately if you wanted. If you don't understand binary bits, and hexadecimal representation, please see my FAQ subforum., the thread "About bits ...." You "know" it because you choose the name yourself. It's just a name. Call it "MyLovelyLEDlights" if you like. Use something meaningful so you'll know next time what you did. Just use letters and number, starting with a letter. So you could call it X1243578 if you wanted, though that wouldn't be very helpful to understanding it. Yes, you must do now! ;-) You have all of the elements, except maybe one more to note: The function you name in the event.offset line is only called when the offset contents CHANGES. If it does not change nothing happens. That's the whole point of events -- an "event" is something happening, something changing. If you want to initialise the LED to some initially loaded value from the offset you need also to add to the plugin a line to call the function explicitly, like: set_ap( 0x04F0, ipc.readUW(0x04F0)) All this line is doing is making your function operate according to the initial value read from the offset. [Note here that this is such a common need that I am now seriously considering making the initial function call automatic. This should save a lot of this confusion]. Regards Pete

I'll help, but I'm not going to do all the work. First you need to download the FSUIPC SDK and locate the throttle values, because probably your Elite driver is writing direct to those. Then check the Lua library documentation (installed in your FSUIPC Documents subfolder, in the Modules folder of FS). In particular look up the "event.offset" function, in the EVENT library, because you will be using that to monitor the changes the Elite driver is writing. The only other Lua functions you are likely to need are the ipc.read and ipc.write functions -- there's a series of each for different value types -- and the ipc.control function, which you'll use to send the Axis control to FS. (FS controls are listed in the "List of FS controls" document, also in your FSUIPC Documents folder). You'll also only want this Lua plugin running when you are using this specific aircraft, so you need to check the aircraft name, or title. For that again check the offsets list. (use Search). You'd read that string value and compare it -- using a string library function which I'll explain when we get that far. Pete

Ah, in that case I don't really think there's an answer -- unless you want to try writing a Lua plug-in which reads the values which the Elite driver is writing (presumably?) direct to the throttles, and forwarding those via the Axis controls. If you want help with that, left me know. But have a look at the Lua documents first. Regards Pete

You don't give enough information for me to help much, but usually for proper Airbus "fly-by-wire" implementations, where the aircraft code intercepts the throttle axes in order to determine thrust modes, you need to assign (whether in FSUIPC or FS) to the FS axis controls, not 'direct to FSUIPC calibration' which bypasses everything and sends the thrust data direct to FS. Regards Pete

Don't use ipcInit.lua for anything reading offsets because that is run as soon as FSUIPC is initialised. You need to use ipcReady.lua which is run when FS is ready to fly. And Lua programs only continue to run if they are in a never-ending loop (not the best way) or use events to get themselves called regularly. You'd use "event.offset(...)" to get your sound-making function called whenever the offset changes. Sorry, I don't understand. You can't find the documents you have? If you mean you can't find the Lua documentation, please look inside your FSUIPC Documents folder, inside the FS Modules folder. BTW I have deleted the other identical thread you started. Please stick to one thread per subject. Thank you. Pete

Support for pmSounds would be by PM. I'm afraid I don't know it that well. You could try asking PM. Alternatively it would be easy using Lua which supports sounds. In fact there's another recent thread near here about Lua sounds. Regards Pete

I've never had a Game Port PFC device -- mine have always connected via one of their control boards (Throttle Quadrant system or Centre Console) and thence via a COM port and my driver for FS. However, I think all of the buttons on their yoke operate using the same principle as the buttons on the old CH flightstick -- each press produces a difference resistance on the same wires and this is decoded into combinations of only 4 bits -- 14 possible button values (all on being nothing pressed) supplied to the CH-type driver looking like 4 button combinations. As for what wires go where and what they do, sorry I can't help. But have you tried PFC themselves? www.flypfc.com. They have a Support Forum too. Probably not as responsive as this one, but worth a try. Regards Pete