Oolite Bulletins

KW: did you try 1.67, and if so, did it have the same problem? It may be due to the “Image placement in HUDs should be consistent across platforms. Presumably this will break some HUDs.” feature of 1.67 (I’ve been waiting for someone to mention this).

i didn't, no. is it a fixable problem? all the gauges and meters are in place, but the dashboard graphic is vertically lowered - it looks horizontally correct, as far as i can tell.

also, the left/right/rear views look a bit odd too, as though some of the stuff near the bottom of the screen isn't being shown due to an odd camera angle or such.

Basically, HUDs were displayed incorrectly in previous Windows and Linux builds, and are now being displayed properly. HUDs which explicitly or implicitly worked around the bug will therefore look wrong… unless something’s wrong with the standard HUD. (Screenshots are always useful in these situtations.)

standard HUD's fine, like i say it was just my PNG of the dashboard that gets dropped a few hundred pixels. i'll grab a shot tonight, didn't have much time to do anything last night.

With 1.68, on my elderly PC with all the OXPs installed, the game runs much quicker in flight and even when there are 80+ objects in the system the game clips along at a respectable 32 fps!

One oddity is with docking. On docking the game hangs for about 10 seconds and quite often crashs to windows. Has anyone else found this, or is it just that my system is just so low-spec?

Odd thing is on 1.67 I had no hang on docking, but was always getting hangs in flight and on exiting witchspace. Great update though, as docking is a natural break in the game play, so I'd rather have to wait a bit docking than have lots of hangs in flight!

The delay at dock is most likely the game doing a cache pruning (someone please correct me if this is not true). The more OXPs installed, the longer it should take to perfrom it. 1.67 was not using this cache mechanism, so you would not notice this.

Makes sense. Only trouble is that it often crashes whilst doing so. That said I am really overloading Oolite as I only have 0.5 G of ram and about 150 Ms of OXPs installed.

another_commander wrote:

The delay at dock is most likely the game doing a cache pruning (someone please correct me if this is not true). The more OXPs installed, the longer it should take to perfrom it. 1.67 was not using this cache mechanism, so you would not notice this.

The cache sprang to my mind, too – either the pruning or the serializing/saving. It’s pretty fast here, but maybe if you’ve got VM thrashing…

If it is the cache pruning that’s crashing, your log should end with an entry like “[dataCache.prune] Pruning cache - removing 42 entries”. If you don’t get an entry like that at all – and haven’t fiddled with your logcontrol.plist – the cache isn’t full and no pruning is happening. If there’s a line like “[dataCache.write.success] Wrote data cache.”, the cache has been written by the time of the crash. Unfortunately, there’s no “about to write cache” message you can enable. *adds one for future use*

Yep am getting:-
When it crashes.

Would I be better off setting virtual memory to zero, or increasing it. Currently have it set at 1200 (on window's reckomendation!)

Hmm, failed to write cache? …Hmm, the cache code should probably be ensuring the directory exists, only without the probably. Still, that probably isn’t the cause of the crash, then.

The “Found mode” thing is rather curious. As far as I can see, that should only appear once at app startup time. That’s part of the small bit of SDL-specific stuff that I’m not familiar with and can’t really test, though. :-/

couple quick pics :
from 1.65 :

and 1.68


re the camera view, i'm now thinking it always displays that daft gap, but up till now it's been masked by the Dash.
re the dash graphic, as you can see it's dropped vertically - if you squint you can (just!) see the three dot sight resting right on top of the scanner grid.
i set up the display as per your read me, 1280x1024 as per my monitor, also tried 1024x768, no different. BTW, in my folder the parameters were "window_width" and "window_height", but changing them to "display_width" etc made no difference either.

Yes, you can see the gap on the right hand side in the top position. This is basically down to fiddling with your view_position_starboard so that the camera clipping plane doesn’t intersect the ship’s hull.

I think this is the result of the bug fix I referred to earlier, and you’ll just have to change your HUD until it aligns properly again. The good news is, it will then work the same on all platforms, which is not the case in 1.65.

and you’ll just have to change your HUD until it aligns properly again

you mean just by messing w/ the image in Photoshop, or are there some positioning commands i can play w/? i can't understand why it's dropping, i positioned it over the normal HUD display when i was designing it, and the normal HUD's fine but mine's not - it's like it's positioning it via a different origin to the normal one, or something :-/

<key>y</key><integer>42</key>

:-)

(Properties supported for HUD image items: image, x, y, width, height, alpha (opacity).)

Is it possible to predict when 1.68 is going to be announced as "the" new basis for Oolite?

Will all the old oxp`s still run properly if I upgrade now?

Greetings,

Lestradae