This PR has two changes (three if you include the version number change). The changes are readily separable if required:
Bump the build number to 2.7.30 (to make it easier for you to integrate if you like it as-is).
Fix "reload plugins" to correctly reload FWL scripts after start. (One-line change; see line #7313 herein.)
For years, every time the user does a "reload plugins" (e.g. using the command in DRT), FWL gets into a strange state, displaying an error after reload, saying FLYWITHLUA_DEBUG() is not defined. (The Lua engine is, at that point, stopped unless the user manually invokes the "reload scripts" command.)
To fix this, we simply make sure ReadAllScriptFiles() is called not only when LuaResetCount > 0 (as it is now), but also when XPLMGetCycleNumber() > 0 (meaning the simulator has already started up). This allows us to correctly detect that XPluginEnable() was invoked after a reload-plugins event! (I have used this successfully in other projects as a quick way to detect this case.)
Alternatively, to be conservative, you could change this to XPLMGetCycleNumber() > 9999 (or some other constant number of cycles after start), so it doesn't otherwise trigger too early; but I don't think this is necessary.
Add two missing predefined global string datarefs from User aircraft file (provided by XPLM): PLANE_AUTHOR and PLANE_DESCRIP.
This is more code than the first change above, but it is very straightforward.
We simply define new plugin globals gPlaneDescrip and gPlaneAuthor, and look up the datarefs in XPluginStart().
We define new string globals PlaneDescrip[] and PlaneAuthor[] to hold the strings, of size (sic) SHORTSRTING chars.
We fetch the dataref byte-array data just as is already done with PLANE_TAILNUMBER and PLANE_ICAO globals.
We export both as globals within the user's FWL context, i.e., PLANE_DESCRIP and PLANE_AUTHOR.
Both of these changes were tested out, and FWL starts up just fine on Mac, Linux, and Windows, and the new variables are available and correctly mirror the User aircraft's state as well.
I even verified that the new globals are correctly updated after changing User aircraft (i.e., by loading a new aircraft, and running the test script again). Note that the globals added update each time the aircraft is changed because FlyWithLua reloads all scripts at that point, which runs the same dataref code (as with PLANE_ICAO and PLANE_TAILNUMBER.
(There is no good way to automatically test the first change. It's just a matter of verifying that FlyWithLua actually doesn't fail to come up after a reload-plugins event!)
This PR has two changes (three if you include the version number change). The changes are readily separable if required:
Bump the build number to 2.7.30 (to make it easier for you to integrate if you like it as-is).
Fix "reload plugins" to correctly reload FWL scripts after start. (One-line change; see line #7313 herein.)
FLYWITHLUA_DEBUG()is not defined. (The Lua engine is, at that point, stopped unless the user manually invokes the "reload scripts" command.)ReadAllScriptFiles()is called not only whenLuaResetCount > 0(as it is now), but also whenXPLMGetCycleNumber() > 0(meaning the simulator has already started up). This allows us to correctly detect thatXPluginEnable()was invoked after a reload-plugins event! (I have used this successfully in other projects as a quick way to detect this case.)XPLMGetCycleNumber() > 9999(or some other constant number of cycles after start), so it doesn't otherwise trigger too early; but I don't think this is necessary.Add two missing predefined global string datarefs from User aircraft file (provided by XPLM):
PLANE_AUTHORandPLANE_DESCRIP.gPlaneDescripandgPlaneAuthor, and look up the datarefs inXPluginStart().PlaneDescrip[]andPlaneAuthor[]to hold the strings, of size (sic)SHORTSRTINGchars.PLANE_TAILNUMBERandPLANE_ICAOglobals.PLANE_DESCRIPandPLANE_AUTHOR.Both of these changes were tested out, and FWL starts up just fine on Mac, Linux, and Windows, and the new variables are available and correctly mirror the User aircraft's state as well.
I even verified that the new globals are correctly updated after changing User aircraft (i.e., by loading a new aircraft, and running the test script again). Note that the globals added update each time the aircraft is changed because FlyWithLua reloads all scripts at that point, which runs the same dataref code (as with
PLANE_ICAOandPLANE_TAILNUMBER.(There is no good way to automatically test the first change. It's just a matter of verifying that FlyWithLua actually doesn't fail to come up after a reload-plugins event!)