Modifying core Oolite v1.76.1 release Constrictor Mission...
Moderators: winston, another_commander, Getafix
Modifying core Oolite v1.76.1 release Constrictor Mission...
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.
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?
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.
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?
- Commander McLane
- ---- 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
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.
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.
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
Here's my OXP...
Constrictor Mission MOD.zip (41.77KB)
Download Link
http://www.sendspace.com/file/yqrdi0
Constrictor Mission MOD.zip (41.77KB)
Download Link
http://www.sendspace.com/file/yqrdi0
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
The cause for the errors I was getting was due to putting all this into world-scripts.plist: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.
Code: Select all
(
"oolite-constrictor.js",
"oolite-constrictor-hunt-mission.js",
"oolite-thargoid-plans-mission.js"
)
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
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 (
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.
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.
- Commander McLane
- ---- 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
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,
(2) Create a new function
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.)
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;
}
(@ 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.)
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
Indeed, I would want my this.startUp to run as soon as possible.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.)
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?
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
In more detail, since you may have misunderstood what "the script inside Oolite is loaded first" meant: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.)
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)
- Commander McLane
- ---- 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
What I was worried about in my PM was whether all scripts (especially the oolite-constrictor-hunt script) would be loaded when the
The oolite-constricor-hunt
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.Re: Modifying core Oolite v1.76.1 release Constrictor Missio
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:What I was worried about in my PM was whether all scripts (especially the oolite-constrictor-hunt script) would be loaded when thestartUp
of Switeck's script is executed, because otherwiseworldScripts["oolite-constrictor-hunt"]
wouldn't yet be defined, and couldn't be modified.
It does sometimes delete a lot of handlers, so execution order can still matter.Commander McLane wrote:The oolite-constricor-huntstartUp
isn't a problem, because Switeck's OXP doesn't modify it. It also doesn't call any function that would be modified.
- Commander McLane
- ---- 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
Out of curiosity: Does such code exist in scripts? I thoughtcim wrote:Code run before startUp can't guarantee that other scripts are defined, of course.
startUp
would be the first handler to be called.Re: Modifying core Oolite v1.76.1 release Constrictor Missio
Commander McLane wrote:Out of curiosity: Does such code exist in scripts? I thoughtcim wrote:Code run before startUp can't guarantee that other scripts are defined, of course.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.- JensAyton
- 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
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.)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.
The obvious question is, would there be any problem if this was fixed? I can’t think of any offhand.
E-mail: [email protected]
Re: Modifying core Oolite v1.76.1 release Constrictor Missio
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.
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.
- Commander McLane
- ---- 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
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.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.
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.)