John Dowson

So the [CAMERADEFINITION.004] is overriding the default P3D spot view. I guess you would need to remove (or comment out) the whole section so that the original view is still available. Did you try some of the other camera's with the 'View Camera Select x' control? If other camera's are (locked) spot, you could use them instead.

If F11 is sending 'View Camera 3' when you press F11, then your add-on aircraft is using 'View Camera 3' for 'Pedestal / Radio' and you won't be able to use this control. Similarly, if you have mapped your button press 'View Camera Select 3' and this works for default aircraft but not for your A320/A321, then that control is being remapped by the add-on aircraft. Alternatively, your add-on aircraft may have remapped F11 for its own use (and is sending a different control). First try assigning your button directly to the control 'View Camera Select 3', not the keypress (F11). If that doesn't work, you can try some of the other 'View Camera Select' controls to see if they provide what you need. Otherwise check the aircraft documentation (or support forums) to see if provides any other method/control for view selection. If not, you may have to live with using the view mode, sub mode, and next/prev controls. Sorry but I don't have the A320 /A321 so can't really help any further with the specifics of this aircraft.

Also look into the P3D Options -> Key Assignments. By default' F11 is mapped to 'View Camera 3 (select)'. You could try assigning another key (or key combination) to this, and then assign your button press to that key (or key combination). Or, better still, assign direct to control 'View Camera Select 3' (66853). John

You could try assigning to keypress F11 which is for 'Locked Spot view' (see http://www.prepar3d.com/SDKv3/LearningCenter/getting_started/view_system/using_views_and_windows.html).

Hi Andrew, thanks for the update. This patch will be officially released with a few other minor updates within the next week or so. Cheers, John

CPFLight MCP - don't know, sorry - you should probably ask them or on their support forums. If 'PM' is Project Magenta, then that would need FSUIPC, but again you are better off asking the suppliers/developers. There are these following (old) posts related to these items (although I'm not sure this helps): Cheers, John

FSUIPC only records the first click. Thats why you need to edit the macro file to change the action, or if you want to change the action to a compound action (i.e. click & drag followed by release). Also, when you assign the button press to the macro, you can assign a different action on the press and release, which is why I suggested two macros, one for the left click and drag (action 9) assigned to the button press, and another for the release (action 13) for the button release. Thats just one thing to try - you could try other compound actions, activated either on a press, a release or both. Good luck with your investigations!

Yes, sorry - no spaces. As Pete says, you need to play around with different (compound) codes/actions to see what, if anything, works. Otherwise investigate an L:var solution if the standard controls don't work. You can use the provide lvar plug-in to see what L:vars are available. I think there are also Linda scripts available for the A320 - these will be based on Lua & L:vars so may give you some insight, even if you do not want to use the Linda framework. As Pete suggests, the Aerosoft support forums may be the place to ask about this. Cheers, John

In your scripts you have infinite loops, so the first loop, eg will never end, and so the second loop (while) will never be reached. Thats why they work in separate scripts but not together. If you want them in one script, you could try a single loop, e.g. something like -- test RPM and IAS while 1 do RPM = ipc.readLvar("L:Eng1_RPM") ipc.writeUW(0x66c1, RPM) ipc.sleep(50) IAS = ipc.readLvar("L:AirspeedIndicatedNeedle") ipc.writeUB(0x66c0, IAS) ipc.sleep(50) end Better still, look into using the 'event.lvar()' libarary function and have two functions that get called only when the lvar changes (see the FSUIPC Lua Library.pdf, page 26). Cheers, John

Also note that mouse macros will not work if the gauges haven't been written strictly in accordance with Microsoft's C/C++ gauge SDK and you may need to try looking into using lvars instead, if available. However, I also see this comment from 2016 on lvars - not sure if still valid:

...or you can also try programming one macro for the press and one for the release: [Macros] 1 = sb-full-press = RX40000170,92 = sb-full-release = RX40000170,13

You can try that for the left click and drag. You may also want to add the button release, so it would be [Macros] 1=sb-full 1.1=RX40000170,9 1.2=RX40000170,13

