User variables within Mobiflight

[tigert]

Now that we can do user variables by defining events with our own L-vars in events.user.txt, it would be actually better to avoid that roundtrip and do them internally in MF Connector.

[rofl-er]

Would it be sufficient to have a solid preset sharing platform to share the own Lvars? That way inexperienced users can profit from the a bit more experienced ones by just adopting their custom Lvars.

[madmonkeyfpv]

goodness yes please, hardware and electronics I’m ok with but coding I just don’t understand. Jaime was kindly mentioning an alternative to the custom fauipc offsets to use as a precondition but even explained I still don’t get what it all means or where it all goes

[JaimeLeon2]

Hello guys,
I just opened my Github account.

I agree with Tuomas that either using FSUIPC or the wasm module for our panels internal controls (preconditions) requires the data to be sent outside and read back into MF as an output. This cannot be as efficient as having a data storage and retrieval solution inside Mobiflight that allows us to set, read and modify values without having to use external resources. It doesn't have to be a large space in my opinion.

A solid presets catalog is necessary to ease the barrier for new and inexperienced users, and I support this idea also, but it does not solve having to use outside Lvars for internal controls.

[pizman]

I fully agree.
The idea to use the WASM is ( for me) not logical..... Cause its not "compatible" for users who not have FS2020. So our target is still to allow a user "fast and easy" to swap from e.g. P3D to FS2020.... means the "new" system should be indipendet from the Sim/FSUIPC/WASM at all. And for Sure.... A Bypass is nonsense !

Another Factor.....
Currently we need to READ the Storrage Information with a pretty unless Output Config (Cause its the only thing we can use as indication for a Precondition OR a Config Refference/Placeholder)
With a INTERNAL Solution this is gone!

For Input Configs we would need a new "Typ" Next to "FSUIPC Offset" or "Simconnect Event" we would have "MF Mem" .
There we choose one of the "Data Slots" by a Dropdown and define what we like to "send" to it.

Finally we no longer need the READ Config to handle it aslong Sebastian give us a new Element at the "Config Refference" in the Placeholder system OR the "Config Item" in the Precondition Tab..... Here we THEN can choose between a "existing Output Config" OR a "MEM Slot"! .

E.g. we say in a Config Placeholder "a" should represent the value of MEM Slot XX .
Or in Precondition we say "Only work if MEM Slot XX = 1"
So no longer needed to Read the Storrage back with a Output Config just to have it available.

---

About Size.... I think no Problem. MF runs on the Computer itself. We have Gigabytes of RAM and Virtual MEM .
Stop thinking about "Custom Area in FSUIPC" .... For a Computer a Gigabyte is nothing. We could support Storrage Mem as much as we like.... In theroy Trillions of Bytes.

[tigert]

Yes, the wasm to do user variables is just msfs2020 specific, and it was actually discovered that it works without any additional development / support from MobiFlight itself. So it is a "hack" - any L-variable can be referenced in the output presets, and if any named variable does not yet exist, it gets created. So the functionality just happens to work due to the way the WASM module itself functions. It is not meant to be a final solution, as it works on msfs2020 only.

Even though MSFS2020 is driving a lot of the new stuff in MobiFlight, stuff "user variables" should be done so that they work on all supported simulators, if at all possible.

[MobiFlight-Admin]

Well guys, this feature is now available. #373