Progress

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

[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]

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?

[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"

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

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

[Eric Walch]

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

[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).

[JensAyton]

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.

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

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

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

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

[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

[JensAyton]

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

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

[Commander McLane]

Some clarification, please, as I am in the process of understanding all the 1.74-changes and adapting my OXPs:

Am I right that missionScreenOpportunity should become the handler of choice for calling mission screens? Practically: Is it advisable to move all calls of mission screens from shipDockedWithStation, missionScreenEnded, reportScreenEnded, and missionChoiceWasReset (which is where they mainly reside in my scripts now) into missionScreenOpportunity?

For instance, in the script of Cataclysm, can I just substitute

Code: Select all

this.shipDockedWithStation = function()
{
	this.missionScreens();
}

this.missionScreenEnded = function()
{
	if(!player.ship.docked) return;
	if(missionVariables.cataclysm_hivemission == "WAIT_A_MINUTE") 
		this.waitTimer = new Timer(this, this.stopWaiting, 45);
	this.missionScreens();
}

this.missionChoiceWasReset = function()
{
	if(!player.ship.docked) return;
	this.missionScreens();
}

with

Code: Select all

this.missionScreenEnded = function()
{
	if(missionVariables.cataclysm_hivemission == "WAIT_A_MINUTE") 
		this.waitTimer = new Timer(this, this.stopWaiting, 45);
}

this.missionScreenOpportunity = function()
{
	if(!player.ship.docked) return;
	this.missionScreens();
}

to the same effect? Can I even drop the if(!player.ship.docked) return;, which is my insurance that the player hasn't pressed F1 to exit the previous mission screen, because missionScreenOpportunity wouldn't fire in that case?

An ahrumalaconic YES would be very much appreciated.