Jump to content
The simFlight Network Forums

DanW

Members
  • Posts

    22
  • Joined

  • Last visited

Posts posted by DanW

  1. 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

  2. Not sure I understand you here. Why would that make any difference? Most of the examples in User Contributions do it with each button assigned to the same Lua plug-in but with a different parameter for each function, You still only need maybe just one plug-in for each different aircraft.

    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.

  3. 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

  4. 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

  5. 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

    SPAD_Profiles.jpg

    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

  6. 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:

    SPAD_Button.jpg

    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.

    FSUIPC_Button.jpg

    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.

  7. 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

  8. I've managed to get a similar crash, but it took a while, ad it seems to happen more if Lua logging is enabled. I've tracked it down very very deep into the Lua interpreter logic. It looks like there's a number of places in the original Lua code where things are used without checks. with threads coming and going I find a lot more checks are needed.

    Anyway, I've added checks in three places which I think are relevant, and in version 4.858, which i'll release later today or maybe tomorrow, I can't get it to crash at all.

    BTW I tested with the idea I had in my last message, where you are using the difference in the parameter values as an increment / decrement, and I think you need to do a few things slightly differently:

    1. If, like my test axis (not a wheel), you need to reverse the trim action to match wheel-for-wheel, you need to change

    trim = trim + val - prev[/CODE]

    [size=4][font=arial,helvetica,sans-serif]to[/font][/size]

    [size=4][font=arial,helvetica,sans-serif]

    [CODE]trim = trim + prev - val[/CODE]

    2. You might want to reduce the effect somewhat. if so, just divide the difference byt some factor, e.g.[/font][/size]

    [CODE]trim = trim + ((prev - val) / 2)[/CODE]

    [size=4][font=arial,helvetica,sans-serif]3. With a Delta of 1 your trim is subject to any jitter on the wheel axis. Set it instead to the minimum change you can see in the axis inputs x 2.[/font][/size]

    [size=4][font=arial,helvetica,sans-serif]4. You'll probably want a button you can push to centre the trim, for initial use or after loading a flight with the trim non-centred. Assign the button to [b]Axis elev trim set[/b] with parameter 0.[/font][/size]

    [size=4][font=arial,helvetica,sans-serif]Pete[/font][/size]

    Sorry I wrote that last post before checking for new posts, the window was open in the background while I was testing.

    It's funny you are reducing the effect and I am increasing it :)

    I think it depends on the sensitivity of the trim wheel. Saitek Cessna wheel has 9 full rotations with a large diameter wheel, so it's quite fine. Increasing the effect means less likely to hit the end of the axis as well as I don't need to go as far.

    [size=4][font=arial,helvetica,sans-serif][b]Axis elev trim set[/b] - just gave it a try, unfortunately it's not working for me with parameter 0. Maybe the NGX doesn't like it or they are setting the FSX trim to a value remembered in their code.[/font][/size]

    Thanks for the fix for lua logging, I haven't had any crashes after that one today but good to prevent any others.

    Cheers

  9. 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

  10. 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

  11. I'm controlling the NGX trim wheel with my Saitek trim wheel via lua script. This is working, the trim wheel moves etc.

    However when using it for a little while probably when I trim alot at once then FSUIPC crashes FSX.

    It may be when I get to the end of the trim wheel actually.

    Am I doing something wrong in my script or is it an FSUIPC issue?

    FSUIPC version: 4.843

    Details of the error and log file: https://dl.dropbox.c...68/LuaCrash.zip

    My script is in the Auto.ProfileName section, and also in the LuaValue on the Trim axis assignment as recommended in another thread.

    This is the current script, note I have to repeat the controls alot because otherwise the wheel hardly moves at all and I run out of physical wheel before I run out of virtual wheel.

    
    function checkvalue(val)
       if prev ~= nil then
    		  if val > prev then
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    		ipc.sleep(50)
    		ipc.control(65607)
    elseif val < prev then
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		ipc.sleep(50)
    		ipc.control(65615)
    		  end
       end
       prev = val
    end
    
    event.param("checkvalue")
    

    EDIT: Here is the final NGX Trim scripts for any other users that want to do the same thing:

    https://dl.dropbox.com/u/29331868/NGX_Trim.zip

  12. Hi,

    For the NGX I've assigned my left most lever on Saitek Quadrant as the Speed Brake.

    However it's movement is backwards, so I'd like to invert it.

    However NGX doesn't like the FSUIPC calibration, if I calibrate it there then the speed brake moves back to the middle area on it's own and doesn't behave. This is only with the NGX of course, other planes I can invert just fine with the calibration tab for speed brake.

    So I'm hoping that you'll tell me I can edit FSUIPC ini file and change something in the axis assignment line to make it work inverted? :)

    Or maybe you have any other suggestions?

    I looked at your document with the NGX offsets but I didn't see the speed brake levers in there, only boolean values.

    many thanks

  13. Hi John,

    I managed to get around the heading reset by overriding the heading movement as a button, then using a lua script to incr/decr heading found here: http://spad.189988.n3.nabble.com/PMDG-Jetstream-4100-AP-ALT-Display-on-Multipanel-tp4024982p4025041.html

    I can now set heading before switching the HDG mode on, although it won't show in the panel until I press heading, I can see the bug in the VC.

    I have only tested on the ground so far, as I'm multi-panel enabling all my planes first before I fly again.

  14. Hi John,

    Thanks for the script.

    I'm also finding the heading bug can't be moved, unless HDG mode is turned on first. This is not like the default aircraft, normally you can bug the hdg in advance.

    If HDG mode is off, when I move the HDG around, it jumps back to where it was before I moved, about 1 second later.

    Any ideas on what causes this or what we can change in the script?

    many thanks

  15. Hi Guys,

    I've managed to setup everything in the past in all my hardware, but I'm stuck on one change I was thinking of doing.

    I have the Saitek Cessna trim wheel, and I want to convert it from an axis to Trim up/down. The reason being that it's not motorized, so if I use the trim buttons on my yoke, it doesn't move. But if I make the wheel work like buttons, I won't know the difference and there will be no "jump" in trim when I use the wheel.

    Now normally I would create a whole series of ranges, like my cowl flaps lever, and my gear lever etc, and that works fine.

    But this axis is so big that I don't want to have to create 32,000 ranges to make it work. I was hoping to just overlap the whole range of movement, and tell it UP movements should be X button, and DOWN movements should be Y button etc.

    Here's my screenshots of what I was trying to do:

    https://dl.dropbox.com/u/29331868/Screenshots/TrimDown.jpg

    https://dl.dropbox.com/u/29331868/Screenshots/TrimUp.jpg

    It doesn't trigger the trim event, or any other button I assign. I suspect I am doing it wrong or this feature only works with small ranges when they are actually entered or exited not when they are moved within.

    Would appreciate if anyone can point me in the right direction to convert the axis to buttons along it's whole range.

    many thanks

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.