Progress

JensAyton · Post by **JensAyton** » Fri Sep 11, 2009 10:02 am

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.)

JensAyton · Post by **JensAyton** » Sat Sep 12, 2009 11:29 am

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

You may be seeing a theme here.

Website · Post by **DaddyHoggy** » Sat Sep 12, 2009 11:40 am

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

CptnEcho · Post by **CptnEcho** » Sat Sep 12, 2009 1:14 pm

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.

Diziet Sma · Post by **Diziet Sma** » Sat Sep 12, 2009 4:55 pm

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

JensAyton · Post by **JensAyton** » Sat Sep 12, 2009 11:35 pm

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.)

Commander McLane · Post by **Commander McLane** » Sun Sep 13, 2009 8:34 pm

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.

Post by **Kaks** » Sun Sep 13, 2009 10:01 pm

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.

JensAyton · Post by **JensAyton** » Mon Sep 14, 2009 10:34 pm

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. :-)

Website · Post by **DaddyHoggy** » Mon Sep 14, 2009 10:37 pm

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

Website · Post by **Cody** » Mon Sep 14, 2009 10:42 pm

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.

Lestradae · Post by **Lestradae** » Mon Sep 14, 2009 11:26 pm

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

ovvldc · Post by **ovvldc** » Tue Sep 15, 2009 4:59 pm

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.

Star Gazer · Post by **Star Gazer** » Wed Sep 16, 2009 8:24 am

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

ovvldc · Post by **ovvldc** » Wed Sep 16, 2009 6:03 pm

In Witchspace perhaps?

-Oz