MobiFlight Community Support

Greetings to all
First, I would like to share my humble opinion in the effort expended on this wonderful piece of software.
I watched the recently released video from the MobiFlight designer, and it is very cool.

within the development that we see every period, I would suggest adding (Functions) between )input and Output) in the near future... There are many additions of professional aircraft in the Flight Sim (P3D V.4, V. 5 and msfs2020) such as (CRJ-FSLabs) used (LVAR) -It has not been listed yet in MobiFlight, as there are keys that need between (Press and Release) to be placed, either (Sleep-Pause) or any other name.
Thank you

Hi

I´m sorry. I not fully understand.

Lvars was not possible to read in the older Sims.
In FS2020 they will be in the near future.... But i think for older Sims this will be more difficult. Here we not have a regular planning for now.

Whatever.... I not understand what you mean with "something between input output" Everything what we do is even a Input or a Output. So what 3rd group do you mean ?
Also you say " Keys between press and release to be placed" I fully can not follow your logic here.

If possible explane more detailed or better give us a simple example for a situation what you like to do.... And what "new" feature you request in this situation.

INPUTS Setting ON MOBIFLIGHT
AP_LOC_HOLD_ON =======ON PRESS
sleep(500)
AP_LOC_HOLD_OFF ======ON RELESE

example
THIS FROM FROM LINDA USE Lvars

function AB_AP_AP2_on()
AB_AP_AP2_on2()
sleep(200)
AB_AP_AP2_on2()
end

THIS FROM SPAD.neXt
<EventDefinition xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Trigger="PRESS" xmlns="http://www.fsgs.com/SPAD">
<EventActions>
<EventActionControl TargetDataDefinition="FSUIPC:AP_LOC_HOLD" Value="1" ValueOperation="Set" />
<EventActionDelay Delay="800" />
<EventActionControl TargetDataDefinition="FSUIPC:AP_LOC_HOLD" Value="0" ValueOperation="Set" />
</EventActions>
</EventDefinition>

Whatever Sleep Commands would be usefull..... E.g. to light a LED for 5 Seconds .....

But for a Input there is ne neednes.
If it´s a "toggle" then we simply send on Press..... No Release is needed.

If it´s a ON-OFF Then we send ON with Press and OFF with Release ( Latching switch)

If it´s a ON-OFF and we like to use a momentary Swtich We simplay say..... If($=1,0,1) (Build a fake toggle)

If it´s a toggle and we like to use a LAtching switch we say for On Press " If value is currently 0 then Toggle ELSE do nothing" and for on releae "If Value is 0 do nothing, ELSE Toggle"


I see no sense or needness for Sleeps in Input actions !

I completely disagree with you on that… it’s Useful for input and output …. Why? ...Because:

First: There are a lot of SIM lovers who do not know how to write the (lua) and I am one of them is very difficult for me at least.
Second: As I mentioned before, there are some aircrafts that do not use the Offset, such as (CRj - QW787 - FS Labs), and some of the buttons in these aircraft need a (Slip or Delay) between Press and Release.
Third, and it is most important: this is a suggest (Take it or leave it) ... In the last video, the program’s developer asked for suggestions - so I made a one.

Hi Again
I think you missunderstand me.

About your arguments:

1. I not talk about LUA ..... All is done within MF and within the GUI.... No Programming skills are needed.
"if($=1,0,1) " is a simple entry in the Transform line ( Instead form e.g. "0" or "1" for Press and Release) ..... This is done by every user here and a fully standard process.
" If value is currently 0 then Toggle ELSE do nothing" is a Precondition within Mobiflight...... Also a totaly regulary thing and nothing advanced like LUA Code.
By the way.... In the Future ( already today in some elements) we will do this Stuff INSIDE of FS2020 WASM Module.... So the user no longer need to think about !

2. Not think about Offset.... Inputs are done by EventID mostly. And also specify the "Slip and Delay" . I never see a system till now ( Latching) that need Delays. Only Momentary Systems needs Delays.... E.g. the "START" Position of the APU need to be hold for e.g. 1 second to initialise the Startup process. And This can be done with Simple Press Release Logic. So you Press the Button ( To start) And you HOLD the button aslong start is begin ..... And then your Release it and it goes back to former position.
May i´m wrong here..... Please show me a example of a Input we would need a DELAY and thats not possible with current Mobiflight Options. Then i will agree to you.

3. Thats right.... And we are happy about Suggestions.
In that case i was just a little unfriendly cause "Delay with Sleep Commands" is a Point that Sebastian is fully against. I also request for this years ago ( For LED Timers) and he said THIS is NO Option!
As i understand.... MF work in a countinious Loop..... Means if we make a Input then MF detect it, execute the command and then going forward.
A Sleep would meen it "stops" for 500ms e.g. and then in this periode there is no other Read or Update of a Display.... No other Button Inputs are detected and so on.
With a logic rework this could be solved (So Inputs get done "outside" of the loop) ..... But he said (that time) the needed time to implement is not paid by the small benefit of this delay ( that is not needed for 99% of users). Maybe he change opinion.... We need to ask him!


