Jump to content
The simFlight Network Forums

Tutorial: how to get LUA Vars or commands out of FS


Recommended Posts

Posted

Because of several questions I have decided to write a little tutorial for this people which want to assign their custom key commands via FSUIPC using LVARs or just the logging.

In the example screenshots you see the logging and assigning of the PMDG MD11X. Of course the principle for other addons is the same.

The hole work is just try and error!

What you need:

1) patience

2) registered version of FSUIPC and the latest update

3) Lua Plug-In documents and examples

2 and 3 is available here at Pete's site: look at Updates and other goodies

unpack the "Lua Plug-In documents and examples" into your X:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules Folder.

Important is the file "log lvars.lua"

Start FS, start a flight and load your addon you'd like to dissect

Part 1: logging via logging window

logging2.jpg

Open FSUIPC menu and check "Button and Key operations" and "Events".

Also check "Send to console window".

There will immediately open up a new window.

If you close FSUIPC menue now you will see (if you have two monitors :wink: ) in the logging window that several lines appear - depends on the aircraft addon; it could be that many lines appear very fast, but doesn't matter.

Now make any action you want . You will have a response in the logging window.

screen1g.jpg

In the example above I have pressed the waypoints knob in the MD11.

The reaction in the logging window was the event line which I have green highlighted.

You can read now the controls number (66587 - you will finde these numbers in the PDF "List of FSX controls"), maybe a parameter number (71128) and the expression for the controls number: ROTOR_BRAKE

If there will appear many logging lines very fast you can pause logging by entering FSUIPC menu.

You can scroll the logging window to find your command.

Now you know the command and maybe a paramter and you can use and assign it via FSUIPC menu:

buttonwn.jpg

Select the ROTOR_BRAKE and enter the paramter 71128

:!: Note: there don't have to be parameter numbers, this could also be zero.

It depends on the developer. With PMDG as example, they control the most functions via ROTOR_BRAKE, simply changing the paramters.

As you can see in the picture, I can now press the waypoint button in the PMDG MD11 with my joystick E button 32.

But what, if nothing happens in the logging window after you have pressed something?

Part 2: Logging via LUA Vars

First, assign two keys:

log1.jpg

log2.jpg

Assign one key (or button if you want) to "Lua Log Lvars" (e.g. F5)

(Thats the way you call a LUA file)

Assign an other key to "Luakillall" to stop the LUA programm.

Now go back to FS and press F5: a window opens in FS and like with the logging window there will show up several lines.

(don't forget to check "LUA program logging" in FSUIPC menu)

luadisplay.jpg

The difference is, that you will see now LUA Variables.

Now, same way, press some knob or switch in the addon and see what happens.

But it will be hard to read that out of the small window, so end the LUA (press the assigned F6).

Go to your modules folder and look for this file

dateien.jpg

log lavars.log

open it with editor or wordpad and you will see endless lines of codes: the LUA Variables!

Now, the search begins...

But luckily the developers choose ligical names for the variables.

e.g. L:pmdg_hide_yoke=1 means what?

yes, rising and lowering the yoke

You can't use this LUA variables in the same way like the above controls.

One way is simply enter this Vars in a Macro:

1=L:pmdg_hide_yoke=tog

Or you make a LUA file wich means you enter this line into an empty wordpad document:

ipc.writeLvar("L:pmdg_hide_yoke", 1)

name this file "hide yoke.LUA"

You can now assign a button or key to it by choosing it from FSUIPC menu under "Lua hide yoke"

Note: this only let the yoke move down (1).

:!: This should be just a simple example how you can use LUA.

For effective working with it you have to read something about LUA programming, starting with it in Pete's FSUIPC forum and the several PDFs provided there.

It depends on the developers if and how many LUA they use or what you can find in the logging window (part 1).

It could also be that both is used, so for example in the PMDG J41 some knobs are controlled via LUA variables and the sounds for this knobs are made with ROTOR_BRAKE parameters.

As I stated above: you need patience and a lot of trial and error :!:

Try FSUIPC genious mouse macros before (explained in the manual)

The method with logging and LUA is just for the case you can't get any commands out of a addon in other ways.

And: do everything at your own risk! :wink:

Have fun and may the force (of FSUIPC) with you!!

Guenter

--------------------

Hi Pete,

feel free to correct and complete this little tut...

  • Like 1
Posted
Hi Pete,

feel free to correct and complete this little tut...

Hi Guenter

For now I made it "sticky". I have to go out soon. When I get a chance I will read it carefully and make any tiny corrections. ;-)

