thanks, questions & feature wish

[noOp]

Brilliant!
Thanks to everyone who made this possible.

I would like a little more docs in the package (used the binary install of 1.52rc4); maybe the reference sheet, the first-flight faq and depending on copyright the elite manual (or a link to it?).

Are there any more docs on howto script missions? Besides the bits in the forum, AIReference.html and the source code itself?

Feature: inflight/battle music
From a quick glance at the source I guess this is not too far off (SDL does play the two ogg tracks), but currently not implemented (on non-OSX); I would really like to feed at least one playlist for inflight music into the game.

Anyone compiling the oolite source on debian? I'd appreciate it if you could tell me which of the (lib)GNUstep*(-dev) packets are required.

[winston]

I'll put docs on the TODO list.

How far did PLAYING.TXT get you? On a scale of 1 to 10 (where 1 is totally inadequate, and 10 was fantastic), how good do you think it is for new players? I'm assuming it's not 10 or you wouldn't be posting

The nice thing about the Mac is you have this lovely rich API for playing music etc. on every Mac. My original intention was to use Xine to provide this functionality under Linux, but then that'd drag in yet more dependencies (and a LARGE one at that). However, it's not hard to play music via SDL, so a simple playlist manager wouldn't be an enormous task (certainly via editing a plist, a bit more work to make a GUI to control the playlist). I have been idly thinking about it, since there's lots of Creative Commons/Attribution/Sharealike/Non-Commercial music available from places like Magnatune which we could include (assuming the right music can be found). Or if anyone wants to compose some, of course.

I'd probably want to make music an add on though, because otherwise the basic installer will rapidly bloat!

