Page 1 of 1

Update to Asteroid Storm OXP - Bug Fix

Posted: Thu Jul 17, 2008 8:39 am
by LittleBear
Version 3.46 is an updated version which fixes a bug. In the previous version only the Large Asteroids had a role. This meant that only these appeared in game (oops)! On the old version, only one new type of asteroid was added even though the OXP has the graphics and models to add 12 different types. The new version now works as intended and you will see a greater variety to the shapes and sizes of all asteroids in the Ooniverse. Only the graphics are changed, rocks are still rocks! With this version all of Charlie's asteroids now appear, rather than just one of them.

If you follow the link on my signature it'll take you to a Wiki Page where you can download the new version.

Posted: Thu Jul 17, 2008 8:59 pm
by Rimbaud
That explains it. I removed this oxp as I kept having loads of the same large asteroid (attractive though it was)

Posted: Sat Aug 02, 2008 9:02 am
by Cmdr James
EDIT: I no longer think this is an AsteroidStorm problem, Im pretty sure something isnt right in the trunk oolite-global-prefix.js.

When starting oolite (trunk) with AsteroidStorm oxp 3.46 installed (I know the output says 3,43, I checked, and that is the text in 3.46), I get the following:

Code: Select all

Warning: Player.fuelLeakRate is deprecated, use Player.ship.fuelLeakRate instead.
    Active script: "AsteroidStorm" 3.43
Warning (strict mode): reference to undefined property this[subName]
    Active script: "AsteroidStorm" 3.43
    oolite-global-prefix.js, line 138:
    		return this[subName][propName];
Exception: TypeError: this[subName] has no properties
    Active script: "AsteroidStorm" 3.43
    oolite-global-prefix.js, line 138:
    		return this[subName][propName];
I cannot find a reference to fuelLeaks anywhere in it, could you point me at the place where this is happening, so I can take a look? ( I guess it shoulnt be changed, as the new syntax probably isnt valid in 1.65, but Id like to fix it for my installed version anyway).

Re: Update to Asteroid Storm OXP - Bug Fix

Posted: Sat Aug 02, 2008 6:03 pm
by ovvldc
LittleBear wrote:
If you follow the link on my signature it'll take you to a Wiki Page where you can download the new version.
I'd really like to, but neither your user page, nor the Asteroid Storm description page had any download links on it when I opened them.. :?

Best wishes,
Oscar

Posted: Sat Aug 02, 2008 6:12 pm
by JensAyton
Gosh, this JavaScript stuff causes some interesting bugs, doesn’t it?

On an unrelated note, AsteroidStorm.js uses LogWithClass(), which has been renamed log() and won’t be available after 1.72, and player.call("playSound:", foo) which should be replaced with sound objects for 1.71 and later.

Re: Update to Asteroid Storm OXP - Bug Fix

Posted: Sat Aug 02, 2008 6:26 pm
by Cmdr James
ovvldc wrote:
LittleBear wrote:
If you follow the link on my signature it'll take you to a Wiki Page where you can download the new version.
I'd really like to, but neither your user page, nor the Asteroid Storm description page had any download links on it when I opened them.. :?

Best wishes,
Oscar
His userpage links to the wiki page, which contains this link http://www.box.net/shared/8awv25rksk

I downloaded it from there earlier today, the link was fine then.

Posted: Sat Aug 02, 2008 7:14 pm
by JensAyton
I have identified the problem in AsteroidStorm. I had thought I’d fixed this problem before, but I think I just pushed it to the back of my mind. It’s a combination of a bug in the way JS objects are set up in Oolite, and a bug in AsteroidStorm.js. The AsteroidStorm bug is this:

Code: Select all

for (var i in this.badOolite) // line 31
This code iterates over all properties of an object (in arbitrary order), except ones hidden by the host application. An array can have properties other than indices. The bug in Oolite causes properties intended only for certain objects to be added to all objects.

The fix in AsteroidStorm.js is to replace the above line with:

Code: Select all

for (let i = 0; i < badOolite.length; ++i)
The fix in Oolite is rather more complicated, but I can change the prefix script to avoid triggering it in this case.

Posted: Mon Aug 18, 2008 9:39 am
by tinker
While checking all my installed OXP's for case problems I noticed that astorm08.dat and astorm10.dat both use astorm08.png and nothing uses astorm10,png.
Could be it was meant to be or just a slip up - doesn't stop it working, just thought I'd let you know.

More important perhaps is the error messages I get in stderr when running with this oxp loaded.

Code: Select all

2008-08-18 13:43:34.014 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.missionScreenTextKey is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.imageFileName is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.musicFileName is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.choicesKey is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.instructionsKey is deprecated and read-only.

Posted: Tue Sep 02, 2008 11:15 pm
by CmdrLUke
I can't get the mission to trigger -- I think I'm in the right system, according to the hint, I've seen tons of asteroids on the way to the station including a huge one, I get to the station, but no mission starts.....?

I'm "competent", which should be enough for the mission, according to the readme...

I'm running AsteroidsStorm 346

edti: never mind, I'm as blind as a bat again. Too much oolite in a row this holiday weekend :) I was in the wrong system.

Posted: Tue Oct 21, 2008 2:56 pm
by JensAyton
Fun bug in Asteroid Storm: the “stationbits” pseudo-ship has the roles string “station-alloy alloy(0.1)”. Any roles string that contains the substring “station” marks the ship as a station, even if it’s not a whole word. This means that 1 out of every 21 alloys generated (assuming no other OXP-defined alloys) will be a station and respond to auto-docking requests. They can also potentially become the main station if the real main station is blown up.

Unfortunately, there is no way to indicate that an entity with “station” or “carrier” in its role string is not a station/carrier. For 1.72, I’m changing it so that isCarrier = no; works in that case.

Also, insert general rant about overly generic names here.

Posted: Sat Oct 25, 2008 9:34 am
by Commander McLane
Ahruman wrote:
Also, insert general rant about overly generic names here.
Yeah, the name-thing again... :wink: