Re: Getting into a crossfire game

[mwedel@pyramid.com (Mark Wedel)]

>
>Matt Cortes wrote:
>> On Wed, 22 Nov 1995, Arne Wichmann wrote:
>> > 
>> > Hmmm... wouldn't it be a good thing to have crossfire handle
>> > X security?
>> 
>> I agree.  Its very poor to set it up that why.  COuldn't some automated 
>> security be taken on by crossfire itself?  Its a major hole for a popular 
>> game.  There is enough holes in unix to worry about already. :>

 I suppose some additional authorization method could be used (in the
initial telnet connection, the user could enter some key that the server
then uses to connect to the remote display.  Unfortunately, there doesn't
look to be much in place on the client side to handle this.

>> While we are on topic, it would be nice to have a group of programmers to 
>> make crossfire more user friendly.  I finally managed to get a good game 
>> going, already on level 8 in one day.  (Thanks to all those who replied 
>> so fast and helped me get it running)  The point is, I had alot of 
>> trouble figure out crossfire, and I'm a above/novice programmer as well 
>> as a computer consultant/technican.  There are probably lots of other 
>> people who would love to play this game but haven't a clue how to compile 
>> it, etc.

 What are the main difficulties encountered while compiling it?  Sure, a
couple files need to be edited and paths set up, but beyond that, I would
think that the xmkmf -a and then make and make install pretty much does it.

 IT might be a good idea to put all the options that must be changed (ie,
path names) at the very top, and then say everything beyond that is
optional, and the game should compile fine even if you don't changed any of
the other options.

 I would like to have suggestions that would make things easier for people
to install or more user friendly.  I do acknowledge that the docs leave a
lot to be desired - Steve Lembark (I beliee that is the person) is working
on new spell doc along with better doc on some of the other magic items.  I
need to look over the docs and see if there is a basic instruction set (ie,
keypad moves you around, this button applies, to save go to a savebed, etc.)

>>  My suggestion is to first make pre-compiled binaries for Linux 
>> and other popular UNIX distros.  It would also be nice to have a easy to 
>> use installation program as well as a metacache server as found with the 
>> netrek game.  People who have public servers can add themselves to this 
>> metacache list and then when someone starts up crossfire with the 
>> metacache server, get a point & click listing of all running servers.

 Nothing is stopping precompiled binaries.  I only have access to sparc
systems with sunos 4.1.x and pyramid systems, so I can't contribute much.
Plus, releases are still coming out pretty often.

 However, before precompiled binaries really become much of an option, a lot
fo the configuration options need to be put in an option file that is used
at startup.

 Obviously, the present startup mechanism (telnet to source, etc) doesn't
support metaservers at all.  However, that could probably be done on web
pages pretty easily (I've looked over html stuff, and I believe the have
html iniate a remote telnet connection to a specific port is possible).
Likewise, it would probably be possible to have people enter new sites into
that.  The other place to do that would be with the new client/server stuff,
but that seems to be at a pretty dead end.

>
>Using the client/server is a better way of solving the security problem.
>There is no way I would let X traffic through our firewall, but crossfire
>protocol traffic I probably would. The client/server approach could also
>help solve the complexity problem. Assuming the protocol doesn't change and
>there are no major changes such as adding a new stat, the same client 
>should be able to work with many versions of the server.
>

 Correct.  Problem is that I think client/server developement has pretty
much stopped.  I doubt I will ever work on it any time in the near future
(hell, there is enough stuff that needs to be done with the non
client/server aspect that will probably keep me busy for quite a while.) The
problem as I see it is that someone needs to get committed to working on the
new client/server stuff and do the following:  A) figure out how it is doing
everything right now.  Stats are fairly clear, but the object handling is
the real mystery.  B) document what it does, so that future peopel don't
have to repeat A.  C) work on refinements/improvements.  However, in some
sense, it may be just as easy to rewrite a lot of the code.

 As I have said in the past, I believe the client/server is working
reasonably well (ie, is playable.)  There are a few shortcomings I know of:

1) Speed for players using the client isn't done correctly.  What to do with
command received when the player lacks time needs to be dealt with (ideal
way would be store this information in an area accessed by the server.  Some
commands could have immediate access regardless of the player has time (ie,
you might want to be able to do a who, even if you are paralyzed or
something)).  Player should also have some option to either store these
commands or throw them out (like the existing keyboard buffering.)

2) Magic mapping is totally missing from the game (no mechanism exists for
sending the data to the new client.)

3) Performance seems worse than existing methods even if you are on a fast
link to the server.

4) Object ordering between server and client aren't synchronized.  This for
the most part is not a problem (ie, server typically doesn't care about
order of objects in inventory).  However, the one cases this does make a
difference is the improve weapon stuff (operates on the first object in the
players inventory.)  IT would probably be nice to have some way to target
specific objects (Even on the server).  That is to say, that the improvement
scroll gets applied to item XXX.

 I am not sure if there are other features that are missing.

 Things client/server gain (if it every works perfectly):

1) Can be much smarter on certain actions without complicating server more
(let player order objects how they want, and server doesn't care about it.)

2) Remove all X11 code from server.  Would probably make it much smaller and
faster (and you don't have to worry about 1 user with a slow connection
messing it up for everyone).  would probably make the server much easier to
compile on different machines.

3) No longer need to deal with X11 security issues.