Progress

[Thargoid]

For "rapid-fire" launch tubes in case of attack to get defenders out fast, it may be better simulating it with script and a dummy dock. A quasi-example of this is in Liners, when the Emerald arrives and can launch multiple ferry shuttles at once.

[Shipbuilder]

I like the idea of the rapid fire launch tubes.

It would also be interesting to look in to the 2 separate docking bay issues that have been discussed in the past.

[JensAyton]

Subentity dictionaries can now have 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.

Example:

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;
        };
    };
}

If you spawn a my_super_entity, its ship.subEntities[0].scriptInfo will be:

Code: Select all

{
    bar: 42,
    foo: "Fred",
    my_tag: "this is important"
}

[cim]

A change to 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.

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 because 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.

There's also a 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.

A few other small changes:
- a bunch of wormhole bugs fixed, including the "ghost wormhole" bug most often spotted around zero-distance doubles
- bounty award rules now the same for the player and NPCs, where possible
- traders will dump cargo for hostile NPCs, not just the player
- offenders won't call for help from bounty hunters or the police.
- new world script event "dayChanged(newday)" fires at 00:00:00 (or possibly a bit later, if the clock is adjusting)

[Cody]

... a bunch of wormhole bugs fixed, including the "ghost wormhole" bug most often spotted around zero-distance doubles

Oh good!

[Commander McLane]

<a bunch of code changes over the last weeks/months; thus becoming deeper and deeper involved in Oolite development>

Give the man a cookie!

And a promotion from his current 'Commodore' title seems to be in order, if I may humbly suggest so.

[Fatleaf]

And a promotion from his current 'Commodore' title seems to be in order, if I may humbly suggest so.

Indeed! Hip Hip Huzzah !

[Eric Walch]

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 because 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.

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 current 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.

[Fatleaf]

I cant remember any oxp setting more than one system at once

Commander McLane's Anarchies with the amnesty offer sets two system's at once.

[cim]

I cant remember any oxp setting more than one system at once

Commander McLane's Anarchies with the amnesty offer sets two system's at once.

Lovecats unmarks two at once a few times. Though it does that from a ship script so would need adjusting anyway.

On the other hand, Feudal States already expects it to be working in the way that 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.

The parameter is only a convenience, of course, so if the code is to be rewritten anyway:

Code: Select all

// in world script
this._unmarkSystem = function(id) {
  mission.unmarkSystem(id);
}
// in ship script
this.shipDied = function() {
  worldScripts.foo._unmarkSystem(system.ID);
}

I'd rather not change the meaning of markSystem to break any more code than the unavoidable ship script case. mission.markSystemAs(id,script) is a possibility.

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)

[Switeck]

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)

What about using a numeric array for the id locations followed by a string? Like this:
mission.markSystem([12,17,213],"other world script");

[Eric Walch]

What about using a numeric array for the id locations followed by a string? Like this:
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.

[Commander McLane]

… and congratulations to your promotion, cim!

[Smivs]

… and congratulations to your promotion, cim!

Indeed. And very well deserved

[Fatleaf]

… and congratulations to your promotion, cim!

Indeed. And very well deserved

Well said that flying disc thing and gourd! Congratulations Cim.

So... where is the party?