Crossfire client (and Re: Patches, ftp, new releases. )

["'Evil' ERic Mehlhaff" <mehlhaff@ocf.Berkeley.EDU>]

Tero Haatanen <Tero.Haatanen@lut.fi> recently wrote:
>At least nobody can say that crossfire deveplopment is dead. I add some
>of my thoughts in this discussion. 

Well, for us here at berkeley, it was for a while, as the machine we were
using basically died.  We're still trying to either fix it or find
another.  :-P


First, you folks can work on a new merged release. Once that's out, we'll
work on adding all the cool stuff we have in our own crossedit0.7 release
based code.  I had to do the merge from the .5 base, and it wasn't too
bad.   Just don't do any major code structure changing, and we should be happy.

>After we have the stable version we can start doing the client/server 
>version. Like Kjetil descripted differences between crossedit 0.7 and 
>crossfire 0.90a, those don't affect client/server code. 


I'm currently working on crossfire server-client code. It shouldn't really
be affected by those changes in the code.  It's going to end up being very
strongly based on netrek.  TCP only (at first), and Xlib only, with the
windowing system calls easily ported out (again, just like netrek).  Once I
get that stable, people can throw in whatever funky xwidgets for things
they want.

>Also we have time to discuss, what client does and what server does and 
>how they communicate with each other. I think that server should handle
>everything, excluding maybe animation. So slow client could have option
>no-animations, but this probably requires that where animation is used 
>something important (i.e. opening/closing gates), those have to be done 
>with changing objects.

Well, my client code's going to do its own animations, except maybe for
the monster animations.  Really, it's just goint to be displaying things.

>Client also could handle inventory, so that server only knows what item
>is applied, dropped, etc. How that is applied is client trouble (i.e.
>clicking with mouse or pressing 'a'). And when server sends info that
>player has 10/105 hp's, client can draw status bar, print numbers or
>play audiofile in /dev/audio :).

My idea was the server handles the inventory, but also tells the client
what the player is carrying, etc.  The client can then nicely sort and
display things, as well as provide a nice frontent to applying/droppgin,
etc.

>I think that possibility that there is ability cheat with 'superclient'
>isn't important. Mainly because there is not very much to gain. It's 
>easier gain exp in the maps where you can kill trapped monster and gold
>collecting all those 'free' treasures on maps. And there is always some 
>maps where this is possible. Only useful feature a can think is automatic
>'read recall' when low hp's, but that probably cause more problem that
>it helps. Mud-players have done this kind of things and it's normally
>easy to detect.

I'm not too worried about players making the 'superclient'.  My idea for
server-client protocol would make this extermely hard.  To top it off, 
I propose we just plain plug in netrek's RSA code, should we need binary
verification. Its portable, its debugged, it's done.  We could do just as
netrek has with it. It's availalbe freely from sites outside of the US.
It's not a problem.

>And binary distributions with RSA means much more work and many people
>don't like idea installing binaries from net, especially when it the 
>network game.

Well, any binary distribution is dangerous.  I doubt we really need to
worry about it.


I can explain more about my client code protocol, if people want. I'm
still busily hacking away on it, though.

 ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU