Oolite Bulletins

I replaced most low resolution maps by 256x256 maps. The asteroids now have a more pronounced texture. I currently am working on version 3.56b10 (downloadable in my signature below)

It will probably get some minor adjustments before it is released as a new version 4.0 but as Oolite 1.74 is just released and my older official releases will stop working with this new Oolite release, I decided to release it as it is.

Edit: 3.56b10 has become the final 4.0 release.

I just updated the oxp to Asteroid Storm v 4.02

The only change is the mapping of texture around the asteroids. It used to be one texture on the front and the same texture mirrored, on the back.

I now realised that Oolite supports repeating textures and all my textures were in fact capable of using seamless in a repeating way. For most asteroids I now used a 3x3 map of the texture. Meaning it repeats 3 times, but because of changing distortion over the surface, the repeating patterns are very difficult to notice. But the benefits are great: The resolution is now 3 times higher than before while using the same maps.

hej,
AS 4.02 + Oolite 1.76 stable, Win XP, OpenGL 1.5.3

I sometimes have a problem with the Large Asteroids, but am not sure if it is a problem of these Large Asteroids/ Asteroid Storm only, or not also a problem of Oolite itself seriously choking on such situation.

The problem is that sometimes the Large Asteroids are placed so, that they rotate through another asteroid or boulder, or really bad : the rock hermit.
This does not look good.

But more seriously, the rotating through the rock hermit has Oolite choking, displaying a framerate of 4 fps ("usual" framerates for me would be : 20-30 fps), but I think it is much worse - the framerate calculating not being accurate itself at such low framerates ?

Shooting the culprit usually results in framerate recovery.
But getting to where I can get rid of the bugging asteroid may be a chore, or even impossible with evil folks around, @ 4 fps.

I do not know what to think of this - even if Asteroid Storm, or Oolite's own method of populating the Ooniverse with asteroids would change to avoid this, there still might be an issue with "things" wanting to occupy the same space (at least visually) bringing Oolite onto its knees ?



nevermind the framerate displayed in this screenshot, must have been a mini-spike towards "normality".

It's not the asteroids I'd be worried about if I were you

In shipdata.plist of this OXP:The "has_ecm" = NO; should probably be "has_ecm" = no; to avoid possible sign issues...even though it probably defaults to no ECM anyway.
(I think unlike filename CaPs issues, NO and no are equal to Oolite, but pointing it out because sign issues are brutally important elsewhere at least.)

Switeck wrote:

should probably be "has_ecm" = no;

Not really needed, even a mixed casing like No or nO would work. See also the boolean definition on the wiki.
See also the discussion about the boolean here

So, any casing is explicit ignored when evaluating. That also includes OFF, FALSE or even fAlSe as working syntax if you want to confuse others
Even the empty string "" should work as false.

EDIT: added the info about uppercase also working to the wiki.

Updated Asteroid storm to version 4.03.

It is a very minor update, but needed to play the mission after Oolite 1.76. Problem was the missing Energy Bomb in future Oolite versions. The generated error on awarding this bomb at the missions end, made that the final screen was displayed over and over again. No need to update if you only keep the oxp for its ambiance.

Testing was a bit difficult as I also had the Hotrods.oxp installed and for some reason the tigers insisted every time in trying to kill me instead of helping to kill the doomsday asteroid.

Finally I killed the doomsday asteroid before the tigers killed me.

