Progress

[JensAyton]

Minor JavaScript changes:

• Entity.position and Entity.orientation are now read-write, and Entity.setPosition() and Entity.setOrientation() are therefore deprecated as of 1.73. (Note: deprecations in 1.73 may be removed in 1.74 already, depending on how the Grand Plan advances.) Statements like ship.position.x += 100 still don’t work as expected, but making position read-only didn’t actually affect that, so what’s the point?
• Entity.ID and Entity.entityWithID() are now deprecated, along with the ability to pass an ID instead of an Entity object. I know of no good reason to be using any of these. (Note: this does not affect System.ID.)
• Added toSource() method to Vector and Quaternion. This function is similar to toString() returns a string that can be used as JavaScript code – for example, “Quaternion(-0.470127, 0.391883, -0.497289, 0.614908)” instead of “(-0.470127 + 0.391883i - 0.497289j + 0.614908k)”.
• Vectors and quaternions can now be constructed with syntax like Vector(x, y, z) instead of new Vector(x, y, z). This is not necessarily better in general, but it increases flexibility – specifically, it allows the use of apply() as seen at the bottom of oolite-global-prefix.js. Feel free to ignore this bullet point. :-)

[JensAyton]

AI tweaks:

• New exitAIWithMessage: method is a generalization of exitAI. exitAI is now an alias for exitAIWithMessage: RESTARTED.
• New messageSelf: method queues a message to be handled next AI update.
• JS Ship.exitAI() now takes an optional message argument; if none, "RESTARTED" is assumed.

[JensAyton]

Subentities may now be declared as dictionaries instead of magic strings. This improves readability and flexibility (i.e. it makes it easier to add new attributes).

A subentity dictionary may have any of the following types, specified by the “type” entry: “standard”, “flasher” or “ball_turret”. No type entry implies “standard”. All subentities have an optional “position” entry, which is a vector specifier – a string with three space-separated numbers, or an array with three numbers. (The default is (0, 0, 0).)

Standard and ball-turret subentities are required to have a “subentity_key” entry, whose value is a ship key. They also have optional orientation (quaternion specifier – string with four space-separated numbers or array with four numbers; default is the identity quaternion).

Standard subentities may have an “is_dock” entry whose value is a boolean. This replaces the use of “dock” in the subentity key when using dictionaries to specify subentities; old-style subentities work as before.

Ball-turret subentities may have a “fire_rate” entry, whose value is a floating-point number greater than or equal to 0.25 (default: 0.5).

Flasher subentities have the following attributes, other than type and position: size, frequency and phase, which correspond to parts of the old-style strings (defaults 8, 2 and 0); “colors”, an array of colour specifiers, or “color”, a single colour specifier (support for multiple colours is not yet implemented); and “initially_on” (boolean, default false). As with lasers, flasher colours must be “sufficiently bright”.

Related to this change, the script method initialiseTurret no longer does anything when executed. However, its presence in setup_actions (and only in setup_actions, and not in any conditions) is used to recognise a ball turret when handling old-style sub-entities.

Here is the full subentities list for the Coriolis in the new format.

Code: Select all

{
    subentities =
    (
        {
            subentity_key = "dock-flat";
            orientation = ( 1, 0, 0, 1);    // rotated 90 degrees
            position = ( 0, 0, 500 );
            is_dock = true;
        },
        {
            subentity_key = "arc-detail";
        },
        {
            subentity_key = "arc-detail";
            orientation = ( 1, 0, 0, 1 );
        },
        {
            subentity_key = "arc-detail";
            orientation = ( 0, 0, 0, 1 );
        },
        {
            subentity_key = "arc-detail";
            orientation = ( 1, 0, 0, -1 );
        },
        
        {
            type = flasher;
            size = 12;
            color = { hue = 60; };
            frequency = 1;
            phase = -1;
            position = ( 0, 92, 475 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 75; };
            frequency = 1;
            phase = -1.2;
            position = ( 0, 92, 425 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 90; };
            frequency = 1;
            phase = -1.2;
            position = ( 0, 92, 375 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 105; };
            frequency = 1;
            phase = -1.6;
            position = ( 0, 92, 325 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 120; };
            frequency = 1;
            phase = -1.8;
            position = ( 0, 92, 275 );
        },
        
        {
            type = flasher;
            size = 12;
            color = { hue = 60; };
            frequency = 1;
            phase = -1;
            position = ( 0, -92, 475 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 75; };
            frequency = 1;
            phase = -1.2;
            position = ( 0, -92, 425 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 90; };
            frequency = 1;
            phase = -1.2;
            position = ( 0, -92, 375 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 105; };
            frequency = 1;
            phase = -1.6;
            position = ( 0, -92, 325 );
        },
        {
            type = flasher;
            size = 12;
            color = { hue = 120; };
            frequency = 1;
            phase = -1.8;
            position = ( 0, -92, 275 );
        },
        
        {
            type = flasher;
            size = 12;
            color = "orangeColor";
            frequency = 1;
            phase = 0.5;
            position = ( 0, -16, 252 );
        },
        {
            type = flasher;
            size = 12;
            color = "orangeColor";
            frequency = 1;
            phase = 0.5;
            position = ( 0, 16, 252 );
        },
        {
            type = flasher;
            size = 12;
            color = "orangeColor";
            frequency = 1;
            phase = 0;
            position = ( 16, 0, 252 );
        },
        {
            type = flasher;
            size = 12;
            color = "orangeColor";
            frequency = 1;
            phase = 0;
            position = ( -16, 0, 252 );
        }
    );
}

