Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

A fiddly change to the material model:

Prior to r3388, the same specular_color (or specular in 1.73) attribute was used as the overall specular colour when there was no specular map, and modulated the specular map when a specular map was used. This turns out to be a bad idea.

In the following picture, the Griff Cobra has been modified to use the material model with no custom shader. The first version is shown in full shader mode. The second version is in r3385 with shaders off and exactly the same material configuration. The third version is with shaders off and specular_color set to (0.2, 0.2, 0.2) (instead of white), giving roughly the desired effect. The problem is that if I left it that way, the specular highlights would barely be visible with shaders turned on.

Image

As of r3388, specular_color is ignored when shaders are available and a specular map is specified. Instead, a new property specular_modulate_color can be used to modulate the colour of the specular map.

The same basic problem applies to emission_color(née emission) and emission maps: when emission mapping is unsupported (i.e. reduced detail mode, systems which don’t support multitexturing, or versions earlier than r3155) the emission colour is applied to the whole ship instead of modulating the emission map. (This effect isn’t visible above since multitexturing is used in the shaderless shots.) The fix is the same: emission_color is now ignored when an emission map is used, and emission_modulate_color has been added.

The recently-introduced illumination_color has been renamed illumination_modulate_color for consistency.

Here’s the material dictionary for r3388, which works right with or without shaders:

Code: Select all

// Ship:
materials =
{
    "griff_cobra_mk3_mainhull_diffuse_spec.png" =
    {
        diffuse_map = "griff_cobra_mk3_mainhull_diffuse_spec.png";
        normal_map = "griff_cobra_mk3_mainhull_normal.png";
        specular_map = { name = "griff_cobra_mk3_mainhull_diffuse_spec.png"; extract_channel = "a"; };
        specular_color = ( 0.2, 0.2, 0.2 );  // Applies when specular map is not used (no shaders)
        shininess = 5;
        emission_map = { name = "griff_cobra_mk3_mainhull_normal.png"; extract_channel = "a"; };
        emission_modulate_color = (0.9926, 0.9686, 0.7325);
    };
};

// Gun:
materials =
{
    "griff_cobra_mk3_front_gun_diffuse_spec.png" =
    {
        diffuse_map = "griff_cobra_mk3_front_gun_diffuse_spec.png";
        normal_map = "griff_cobra_mk3_front_gun_normal.png";
        specular_map = { name = "griff_cobra_mk3_front_gun_diffuse_spec.png"; extract_channel = "a"; };
        specular_color = ( 0.2, 0.2, 0.2 );
        shininess = 5;
    };
};
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

I forgot to mention a JavaScript change recently: appending “_DAMAGED” do equipment keys in JavaScript is no longer valid. (This does not apply to legacy scripts.) Instead, damage can be manipulated using the equipmentStatus() and setEquipmentStatus() methods. Note that this approach can be used (for the player only) in 1.73 as well.

In 1.74, using a _DAMAGED key with awardEquipment(), removeEquipment(), equipmentStatus() or setEquipmentStatus() will cause an exception.

Using a _DAMAGED key with hasEquipment() will cause a warning in 1.74.0, but work. (Note, however, that using a key without _DAMAGED will not distinguish between damaged and undamaged equipment – for example, if the player has a damaged ECM, player.ship.hasEquipment("EQ_ECM") will return true.) As an implementation detail, canAwardEquipment() will also generate the warning (and return false) when passed a _DAMAGED key.

This warning will be replaced by an exception when deprecated-in-1.74 features are removed. As a general note, this will happen earlier with 1.74 than has previously been the case – either in 1.74.1 or 1.74.2. This is necessary as we get closer to a release and need to lock down the feature set.

Clarification: the above applies as of r3406. Most of the changes were made earlier, but there was a bug in hasEquipment() that made it behave (partially) the old way.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

It has been suggested elsewhere that hasEquipment() should keep its current semantics and be deprecated completely. The new way to test availability would be ship.equipmentStatus("EQ_FOO") != "EQUIPMENT_UNAVAILABLE". This is less handy than hasEquipment(), but will avoid subtle problems with existing OXPs (by replacing them with very obvious ones, which are always easier to fix).

Any great wave of opposition?
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6571
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

I don't know... hasEquipment is so simple, the other one sounds weird. It's like saying "My forum tag isn't not 'another_commander'". Sounds weird, right?
User avatar
Yrol_Denjeah
Dangerous
Dangerous
Posts: 75
Joined: Mon Apr 26, 2010 8:29 am

Post by Yrol_Denjeah »

If i understand this correct, the gamecode gets adapted so it fits
an ( or several ) addon(s)?

That sounds massively wrong and totally contrary to what an addon
is, in my view.

Its like saying "ok, we have here nice spoiler for your car
but you have to go to the carshop and make your hood 10 inches
wider, else our new spoiler wont fit"
(in a cutely insane, electronic, stuttering female voice)
Are you Afraid? What is it you Fear?
The End of your Trivial Existence? Ha!
When the History of my Glory is written,
your Species shall only be a Footnote
to my Magnificence.
I am SHODAN.
User avatar
Thargoid
Thargoid
Thargoid
Posts: 5525
Joined: Thu Jun 12, 2008 6:55 pm

Post by Thargoid »

If equipmentStatus was made read/write with it's current three options all available, then the whole functionality of hasEquipment, setEquipmentStatus and removeEquipment could all be covered by it (and with a little extension awardEquipment too). But then it would be better renamed to equipmentItem or somesuch.

Personally just removing js visibility to _DAMAGED doesn't seem to be fixing anything, only making more work for scripters as we then have to work around it by changing our use of hasEquipment to equipmentStatus to see if a player has certain equipment and it's functional.

