• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX FUIPC Creating custom button macro with multiple Lvar functions.

Messages
1,749
Country
unitedstates
I am trying to create a custom Lvar macro for FUIPC for one of my payware aircraft so users can have function of the autopilot with hardware. But since the functions all use Lvars we can only do this with FUIPC. But my issue is not customizing this FUIPC4.INI file it's making each assignment work with multiple functions. Or the button will fail to animate and function.

Here is my Macro to assign all single events

Code:
[MACROS]
1=L:HDG=SET          // L:MODE_HDG=TOGGLE (i WANT TO USE LVAR THIS AS WELL)
2=L:BNC=SET
3=L:NAV=SET
4=L:BC=SET
5=L:LVL=SET
6=L:TST=SET
7=L:ENG=SET
8=L:SFT=SET
9=L:SPD=SET
10=L:VS=SET
11=L:GS=SET
12=L:ALTSEL=SET
13=L:ALTHLD=SET
14=L:AUTOPILOT=SET


I assign the first entry to a button on my joystick and end up with this entry in the FUIPC4 ini file.

Works
Code:
[Buttons.1LJ35A]
0=P0,7,CM1:1,1     -{Macro 1LJ35A: L:MODE_HDG tgl}-     // TOGGLE MODE

And this as well.

Works
Code:
[Buttons.1LJ35A]
0=P0,7,CM1:1,1     -{Macro 1LJ35A: L:HDG SET}-        // ANIMATION PRESSED
1=U0,7,CM1:1,0     -{Macro 1LJ35A: L:HDG SET}-        // ANIMATION RELEASED


I managed to get the first entry to work but not all 3 together. i can also get the 2nd and 3rd entry to work without the 1st entry.

Does not work!!!
Code:
[Buttons.1LJ35A]
0=P0,7,CM1:1,1     -{Macro 1LJ35A: L:MODE_HDG tgl}-  // TOGGLE MODE
1=P0,7,CM1:1,1     -{Macro 1LJ35A: L:HDG SET}-          // ANIMATION PRESSED
2=U0,7,CM1:1,0     -{Macro 1LJ35A: L:HDG SET}-          // ANIMATION RELEASED

I read online this can be done but can't find any samples. What am i doing wrong?
 
Last edited:
What is the difference between lines 0 and 1 there? They appear to be identical yet the FSUIPC auto comments
are different.

I have multiple assignments for the same switch in several of my aircraft and have had no problems implementing
them via edits to the INI file..

I'm not quite sure what, exactly, you want to do from your description. If it is simply multiple actions on a
switch/button press or release it is as simple as just having multiple INI entries for the same switch/button state
as you are apparently doing.

If you need some action to be set before another you can make use of the 'flags' feature in FSUIPC such that
the first press of a button sets a flag, a second press performs a function based upon the state of the flag.

The Advanced Users Guide PDF file in the FSUIPC Documents folder inside the Modules folder is the place to
go for answers to questions such as this.

Paul (whose current FSUIPC4.ini file is 7,229 lines long)
 
I think i have solved my issue. I did not have both functions in the macro list. So that's why the first 2 lines are the same. Figured this out while in bed passing out last night.:rolleyes:


Code:
[MACROS]
1=L:HDG=SET
2=L:MODE_HDG=TOGGLE

Now this should work. I need to test it.
Code:
[Buttons.1LJ35A]
0=P0,7,CM1:2,1     -{Macro 1LJ35A: L:MODE_HDG tgl}-  // TOGGLE MODE
1=P0,7,CM1:1,1     -{Macro 1LJ35A: L:HDG SET}-          // ANIMATION PRESSED
2=U0,7,CM1:1,0     -{Macro 1LJ35A: L:HDG SET}-          // ANIMATION RELEASED
 
Is this hardware-specific?
Because a simple XML gauge (based on XMLEvents or default functionality) could easily bind the Learjet's custom autopilot buttons to the default autopilot events (and from there on, be accessed by keyboard or hardware controllers).
 
