John Dowson

Does it work in the 737-700? If so, it will be an issue with the 737-800. That preset uses the Rotor Brake control with a parameter of 57301 - you could try assigning to that instead, to check its not an issue somewhere with the execution if the preset.

How have you assigned this? Again,. how is this assigned? For idle / cut off levers in the PMDG 737, please see the following post: John

This will be corrected in the next release. Not sure when this will be, but I can make a beta version available if needed. Just let me know. I assume you also realise that if doing this, the elevator will also move when you move the drone camera forward... John

I have just updated the license. John

The license has been updated, valid until 5th January 2023.

Nice! Thank you very much, John! When I am at home I will get on it! Ok, but if you want fast when you hold the encoder in, you want to assign to the standard controls first, not the fast one. When you do this. you will find the corresponding entries in your FSUIPC7.ini that will look something like this (the index numbers [12,13], device letter [A] and button numbers [1,2] will be different): 12=PA,1,C65879,0 -{HEADING_BUG_INC}- 13=PA,2,C65880,0 -{HEADING_BUG_DEC}- To make these conditional on the rotary NOT being pressed, you would need to add a compound button condition to those assignments (see page 21 if the Advanced User guide) so that they are only triggered when the encoder isn't pressed in. Assuming the encoder push registers button 5, on the same device (A in this example), then you would change those assignment lines as follows: 12=CP(-A,5)A,1,C65879,0 -{HEADING_BUG_INC}- 13=CP(-A,5)A,2,C65880,0 -{HEADING_BUG_DEC}- You can then manually add the fast controls, by duplicating those lines, changing the index number (must be unique!) and the control number, resulting in the following: 12=CP(-A,5)A,1,C65879,0 -{HEADING_BUG_INC}- 13=CP(-A,5)A,2,C65880,0 -{HEADING_BUG_DEC}- 14=CP(+A,5)A,1,C1025,0 -{heading bug inc fast}- 15=CP(+A,5)A,2,C1024,0 -{heading bug dec fast}- Just give it a try and let me know if you have any problems. Also, please note that when editing the FSUIPC7.ini file, either do this with FSUIPC7 not running, or if it is running then open the button assignments window before editing, and when you have saved the changes, click on Reload all buttons to load the changes. John

Then you posted in the wrong forum - there is a specific sub-forum for FSUIPC7/MSFS - I will move this topic to that sub-forum. How does this work exactly? Is this a sticky button, i.e. when you push the encoder you get a button press, and when you press again a release? Or do you hold it pressed and rotate? Does FSUIPC register a button number when you press the encoder? This is by far the best option. Unfortunately I have no idea how to achieve such thing. I read the "Advanced User Manual" but I do not have a clue where to paste these commands in the .ini file. So you would like to achieve this on the button press of the encoder? I can help you with this. If you can assign your rotary to the fast inc/dec controls and check that is working, then show me your FSUIPC7.ini file and let me know the button number on the encoder push, then I can let you know how to use an conditional assignment for this. John

What FS and version of FSUIPC are you using? What ecent/control are you assigning to for this? Does your rotary have one button in each direction, or two (fast & slow) in each direction? FSUIPC provides additional controls for faster heading bug changes: Heading Bug Dec Fast Heading Bug Inc Fast You can just assign to those rather than the standard inc/dec controls. However, it is more common to want to be able to use both fast and slow increments and decrements. There are various ways to achieve this, depending on your rotary type (2 or 4 button). If you have a 4-button rotary, it will show one button for slow rotation in each direction, and another for fast rotation. Just assign the slow button to the standard controls, and the fast button to the fast controls. If you have a 2-button rotary, with a single button in each direction, then there are a couple of ways to achieve this. The first is to use a lua script to convert your rotary movement to set virtual fast/slow buttons, depending on the speed that you turn the rotary. A lua script is provided for this, which you can use/adjust for your device, called Rotaries.lua - from the Lua Plug-ins manual: The second method is to assign the rotary buttons to both standard and fast controls, and then use an offset condition to determine which control to use. The offset condition can be based on another button press or a key press, so that when you turn the rotary on its own you get slow movement, and when you turn it and the defined button or key is also being pressed/held down, then the fast controls are used - or vica versa. You can also achieve finer control by using offset 0x07CC with the offset controls Offset UWord Increment and Offset UWord Decrement (or the cyclic ones), which allow you to define the actual inc/dec delta values to use (the standard ones use 1, the fast ones use 10). John

