LUA Multiple Vessel-Persistent MFDs are Incompatible

[wizard1073]

I created one LUA-based MFD, vessel persistent, fully functional with calls to setup, update, prestep, and the button-handling routines. By itself (listed alone in ScriptMFD.cfg) it runs just as it should.

I run into a problem when I create a second, similar MFD in LUA. The first Script-based MFD selected from Orbiter's in-flight list of MFDs opens first, and afterwards that same MFD opens when any other Script-based MFD is opened. Example: First AttitudeRCS, then Higgs Field Controller--except AttitudeRCS opens both times. Next test: First Higgs Field Controller, then AttitudeRCS--except HFC opens both times.

From the help file:

By contrast, if Persist = vessel, the interpreter is attached to the vessel the MFD is running in. It doesn't get deleted when the MFD is deleted. All MFDs running this mode share the same interpreter.​

(Emphasis is mine)

It seems contradictory that one can have multiple LUA-based MFDs under this specification if they share the same interpreter, yet need different setup, update, etc. functions. Even the test MFDs included in the distribution are vulnerable.

What am I missing?

 

[Tschachim]

I know it's necroposting but I just ran in exactly this issue, once I activate e.g. the AttitudeRCS script MFD I can't activate any other script MFD.

Does a bug report exist in the bug tracker of this forum yet, I didn't find anything, just this post?

Cheers
Tschachim

 

[BEEP]

I should have looked for info on Lua MFD's here before employing a large amount of effort and time developing two MFD's and a related Vessel using Lua Script resources. I ended up finding myself in the above situation: I can load only one from the MFDs in the ScriptMFD.cfg list per Orbiter session. The first one loaded prevails over any subsequent diverse selection.

May I have any hope of not having all the LUA code I've written and painfully debugged (no fancy deb tools) as a waste?

Regards,

Beep

 

[BEEP]

Final info on Persistent and Non Persistent MFD's: a circunvention

Since this subject is too important to be left without proper conclusive explanation I'd like to have this thread complemented with relevant information from the readme from my script MFD's

" NOTES ABOUT NON PERSISTENT Script MFD´S

This is a LUA run time source code interpreted Script MFD. This means it was not developed in C++ and compiled as a dynamic link lybrary (.DLL) as usual but is an open source code that is interpreted whenever an Orbiter session is running and the MFD is activated. The advantages are that the code is open and easy modifiable by anyone who knows how to improve or expand it, that the developer doesn´t need to keep a sophisticated and updated development platform in his machine but can produce MFD´s with simpler tools, and that ,hopefully, the code won´t need to be recompiled regularly as Orbiter and Windows get into newer versions.
However, this comes with a somewhat heavy price tag.
Despite there´s a 'performance penalty' in LUA MFD´s it´s barely noticeable in current machines and on the kind of application.
The main problem with LUA MFD´s is related to the two options available from which the developer must choose one:
The first one is coding the MFD as 'Vessel' or 'Persistent' MFD. In this case this persistent MFD will be the only script MFD that can be run in one Orbiter simulation session.
The second option is to have the Script MFD as a a 'MFD' or 'Non-Persistent'. In this case the MFD is prevented from background running which means that the MFD can't process real time data (monitor and take actions on current flight data such as measuring your altitude while setting your hover engines to keep it to a value for example) whenever the MFD is not showing (or being updated), or in other words, while in the cockpit screen of the intended vessel with the MFD active or with the MFD active in an external MFD window.
I chose the 'Non-Persistent' option, therefore remember that, for example, if you leave out the cockpit to see your plane releasing loads , release sequence will stop untill you get back to the cockpit and the MFD is shown again. Also, if you close the MFD ( choose MAP MFD in its place for example) all operation is aborted and should be restarted. One way to get around this situation is to have the MFD opened as an External MFD which will appear independently from cockpit or external views, will be always updating and therefore can do a more autonomous 'background running'. "

Also, I would add that to do something as close as a 'background running' as possible the MFD Refresh rate should be increased in Launchpad reducing the interval to .1s max.

Clearly, it seems to me that choosing Non- Persistent MFD's is the option that brings the greatest advantage of allowing to have multiple Script MFD's available. The disadvantage of not having a true 'background running' can be dealt with by using the MFD update routine and , if it's the case, opening the MFD in an External MFD window.


Rgds,

Beep