Thanks!

Pete

Posted

I would really like to make use of this but

1. my FSUIPC window has an Extras (Miscellary) checkbox under Lua program logging (I'm using version 4.549) / shouldnt matter, should it?

I have Lua's installed in the \modules, load my MD-11, check the boxes, have the console screen

see the typical PMDG

454852 *** EVENT: Cntrl= 65709 (0x000100ad), Param= 67648 (0x00010840) NAV2_RADIO_SET

457910 *** EVENT: Cntrl= 65709 (0x000100ad), Param= 67648 (0x00010840) NAV2_RADIO_SET

460968 *** EVENT: Cntrl= 65709 (0x000100ad), Param= 67648 (0x00010840) NAV2_RADIO_SET

etc

push the WPT button on the MD-11 panel, and then: Nothing

no 66587 no 71128 no ROTOR_BRAKE

?

what went wrong?, mt

P.S.

my

DontResetAxes=Yes

keeps be rewritten at every (auto) save of fsuipc to

DontResetAxes=No

I just noticed

??

Posted

Hi everyone.

I find this post very helpfull, but have a problem trying to implement this concept on the CLS DC-10.

The overhead panel has a gauge for the landing lights operation, which I managed to get the variable out with Log Lvars.lua file.

The variable is named LL_SWITCH, and gets the values 0, 1 and 2, to operate the landung lights. 0 value is for retracted; 1 is for extended off, and 2 is for extend and lit. There is another variable, dc10cls_sound_id, for the click sound - this is a clickable switch operation on the overhead panel.

I wrote a MACRO file for this, which I named 1DC-10.MCRO, and tried setting the values 0, 1 and 2...

[MACROS]
1=L:LL_SWITCH=SET

This works, but I can only get the switch to move (I don't get the sound of it because I didn't set the dc10cls_sound_id values), but they do not operate the landing lights - switch operation ok, but no results?!?

Here's the gauge xml code:




(L:LL_SWITCH,enum)














8 (>L:dc10cls_sound_id, number) (L:LL_SWITCH,enum) ++ d 3 < * (>L:LL_SWITCH,enum)
			 (A:LIGHT LANDING,bool) 0 == (L:LL_SWITCH,enum) 2 == &
			 if{ (>K:LANDING_LIGHTS_TOGGLE) }
			 (A:LIGHT LANDING,bool) 1 == (L:LL_SWITCH,enum) 2 < &
			 if{ (>K:LANDING_LIGHTS_TOGGLE) }			 




8 (>L:dc10cls_sound_id, number) (L:LL_SWITCH,enum) ++ d 3 < * (>L:LL_SWITCH,enum)
			 (A:LIGHT LANDING,bool) 0 == (L:LL_SWITCH,enum) 2 == &
			 if{ (>K:LANDING_LIGHTS_TOGGLE) }
			 (A:LIGHT LANDING,bool) 1 == (L:LL_SWITCH,enum) 2 < &
			 if{ (>K:LANDING_LIGHTS_TOGGLE) }



(c)2006 Commercial Level Simulations

I believe there must be a way to solve this, but I'm not into xml coding and this postfix (?) syntax isn't easily understandble.

Can somebody help?

Posted

This works, but I can only get the switch to move (I don't get the sound of it because I didn't set the dc10cls_sound_id values), but they do not operate the landing lights - switch operation ok, but no results?!?

There will be lots of cases like this, where the variable only keeps track of the switch position. That's its purpose in this case. You can see from the XML that the switch merely operates the standard default FS landing lights:

K:LANDING_LIGHTS_TOGGLE

The "K:vars" are the standard KEY EVENTS which I call FS controls and which can be assigned in FSUIPC's assignments drop downs (or, indeed, in common cases like this, in FS's own keyboard and button assignments).

Before venturing into more complex possible solutions such as mouse macros and L:vars, one should always first try the obvious, like normal controls. You can always determine if a normal control is used by switching on FSUIPC's Event logging, operating the swtch or button, and checking the FSUIPC log file.

Regards

Pete

Posted
There will be lots of cases like this, where the variable only keeps track of the switch position. That's its purpose in this case. You can see from the XML that the switch merely operates the standard default FS landing lights:

K:LANDING_LIGHTS_TOGGLE

The "K:vars" are the standard KEY EVENTS which I call FS controls and which can be assigned in FSUIPC's assignments drop downs (or, indeed, in common cases like this, in FS's own keyboard and button assignments).