Hi, the mouse macro will only contain the mouse press (left single click code 3), so if you call it on a button press or release, it will still be sending the mouse (left single) click only. What you probably want is a left button and drag then a mouse release. Do do this, you will have to manually edit the macro file. See page 32 of the FSUIPC User Manual for the mouse action codes, and page 37 of the Advanced User Manual for 'multiple actions in one macro control'. If that doesn't work, try a few other combinations. You could also see if there is a control or lvar you can use for this by activating logging. Cheers, John P.S. If its the Aerosoft A320 you are trying to set-up, there is also a discussion on setting up the speedbrake on an axis or buttons in this (ongoing) thread that may be of interest (half way down):

You can try activating event/control logging (via FSUIPC logging tab) to see what is being sent when you toggle it with the mouse and then replicate this, or look into using mouse macros (see FSUIPC documentation).

Hi Andrew I just replaced the above attached zip with a minor correction if you could use that instead. Thanks, John

Hi Rod, sounds like you have usb power management (sleep/selective suspend) active in the USB hub. Try disabling that. Cheers, John

Hi Andrew, the state wasn't being advanced which will have prevented the commands being sent. Please try the following build: FSUIPC5150i.zip Cheers, John

Hi Yves, I should point out that the strings in the string table returned to the lua function will have a nul ('\0') character at the end, included in the length of the string. I am not sure this is correct, but it is also the way WideClient handles the strings in the string table so I've kept this implementation the same. These can be handled how you wish in the lua code (for most purposes, this won't matter). Cheers, John

Hi Andrew, Hmmm...it was only the CMDRST call that was disabled. You can try the following, which has the CMDRST enabled before closing (so the device is ready for next use): FSUIPC5150i.zip If this doesn't work, maybe the device does not respond unless being reset first? Otherwise it may be a power problem - do the devices have a powerful enough power supply? Cheers, John

Sorry, was confused by your video - at first it looked to be a video of the actual joystick device, not the sims controls! Ignore my comment and try Pete's advise. Also, are you sending to FS as normal axis or to FSUIPC for calibration? Some add-on aircraft do not behave well when the axis is calibrated in FSUIPC. John

Sorry, I have no idea whats causing this. Is it a force-feedback device? FSUIPC only takes input from joystick devices, so I doubt very much this is anything to do with FSUIPC.

You can do, but try changing AutoAssignLetters=No to AutoAssignLetters=Yes in the '[JoyNames]' section after you have made the assignments (or even before, once you have generated a clean ini file). Or look into manual joy letter assignment. If you don't do this, your joy ids could change again further down the line, which would give you the same problem. The joy ids can change for different reasons, but usually due to disconnecting then re-connecting your usb device to a different port/hub.

*** Moved from FAQ: please post in Support Forum in future *** Hi, it looks like your JoyId numbers have changed (and you are not using JoyLetters): you have two devices, one with a joy id# of 3 (Razer Tartarus Chroma), an another with id of #2 (B737), but your assignments are to devices #1 and #2, e.g. 0=R2,0,C65602,0 -{THROTTLE_DECR}- -- Assigned to joy id #2 10=P1,14,C70325,0 -{Custom control: <70325>}- -- Assigned to joy id #1 You will need to edit your ini file to use the correct joy ids, or better still, switch to using Joy letters - please see the documentation for this.

Sorry, this is not correct - 'print' IS a basic lua command (just one I've never had need to use!). The rest of my comments still apply.

Hi Claude, Is this a lua script? If so, 'print' is not a statement and will cause the script to fail. And, without tis line, the script would end very quickly anyway! Also, how are you starting the lua? In FSUIPC, to automatically start a lua script it must be added to the '[Auto]' section, otherwise it should be activated from a button or key press. If you are trying lua for the first time, you can also try activating 'Log Lua plugins separately' (and maybe 'Debug/Trace Lua plugins') from the FSUIPC logging tab, which will create a <yourLuaScript>.log file. Also, please check-out the documentation and example scripts provided. Cheers, John