Assignment facilities are only available in the registered version. There is a trial license available to test these facilities before purchasing, available from a sticky post at the top of this forum, here: Unfortunately the current license has just expired. I will update this license tomorrow (or maybe later this evening), so please check then. John

You could also try using Alt+Tab to see all windows and select each one in turn - that should also show you what program that window belongs to... Are you tunning any lua scripts in WideClient, i.e. are there any .lua scripts in the WideClient folder? If so, you could also try disabling them to see if they are the cause. There will also be a log file for each lua running, so you could also check those. John

Yes...did you try and determine the program/process that owns this window, as advised? That would be helpful (if it has an owner...) Not sure what WideServer has to do with this...FSUIPC handles lvars through the FSUIPC WASM module. You can add an lvar to a free FSUIPC offset and treat it like any other FSUIPC offset - read its value or write to it to update the lvar, or you can use the lua facilities for lvar handling (or macros). John

Yes, intriguing - but I can't see how it can be WideClient itself doing this, as it does nothing at all with displays/windows, unless using the button screen facility, which you are not. Did you check the task bar, as suggested, to see if the WideClient window is still available (i.e. hover over the icon with a mouse) and if it can be brought to the front? Or when WideClient is started, move it to the part if the screen still visible before it connects to FSUIPC7 - if you do this, fo you still see the WideClient main window? ( it is very difficult to see what is actually happening as the image you attached is so small!) Ah, so you are using WideVieW...I would certainly look into this as a cause...can you test again with no trace of this running in either the server or clients? Maybe also see if you can figure out what is creating that window, using either the Task Manager or maybe Process Explorer. John

First, your FSUIPC is version 7.3.11 - the latest version is 7.3.15 - please update. I am not sure what is causing that... is the WideClient still visible/available - i.e. can you see the WideClient window by using the task bar icon? Your WideClient.log file shows that you have one client application running/connected: Could it be that application that is causing this? Could you try without running SPAD to see if that is the cause? Btw, FYI you can also run FSUIPC7 on your client machine - see the Appendix in the Advanced User Guide for details in how to do this. This doesn't provide the exactly same functionality as WideClient, or as running FSUIPC7 on the server machine, but is an alternative solution to using a client PC with MSFS. John

Please see https://appuals.com/nsis-error-error-launching-installer/ ot https://pupuweb.com/solved-fix-nsis-launching-installer-error-windows/ (or google) for this issue. John

Just taken a look at the available lvars and found these lvars for the landing light position switches: L:switch_111_73X - retractable left L:switch_112_73X - retractable right L:switch_113_73X - fixed left L:switch_114_73X - fixed right They hold 0 when the corresponding light is off, 50 when set to pulse, and 100 when on. You can therefore use those to determine the switch positions. You can add those lvars to free FSUIPC offsets using the Lvars-to-offsets facility. Also lvar L:LandingLightOptions holds the landing light configuration, John

Ah, ok. I will enable in the FMS and take a look... Yep, and that would be good, thanks, John,

The current license is still valid. And as you have been using FSUIPC7 since the beginning of October, why are you requesting a new trial license? Surely you must have decided to either use the registered facilities (and therefore purchase a license) by not or not... The trial license is not provided so that it can be continually used, which is why I leave a day or two between the expiry of one license before I generate a new one.

