Modifying core Oolite v1.76.1 release Constrictor Mission...

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Switeck
---- E L I T E ----
---- E L I T E ----
Posts: 2411
Joined: Mon May 31, 2010 11:11 pm

Modifying core Oolite v1.76.1 release Constrictor Mission...

Post by Switeck »

I'm trying to anyway!

Seems my mod for the Constrictor mission...blows up in my face and causes game errors -- but only when I leave the original files intact!
I'm trying to edit the mission, and can't because the originals override my changes.

I'm just editing their data not their logic.
Even something as simple as which systems report that the Constrictor was seen...elsewhere or was bound for elsewhere...fouls things up royally.
Maybe if the switch command can't handle >30-something cases I might be to blame. :P

If I rename the original files to *.txt, it works.
If I overwrite the original files, it works.

Do I need to add "-overrides" or something to the filenames to get them to completely replace the originals without conflict?
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Commander McLane »

It would be easier if we could look at what you've done. Can you upload your OXP as it is now (or send it via email)?

One thing is for sure, to begin with: Amending filenames arbitrarily with "-overrides" does nothing apart from effectively deleting that file by making it invisible to Oolite.
Switeck
---- E L I T E ----
---- E L I T E ----
Posts: 2411
Joined: Mon May 31, 2010 11:11 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Switeck »

Here's my OXP...

Constrictor Mission MOD.zip (41.77KB)
Download Link
http://www.sendspace.com/file/yqrdi0
Switeck
---- E L I T E ----
---- E L I T E ----
Posts: 2411
Joined: Mon May 31, 2010 11:11 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Switeck »

The cause for the errors I was getting was due to putting all this into world-scripts.plist:

Code: Select all

(
	"oolite-constrictor.js",
	"oolite-constrictor-hunt-mission.js",
	"oolite-thargoid-plans-mission.js"
)
The errors pointed to Oolite's oolite-constrictor.js if I did not rename/remove the originals. oolite-constrictor.js is not meant to be a world-script, only a ship script (for the Constrictor) called by oolite-constrictor-hunt-mission.js as needed. So removing "oolite-constrictor.js" (from my world-scripts.plist) suffices to eliminate errors from Latest.log ...but my modified mission files are still ignored unless I remove the originals from Oolite's Scripts folder.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by cim »

When you add it to world-scripts.plist, it will try to load a script file with that name. To do that, it will search through the Scripts directories in order until it finds one. The order is mostly undefined, but it will search Oolite's core Resources folder before it searches AddOns. So your scripts will be ignored because it already finds something with that name first.

