OXPs not working with newest build?

[davethebrave]

I just downloaded Oolite for the first time in a long time, and discovered that some core OXPs don't work with the newest build! When I start up Oolite with Anarchies, the Illegal Goods tweak, Explorer's Club, Liners, Snoopers, the Cabal Common Library, CCL Material Finder, OXP Config, BGS, Star Jelly, Taxi Galactica, Rescue Stations and New Cargoes, each one of these gives me the message: "(insert OXP name here) is incompatible with version 1.75.3 of Oolite."

Really? CCL and OXP Config?! BGS?! How is that even possible, those are core OXPs as far as I'm concerned! Is there something that might be wrong on my end maybe?

Oh, first time poster! Hi!

[another_commander]

Hi and welcome.

Oolite's latest version is 1.76.1, not 1.75.3. Try using that. It is available from www.oolite.org.

[davethebrave]

Hi and welcome.

Oolite's latest version is 1.76.1, not 1.75.3. Try using that. It is available from http://www.oolite.org.

Ah, that's what I get for grabbing it from the Ubuntu Software Center. lol, thanks!

[Cody]

<chortles, having been ninja'd by the Admiral> Welcome aboard!

[Smivs]

Hi davethebrave, and welcome.
The silly thing is some of those would work with 1.75.3, but the convention is to include within the OXP a 'requires.plist', a small file in the OXP which determines which version it should be used with. Generally the OXP author will list the version it was developed on or most recently tested on, and because the authors always tend to use the most current version, that is the one that is specified.
Lets hope the Ubuntu Software Center is updated soon

[cim]

The silly thing is some of those would work with 1.75.3, but the convention is to include within the OXP a 'requires.plist', a small file in the OXP which determines which version it should be used with. Generally the OXP author will list the version it was developed on or most recently tested on, and because the authors always tend to use the most current version, that is the one that is specified.

The only functional differences between 1.75.3 and 1.76.1 should be which bugs are included, but some of those bugs were pretty big.

Lets hope the Ubuntu Software Center is updated soon

They have 1.76.1 packaged up for Quantal, which will be out some time in October.

[Wildeblood]

The only functional differences between 1.75.3 and 1.76.1 should be which bugs are included, but some of those bugs were pretty big.

And some are still included. A case in point is this one, which I re-discovered this week.

[Kaks]

What do you mean? Afaik, creating a hud without a scanner in 1.76.1 doesn't cause the problems CSOTB mentioned - or any specific problem, apart from causing the player to fly blind, as presumably intended.

In 1.75.3 on the other hand...

[Wildeblood]

A_C's fix scans the HUD definition to see if a dial including :drawScanner is defined, not if it's actually drawn. Put something like this into a HUD:-

Code: Select all

// Red scanner
{ alpha = 1.0; height = 74; y = 55; y_origin = -1; width = 296; selector = "drawScanner:"; x = 0;
  rgb_color = (1.0, 0.0, 0.0); equipment_required = "EQ_WA_SCANNER_ALERT_3"; },

- and it will pass the check and the transparent scanner won't be drawn, but if the ship doesn't have the equipment the bug is revealed. Myself, I don't have a problem with this bug per se - I thought the story was that mass locking was a safety feature, not a law of ooniversal physics, so flying into things at ludicrous speed seems reasonable to me if you accept the idea that ludicrous speed exists in-game (I don't) and isn't just a cheat button (which it is).

The problem is that Oolite apparently uses the in-game scanner in its calculation of player.alertCondition and alertConditionChanged for scripting, leading scripts that use them to yield unpredictable results if the scanner isn't drawn. And in cases where replacing the missing scanner depends on alertConditionChanged, an unrecoverable trap can sometimes form.

[Kaks]

I see! Tricky envelope pushers!

As A_C pointed out way back then, that part of the code is quite ancient, and messing with at least 5 years' worth of implicit assumptions is bound to cause 'some' disrupion once we decouple the drawing of the scanner from what the scanner actually checks for.


That said, I'm a sucker for refactoring, and as they say, there's no time like the present!
There might well be some related exciting new breakages in trunk within the next week or so...

[Kaks]

Hmm, it was a bit of a pain, but seemingly not as bad as I anticipated. The refactoring isn't quite complete, I'd prefer to test that change a bit more thoroughly before making any further changes. In other words, it seemed a bit too easy...

In any case, as of rev5319 mass lock calculations should work fine, regardless of the scanner being displayed or not. Please do test the new code and let us know if there are any more bugs with that part of the code!