Pete,

I started tracking this with "the obvious" solution. The problem is the lights, they do not extend and don't switch on.

Let's see if I can explain this clearly:

1) The panel switch is of cyclic kind and has three positions: retracted, extended off, and extended on (the animated landing lights rotate out of the fuselage on the DC-10);

2) Those are set by the switch position variable LL_SWITCH, values 0, 1 and 2 (cyclic mouse clicks gets them going 0,1,2,0,1,2...);

3) Using the default key event LANDING_LIGHTS_TOGGLE, nothing happens.

The landing lights on/off should only work when they are extended, and that's seems to be the problem as the event LANDING_LIGHTS_TOGGLE doesn't extend the lights - I'm afraid something else (that might be programmed in the model itself) is taking care of the animation, and that's behond the L:vars and K:vars...

I'll be checking this again, maybe I'm missing something...

Posted
[

1) The panel switch is of cyclic kind and has three positions: retracted, extended off, and extended on (the animated landing lights rotate out of the fuselage on the DC-10);

Okay. Understood. On the 737 only the outboard landing lights are retractable and have the three way switch.

The landing lights on/off should only work when they are extended, and that's seems to be the problem as the event LANDING_LIGHTS_TOGGLE doesn't extend the lights - I'm afraid something else (that might be programmed in the model itself) is taking care of the animation, and that's behond the L:vars and K:vars...

If the landing lights are handled completely internally, not using anything in FS internals, and the L:vars are only its memory of the switch position and not it's activation to change the graphic results, then I really suspect there's no answer. Maybe the add-on makers have a suggestion?

I wish panel makers would always add Key Event processing to every switch and option they implement outside of FS's internals. It would be so easy to do. The Key Event systems has hundreds of events which wouldn't have any other adverse affect on any specific aircraft so could be re-used (as some implementers do, in fact), and really there's nothing stopping additional ones, unnamed, just numbered, being used. I did try to pressure Microsoft's FS team (the gauge SDK designer, actually) to automatically generate Key Event processing for any Mouse Rectangle defined, and I think it would have happened in FSXI ...).

Alternatively, if they don't feel at home with Key Events, provision for Keyboard assignments would do -- but I think that's more work because they then need an interface for assignment.

Regards

Pete

Posted

Hi Muas,

just to be clear: have you tried "Part 1: logging via logging window" also?

it is often the case that the LuaVars which are given are just for remembering the switch position or whatever, like Pete descriebed it.

In that cases there are often some controls assigned with different parameters....

And the overall simpliest way: have you tried mouse macros?

Posted
just to be clear: have you tried "Part 1: logging via logging window" also?

Yes, I did. I followed this thread when trying to sort this out. And only the LL_SWITCH var appeared in the console window.

And the overall simpliest way: have you tried mouse macros?

I tried to, but I'm on FSX SP2, and it seems the automated macro feature doesn't work with SP2... in fact the macro recording doesn't seem to work. I was about to do it manualy, but then I gave up, I was spending to much time around the issue, so it was time to ask for some help.

That's the second time I plunge into this L:vars thing, the first was the lights system on my fave DA Fokker 100, on which I got no success also. The CLS DC-10 seemed easy to get into, but then I got stuck... I plan to return to the Fokker one of these days...

Posted
I'm on FSX SP2, and it seems the automated macro feature doesn't work with SP2.

But of course that is absolutely not true! It works with SP1 and SP2 only, not the original RTM version of FSX. I've been using SP2 ever since it first went into Beta, years ago! Surely everyone with any sense is using SP2 or Acceleration. It is so much more efficient!

As documented, Mouse Macros can only operate on gauges built using the standard FS C/C++ gauge SDK. It relies on the mouse rectangle structures that provides. It cannot possibly work with XML gauges as they are either interpreted or compiled on-the-fly. There's no way to discover where to place hooks even if there were any places for hooks!

My guess is that without the help of the maker of your add-on cockpit there's going to be no way to do it other that a real mouse emulation like Key2Mouse. Unless, that is, you want to delve into the XML and re-program it yourself (assuming you can work out how to influence the MDL side of it or trigger the fx file if that's what it needs).

Regards

Pete

Posted
But of course that is absolutely not true! It works with SP1 and SP2 only, not the original RTM version of FSX. I've been using SP2 ever since it first went into Beta, years ago! Surely everyone with any sense is using SP2 or Acceleration. It is so much more efficient!

