DanW

Yep I can see your point, in the long term it may be nicer to not have to go back into the lua file. Although for now I'm facing a massive task of moving all my scripts around into the new method, this will be quickest for me for now to get me flying again. Thanks for the advice

Hi Terry, I use multi crew experience and can highly recommend it. It can be adapted by the user to work with other aircraft, via keyboard mappings to phrases. But the aircraft it directly interfaces is quite a good list. On aircraft it doesn't fully support, I use the voice checklist feature, plus almost always set heading set course etc works, altitude sometimes doesn't work on others. Most of the best aircraft work though, PMDG 737, 747, MD-11, Simcheck A300, feelThere ERJs to name a few, there is more on their website. They are always developing bit by bit adding more, I think next up is the captain sim 777 then probably they will interface another airbus. You do need to do alot of windows voice speech training to get it to work, but once it does work it works amazingly. Get it on the 7 day trial when you have some spare time to give it a good run, it takes alot of setting up, building your favourite checklist etc. The trial is here: http://www.multicrewxp.com/Downloads.html

If I was using the parameter method to do this, then I would have to configure things both inside the script, and also inside the FSUIPC gui where I would map the buttons, lookup which parameter number corresponds etc. So in order to manage all my assignments, I would have to both edit the file and go into FSUIPC gui or ini file. So when I say Event.Button() allows me to keep it in one place, I'm hoping I can just have one big script for an aircraft, event.button("joyletter",button,"function-name") one line per assignment and no need to go into the gui or ini file. Any time I need to make a change, it's just one file. It just seems so much easier this way unless I've mistaken how this works. I'll use that ipc.macro as well thanks, I will call my existing macro files with it keeping all the assignments in my single lua file. Thanks for the clarification on running the background luas, the only problem I was worried about was having multiple luas building up in the background when changing aircraft.

Thanks guys, I might try the event.button monitoring the buttons so I can keep it all in one place. If I then put the script that monitors button events, in a section specific to one substring named aircraft type, am I going to run into problems when reloading that aircraft? For example in the FSUIPC ini: [Auto.PMDG 737NGX] 1=Lua NGX_buttons If I change to the Trike, and reload the NGX again for another flight, or change from the 800 to the 600 variant, am I going to get this script running multiple times? Do I need to explicitly terminate it when the plane is unloaded? Also is there a way to call mouse macros from a Lua script? I need to use a combination of Lua and mouse macros to control everything nicely, but it would be nice to keep all the assignments together in the one file regardless of how it is actioned.. many thanks

At user's request, I've attached the final scripts to the first post for them to use.

Hi Pete, This is with 4.858, i've got about 135 Lua Macros (and more coming) for various actions I map my hardware to. However when I get more than 127 macros it won't add any more than that to the list in the FSUIPC.ini Is there a maximum number of macros, or is it failing to add the new ones because of something else? e.g finding an error or something in one of my macros that stops the list growing larger? If there is a limit, is there another way I can get all my macros into the same file but still be accessible by the button assignment tab? At the moment, for every discrete function that I want to map a button to I create a lua file like this: require("MD11_LIB") event.offset("029C", "UB", "VVS_plus") Mainly because it's the only way I know how to do it, if there is a better way I'd be interested to know. many thanks

ps before you do any of this, create a custom profile in SPAD for the NGX, because you don't want to change the default stuff that works for other planes. Then anytime you fly the NGX, just pick this profile. Eg these are the profiles I have in use Also go into SPAD general options, and select "when a new aircraft is detect", pick "ask for a profile to bind", then it will remember your profile selcetion

Hi Steve, Massimo's special programming with SPAD for the NGX is more about the multipanel and autopilot functions, the switch panel doesn't do much for the NGX in particular the top row because the top row is GA focussed. By default you should find the gear and the lights work however, although NAV and STROBE active different things on the same 3 position switch but the rest of the lights are good. Watch the overhead panel when pushing your light switches, you should see them toggle. This is assuming you don't have the default Saitek drivers, I never installed them so I don't know if they would conflict but it's likely they would. With SPAD you don't have to use Saitek drivers at all if you don't want to. If you still want to map the top row, you need to go into SPAD (double click the taskbar icon) and click setup on the switch panel tab. Then pick the switch you want, change the event to "FSUIPC Virtual Button" For example for battery on/off you could assign the first two buttons and it would look like this: Since NGX doesn't use default commands, you need to create macros to connect to: 1. Go into FSUIPC, buttons tab 2. Click create mouse macro, call it "NGX". Every time you do this for the NGX controls, ensure you give it the same name so they are grouped. 3. Click OK 4. Go to the 2D panel for where the switch is that you want. 2D panels are more likely to give you a result. 5. Click the switch, give it a name, and hit enter. See the FSUPIC manual for more information about mouse macros and testing them etc. 6. Go back into FSUIPC and End mouse macro and it will save to disk. Click OK. Then go back in FSUIPC, you would go into the buttons tab, push the button/switch on your Saitek, and assign the control, script, or mouse macro. Here is where you select the mouse macro you created earlier. Note some macros only allow you to toggle, where others might give you an ON and an OFF. Because the macro only allows you to toggle, and no specifically ON/OFF, you can just assign the toggle to one way of the switch. Then to turn the battery on flip it up, to turn it off flip it up then down again.

