Oolite Bulletins

DaddyHoggy wrote:

Wow! That's a better trick than Derren Brown! How did ya do it?

By being less monstrously inefficient, basically. 336 bytes for a flasher is still ridiculously big. (Note that this doesn’t count the size of the texture, which is shared between all flashers and various other special effects.)

Spark memory consumption in 1.73.3: 324528 bytes.
Spark memory consumption in trunk: 332 bytes.

You may be seeing a theme here.

And to think I upgraded to 2.5GB from 1GB to help Oolite run better!

DaddyHoggy wrote:

And to think I upgraded to 2.5GB from 1GB to help Oolite run better!

It will still run better. You may even notice the difference.

It's all good.. the memory Ahruman has saved will let you run more oxps without bogging down!

Reduced maximum number of saved comm log lines from 125 to 15, and now actually use those when loading the game. (If anyone was actually using all those extra lines for something, now would be a good time to speak up.)

For what could you have used them, as they couldn't be re-loaded again?

I'm very happy to have them reduced, they were always only a tedious scrolling exercise when opening a save-file.

To increase consistency - and making things easier to remember - some shipdata.plist keys have been given standard names:

From 1.74 onwards the escort_role, escort_ship, has_shipyard, is_carrier, and scan_class keys can be used instead of the equivalent escort-role, escort-ship, hasShipyard, isCarrier and scanClass keys, which are still available.

The old keys will still work for future versions of Oolite, and there are no plans to deprecate them, so you won't be getting any deprecation warnings. This change is solely designed to help remove scripting anomalies for 1.74 and above.

Today I have discovered that Oolite writes utter and complete garbage to the cache, yet somehow manages to read back the correct data even though it isn’t there. Clearly this is not a problem to try to fix at night, so I won’t. :-)

The Men in Black will be round in the morning to discuss your highly sophisticated encryption techniques...

Ahruman wrote:

Today I have discovered that Oolite writes utter and complete garbage to the cache, yet somehow manages to read back the correct data even though it isn’t there.

Now that's got me chuckling.

Ahruman, the result of your machinations is amazing.

Under 1.73.3, with my usual oxp configuration, Oolite was eating 1.5 GB of my RAM.

Under "1.74" trunk SVN 2504, it's 650 MB.



L

Ahruman wrote:

Today I have discovered that Oolite writes utter and complete garbage to the cache, yet somehow manages to read back the correct data even though it isn’t there.

...so... ...where's that there alternate cache lurking...?

In Witchspace perhaps?

-Oz