Oolite Bulletins

Version 2.2 released - Happy new year!

Have downloaded the new version. Will report on any problems I get.

One thing, the readme needs to have a .txt file extender otherwise Windows complains it doesn't understand how to open it. I suggest you reformat the text too, its currently one paragraph and difficult to read.

Getting this warning in my log, running trunk v1.77.0.5595. I searched my AddOns folder, and found it was from the SIRF OXP.

Oh wow thanks Tink!

...So I arrived to find lots of cargo pods floating about as the poor traders must have gotten stuck in the spinning bits of the station lol! I figure free credits. Then I dock inside to find out I have to pay a 850 credit fine for not requesting docking clearance. DOH! Things have changed.

I am using simple shaders and I like the reddish brown color. Reminds me of iron oxide.

So far I like what I see. I guess I won't cheat and pay the 1.2X cost.

New version uploaded, same link from wiki, or here.

Unneeded subentity removed, readme in rtf included for windows boxes that do not understand mime types or unix formatting.

SIRF fugitive? by JazHaz, on Flickr

Fugitive? Really?

This is a known problem, I have never seen it happen but it has been reported to me.

It is caused by a galcop ship spawning to close to the station and hitting it, this is interpreted as an attack by the station.

I am testing some options for spawning the traffic cloud, update will follow soon.

The screenshot also shows that the model is badly centered (not centered at all). One result is that its target reticle box is ridiculously big, which is aesthetically unpleasing. Whether there are other ramifications, for instance for collision detection, I don't know.

Commander McLane wrote:

The screenshot also shows that the model is badly centered (not centered at all). One result is that its target reticle box is ridiculously big, which is aesthetically unpleasing. Whether there are other ramifications, for instance for collision detection, I don't know.

Collision detection uses a first pass based on collision radius. It's larger than it needs to be, so this will mean more objects have to be checked for collisions. There is then a second pass which actually checks (an approximation of) the space the two objects take up, but this is only done for objects near the player - otherwise a collision is assumed for efficiency {1}. This probably explains the debris fields, smashed Vipers, and everything else near it...

{1} How much extra efficiency I haven't properly tested. I suspect from the profiling I've done that in a typical OXP selection with 50-200 entities per system, it doesn't save a lot of time. On the other hand, collision detection also needs further optimisation to work well at higher entity counts.

cim wrote:

Commander McLane wrote:

The screenshot also shows that the model is badly centered (not centered at all). One result is that its target reticle box is ridiculously big, which is aesthetically unpleasing. Whether there are other ramifications, for instance for collision detection, I don't know.

Collision detection uses a first pass based on collision radius. It's larger than it needs to be, so this will mean more objects have to be checked for collisions.

How is the collision radius calculated? If it's based on the distance of the object origin to its farthest point, then this would indeed result in a grossly overblown sphere of collision. This would emphasize the need of properly centering objects. In this case I'd even go as far as calling non-centered models OXP-bugs.

Commander McLane wrote:

If it's based on the distance of the object origin to its farthest point

Correct. The collision radius of an entity includes not only its own model, but the models of any subentities, so if an entity is mostly sub-entity it's possible for all the models to be correctly centred but the entity as a whole still look off-centre. If the sub-entities are frangible you may just have to put up with this a bit...

Also the AI in combat will aim for the model origin, using (a multiple of) the collision radius to determine whether it is on target or not, but the laser shot uses the model itself for collision detection. Yes, you possibly can exploit this by making a torus-shaped ship with the hole parallel to the direction of travel, but it'll probably confuse most players too, so that's okay.

Version 2.4 now released, using a different traffic spawn routine from Svengali. Direct link here.

Added to the todo list for this oxp is build a new model, based on the original design concept but properly centred, with fewer sub-entities, consistently named models and textures. I may well remove the debris field of damaged ships though some people have commented it is nice to see them and the new ships in docks.

It's been some years but SIRF could now be found on the expansion or alternatively here: S.I.R.F. v2.51 . We are currently at V2.51 with the next release soon to come.

The next version will include 3 core-ship variants (Gecko "Dragon Class", System Shuttle and Worm Prospector) a ship-script (should also prevent the station to accidently become a criminal), a refactor of the shipdata.plist and some re-textures. Additional the ship wracks outside the station have been upgraded to current core-game models:



Additional information could be found on the wiki-page: S.I.R.F.

montana05 wrote: ↑Fri Jan 15, 2021 11:59 am

It's been some years

It has, great job!

The wiki page mentions a mission OXP, Spylarn, which I never came across. Has anyone heard more about it? Was there ever a release?

maik wrote: ↑Fri Jan 15, 2021 3:20 pm

It has, great job!

The wiki page mentions a mission OXP, Spylarn, which I never came across. Has anyone heard more about it? Was there ever a release?

Thank you, I am still experimenting with a new AI and I need to update an external resource package as well, but I guess with next week the latest update should be available. However, I turned this OXP upside down and for sure there is no hidden mission inside.