Oolite Bulletins

Cody wrote:

It ain't only about the math - slower rotation enhances the impression of size.

For a mathematician, it's all about the math . But yes, immersion vice, slower rotation makes it feel bigger. The station, I mean .

spara wrote:

Variable rotation velocity means more variance and more believable environment. I would vote for different roll speeds for different stations.

I'm in favour of slowing down station rotation generally - like Cody says, it adds to the sense of scale. But using a slow rotation speed as a base, it might be possible to vary station rotation using the radius of the main planet. A larger planet can be assumed to have a higher gravity, so the station should rotate faster so that the outer levels match the local g. Smaller planets would have lower gravity, and slower-spinning stations.

There is a bug in two of Griff's asteroids causing those asteroids to not spawn boulders. Keys are "griff_asteroid_13" and "griff_asteroid_14". In both there is a line: That does not work, only one role should be given in debris_role. For example: I also found another asteroids related bug, resulting from Griff's asteroids and my replacement set. The combination suppresses the core role "boulder" totally away causing any attempt to spawn with the role "boulder" to fail. For variety, it might be an idea to add the role "boulder" to all boulders in the package, but that's up to you Griff. The main culprit is in the Replacement package.

I have fixed both issues in the new version (1.1.3) of Griff's Normalmapped Ships Replacement Package. However, The first issue should be fixed from the Griff Asteroids package too.

Thanks for spotting this bug, spara. I also inherited it for the noshader accessories and now applied your fixes. Keep up the good work!

I've updated the asteroids oxz with spara's bugfixes, i haven't got my login for the oxz site on me at the moment to update the manifest but i'll sort that out this evening and update my post here when its done

This Krait was buzzing me - is that decal correct? It looks rather odd to me!

Really, really small bugs.

In both the Cobra_MKIII_Alt and Cobra_MkIII.SubentMissiles oxz's, in the "griff_cobra_III_(alt)_externalMissiles.js" file, the first line reads: Really should be .

Strangest paint job I've seen on a Cobra MK III (and BGS seems to be missing the 'Price' display - is anyone maintaining BGS?).

Reminds me of my Python 'accident' with a cargo barrel texture. New model with old texture?

Possibly something like that - and I've now seen it several times in the shipyard.

I've uploaded the prototype boa to the OXZ manager, has a few cosmetic shader bug fixes over the OXP version.

Sorry about not replying sooner to this - I've fixed the 'use scrict' bug phkb spotted in the cobraIII OXZ's and reuploaded the OXZ's

@Cody, Sorry about the late reply, I did checkout that screenshot at the time - i think that decal paintjob is actually working OK (as ugly as it looks), the shaders let the decals appear as black now (whereas before the darker the colour, the more transparent the decal was), not sure if this (and the other paint changes) were a good idea or not, seemed OK at the time but now looking at it a few months later

Griff wrote:

... not sure if this (and the other paint changes) were a good idea or not, seemed OK at the time but now looking at it a few months later :?

Hello Griff... I ain't too fond of them, tbh. Have you looked at your Wolf Mk II lately? All I see is grey!

yeah, I did check that out, no idea what went wrong there, it's the drabbest looking thing in the Ooniverse.
I'll do some shader work on it this afternoon

A friend from the past is back... Thanks Griff, great job as always.


I think there is something wrong with the side cannons though, they seem to be not attached to the hull.

Edit: Here is a shot with post-processed increased gamma, showing the problem. Also, the NPC variant in the oxz shipdata is missing a roles entry, is this deliberate?

Griff, please disregard the previous bug report about the side cannons and the image I posted. This is actually a bug when rescaling models and happens also in 1.82. The model with the problem in the earlier image was a 2.0x scaled one.