[Commander McLane]

Here is the full subentities list for the Coriolis in the new format.

Code: Select all

{
    subentities =
    (
        {
            subentity_key = "dock-flat";
            orientation = ( 1, 0, 0, 1);    // rotated 90 degrees
            position = ( 0, 0, 500 );
            is_dock = true;
        },
        .
        .
        .
}

Sorry if I'm missing something obvious here. But why a rotated "dock-flat" instead of an unrotated "dock"?

[JensAyton]

Sorry if I'm missing something obvious here. But why a rotated "dock-flat" instead of an unrotated "dock"? :?:

You expect me to know things like that? That’s what’s there in the old format. :-)

[Commander McLane]

Sorry if I'm missing something obvious here. But why a rotated "dock-flat" instead of an unrotated "dock"?

You expect me to know things like that? That’s what’s there in the old format.

Don't know what I can expect of you. You tend to surprise me.

Anyway, it strikes me as kind of, errm, odd, to have two different dock models, one horizontal and one vertical, and then to use only one of them and rotate it to the other orientation. Seems like a relic to me.

[JensAyton]

“Relic” sounds right; I suspect this changed around the time the “redux” ships were made (or when dock models started being used to detect the docking position instead of dock-radius etc), and the old “dock” was kept around for backwards-compatibility with any OXPs that used it.

[Commander McLane]

Just out of curiosity: Does this mean that you would advise against using the old "dock"?

[JensAyton]

I don’t see any reason to get rid of it. In future released there will be a very slight memory overhead to using two different interchangeable models, but it’s not enough to be concerned about.

[Thargoid]

Minor JavaScript changes:

• Entity.position and Entity.orientation are now read-write, and Entity.setPosition() and Entity.setOrientation() are therefore deprecated as of 1.73. (Note: deprecations in 1.73 may be removed in 1.74 already, depending on how the Grand Plan advances.) Statements like ship.position.x += 100 still don’t work as expected, but making position read-only didn’t actually affect that, so what’s the point?

Before this is done, can I ask if there is a simple trick to make scripts compatible with both versions (after the depreciated one is gone)? I'm thinking like the one for player / player.ship, as orientation and position are a little more complex as they're functions with parameters.

If not then it's going to make producing scripts compatible with both very complicated, and we're going to end up with multiple versions of OXPs for pre/post depreciated change compatibility. Which is not a nice thought for me at least.

I can understand the thoughts behind doing this, but in tidying things up it may make OXP scripting with backward/forwards compatibility difficult both ways. I'm not sure this one is quite such a minor change as it sounds.

[JensAyton]

Before this is done, can I ask if there is a simple trick to make scripts compatible with both versions (after the depreciated one is gone)? I'm thinking like the one for player / player.ship, as orientation and position are a little more complex as they're functions with parameters.

Don’t. Once 1.73 is released, update to the new syntax and ignore 1.72 compatibility. Backwards compatibility with earlier test versions is not worth investing time in.

However, given that you’ll probably ignore this advice again, the least painful way to do it would be something like this:

Code: Select all

if (0 < oolite.compareVersion("1.73"))
{
    self.setEntityPosition = function (entity, position)
    {
        entity.setPosition(position);
    }
}
else
{
    self.setEntityPosition = function (entity, position)
    {
        entity.position = position;
    }
}

[JensAyton]

As people may have guessed, I haven’t had much enthusiasm for Oolite recently. Waiting another two years for a release would be silly, so I hereby propose an alternative release schedule:

• Abandon new mesh code. This means no unlimited vertex and face counts (but tangent support, and thus normal mapping, will be in).
• Fix lighting for shaders in old mesh code. No additional lighting features.
• Release 1.73 as essentially feature-complete.
• Fix loads of bugs, hopefully including subentity collision stuff.
• Release MNSR as 1.74 or 1.75.

[DaddyHoggy]

No objections from me - your continued support and long term enthusiasm is as equally important (to me) - so if this is good for you and the rest of the devs then I say go for it!

[Ark]

From the original plan here are the features that are not done yet:

Frustum culling (not a mandatory feature anymore – after the release of 1.72)
Camera code (well!!! I can live without it )

One the other hand we have dozens of new features that were not on the original oolite upgrade plan like:
Oolite localization
Docking clearance
Wormhole scanner
Multy nebula skies
and more that I can not remember right now.

So if we can see the big picture the NMSR is going to have far more new features that were not in the original oolite upgrade plan that those that you didn’t manage to implement. Anybody with a common sense should be happy and own a great dept of gratitude to you and the dev team for everything you have done for oolite (so far )

In simpler words no problems Ahruman

[ovvldc]

Waiting another two years for a release would be silly, so I hereby propose an alternative release schedule

Sounds very good to me. In a way, I do not mind limited vertices, because it brings out the best in artists who make creative models with few resources.

Best wishes,
Oscar