Is this hardware-specific?
Because a simple XML gauge (based on XMLEvents or default functionality) could easily bind the Learjet's custom autopilot buttons to the default autopilot events (and from there on, be accessed by keyboard or hardware controllers).
I just had success today on pulling this off but had to move all the logic from the model def to the outside logic. This was rough and needs a ton of testing. Almost done.

So do you have an example on how to create what your talking about. Because the modes are so complex and a few share the same default autopilot modes that i dont think that is possible.
 
Last edited:
I just had success today on pulling this off but had to move all the logic from the model def to the outside logic. This was rough and needs a ton of testing. Almost done.

So the Learjet v2.8 will not feature any K: var interactions in the mouse rectangles for the autopilot! Hallelujah!
Although I was pretty successful so far with simply cancelling issued default autopilot commands and then executing my own AP logic.

So do you have an example on how to create what your talking about. Because the modes are so complex and a few share the same default autopilot modes that i dont think that is possible.

Sure. Sticking to the peculiarities of your Learjet and XMLTools:
Code:
<Gauge Name="Key Control for some functions of the FlySimWare Learjet 35A">
<Element>
<Select>
<Value>
'SPOILERS_TOGGLE' (>C:XMLEVENTS:EventName,string)
'(L:SPOILER_SW, Bool) ! (>L:SPOILER_SW, Bool) 1 (&gt;L:XMLSND70,enum)' (>C:XMLEVENTS:EventString,string)

'PROP_PITCH_LO' (>C:XMLEVENTS:EventName,string)
'0 (>L:LEAR_SHUTOFF1,bool) 0 (>L:LEAR_SHUTOFF2,bool)' (>C:XMLEVENTS:EventString,string)

'PROP_PITCH_HI' (>C:XMLEVENTS:EventName,string)
'1 (>L:LEAR_SHUTOFF1,bool) 1 (>L:LEAR_SHUTOFF2,bool)' (>C:XMLEVENTS:EventString,string)

'AP_MASTER' (>C:XMLEVENTS:EventName,string)
'(L:MODE_ENG,bool) ! (>L:MODE_ENG,bool)' (>C:XMLEVENTS:EventString,string)
</Value>
</Select>
</Element>
</Gauge>

A version without XMLTools as a requirement would look like this, but you need to be in VC view for it to work:
Code:
<Gauge Name="Key Control for some functions of the FlySimWare Learjet 35A">
<Keys>
<On Event="AP_MASTER">
(L:MODE_ENG,bool) ! (>L:MODE_ENG,bool)
</On>
</Keys>
</Gauge>

I haven't tackled your custom autopilot modes yet, but as you can see, it's mostly a matter of tying the button's L: vars to a default event (that can be further mapped to controllers or keyboard keys by the user).


P.S:
I'm reworking the Lear's vertical autopilot modes at the moment to make them more usable. SPD/MACH HLD is a tough nut though.
 
I haven't tackled your custom autopilot modes yet, but as you can see, it's mostly a matter of tying the button's L: vars to a default event (that can be further mapped to controllers or keyboard keys by the user).


P.S:
I'm reworking the Lear's vertical autopilot modes at the moment to make them more usable. SPD/MACH HLD is a tough nut though.

There are 13 buttons for my autopilot modes. Not sure this will work as we don't have enough default functions i think!

I think if we use the G1000 softkeys we might be in business.

Update: Working perfect. Here is a temp setup until the next version is released. Once 2.8 is out the files will already be included. And we will have instructions on the website. Give this a try as it works perfect. And i included the default autopilot to work as well.

No FUIPC required. This new simple method uses default softkeys.
http://www.flysimware.com/website/help/LEARJET35A_AP_KEYS.zip
 
Last edited:
Hi Folks,

