Some folks may want to maintain creative control over their add-ons, which I think is a valid concern that some developers might have. I don't know of any way one could lock down a script file to prevent it from being taken and modified.
The same is true of textures and config files though.
It's called licensing. True, no add-on developer is going to go through the trouble of hiring a lawyer to send out a cease-and-disist, but the community in general takes a dim view on unauthorised re-use, so I think that's enforcement enough for our purposes.
That is true. Completely forgot about that as Orbiter itself isn't very portable yet. But that is a good argument!
bind_readstatus_func(<func>) and bind_writestatus_func(<func>) that must be called once in the Lua script).
Well, it can detect prestep and poststep callbacks in the Lua script even if one or the other isn't implemented. How is that done?
Certainly possible, but then those states aren't associated with a particular scenario. If you switch scenarios that has another MFD instance, you would need a separate file for every instance.
I don't know
const int NCLBK = 13;
const int SETUP = 0;
const int BUTTONLABEL = 1;
const int BUTTONMENU = 2;
const int CONSUMEBUTTON = 3;
const int CONSUMEKEYBUFFERED = 4;
const int CONSUMEKEYIMMEDIATE = 5;
const int UPDATE = 6;
const int STORESTATUS = 7;
const int RECALLSTATUS = 8;
const int WRITESTATUS = 9;
const int READSTATUS = 10;
const int PRESTEP = 11;
const int POSTSTEP = 12;
const char *CLBKNAME[NCLBK] = {
"setup", "buttonlabel", "buttonmenu", "consumebutton", "consumekeybuffered", "consumekeyimmediate",
"update", "storestatus", "recallstatus", "writestatus", "readstatus", "prestep", "poststep"
};// Read MFD status from file
void ScriptMFD::ReadStatus (FILEHANDLE scn)
{
if (bclbk[READSTATUS]) {
lua_getfield (L, LUA_GLOBALSINDEX, CLBKNAME[READSTATUS]);
lua_pushlightuserdata (L, scn);
lua_call (L, 1, 0);
}
}Seriously. There are so many dead add-ons because of this.
Readstatus() and writestatus() are both "implemented" in Orbiter 2016, but there is something wrong with the passing of the scn handle so reading and writing can't happen.
Here you go. Assuming OpenOrbiter works like Orbiter 2016, you should be able to unzip this to the main Orbiter folder, then re-enable ScriptMFD under Modules, and start the scenario DG MFD Script Test.scn. Note that I am on a Linux box, but I don't think there is anything OS specific here. I left prestep and poststep callback functions in the script, but nothing is done in them other than outputting messages to the MFD display.
github.com
scn:lines()
scn:write(...)scn parameter given is just a handle! You can only use it with OAPI functions that take that handle!writescenario_string", "writescenario_int", "writescenario_float", "writescenario_vec" and "readscenario_nextline")
Maybe, but there are no oapi read/write functions that I am aware of. These are Lua syntax lines() function iterator and write statements. If scn were truly a file handle they should work.
I already did so:
www.orbiter-forum.com
github.com
function readstatus(scn)
line = readscenario_nextline(scn)
-- ...do something with the string "line"
-- or...
writescenario_float(scn, "wherever'" 3.141592)
endscn FILEHANDLE is not that!
Yes, I understand file handles. The usage of scn:lines() and scn:write functions are correct Lua statements assuming scn is a valid file handle.
OK. Can we get information from scn as-is that would let us get access to the file? If a valid file handle can be passed to Lua, is there any reason why read and write statements could not be implemented in pure Lua?
