Oolite test release 1.67

Wolfwood · Post by **Wolfwood** » Tue Mar 06, 2007 4:44 pm

Ahruman wrote:
Yeah, that was expected. Any suggestions for key assignments?

Nothing on numpads, please, since laptops don't have them. I'd suggest something on the right side of the main keyboard instead...

Uncle Reno · Post by **Uncle Reno** » Tue Mar 06, 2007 4:51 pm

Ahruman wrote:
Yeah, that was expected. Any suggestions for key assignments?

I don't think the "[" and "]" keys are used for anything else, seem reasonably placed to me.

JensAyton · Post by **JensAyton** » Tue Mar 06, 2007 5:13 pm

I’m leaning towards , and .. , is currently the default for key_previous_target, while key_next_target is N; moving key_previous_target to M seems reasonable.

JensAyton · Post by **JensAyton** » Tue Mar 06, 2007 6:02 pm

Of course, it could be that part of the reason yaw control wasn’t working (even after changing the key settings) was that it was set to only build under GNUstep. This would also explain a compilation problem dajt e-mailed me about. *headdesk*

JensAyton · Post by **JensAyton** » Tue Mar 06, 2007 6:29 pm

Ahruman wrote:
, is currently the default for key_previous_target, while key_next_target is N;

…or not. I missed a remapping step in the key handling process. I now have yaw working with , and .. What are next/previous target mapped to, though?

Uncle Reno · Post by **Uncle Reno** » Tue Mar 06, 2007 9:48 pm

Ahruman wrote:
What are next/previous target mapped to, though?

Isn't it "-" and "="?

aegidian · Post by **aegidian** » Tue Mar 06, 2007 10:09 pm

Ahruman wrote:
[*] Giles’s experimental procedural textures (not dajt’s). Activate by pausing (P), then pressing T. The change will take effect when a new planet texture is generated, i.e. it won’t affect the planet in the current system. This feature is, er, in need of additional performance optimization.

The desired performance optimisation would be to roll the procedural texture into a GLSL shader. (I was working on this when my brain crashed.)

johnsmith · Post by **johnsmith** » Wed Mar 07, 2007 10:47 am

Maybe this is just me, but does the laser sight on my Cobra appear to have moved slightly to the right with this update?

JensAyton · Post by **JensAyton** » Wed Mar 07, 2007 1:32 pm

johnsmith wrote:
Maybe this is just me, but does the laser sight on my Cobra appear to have moved slightly to the right with this update?

Now that you mention it, yes. But it’s not consistently to the right, just off a bit.

Uncle Reno · Post by **Uncle Reno** » Wed Mar 07, 2007 2:06 pm

johnsmith wrote:
Maybe this is just me, but does the laser sight on my Cobra appear to have moved slightly to the right with this update?

The actual sight itself or the laser fire point? The sight I can't see any change but if its the laser fire point it could explain something that I was blaming on my combat skills.

EDIT.
Knew I forgot something. I've had a couple of instances of sleeping pirates who then woke up and attacked me, so not proper zombie ships but perhaps a related problem.

JensAyton · Post by **JensAyton** » Wed Mar 07, 2007 2:23 pm

The sight stays in place, the laser is a bit off.

JensAyton · Post by **JensAyton** » Wed Mar 07, 2007 2:35 pm

The laser problem appears to have been an accuracy issue in a the function FastInvSqrt(), which has also caused headaches for the Windows build. I’ve disabled it for now. Selective re-application may be appropriate at some point.

Ships failing to respond to stimuli is an old problem, and unrelated to the ghost ship issue. I think it’s one of the things Giles was planning to fix with the new AI code. I’m not at all familiar with that side of things, though.

Post by **winston** » Wed Mar 07, 2007 2:43 pm

Damnit, I'm going to need a new video card at this rate

Uncle Reno · Post by **Uncle Reno** » Thu Mar 08, 2007 4:50 pm

On the subject of possible AI changes, I have seen more ships run away from me in the last week than I can remember ever seeing. Now, that could be just down to coincidence but I thought it was worth mentioning.

Also on a connected but different subject, these ships running away are apparently able to outrun me, even when I use fuel injectors. Normally I wouldn't mind but I'm flying an Eel Rapier with a top speed of .495lm (according to the Wiki)! I've had both an Asp and a Mussurana outpace me this way!

JensAyton · Post by **JensAyton** » Sat Mar 10, 2007 4:25 pm

Uncle Reno wrote:
Also had a number of crashes to desktop, the last few lines in the console report are ...

OK, I think I’ve diagnosed and fixed this, but the conditions for the crash never manifest on my system. Am I correct in guessing you’ve got a multiprocessor/multicore Mac?
In any case, so I don’t forget to mention it later, I’d like some assistance with verifying this bug when the bug-fix release comes out (tonight or tomorrow). To help with testing, use the following commands (in Terminal):

Code: Select all

defaults write org.aegidian.oolite max_buffered_sound -int 0
defaults write org.aegidian.oolite logging-enable -dict-add \$soundDebug -bool yes
defaults write org.aegidian.oolite logging-enable -dict-add \$soundDebugVerbose -bool no

(If you do this now, the Right Thing will happen after the update.) If the crash does continue after the update, you can supress most instances of it with:

Code: Select all

defaults write org.aegidian.oolite max_buffered_sound -int 4000000

For reference, max_buffered_sound is a size in bytes; 4000000 is sufficient that only the theme and docking music will be streamed -- the theme music is about 76 MB uncompressed (floating point, stereo), and the docking music is 105 MB. The default max_buffered_sound is 1 MB, and can be restored using:

Code: Select all

defaults delete org.aegidian.oolite max_buffered_sound

This setting is new and has no effect in existing releases.

Oolite Bulletins

Oolite test release 1.67

Re: Oolite test release 1.67

Re: Oolite test release 1.67

Re: Oolite test release 1.67