Today, by accident I was reminded that Asteroid Storm not only brings more variety to the asteroids, but also has an (awesome) mission. That one was big fun, although I (and the other ships) failed to save the station, we saved the planet (at least that's what the news said).

Since it was so cool, I was wondering if it would be possible to make the mission occur more than once, for example randomly (with a low probability - perhaps 1%?). I really liked how the asteroids detonated on the planet's surface.

Now I have another crazy idea: how about making "asteroid storms" sometimes randomly appear somewhere in the system? Navigation would become more dangerous and challenging through that... what do you think?

Oh, and I noticed that after the asteroid had destroyed the main station, all other stations (Rock Hermits, RRS, Taxi... whatever) had vanished, too. Is this a bug?

It would be easy to do in code to make the Asteroid Storm Mission happen with a low probability at any station. The trouble would be if failed it then takes out the Main Station, which other OXPs may expect to be there in order for their missions to run. So it was coded as a one off at just one system.

Taking out all other stations if the Main Station is destroyed by the asteroid strike isn't a bug but more a Necessary Weasel (http://tvtropes.org/pmwiki/pmwiki.php/M ... saryWeasel). If all stations are not removed, any OXP station left is promoted to the Main Station, so the only way to leave a system with no main station is to remove all stations.

How about make a "lesser" form of it at planets with rings?
...part of the innermost ring spiraling into the planet.
Not enough to be a major disaster, but still a pretty light show.

GGShinobi wrote:

Since it was so cool, I was wondering if it would be possible to make the mission occur more than once, for example randomly (with a low probability - perhaps 1%?). I really liked how the asteroids detonated on the planet's surface.

In the original version with Oolite 1.65, it was maybe doable. You could simply define the role for the main-station to a non-existing role and the save file would make that the station stayed destroyed for that mission.
In current Oolite, a replacement station will be added if the stored role does not exist. That means you have to add code for every system that has a destroyed station to actively remove the stations in the system on every entry of that system. And as Little Bear writes, it must be all stations in those systems to prevent an other station from becoming main station.

The only thing I have been pondering is to give some other systems the asteroid bombardment without the mission. When the word "asteroid storm" in the system description would have been given to some systems, like the word 'deadly vulcanos", I would have added the asteroid bombardment to those systems. But, alas, it was a manually altered system description.

The current form of asteroids hitting the surface was an idea from Micha when I remember well. Originally they flew in the direction of the station, like the station was an asteroid magnet. Looked a bit wrong but without JS there was no better way. In the current version, the asteroids are added in deep space, in an area of about 10 times the scanner range, to prevent the player from finding an "addition spot". From there on the asteroids are accelerated in the direction of the station and obtain a vector that intersects with the safety area around the station. Only during the mission, some asteroids are aimed more precise to intersect with a very small area around the station, leading to many hits on the station. The nice effects of asteroids exploding on the planet surface is just a core-oolite explosion effect.

Everyone, thanks for the info. Interesting to know, and I'm really impressed how much creativity went into the oxp!

Well, at last it gave me one of those "unforgettable moments" in computer games that remain in memory forever!

GGShinobi wrote:

Oh, and I noticed that after the asteroid had destroyed the main station, all other stations (Rock Hermits, RRS, Taxi... whatever) had vanished, too. Is this a bug?

I think it is, yes. I suspect the purpose of this is to prevent another station becoming the 'Main' station, but in my opinion it goes way too far.
I'm currently fixing a few OXP incompatibilities with Xeptatl's Sword and this is one of them. In this case it not only removed the main station which my OXP relies upon, but it also removed a vital Monitor Station which is in solar orbit (so nowhere near the asteroid storm/planet/main station), and to make matters worse this is after months or even years of in-game time when the player has been around all Eight galaxies!
Could I suggest adding something like to the AsteroidStorm.js which would 're-set' the variable on jumping to G2, thus allowing the main station to be present again if a player does get round all Eight galaxies and returns to Leesti? Surely GalCop would replace the main station as soon as possible, but as things stand, it never, ever gets replaced and that doesn't seem right at all.
I noticed also that dockables are removed - according to the log a Liner was removed at one point during my testing - and as far as I know dockables cannot be given Main Station status.

If we talk about OXP stations gaining main station status, does that mean they get the main model, too?
If not it would totally make sense, from a in game perspective, that one of the oxp-stations would be promoted to mainstation status (by GalCoop renting or other arrangements) until there is a new station built... so that Leesti isn't a "lost" system. Of course, this would be more of a style decision... and change the oxp quite a bit.
Another thing is, that I am repeatedly reminded that some blokes saved Leestimain by the News... only I had failed this mission... GalCop hides a major disaster from the general public!

The problem with promoting an OXP station (or dockable) to main-station status is that they are not guaranteed to be there after a save, and main stations are the only place you can save. It's a bit of a conundrum!