script_info entries. These are merged with any script_info in the subentity’s shipdata entry’s script_info, with the subentity dictionary taking precedence. The obvious use case is for tagging subentities of interest to a script, instead of relying on indices.Code: Select all
{
"my_super_entity" =
{
// Other shipdata stuff goes here…
subentities =
(
{
subentity_key = "my_sub_entity";
position = (100, 0, 0);
script_info =
{
my_tag = "this is important";
bar = 42;
};
}
);
};
"my_sub_entity" =
{
// Other shipdata stuff goes here…
script_info =
{
foo = "Fred";
bar = 0;
};
};
}my_super_entity, its ship.subEntities[0].scriptInfo will be:
Code: Select all
{
bar: 42,
foo: "Fred",
my_tag: "this is important"
}mission.markSystem/mission.unmarkSystem - this now has a separate "marked systems" list for each script. So if I mark a system, and then you mark the same system, and I then unmark it, it stays marked until you also unmark it. This works in a similar way to mission.setInstructions.markSystem and unmarkSystem take a list of system IDs as parameters, it's not possible to do what setInstructions does and add a worldscript key as an extra parameter.mission.markedSystems function which returns an object with properties named after the world scripts currently marking systems. Each of those properties is an array of system IDs.dayChanged(newday)" fires at 00:00:00 (or possibly a bit later, if the clock is adjusting)Oh good!cim wrote:... a bunch of wormhole bugs fixed, including the "ghost wormhole" bug most often spotted around zero-distance doubles
cim wrote:<a bunch of code changes over the last weeks/months; thus becoming deeper and deeper involved in Oolite development>
Indeed! Hip Hip Huzzah !Commander McLane wrote:And a promotion from his current 'Commodore' title seems to be in order, if I may humbly suggest so.
That could potentially break several of my missions. In the case of a target to be killed, I normally unmarked the systems and set new systems in the ship script of the target. I understand the problem of a unknown number of parameters in the currentcim wrote:If you maintain an OXP which intentionally marks a system in one script and unmarks it in another, you may have to rewrite that bit of code. Unfortunately becausemarkSystemandunmarkSystemtake a list of system IDs as parameters, it's not possible to do whatsetInstructionsdoes and add a worldscript key as an extra parameter.
markSystem and unmarkSystem methods. But maybe we should limit those to one system instead and add the mission as second parameter, because it is very pleasant to be able to set it from within any script. I cant remember any oxp setting more than one system at once (I have a vague memory though, that I used it in one oxp). You can always rename the current code to markSystems and unmarkSystems as the method that still uses a list of systems.Commander McLane's Anarchies with the amnesty offer sets two system's at once.Eric Walch wrote:I cant remember any oxp setting more than one system at once
Lovecats unmarks two at once a few times. Though it does that from a ship script so would need adjusting anyway.Fatleaf wrote:Commander McLane's Anarchies with the amnesty offer sets two system's at once.Eric Walch wrote:I cant remember any oxp setting more than one system at once
setInstructions does, with the option to take an array to set more than one system at once. It works, too, because of how type conversion works in the JS libraries.Code: Select all
// in world script
this._unmarkSystem = function(id) {
mission.unmarkSystem(id);
}
// in ship script
this.shipDied = function() {
worldScripts.foo._unmarkSystem(system.ID);
}mission.markSystemAs(id,script) is a possibility.mission.markSystem(12,17,213,"other world script");. I don't like it at all syntactically, but it would work as expected in both 1.76 and 1.77 (in 1.76, the final parameter converts to NaN and is ignored; in 1.77 I could make it so that the conversion of the last parameter to NaN would make it try again as a string)What about using a numeric array for the id locations followed by a string? Like this:cim wrote:Looking up how the JS to native type conversion works, there is another possibility:mission.markSystem(12,17,213,"other world script");. I don't like it at all syntactically, but it would work as expected in both 1.76 and 1.77 (in 1.76, the final parameter converts to NaN and is ignored; in 1.77 I could make it so that the conversion of the last parameter to NaN would make it try again as a string)
mission.markSystem([12,17,213],"other world script");That would also require a rewrite of existing oxps. The above suggestion of Cim above to call a function in the worldScript is the best because it already works in current Oolite. It allows to write code that works now and in trunk.Switeck wrote:What about using a numeric array for the id locations followed by a string? Like this:
mission.markSystem([12,17,213],"other world script");
Indeed. And very well deservedCommander McLane wrote:… and congratulations to your promotion, cim!
Well said that flying disc thing and gourd! Congratulations Cim.Smivs wrote:Indeed. And very well deservedCommander McLane wrote:… and congratulations to your promotion, cim!