Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: More imporved game starting [patch]
Home

[Freeciv-Dev] Re: More imporved game starting [patch]

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Cc: Daniel L Speyer <dspeyer@xxxxxxxxxxx>, Christian Knoke <ChrisK@xxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: More imporved game starting [patch]
From: Andreas Kemnade <akemnade@xxxxxxxxxxx>
Date: Wed, 26 Dec 2001 12:55:33 +0100

 > 
 > IMO we should send all server options (/set, /show) via the network. This
 > would make the code capable of supporting server options on remote machines.
Agreed. That makes the stuff more portable. The pipe stuff isn't
portable at all. read() can only be used on the pipe if we have real
file descriptors for it. But we haven't file descriptors for it in all
cases.
 > Considering the amount of people that play on civserver i consider this 
 > necessary. This should be the part we should be focused on implementing
 > right now.
 > 
 > About commands, i'm still a bit doubtful about how to properly implement
 > that. My first impressions lead me to consider they too should be
 > transmitted through the network, but then we have the problem that not all
 > commands (e.g. load) can be executed after the server has started.
 > We can use some sort of authentication to ensure who gets cmdlevel hack
 > has what it takes.
At least the save command should go through the pipe because the
client will display a file selection dialog to select the file. Same
for the (future) load command and -f commandline option. 
IMHO these two commands are the most important commands. So this
should be implemented first. How to load a saved game is really a FAQ.
 > 
 > === I propose the following roadmap:
1) implement save/load/start game using a GUI+pipe.
   -This gives almost no common client code
2) build common client code for sending/receiving options. (through
network)
3) build a reference GUI code around that.

4) implement remote commands using a GUI+network. 

> 3) make the server able to load games after it has started up.
That's really another task.

Greetings
Andreas Kemnade


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