As documented, Mouse Macros can only operate on gauges built using the standard FS C/C++ gauge SDK. It relies on the mouse rectangle structures that provides. It cannot possibly work with XML gauges as they are either interpreted or compiled on-the-fly. There's no way to discover where to place hooks even if there were any places for hooks!

Sorry, guess I misunderstood what the manual says about it. :(

(...) Unless, that is, you want to delve into the XML and re-program it yourself (assuming you can work out how to influence the MDL side of it or trigger the fx file if that's what it needs).

Yes, and that might be easier than it seems, because the code is there, one only must subsitute the mouse click call with a keypress call, or even better, a joystick call. Maybe I should learn a bit of XML myself... :roll:

Posted

you have two more options:

1) look through your LUAVars again and try out anything that smell a little bit after your wanted functions... even the unespected.

The namings can be very .... crazy....

(but of course, like with the F1 Mustang, it could be that there no Variables could be found)

2) deal with CS and DA that they sponsor me a free version, then I will take a look into it :lol:

Posted

Guenter I thought you would have realised by now that there is no such thing as LuaVars. Lua is a programming language as you know, and L:Vars is short name for 'Local Variables', they are two completely different things, try not to confuse your pupils anymore than absolutely necessary otherwise everyone will be doing it :lol:

Posted
Guenter I thought you would have realised by now that there is no such thing as LuaVars.

No, I haven't.

I'm 32 years old, I'm not able to learn anything new.... :lol:

Posted
(...) Unless, that is, you want to delve into the XML and re-program it yourself (assuming you can work out how to influence the MDL side of it or trigger the fx file if that's what it needs).

Here's how I got around this problem:

I adapted the xml gauge as a new one, to toggle the landing lights using keys instead of mouse clicks, and added it to the VC panel and 2D panels. I kept the original gauge in the overhead panel, so the clickable mouse option is also working and perfectly syncronized. Next I mapped the keys to my toggle switch via FSUIPC et voilà. No lua program needed this time.

Here is the gauge:




(L:LL_SWITCH,enum)














	(A:LIGHT LANDING, bool) 0 ==
			if{ 2 (>L:LL_SWITCH, enum) (>K:LANDING_LIGHTS_TOGGLE) }
			(A:LIGHT LANDING, bool) 1 ==
			if{ 2 (>L:LL_SWITCH, enum) }


	(A:LIGHT LANDING, bool) 0 ==
			if{ 0 (>L:LL_SWITCH, enum) }
			(A:LIGHT LANDING, bool) 1 ==
			if{ 0 (>L:LL_SWITCH, enum) (>K:LANDING_LIGHTS_TOGGLE) } 





My toggle switch sends an "O" keystroke when at the on position, extending and turning up the landing lights; and a "shift+O" keystroke when at the off position, retracting and turning them off. That's it . End of the story.

Thanks for the help, I learned to log the L vars in this process.

  • 1 month later...
Posted

Great tutorial and discussion, very useful for assigning my usb input devices (GoFlight and other). I've been very comfortable with the mouse macros in FSUIPC so far. Is there any difference performance wise using mouse macros or lua-based commands? Since I've used only mouse macros, sorry if this question shows lack of my understanding of the subject.

Thanks,

Dirk.

Posted
Great tutorial and discussion, very useful for assigning my usb input devices (GoFlight and other). I've been very comfortable with the mouse macros in FSUIPC so far. Is there any difference performance wise using mouse macros or lua-based commands? Since I've used only mouse macros, sorry if this question shows lack of my understanding of the subject.

The name "mouse macro" refers to a way of getting a switch to work with a button or keypress when otherwise it can only be operated by Mouse clicks. It is done by FSUIPC actually hooking into the gauge code and simulating the effect of the mouse click by using a direct call into the code. There's no "performance" measure associated with it as it is a mechanism, not a process.

Lua is the language used to write "plug-in" programs, ones which run in parallel with FS and which can do many different things, as needed, including, if you like executing mouse Macros. They are not alternatives. When you need to use a mouse macro, because that's the only way of operating a cockpit switch, then you need to use it because there's no other way. Whether you assign it directly, on its own, to a single button or keypress or use it withing a Lua program along with other things depends on the complexity of what you want to do, not on the particular switch(es) affected.

The performance overhead of a plug-in depends entirely on what it does and how it is written, like any other program.

Regards

Pete

Posted

Thanks Pete, all is clear. I hope I'll content my self with the excellent mouse macros in FSUIPC for all my needs. Otherwise programming takes too much time.

Dirk.

  • 6 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.