Re: [Freeciv-Dev] Sound support

[Joel Ray Holveck <joelh@xxxxxxx>]

>>>> Is sound support going to be included in main distribution ?
>> I hope so.  But I do not have the time to follow the CVS tree, so I
>> will be making my diffs against the 1.8.1 release (until the next
>> release is ready).
> Hmm, thats a bit unfortunate because freeciv is under rather
> active development...  for example, the format of the ruleset 
> files has changed since 1.8.1.

I'm sorry, but right now I can't track the dev tree closely.  I know
sounds rude and selfish, and to a certain extent it is, but I'm
tracking more CVS trees than I can keep up with right now.  If I tried
to write these patches to a moving target, then I'd never get anything
done.  At least, as it stands, I am making something that's somewhat
useful, and can be ported to the development tree later.

That's also why I don't want these changes merged into the tree until
I have something somewhat stable.  It would be just far too much work
for whoever tried to do the commits, if they had to constantly port
diffs from 1.8.1 to a CVS snapshot.

However, because of the resource file change, then perhaps you could
recommend a (post-change) date that has a relatively non-buggy version
of Freeciv.  Since I haven't been following the tree, I also don't
know how frequently bugs make it in, or how major they are.

>> Up until now, the ruleset has not been loaded by the client.  It is
>> entirely possible for the client to use a different ruleset than the
>> server.  The client still gets the game details (such as HPs and
>> names) from the server; it only uses the rulesets it loads for sounds.
> Um, I'm a bit concerned about this... I think it's correct that
> the client _not_ load ruleset files, because eg the server could 
> be using some third-party modpack the client doesn't know about, 
> maybe containing completely different units.  Instead the server 
> should load the sounds data and send this information to clients.

* In favor of the server-side configuration:

** Modpack support

Without server-side configuration, if the server has a fairly
different modpack that the client doesn't have, then the sounds played
will be utterly inappropriate for the game.

* In favor of the client-side configuration:

** Bandwidth

Sending the sounds over a link can be very slow.  A .tar.gz file
containing the part of the Civ2 soundset that we use holds 56 sounds
and is 2.9 MB.  I frequently play with friends over a 26000 bps or so
link.  (I live in a rural area; good phone lines are hard to come by.)
Obviously, I can't wait for a *minimum* of two minutes, and an average
of 20, for the game to transfer the sounds so it can start.

If we transfer individual sounds instead when they are needed, that's
an average of 51 k per sound.  With a transfer rate of 2.5k/s or so
(which is reasonable) that means a 20 second delay before I hear my
men attacking!  Or, consider that I'm in a heated bit of battle with
another human, every second counting.  He nukes one of my cities.  I
take a quick peek, and keep battling.  Then, two MINUTES later, I hear
air raid sirens and a nuclear explosion!  Now, I'm losing precious
time while I'm looking around trying to figure out what happened,
looking for my message window, anything.  (The current nuke sound is
323k.  Even at a whopping (by dialup standards) 15k/s, that's still a
21 second lag.)

** Configurability

A user should be able to select his own look & feel.  I prefer one
tileset over the other.  I've already heard from people who have made
other soundsets from other proprietary games.  (Okay, one person.)
Unix has a fine tradition in which everything is configurable on a
per-user basis, and I like it.

-----

Now, we could get around the bandwidth and configurability problem by
sending tokens instead of sound filenames.  (I'm handwaving the fact
that a filename is actually a token to access the inode / file data to
begin with.)  Then, you still have to have a sound token -> filename
mapping back on the client side, and end up with something no
different than reading the filenames out of a file mapping
units -> filenames to begin with.  In fact, unless the
unit type -> token mapping (done at the server) is one-to-one,
then you end up losing a bit of client-side configurability.

Finally, the sounds should be coherent with the tileset.  If you have
a modpack that does major changes, then either

 1) You've downloaded the modpack yourself, in which case you'll have
    a tileset, ruleset files, and sound files that are all coherent,
    and you're perfectly happy reading the sounds from the ruleset.

or,

 2) You haven't downloaded the modpack.  Your tileset shows alpine
    troops, but the server is talking about an orcish mob.  Now, do
    you want the sounds to be coherent with the tileset, or with the
    unit name strings?  If you use tokens (filenames or another
    abstract token) instead of sending the sound data, then the
    problem is exacerbated: you don't even have the sounds that the
    server is referring to (since you didn't download the modpack), so
    you will be playing without any sound at all.

Actually, Sune Kirkeby (who first suggested moving the sounds to the
rulesets) suggested it to improve modpack support.  (Admittedly, this
was in contrast with a scheme I was using that didn't support modpacks
at all.)

Well, there you have my not-so-humble opinion.  I've stated it
somewhat forcefully, but despite appearances, I am happy to consider
reasons for using a different configuration scheme.  I would much
rather be told that I'm an idiot for considering this configuration
method now, than to be looking back months from now saying "What on
Earth was I *thinking*?" after it's entrenched and difficult to
change.

So, let's hear it, people, who's got an opinion?  Who's got reasons
behind 'em?  The sooner I hear from you, the better!

> A possible approach to avoid putting actual filenames for sounds 
> in the ruleset file, and allow flexibility for clients to use 
> alternate sounds, could be something like the tilespec stuff I'm 
> working on (see recent post).  But maybe I just have a one-track
> mind :-)

I'll look for the tilespec stuff.  I haven't been following the
mailing list very closely, either, I'm afraid, but my machine keeps it
archived for a few weeks.

I also don't see getting much more time to track the tree in the near
future, although I do need to start paying more attention to the
lists.  I hope to finish this up soon, bring it into the tree, and let
everybody else hack it while I go on to some other hacks I have in
mind (not to mention find my next contract, coordinate my move to the
coast, etc, etc).  I'll be trying to get everything major in before
merging it, so I'll just need to do maintenance after that.

Happy hacking,
joelh

-- 
Joel Ray Holveck - joelh@xxxxxxx
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped