Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mist thoughts (long)



> Sound Improvement:
>
>  I guess Raphael's thought is more that the server will send truly symbolic
> commands to the client (ie, "play hit door" sound, vs "play bash.au" sound

I think that server should offer all sounds and refer them as symbolic
names (or numbers), but how much protocol support is needed to play them?
Some that comes to mind are sound, volume, how many times sound is played, 
and is this a background music?  Maybe Raphael can offer some thoughts 
about this?

> DM MODE

I meant character name, so that DM could be saved as any other character
and when you login the game (using charaster name and password) then if
character file have 'was_wiz 1' and 'wiz 1' (?) set then player would be
in DM mode.  This has nothing to do with dm command.  The problem is
how those wiz-flags are set in the first place (using the text editor or
dm command)?

Of course a server could make some extra checks based on hostname, if that
level of security is wanted.

Client/server:
 
>  I am curious (and maybe Tero can answer this) on how important the
> underlying eutl library is.  Certainly, there are some handy functions here
> and there in it, but at the same time, I know that there are areas of the
> code that pretty much explicity avoid some functions because of their
> overhead.  

I have looked the code and I have a general idea how the server and client
works.  It uses eutl library that has not been decumented (it also has
is own licance that is not GPL).  I think that Eric who made the initial 
implemetation had used the same library in other project, so it was easy 
choice for him (even not the rest of us).  Basically it offers the 
TCP/IP sockets and dymamic list structure called ArgList.  The later
is used to build and send protocol packets.  

Since the server have already TCP/IP code and the ArgList routines really
are overkill to building packets (they dynamically malloc all parameters
for every packet) I thought to try build the server without eutl-library.

> IT would also seem to me that the eutl library would make porting
> to some other systems even more difficult, since the library would also need
> to be ported.

I agree with this.  It probably should compile in many unix systems, but
I'm unsure how portable it really is (at least ArgList routines seemed
to pack packets portable way).

> Things that need to worked out to get if fully playable:
> 
>  1) Magic mapping spell does not work.

This is a real problem, and probably needs a general solution.
(special command to support magic mapping should be simple).

>  2) Containers do not work

Hmm, I must look this, it should easy to fix. But the real solution 
is to redesign whole container model in a server.  The original 
containers were used to make inventories smaller, but client can 
implement this feature without a server.  The real use of containers
then are locked chests, bag of holdings and similar items.

>  3) things that depend on inventory order will not work, since client
> re-orders objects (not much depends on this)

I think this should not be a bad problem, please send examples if this is a 
real problem. Some commands that needs specific items (enchant weapon?)
can use either weapon that is applied or apply command can supply the
target list (APPLY 'scroll of enchant weapon' 'sword'). If command is
applied many items (identify) then it should make no difference (randomly 
identified objects can be thought as feature).  

It also  makes game more interesting (dip scrolls to water, mix potion, etc)
when players are allowed to apply object to other objects.

>  4) Only supports XPM mode.  Pixmap mode should be supported.  I don't know
> if there is any good reason to support font mode.

The pixmap mode should be simple add when other features works. Since
fonts requires that all images are available at startup time, I think
that font mode has a low priority (it can be added later without any(?)
changes to a protocol.

>  5) Client doesn't really do any caching of data.  At mininum, I believe
> client should be able to cache pixmaps/xpm images.

Yes, this is a true and requires some commands at startup time, but 
remember that the current model don't do it either.

>  6) Handling commands from the client.  Right now, it pretty much executes
> the commands as it gets them.

Yes, this really needs to done, but I haven't idea how the timings
work on the server side.  I have understand correctly there is a way
to specify how long different commands take.  How this is a implemented
and is these times really used anywhere else than moving around?  Any 
comments about this is welcome.

I try document the existing protocol and send that to Mark the same time 
as I send other changes.  There are many features that needs to done
before the client can replace the current version, but my highest 
priority currently is get documented protocol and a stable client
in which it is easy to add missing features.

  -Tero