Great! I'll grab that version

Good idea Paul

Got it working with a Lua to reset at value 0 followed by ipc.control. 0 is the forward most position and close to where takeoff trim is as well, but that's fine I can just set my trim wheel near the top before pushing the button. I just have to remember not to push that button in flight, or I'll be pointing at the ground! Cheers and thanks for the Lua help

Hi Pete, Your memory is good, I did intend to use that script for all planes to avoid the jump when first using the wheel after disconnect Autopilot. But assigning it as a normal axis is easier you're right, reaching the end of axis was a pain as well as the scripting. So I did away with that and just reverted to assigning as a normal axis - and held the yoke when activating the trim. Normal axis works fine for most aircraft - except the NGX, PMDG have done something special with the trim. Therefore it doesn't support AXIS trim. Basically if you have an axis assigned to trim, it will only move the trim in one direction. Roll the trim forward, it goes forward, roll the trim back, it goes further some more! PMDG's answer to queries on this is that it's more realistic to use only the buttons on the yoke which may be true I don't know. I like to keep up the physical movements I use when flying GA aircraft so my preference is to use a trim wheel in all planes, and I just like the feel of that. Thanks for the script help I think I'm happy with this now. I added a few things to get round some problems: 1. The trim was backwards so I inverted the axis 2. ipc.control was needed as well to "activate" the change - writing to that offset stored the value but didn't update the elevator or wheel until hitting the button or calling ipc.control 3. Negative trims were achieved and bypassing NGX limits. The 737 has different trim limits based upon flap settings but luckily PMDG use the value of 0 in the offset for the limit. So even if the forward Trim limit changes to 3.95 with flaps down, internally that is 0. This is probably why trim was only going one way before, I think they may only use one side of the axis. Here's the final script if anyone else wants to do the same thing: function checkvalue(val) trim = ipc.readSW(0x0BC0) --flaps = ipc.readSW(0x0BDC) --Not needed as NGX sets 0 trim dynamically based on flaps if prev ~= nil then trim = trim + ((val - prev)*2) --increase movement -- Prevent going past end of trim, NGX trim is one side only if trim < 0 then trim = 0 elseif trim > 16383 then trim = 16383 end ipc.writeSW(0x0BC0, trim) -- Send an trim increment control to force trim update if val > prev then ipc.control(65615) else ipc.control(65607) end end prev = val end event.param("checkvalue") One thing I have to do is try and have my trim centred before loading the flight, but otherwise this solution works well thanks! Cheers

Sorry I meant to say 4.857 :oops: Slip of the finger due to last version number..

Hi Pete, Sorry it didn't seem that long since I updated, you certainly provide better support and updates than many other vendors. I installed your FSUIPC update and now I'm at 4.857 Thanks for the tip on the delta, I had it lowered on my other assignments but forgot it here. Now I've tried it with a delta of 1, and removed the sleeps. The sleeps where an attempt to get around the script not doing exactly what I wanted, it doesn't seem to move the trim very far so I thought it might need to wait until the first part had done or it might have been ignoring duplicate commands. But it makes no difference so I've removed them. On the error, it happened after the new version too but only once, I think I may have still had the sleeps in: Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14 Faulting module name: FSUIPC4.dll, version: 4.8.5.7, time stamp: 0x50604b89 Exception code: 0xc0000005 Fault offset: 0x000435cd Faulting process id: 0x177c Faulting application start time: 0x01cd9ab53e0d10d5 Faulting application path: S:\fsx\fsx.exe Faulting module path: S:\fsx\Modules\FSUIPC4.dll Report Id: a91027ce-06ab-11e2-875f-bcaec591772d However I cannot reproduce the crash anymore, it only happened once. I can't remember if I removed the sleeps before or after the crash, but I'll find out eventually if it happens again. I get hardly any movement out of the trim, which is why I need to add so many ipc.control. I can move through my whole trimwheel axis range, and only get 5% out of the NGX trim like this. Using several entries doesn't help. The wheel still moves soo slow. Do you have any ideas on how I can make the trim move further? I have 15 ipc.controls in a row and it seems to do the same movement as having only one entry. Could there be a problem of the script still executing when the trim wheel moves and triggers the script again? I noticed tapping the trim button in the NGX doesn't move it very far, but holding it down does. Is there a way I can tell the script to hold down the ipc.control for 1 whole second or a certain amount of milliseconds? Or a push, then sleep, then release? many thanks