As for compiling the source - experience so far says that it's best to get the latest GNUstep Startup (and build it) from GNUstep.org itself (the one the binary package is built against is on ftp.alioth.net - but at the moment that's the same as the one on www.gnustep.org). I think Debian might be missing one of the SDL libs as part of the distro (SDL_Mixer perhaps, but I could be wrong - I vaugely recall someone who was using Debian sid not being able to find one of the SDL dependencies using apt) so you may find you need to build that from source too, but SDL is pretty painless to build (the SDL dependencies provided in the binary package were all compiled on my dev system from the source tarballs that I've put up on ftp.alioth.net).

Anyway, I've added those things to the feature queue on the project page.

[noOp]

How far did PLAYING.TXT get you?

Well, I don't seem to have that file; there are only these two:
Oolite/oolite.app/Contents/Resources/README.TXT
Oolite/release.txt
I learned by remembering Elite, trial and error and reading in the forum (found the mouse control that way; I really like it;-).

About the music: The ~free~ music on the net is really cool for opensource games; but I was thinking more about playing my own files.
I wouldn't go as far as editing the playlist in game; maybe just the option to skip a single track. I would go for two playlists (inflight vs. fighting) both created by each user; the game could either simply switch between them or choose the next track with some probability depending on the player state.

Thanks for the info, I'll try to build GNUstep from source then; so far I haven't had any problems with any of the (debian) SDL libs, but I have never used objective c before, too.

[winston]

PLAYING.TXT et al. *should* be in the installer tarball (so should be in the directory where you unpacked the tarball). I'll put a mention in the install shell script so it gets found.

[noOp]

PLAYING.TXT et al. *should* be in the installer tarball

It probably is. I installed from a tmp dir (the unpacked installer is long gone) and only looked at the installed files; mea culpa :-(

I read the version in the svn repo and it would have solved all my troubles from the start. You might want to add something like "SHIFT-M toggle mouse control (only works in fullscreen mode)"; I guess that feature is new.

Compiling from svn source (I used /tags/1.52-1) works like a charm; the result seems to work as well. Though I used the debian gnustep libs, seemed like the easiest way (after some manual attempts).

In case anyone else is trying to compile on debian and looking for the required packages, I guess:

Code: Select all

apt-get install gnustep-core-devel gnustep-make gnustep-back

should pull in the respective dependencies; I ended up with:
gnustep-back gnustep-base-common gnustep-core gnustep-core-devel gnustep-gui-common gnustep-make gnustep-ppd gobjc-4.0 libgnustep-base1.10 libgnustep-base1.10-dbg libgnustep-base1.10-dev libgnustep-gui0.9 libgnustep-gui0.9-dbg libgnustep-gui0.9-dev

The gnustep versions might be a bit old (compared to startup-0.12).

[winston]

I used 0.10 for quite some time (only recently started using 0.12) so it shouldn't be a big deal. The Foundation seems very mature, it's only AppKit (which we hardly use) which seems to be...um 'lacking'.

[noOp]

Trying to write some playlist/music code; I have a working class to handle loading m3u format playlists but am not yet sure how to integrate it with the existing code. My best idea so far is to fill the empty playiTunesPlaylist (and pause) functions.

This might be off-topic but are there any guidelines or even rules when to use "retain/release" or "autorelease". I assume the basic [de]alloc may be used if reference counting is not needed (e.g. private member variable)?

In the meantime I was able to get at least some background music, too; I got around the /dev/dsp locking problem by starting the "esd" mixer daemon (gnome), switching my music player from OSS to esd output and exporting the env variable SDL_AUDIO_DRIVER=esd before running oolite.
Might lag a little bit, but beats flying around in (quite realistic yet somehow dull) silence for most of the time.

[aegidian]

This might be off-topic but are there any guidelines or even rules when to use "retain/release" or "autorelease". I assume the basic [de]alloc may be used if reference counting is not needed (e.g. private member variable)?

Memory management with Objective-C GNUstep is as difficult as with many other OOP languages. I'll see if I can give a potted explanation:-

retain and release

You send an object a retain message and its 'retain count' gets incremented. As long as the 'retain count' is above zero the object will not be deallocated.

When you send an object a release message its 'retain count' is decremented, if it's zero or below the object will be sent a dealloc message and it will be deallocated and the memory used by the object will be freed.

So you use a retain message when you want an object to stick around (for the life of a routine or the life of another object), and a release message when you're done with it (at the end of the routine, or in the retaining objects dealloc method).

autorelease

If you send an object an autorelease message then a reference to the object will be added to an 'autorelease pool' which is created at the start of each run loop.

At the end of the run loop, all objects in the autorelease pool are sent a release message - deallocating those whose retain counts are now zero or below.

So you use an autorelease message when you want an object to stick around until the end of the current run-loop, typically you use this with objects referenced as local variables.


Some object creation methods always return pointers to objects with a retain count of 1 - the most important of which is [NSObject alloc] which is inherited by all other objects.

Other methods return pointers to objects with a retain count of 1, but which have already been sent an autorelease message. You'll have to read the GNUstep docs for more details.

[winston]

SDL_AUDIO_DRIVER=esd before running oolite.

What's wrong with ALSA? I have no problems running Oolite + Xine using ALSA (the mainstream 2.6.x sound arch) and no sound lag. (I thought OSS and esd were deprecated these days).

[dajt]

Thanks for that concise explanation.

Some object creation methods always return pointers to objects with a retain count of 1 - the most important of which is [NSObject alloc] which is inherited by all other objects.

What is the correct way to get these released? Sending them release or dealloc?

Other methods return pointers to objects with a retain count of 1, but which have already been sent an autorelease message. You'll have to read the GNUstep docs for more details.

Are autorelease objects released regardless of reference count at the end of the current run loop?

[aegidian]

Thanks for that concise explanation.

Some object creation methods always return pointers to objects with a retain count of 1 - the most important of which is [NSObject alloc] which is inherited by all other objects.

What is the correct way to get these released? Sending them release or dealloc?

release - release will send an object a dealloc message when the retain count reaches zero, the object will call its dealloc method and then its parent's dealloc message and so on until the NSObject dealloc method is called, which will finally free the object's memory.

Other methods return pointers to objects with a retain count of 1, but which have already been sent an autorelease message. You'll have to read the GNUstep docs for more details.

Are autorelease objects released regardless of reference count at the end of the current run loop?

What happen is the NSAutoreleasePool is itself sent a release message which should then dealloc it, and its dealloc method then sends a release message to each object in the pool, and then call its parent's (NSObject's) dealloc method which frees the NSAutoreleasePool object.

If the objects in the pool have a retain count of 1 when the NSAutoreleasePool is dealloc'd then their retain count is decremented by the release message to zero, which will cause them to be dealloc'd - otherwise their retain count is only decremented, and they don't get dealloc'd.

An object is not necessarily dealloc'd when it's released, only when its retain count reaches zero (or below).

[noOp]

What's wrong with ALSA? I have no problems running Oolite + Xine using ALSA (the mainstream 2.6.x sound arch) and no sound lag. (I thought OSS and esd were deprecated these days).

In principle ALSA is fine (and I agree: it should do it); in particular I can't get it to work right (second program waits for lock or segfaults).
From what I can tell esd is still part of gnome; same for artsd and kde.


Thank you for the explanation Aegidian.

[winston]

Some object creation methods always return pointers to objects with a retain count of 1 - the most important of which is [NSObject alloc] which is inherited by all other objects.

Argh. I'm assuming things like doing [NSString stringFromString:] returns an object that gets released by the autorelease pool? I've also had things disappear at the end of the run loop that I never expected to disappear. Part of this is inexperience with the ObjC classes concerned I expect...

[aegidian]

I'm assuming things like doing [NSString stringFromString:] returns an object that gets released by the autorelease pool?

Yes. In fact most routines return objects in the autorelease pool, it's more the [[SomeObjectClass alloc] init]'s you have to watch out for because they're not autoreleased and might accumulate into memory leaks.


It took me ages to get my head around Obj-C's memory management (despite it really being quite simple), so a lot of my code has comments about the retain/release cycle and the early code sometimes also has a lot of superfluous release and autorelease calls (I think I cleared up most of the mess now).

[noOp]

After some reading and experimentation I was able to convince ALSA to use the dmix plug; finally multiple audio-sources work. Thank you, Winston, you made me try this one more time.

Furthermore I wrote a first ooTunes implementation using my favourite player: xmms. I have played the patched version for a few hours without a crash, though there may yet be memory leaks.
I don't think it is a good candidate for inclusion, mainly because of the glib dependency; it should be possible to use the control socket directly.

In case anyone wants to give it a try:
* http://skybound.portland.co.uk/oolite/o ... ic.tar.bz2
* http://skybound.portland.co.uk/oolite/R ... smusic.txt

How do you feel about changing the file layout like this?
~/.oolite/
~/.oolite/saves
~/.oolite/.firstrun
This would allow using a ~/.oolite/playlists folder for my purpose without adding another directory to $HOME.