Complete.Org: Mailing Lists: Archives: freeciv-dev: October 1998:
Re: [Freeciv-Dev] capabilities, was Re: space race patch
Home

Re: [Freeciv-Dev] capabilities, was Re: space race patch

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] capabilities, was Re: space race patch
From: Mitch Davis <mjd@xxxxxxxxxx>
Date: Tue, 27 Oct 1998 15:55:52 +1100

David Pfitzner wrote:
> 
> It seems to me the client capability strings should be stored
> in the connection struct.

You are correct, my misteak.  Your assessment of the situation is
much better than mine.

> to have multiple clients connect for a single player, it will do
> the right thing and have per-connection capabilities!

:-)

> The way savefiles is currently done with savefile_options (and
> secfile_lookup_int_default etc for small things) I think is better
> than trying to use the capability string, because what's in the
> savefile may change without changing the protocol (ie the
> client-server interaction). 

Right again.  As you have pointed out, the capability strings
should be associated with executables, not the game, and if this
is the case, then another mechanism is needed to assess game
ability.  Viewed this way, it now makes sense why the idea of
capabilities didn't seem to mesh with game options and attributes.

Also, it may be possible to change the abilities of a client
and/or server, and leave the save file the same, or vice versa.
Again, another point in favour of your assessment.

> [1] Though since you're the author of capabilities, maybe I'm just
> misinterpreting or hijacking their real purpose :-)

I wrote it, but I make no special claim to owning it.  I just
wrote it to get us out of a sticky situation.  If it has passed
its time, or needs rewiring, then so be it.

> [2] Hmm, that means the new PRNG should really be in server/ rather
> than common/ ?  I guess you don't really want the client to use the
> PRNG anyway because it won't be initialized properly...

I'm also thinking of the potential situation someone raised,
that if a client knows the seed, it can replicate the "random"
actions that happen on the server, ahead of time if need be.
One way of avoiding this would be not to reveal the seed to
the client, but give the client random numbers if it asks
for them.  Alternatively, just give the client _a_ seed, but
not the server seed, or anyone else's seed.

Regards,

Mitch.

BTW, anyone notice just how much _faster_ the new lists are!! :-)
--
| mailto:mjd@xxxxxxxxxx       | Not the official view of: |
| mailto:mjd@xxxxxxxxxxxxxxxx | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |


[Prev in Thread] Current Thread [Next in Thread]