hiran wrote: ↑Wed Jun 21, 2023 12:17 pm
So my script is looking like this:
Code: Select all
this.playerWillSaveGame = function()
{
log(this.name, "playerWillSaveGame() -> storing resourcePaths");
missionVariables["ooliteStarter_oxpList"] = oolite.resourcePaths;
}
this.playerWillSaveGame = function(reason)
{
log(this.name, "playerWillSaveGame(" + reason + ") -> storing resourcePaths");
missionVariables["ooliteStarter_oxpList"] = oolite.resourcePaths;
}
The method with parameter is getting called, as you perceived it. When I remove the handler with parameter so only the other one is left, the one without parameter gets called. Maybe that is on purpose to be backwards compatible.
This is just how Javascript works (generally and in Oolite).
Your first method defines
this.playerWillSaveGame for that worldscript.
Your second method *overwrites* the first definition (in the same way that if you do
a=2; a=3; then a has the value 3, not the values 2 and 3) [1, 2]
So with the second method in, only the second is set into the playerWillSaveGame variable after the script is executed, so that's all that Oolite can execute when looking to call that handler.
If you reverse the order of the methods in the file, only the one without the parameter will get called, as that will now be the definition that takes precedence.
The interface between Oolite and Javascript also is fairly tolerant of just making up the parameters, provided you don't expect it to do anything useful. So if you define
this.playerWillSaveGame = function(size, reason, override) { ... } then that will be called (it's a callable function and it's assigned to the correct property of the worldscript) - the reason, however, will end up in the variable you've called "size", and the other two will be blank as the Obj-C side won't be expecting them so won't pass anything to them. Similarly, as you've discovered, if you omit a parameter, all that happens is that you don't on the JS side have access to the contents of that parameter.
More generally: Oolite handlers - ship script, world script, whatever - are called by calling a method in Javascript, where the method is a property of a given name on a given object. When Oolite loads a world script or ship script, it executes the content - which conventionally just defines a bunch of properties (which mostly happen to be functions) onto the object referenced by 'this' - and then stops. Then, later, the Obj-C core will call those handlers. You can use this to set up private variables and methods too, if you want, because anything run or defined in the script context is still available to the handlers by normal JS scoping rules.
[1] Not usually recommended, but sometimes useful for debugging or compatibility tweaks: there's nothing other than politeness stopping you redefining the handlers in a *different* worldscript this way.
[2] Overwriting your own worldscript's handlers is a bit more useful. e.g. for a minor bit of efficiency the Nova mission undefines almost all its event handlers after the mission is over, as they'll never be called again.
https://github.com/OoliteProject/oolite ... mission.js
scenarios.plist - so if you wanted to maintain two savegames with different OXP sets, rather than installing and uninstalling the OXPs themselves, the tool could edit the scenario_restriction field on the savegame to set the OXPs which should be applied to it.