Ok - are the pulse landing lights something you configure for the aircraft in the equipment options in the FMS? If so, then aren't they either always set to pulse or not, whether the lights are on or off, and the only way of changing this is to reconfigure the aircraft (i.e. there is no standard switch or button for this)? I don't think there is a way to access the aircraft configuration/set-up options via the PMDG SDK. But again, this would be a question for PMDG. John

Yes - otherwise you would have the axes assigned in two places, and both would be trying to control the aircraft. You can just delete the assignments in MSFS for those that you want to assign in FSUIPC, but I would recommend you start with an empty profile in MSFS for your controller/device if assigning everything (or almost) in FSUIPC. If you create a new profile for your device/controller in MSFS, it will be empty by default, so start with that. John

I have noticed an issue when using the 'Control to repeat whilst in range' option when sending key press and releases. This results in multiple key downs being continually sent when not needed. This seems to be related to how I handle key repeats - I will look into this. Even though this does not cause issues (these down key presses are ignored), it may be better to send single key presses (i.e. no repeat) but do this on several different ranges. Anyway, try playing around with this technique and see if you can come up with assignments that work for you. John

No! Hitting the clear button will clear the currently displayed assignment, i.e. delete it. You should hit the Ignore Axis button, which will ignore the input from that axis for the remaining time the dialog is open - or until you press the Clr Ignores button. Or you hit the Rescan button, which will again wait for the first axis input to be detected and show that. If you hit the Rescan button and it keeps showing an axis other than you want to assign (or check), then you hit the Ignore Axis button and try again. That is probably because you cleared that assignment. It is the Joy# and Axis# boxes you need to be looking at to determine what axis is detected. That is because they are controlled by the same equipment (your foot pedals) and when you activate the rudder you will also be applying pressure to the toe brakes, and FSUIPC/Windows is seeing the toe brake axis change first. This is entirely normal and is exactly the situation in which you should be using the Ignore Axis button. So, I suggest that you try again, now that you understand whet the Ignore, Clear & Rescan buttons do. Note that this is also described in the User Guide. John

Just tested this by assigning my aileron axis also to drone left/right using the following assignments: Seems to work well. I will do the same for drone forward/back but using the Elevator axis. John

You cannot do this as the Translate Drone ... are not axis controls but standard events (not taking any parameters). Also, as previously stated, these controls (Translate Drone ...) are not available via the SDK for external applications. They do however have default MSFS key bindings - A=left, D=right, S=back, W=forward. You can assign your axis to send these key strokes on the right hand side of the axes assignment dialog using the control Key Press & Release. To send the A key (translate drone left), for example, the parameter would be 65+8 (where 65 is the VK code for the A key, and 8 indicates a normal key press - see pages 18/19 of the Advanced User guide for a list of VK codes). You could either try setting up different ranges to send the same additional key press the further you move the axis, or you could try sending on repeat in an axis range (or a combination of both). Up to 10 distinct axis ranges can be used. If you need further assistance, let me know and I could assign here and show you how they look. John

This is possible. Any simvar can be added to an FSUIPC7 offset for read or read/write using the myOffsets.txt file. See page 34 of the Advanced User guide for details. Once a simvar is held in an offset, that offset can then be used as any other offset, i.e. can be read and written to. John

This issue is very puzzling - FSUIPC behaves the same no matter when it i started. I have also taken a look at the 310 and cannot duplicate this behavior. The log file you attached shows that nothing was seen or sent by FSUIPC during the session, which only lasted just over a minute and a half. I see you are using an ipcReady.lua - what does this contain? Maybe you could show me that. That will be the only thing that is ran, but this also should run when FUIPC is already running when you load an aircraft, or if you start FSUIPC7 with an aircraft already loaded and ready-to-fly. Maybe you could take a short video showing this issue, and how it starts/stops when FSUIPC is ran/exited. Thanks, John Later: are you using the Airbus A310-300 Enhanced add-on?