As long as you are looking at the autopilot (believe you have a Lear guy on your staff) - was discussing the autopilot over on AOPA with another Lear guy and he mentioned you should be able to engage [VS Hold] without the [Altitude Select] set and enabled - I know it's not possible on the FSW Lear - is this true or did I misconstrue his statement to me ???

Regards,
Scott
 
As long as you are looking at the autopilot (believe you have a Lear guy on your staff) - was discussing the autopilot over on AOPA with another Lear guy and he mentioned you should be able to engage [VS Hold] without the [Altitude Select] set and enabled - I know it's not possible on the FSW Lear - is this true or did I misconstrue his statement to me ???

The LJ 31 manual I found online says it's true. And I'm working on an autopilot mod to make the vertical modes more realistic, but see the "2.8 patch" thread on Avsim for more infos.
 
The LJ 31 manual I found online says it's true. And I'm working on an autopilot mod to make the vertical modes more realistic, but see the "2.8 patch" thread on Avsim for more infos.

The reason we make the user use the ALTSEL for the VS and SPD mode is because the default alt hold mode always has the ALTSEL active based on the selector setting.
So for example lets say we made the autopilot work on VS mode without the ALTSEL mode and the user changes the selector to 9K feet. Then the aircraft would level off at that height.
So it's best to always have the ALTSEL active and then the user knows to keep the select setting set to zero if they do not want to capture a altitude.

If the selector was digital we could get around this issue but since the selector is manual dial we do not want to force this to zero!
 
The reason we make the user use the ALTSEL for the VS and SPD mode is because the default alt hold mode always has the ALTSEL active based on the selector setting.
So for example lets say we made the autopilot work on VS mode without the ALTSEL mode and the user changes the selector to 9K feet. Then the aircraft would level off at that height.
So it's best to always have the ALTSEL active and then the user knows to keep the select setting set to zero if they do not want to capture a altitude.

If the selector was digital we could get around this issue but since the selector is manual dial we do not want to force this to zero!

I know you're basically using the default autopilot functions since I've analyzed the scripts and for simplicity, your approach is totally appropriate.

Still, I prefer things to be at least decently realistic and that's why I'm modifying the autopilot logic. As far as I understood, in the real Learjet, it's up to the pilot (as there was no widely used "level change" capability back in the day) to get to the altitude that was dialed in on the selector, whether manually, by "VS hold" or by "speed hold".
 
Still, I prefer things to be at least decently realistic and that's why I'm modifying the autopilot logic. As far as I understood, in the real Learjet, it's up to the pilot (as there was no widely used "level change" capability back in the day) to get to the altitude that was dialed in on the selector, whether manually, by "VS hold" or by "speed hold".
The current AP implementation allows one to 'preload' the next target altitude into the altitude select window once the AP is in ALTHLD with the current altitude. This is very useful, for example, while flying a STAR which has a succession of step down altitudes because it makes it convenient to setup 'early' for the next descent leg. Hopefully this is a realistic 'feature'.
Al
 
The current AP implementation allows one to 'preload' the next target altitude into the altitude select window once the AP is in ALTHLD with the current altitude. This is very useful, for example, while flying a STAR which has a succession of step down altitudes because it makes it convenient to setup 'early' for the next descent leg. Hopefully this is a realistic 'feature'.

Altitude preselect and capture is still possible, but it'll be up to you to get there.
 
Altitude preselect and capture is still possible, but it'll be up to you to get there.

I don't know what you mean by "it'll be up to you to get there". How does that differ from how the AP works now (load a target altitude, deselect ALTHLD if necessary, select ALTSEL, pitch the a/c to establish a climb or descent rate, then select either VS or SPD hold and eventually altitude capture happens when the target altitude is reached)?
Thx,
Al
 
Last edited:
It doesn't. But ALT SEL isn't a requirement for SPD or VS anymore.
 
When the ALT SEL mode is "on" you capture the Alt selector setting. But if the ALT SEL mode is "off" then VS and SPD will just climb or descend ignoring any Alt selector setting.
 
Last edited:
Back
Top