The solution then is to rename the script files to something else (switeck-constrictor-hunt-mission.js perhaps) and also make sure that they have a different this.name inside the script file (because this is used to index the script files, and again the loading order is undefined, so if you have two worldscripts with the same this.name only one will survive and you can't guarantee which)

They will then load alongside the core scripts. Having loaded alongside the core scripts, they can then remove and replace the existing event handlers in the core scripts to modify the missions.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Commander McLane »

Switeck asked me to post here as well the answer I PM'd him. It elaborates on what cim wrote. I quote only the relevant part:

If you want to manipulate oolite-constrictor-hunt-mission.js, you have to do it from the outside, not by putting an identically named script in your OXP. In other words: monkeypatching is what is asked for, only that you don't want to amend the event handlers, you want to replace them completely. And you only need to do that for those handlers that you want to actually change.

So, rename your script to something unique (both file name and name tag), and re-organize it thusly (for easiness):

(1) delete all functions and event handlers that are not different from the originals. You don't need to bother with them.

(2) rename the remaining functions and event handlers uniquely. They are not expected to actually run in your script. For instance, guiScreenChanged should become this._constrictorScriptReplaceGuiScreenChanged, and equally for all other functions.

(2) Create a new function this.startUp. It's going to be the only event handler of your script that actually runs. It should look like this:

Code: Select all

this.startUp = function()
{
    worldScripts["oolite-constrictor-hunt"].guiScreenChanged = this._constrictorScriptReplaceGuiScreenChanged;
    worldScripts["oolite-constrictor-hunt"].missionScreenOpportunity = this._constrictorScriptReplaceMissionScreenOpportunity;
    worldScripts["oolite-constrictor-hunt"].shipExitedWitchspace = this._constrictorScriptReplaceShipExitedWitchspace;
    worldScripts["oolite-constrictor-hunt"].shipLaunchedFromStation = this._constrictorScriptReplaceShipLaunchedFromStation;
}
Those are the four handlers you actually need to replace.

(@ Switeck: If it's guaranteed that the script inside Oolite is loaded first—which cim confirms—, you don't need to bother with a timer. So forget that part of my PM.)
Switeck
---- E L I T E ----
---- E L I T E ----
Posts: 2411
Joined: Mon May 31, 2010 11:11 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Switeck »

Commander McLane wrote:
(@ Switeck: If it's guaranteed that the script inside Oolite is loaded first—which cim confirms—, you don't need to bother with a timer. So forget that part of my PM.)
Indeed, I would want my this.startUp to run as soon as possible.

Might another method to get rid of the unwanted (to me!) event handlers be to run this?:
worldScripts["oolite-constrictor-hunt"]._cleanUp

Is Constrictor_morehints.oxp (what got me started on this in the first place) also broken because of the problems I ran into?
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by cim »

Commander McLane wrote:
(@ Switeck: If it's guaranteed that the script inside Oolite is loaded first—which cim confirms—, you don't need to bother with a timer. So forget that part of my PM.)
In more detail, since you may have misunderstood what "the script inside Oolite is loaded first" meant:

During game start:
- all valid locations will be searched for "world-scripts.plist" (starting with Resources/Config, then moving on to AddOns)
- all names in each list will be attempted to be loaded from the Scripts directories. The search for a file with that name will start with Resources/Scripts/ inside Oolite, and then move on to Scripts directories inside AddOns in an undefined order. When it finds one, it stops looking for more with the same name.
- all scripts found by this (a list which is ideally the same length as the number of names) get loaded into a dictionary. The order of this dictionary is of course arbitrary and potentially system-dependent.
- once all scripts are loaded, shortly after this the startUp handler will be run.

During event handler execution:
- each script in the world script dictionary is executed, in arbitrary order. There is no guarantee here that Oolite's core scripts get executed first.

So you may need a timer after all (or, alternatively, since Constrictor Hunt's startUp is self-deleting, call it explicitly to guarantee that it has run)
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Commander McLane »

What I was worried about in my PM was whether all scripts (especially the oolite-constrictor-hunt script) would be loaded when the startUp of Switeck's script is executed, because otherwise worldScripts["oolite-constrictor-hunt"] wouldn't yet be defined, and couldn't be modified.

The oolite-constricor-hunt startUp isn't a problem, because Switeck's OXP doesn't modify it. It also doesn't call any function that would be modified.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by cim »

Commander McLane wrote:
What I was worried about in my PM was whether all scripts (especially the oolite-constrictor-hunt script) would be loaded when the startUp of Switeck's script is executed, because otherwise worldScripts["oolite-constrictor-hunt"] wouldn't yet be defined, and couldn't be modified.
The order is load all scripts, then run all startUp. Code run before startUp can't guarantee that other scripts are defined, of course.
Commander McLane wrote:
The oolite-constricor-hunt startUp isn't a problem, because Switeck's OXP doesn't modify it. It also doesn't call any function that would be modified.
It does sometimes delete a lot of handlers, so execution order can still matter.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Commander McLane »

cim wrote:
Code run before startUp can't guarantee that other scripts are defined, of course.
Out of curiosity: Does such code exist in scripts? I thought startUp would be the first handler to be called.
User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4072
Joined: Fri Nov 11, 2011 6:19 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by cim »

Commander McLane wrote:
cim wrote:
Code run before startUp can't guarantee that other scripts are defined, of course.
Out of curiosity: Does such code exist in scripts? I thought startUp would be the first handler to be called.
startUp is always the first handler that is called.

Therefore, the code which sets the variable this.startUp to contain a function must run before that point (and is run when the script is initially loaded, as it must set this.name which is needed immediately)

Trying to do anything other than define properties on the this object in this code is not a good idea, of course.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by JensAyton »

cim wrote:
When you add it to world-scripts.plist, it will try to load a script file with that name. To do that, it will search through the Scripts directories in order until it finds one. The order is mostly undefined, but it will search Oolite's core Resources folder before it searches AddOns.
Interesting point. This is actually a bug. Other cases which search for a single file without merging iterate over the search paths backwards, so that the last file of a given name in search order is used instead of the first. The bug exists because the world script loading code has its own searching logic, for no obvious reason. (The other effect of the custom search is that world scripts must be in Scripts/, and won’t be found if they’re loose in the OXP.)

The obvious question is, would there be any problem if this was fixed? I can’t think of any offhand.
Switeck
---- E L I T E ----
---- E L I T E ----
Posts: 2411
Joined: Mon May 31, 2010 11:11 pm

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Switeck »

Right now, there's probably not many OXPs that try to modify/replace Oolite's original scripts, and those that do probably use the method described by cim and Commander McLane. (Or they just won't work...unless you're supposed to manually replace the originals.)

If AddOns scripts could consistently override the originals, coding them would be easier. Beyond that, a consistent method will be needed if multiple OXPs try to modify the same script. Use numeric/Alphabetical order instead of first (or last) loaded?

While not scripts, there are some examples of various OXPs trying to replace/use the same OXP component. Anarchies, Black Monks, and Random Hits was using q-mine diffusing satellites if I recall. If either of them tried to add their version and a later OXP wished to replace them with "improved" versions...then a consistent way of overriding them is needed as well.

For me, it's easier to add stuff to Oolite than to remove stuff added by other OXPs.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Modifying core Oolite v1.76.1 release Constrictor Missio

Post by Commander McLane »

Switeck wrote:
While not scripts, there are some examples of various OXPs trying to replace/use the same OXP component. Anarchies, Black Monks, and Random Hits was using q-mine diffusing satellites if I recall. If either of them tried to add their version and a later OXP wished to replace them with "improved" versions...then a consistent way of overriding them is needed as well.
Different OXPs trying to mangle with Oolite's defaults and with each other will always be a problem. Basically it's a systemic problem, and there is nothing that can be done about it, except giving incompatibility warnings where possible, and trusting that the player won't install incompatible OXPs.

One example are replacement ship sets. Each one of them replaces the original set by an improved version. By design it's not meaningful to install two or more replacement ship sets alongside each other. But it is of course technically possible, and we have no control over it. We have to rely on the common sense of each player not to do it. But no code (script or other) exists that could be put in each replacement ship set OXP in order to prevent the player from making that installation mistake.

Another example would be Farsun OXP and (a hypothetical) Nearsun OXP (which would put the suns closer to the planet; not that I would want to do that, but it's technically possible). Again, we have to rely on the player's common sense to figure out that they can't install both of them. (Again, of course technically they can, but they shouldn't be surprised that the sun cannot be farer away and closer by at the same time.)
Post Reply