Summary:
Thanks for suggestion..... And feel free to make a Request also in the Bitbucket Page or to get in contact to Sebastian himself.
From my side i said everything i like to say.....
If you can give me a example where we need this tool AND!!! if this is not possible in a easy way already with the current system.... Then i will support you and vote for your idea!

Thank you for your explanation, support and effort
As for the example that you requested. I found it difficult to upload photos and videos to the Forum ... anyway. There is an example when I was setting the CRJ plane, specifically (STD). This key needs to sleep or a delay between 1 and 0
I think this video explains what I mean the most

https://www.youtube.com/watch?v=1LHVjkPf25U

OK.
Now we are on the same level !
We got a Problem..... And YES.... this "would" be solved with a delay.... But thats ( in my opinion) the wrong way.
If your PC get hot in case it stands 10cm near a oven .... then you could install a cooling system with -120° liquid nitrogen..... OR You simply put your Computer away from the oven and all is fine

So we need to check the situation and looking for a better way to handle this.

I think the problem basically occure in case a short momentary press here result in TWO commands and both are LUA Macro Calls.
Here the System we send Macros is "verry" uncomfortable and slow..... But FSUIPC give us no better interface. This is a technic that is 30 years old :-)
You already see..... MF is not the problem.... MF send the "key" command correctly short behind without Problem..... And also FSUIPC itself is not the problem in case it detect the KEY and execute the Macro to "Pull" the button again also short behind..... The "bottleneck" Point is the Interface that is offert from FSUIPC to MF for fire the Macros.... And that not allow us to do 2 fast behind !

Now what we can do here.....

1. You can confirm..... If you use 2 Lua Macro Calls ( One on Press, and One on release) But you press the button "a little" slower.... Then it already should work.
I mean PRESS.... Hold for 0,2 to 0,5 seconds .... And then Release. If my idea is correct, this should show us, if it´s already work.

2. If it work..... You can try NOW if a INCREASE of the FSUIPC Poll Rate helps..... May it´s enough to solve this.... But i don´t think so.

3. Think about the LUA Stuff.
I know in older Systems (P3D) there is a big problem in Case lots of AddOns ( Except the real professionals) use these Lvar Stuff So in the Past we was forced to use these "unpracticable" LUA Macros.
In FS2020 we no longer need this..... And hopefully we can also implement this new technique into P3D in the "far" Future!

Till then ( for this situation) i would think about a LUA Solution ( Yeah i know you not like it .... But you still need to use these Macros.... So why not pimp them a bit)
Basically your idea is not profitable here....
You send a Macro that PRESS the Virtual Button ..... And you send another Macro to RELEASE the Virtual Button....
Much more logical is to "Combine" the two actions in the First Macro!
You not need a Situation to Push and Hold..... So Everytime it should also get released directly behind and can get combined !

I NOT know the syntax..... But pretty sure you can use "multiple" commands within one Macro.... So no longer work with the 1 / 0 Parameter in MF.....
Simply fire ONE Macro on Press..... And The Macro then include 2 Lines.... One for Press(13) and one for Release (3)
Maybe it still workes..... If it again struggle then we include a delay INSIDE this macro.... So Macro send 13 ... Wait 200ms and then send 3.
Important is..... MF is not effected by this delay.... It start the macro and no longer care about the delay inside it!


**************************

Summary:

I hope you understand.... Usage of Delays is basically not needed in MF .... You still confirm with the Key that MF not struggle! . The usage of 2 Macros with a momentary Button is NOT normal and only in case you not combine the full action within ONE Macro already!
And sure.... Its only need in case FSUIPC not give us a more modern way!

If you need help here..... Or you want to talk about that system..... Meet me on Discord ( with headset ).... Then we make a voice seasson with a cold beer :-)

Thanks, I am already currently using it) usage of 2 Macros with all momentary Button (
My suggestion was to shorten the time and effort,
Thanks again
We will be talking again soon

Yeah
Lets do it so !

By the way.... After check your video a second time..... I see there is missing the "Simconnect" Status Bar in your Mobiflight Window.
This seems to me like that is a verry old version ( prior 8.xxx)

As i know there was no change within the LUA Macro Tool... But sometimes Sebastian find "small" issues in the code when he implement or fix other problems.... So he solve those things without announce this in videos or with a entry in the patch notes.
Means.... Its always a good idea to use the newest UpToDate Version ! ( Whatever i´m pretty sure this not solve your current problem here)

By the way, this video is not mine at all. I found it during my search to fix the aforementioned problem. Of course it is an old video, but I must thank him for his effort and keenness to communicate the information to sim fans.
As for me, of course I use the latest version of MobiFlight