Frankly if it were me I'd restore visibility of _DAMAGED to js pending 1.74 (or perhaps 1.75) test release and then take the time and redo the whole damn thing properly including legacy scripting rather than the current proposals which will almost certainly have to be revised further in the future.

Now it's just making work for scripters to no real benefit, as the functionality of using equipmentStatus is exactly the same as being able to check using hasEquipment on equipment and equipment_DAMAGED.

another_commander wrote:
I don't know... hasEquipment is so simple, the other one sounds weird. It's like saying "My forum tag isn't not 'another_commander'". Sounds weird, right?
Yes, but it's now the only way to find truly working equipment that a player has. Currently as it sits today (since R3406) it's no longer possible to use hasEquipment in the role that it has been in past scripting, as it will also pick up damaged equipment. Hence most existing scripts will have OXP equipment continue to work even when it's damaged (contrary to previously when _DAMAGED equipment wasn't picked up unless you specifically looked for it with that ending - now no longer possible).

Hence all such scripts will need to be amended to either use equipmentStatus or some other way to now differentiate between working equipment items and damaged ones - at which point you may as well use equipmentStatus for the whole task.

Personally I class hasEquipment to now be broken and only usable in very specific cases where you don't care if the equipment is broken or not (ie if it's equipment that can't or shouldn't be broken anyway).
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Ahruman wrote:
.... The new way to test availability would be ship.equipmentStatus("EQ_FOO") != "EQUIPMENT_UNAVAILABLE". This is less handy than hasEquipment(), but will avoid subtle problems with existing OXPs (by replacing them with very obvious ones, which are always easier to fix).

Any great wave of opposition?
When hasEquipment("EQ_FOO") now also is true for damaged equipment, it has little use for a script. To know if it can use the equipment it must also check if the equipment is damaged by using equipmentStatus("EQ_FOO"). But than it easier to skip the first test altogether.
I started to re-code an oxp of mine that handles damaged equipment and noticed the rather uselessness of hasEquipment("EQ_FOO"). So its fine with me when it deprecates.
if the player has a damaged ECM, player.ship.hasEquipment("EQ_ECM") will return true.
I think this would be a bad change because it will mean that most (all?) existing equipment will become unbreakable in 1.74. And why should a player upgrade to a new equipment.oxp when he can keep using the old one?
User avatar
Thargoid
Thargoid
Thargoid
Posts: 5525
Joined: Thu Jun 12, 2008 6:55 pm

Post by Thargoid »

Exactly my point - although all my OXPs since this morning's upload now use equipmentStatus as it's also backwardly compatible with 1.73 and a before (at least for player ship tests).
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

another_commander wrote:
I don't know... hasEquipment is so simple, the other one sounds weird. It's like saying "My forum tag isn't not 'another_commander'". Sounds weird, right?
It is, a bit. However, the primary use case for hasEquipment() today is equivalent to checking either equipmentStatus(foo) == "EQUIPMENT_OK" or equipmentStatus(foo) == "EQUIPMENT_DAMAGED". Having hasEquipment() as a shortcut for either makes sense, but it’s not necessary, and it’ll confuse existing code.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

An additional note on migrating from hasEquipment(): equipmentStatus() throws an exception if you use it with an equipment type that doesn’t exist. In the balance, this is a good thing – it helps catch typos. If you actually do want to manipulate equipment that may not exist (e.g., something defined by another OXP), first check for its existence with EquipmentInfo.infoForKey(key) != null.

The documentation has been updated to reflect this.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Starting tonight, nightly builds will have a nominal 1.75 version. All features deprecated in 1.74 will be removed. This will obviously be somewhat inconvenient if you use nightlies to play rather than for testing.

For releases, the simpler deprecated features may be removed in a 1.74.x update. All currently deprecated features will be removed by 1.75.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Implemented a time limiter in JavaScript, primarily to catch infinite loop bugs. In the current trunk, it’s very aggressive: scripts are stopped if they run for more than 0.05 seconds (with bonus time awarded for particularly slow native code, like adding ships or changing graphics settings).

I expect nightlies won’t be very popular for a while after the new release, but anyone who is testing with them should be on the look-out for messages like this:

Code: Select all

[script.javaScript.timeLimit] Script "slowpoke-oxp" ran for 0.05 seconds and has been terminated.
Please report any such messages so we can track them down and identify the bottleneck – in most cases, it will be a problem in Oolite’s handling of the time limit rather than the script itself.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

To clarify: the time limiter is not intended to penalize legitimate scripts (and the limit will be extended to 0.25 seconds after a testing period). If your script hits the limit and it isn’t stuck in an infinite loop or something, your first recourse should be to report it as a bug, not to try to adapt your script.
User avatar
Lestradae
---- E L I T E ----
---- E L I T E ----
Posts: 3095
Joined: Tue Apr 17, 2007 10:30 pm
Location: Vienna, Austria

..

Post by Lestradae »

So ...

* Is 1.75 going to be(come) the next/new stable version, then?
* Are any further deprecations/java scripting changes still to be expected till then or is 1.74 -> 1.75 99% bug-fixing?

Cheers

L
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: ..

Post by JensAyton »

Lestradae wrote:
* Is 1.75 going to be(come) the next/new stable version, then?
The current plan is for 1.75 to be officially a “beta” series with bug fixes only between it and 1.76 stable.
Lestradae wrote:
* Are any further deprecations/java scripting changes still to be expected till then or is 1.74 -> 1.75 99% bug-fixing?
I don’t really have a useful answer to that. I wasn’t expecting any in 1.74.
Post Reply