Re: Mist thoughts (long)

[mwedel@pyramid.com (Mark Wedel)]

 This contains many topics from the 40 or so mail messages that I got in the
past few days.  Each topic is seperated by a line of hyphens, so it should
hopefully make the things you want to know about easier to find.

------------------------------------------------------------------------------
Sound Improvement:

 Raphael mentioned that he would like to improve sound code, but wait for
client/server to do it.  A few thoughts:

 IT seems to me that rewriting the sounds config file isn't really dependant
on client server.  While this should probably go in the other message I am
about to send it, it seems to me that only thing that will really change is
how the send information is sent to the client.  that is, right now, rplay
protocol is used to send sound requests, with client/server, there will be
some protocol command that tells the client to play the sound.

 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

------------------------------------------------------------------------------
DM MODE

So it seems a name & associated password might be the way to go
(and you then do something like 'dm password and become dm if you have the
appropriate name.)  This would be easy to change, and could keep it in the
existing dm file (could be nice so that you can change dm password without
recompiling the program.)

Tero Haatanen wrote:
>Yes, I wondered why the password was removed and changed to a name check. 
>Generally I would like that dm would be like other players and using 
>the player name and password. Of course there is a problem how to make
>those dm chacacters in a first place.

 I have problems really grasping what the last few lines are saying.  Is it
basically the saying that dm username=character name (ie, what is displayed
at the top of the status, vs other username, which is what uid crossfire is
running under or what the person specifies as name)

 I do note that we can verify the host a user is coming from (we can't
verify who they are on that host, but client/server doesn't help that out.)
 person who did most of
the work is no longer working on it, and left no documentation on what he
had really done so far.  Thus, if you want to start working on it/fixing
bugs in it, you have to spend quite a bit of time just figuring out what he
did/how he sends messages.

 It doesn't make things easier in that he also decided to use a library that
he wrote which does numerous things.  Library looks fairly nice, but lacks
any documentation.

 Certainly client/server is the way to go.  However, I hardly have the time
(or inclination for that matter) to really work on it much - there is still
a lot of stuff that needs to be done on the server side of things, and at
least I know what that code is doing.

 As for the idea of not coding stuff on the server that belongs on the
client, this is fine as long as the client goes someplace.  As I said, I
probably won't be working on it.

Why current client isn't enough to work with:  As I have previously said,
even on very fast connected networks (ie, client is running on the same
system as the server), there is a noticable lag in the client.  Plus there
are aspects of the client that are still missing - if you use the client,
you aren't getting full functionality of the game (I believe it was missing
container support, magic mapping, and seemed to ahve some bugs.)

 I am glad that at least someone is working on the client - this gives hope
that it is going someplace.  However, to me at least, the client has to be
working at least equally good as the present server method for many people
to switch over.

 If more people want to work on the client server, you are more than welcome
to.  I will give you whatever support you have, but you might want to
contact Tero Haatanen, since he still seems to be working on it, and may
know how things work better than I do.

 What I would really like is some documentation on how the existing stuff
works.  I have put notes in the Protocol file on the commands I added, and
some logic on how they work.  Getting this done is really mandatory if we
ever hope for clients beyond the one that is presently being worked on.  If
there is a file the clearly says has data is passed back and forth, people
can write their Java or NT or whatever else clients for it.

 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.  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.

 All that said, a few notes:

 A C version of the client/server does exist, and is reasonably playable.
Things that need to worked out to get if fully playable:

 1) Magic mapping spell does not work.
 2) Containers do not work
 3) things that depend on inventory order will not work, since client
re-orders objects (not much depends on this) A way to handle this might be
something like 'S->C:request item_id', and then the player on the client
clicks on whatever item
 4) Only supports XPM mode.  Pixmap mode should be supported.  I don't know
if there is any good reason to support font mode.
 5) Client doesn't really do any caching of data.  At mininum, I believe
client should be able to cache pixmaps/xpm images.  However, to do this
would mean increased start time, as client tells server what it already has.
The client does handle local commands, and keybindings are stored locally.
 6) Handling commands from the client.  Right now, it pretty much executes
the commands as it gets them.  Some form of buffering needs to be added,
along with looking at what we got, and perhaps running some out of order.

 As someone else said, there is little point getting into a discussion of
what the client should and should not do.  Unless it is rewritten from
scratch, what we have in place now will probably remain.

 One consideration that was made is that the client is assumed to not be
secure (with it being in source code, this is a good bet).  Thus,
information that the player does not know about will not be sent to him.
This means that for the visible map, only information about squares that he
can see in that area will be sent.  Something the next square off will not
be sent - player doesn't know about it.  Likewise, only basic item
information is sent (item name, and appropriate flags).  Thus, if the player
has a +1 sword but hasn't been identified, as far as the client knows, it is
just a sword that weighs a certain amount.

 That said, it will never be possible to have your character saved locally
on the system you are running the client on (without adding special hooks,
like a dump player command that the server can choose to respond to.)  And
at the same time, I never see moving players between servers to happen.
Hell, I could start up a server here and make a super character quite
easily.  I doubt people would like me to move it to some other server where
it is very difficult to do that.

 What the client/server needs more than anything else is for people to
actually work on the coding.  Saying how/why/what should be done is all
great and dandy, but we have already been through that.  Now it is just a
situation of actually doing it.

------------------------------------------------------------------------------
C++ conversion:

 I was more just curious to see how close/far it is.  I have no plans to
convert to C++ anytime in the future.  I thought I would just toss out my
findings.

 IF such a conversion was to take place, I think a line by line rewrite
would probably be in order.  Have the present code in one window, while you
type in the new code in another.  OF course, I doubt the end product of the
conversion would look a lot like the original.

 I do not think that keeping it in ANSI C will be a major limitation.  IF
nothing else, at least there are at least several people writing code for it
now, with many more at least having some idea what the code presently done.
AS previously said, after a conversion, only those involved will really know
much about it.

------------------------------------------------------------------------------
Message output:

 Well, there is already scrollbars in use in crossfire for the inventory and
look windows.  Since all that code is there, it would at least be worth
looking at and seeing if it can at least be generalized some.

 I don't really like the idea of using some toolkit just for scrollbar
usage.  Seems like overkill, and probably won't do much for performance
either.

 As for waiting for client:  There are at least a few notes - if scrollbar
support was added to server, it would be fairly straightforward to add it to
the client (most of the existing display code for the client is stuff from
the server, just copied over).  So certainly, if I add support in the server
for it, I would do the same for the client.

 The bigger issue is how long do I wait for the client to happen.  Work
started over a year ago on it, and I remember telling friends at the time
'message output is a client issue'.  I still believe it is, but unless I see
a strong indication that the client is what everyone will be using pretty
soon, I find it hard to keep waiting for that.

 Also, for sites that use X-terminals, a client/server model really adds
very little (since the client part will also be running a server, with
display going to the terminal).  The only major gain in that is that dealign
with x-errors won't need to be done.

------------------------------------------------------------------------------
 Player interaction:

 The one question I have on that is:  Why would you ever not save in scorn
then?  If you are high level, it is easy to get back to scorn to save (or
other well established in), and typically not that hard to get to where you
were.

 Hell, even if I was a high level person, I don't think I would save out in
the woods, just on the off chance that a higher level person might wander
buy.

 The other problem is that when a player saves on some other map, will that
map then reset?

 If not, it then becomes possible for some player to make it so a map can
not be accessed by any other players (cleans it out, rolls a boulder in such
a way that things are now blocked, etc).

 If it does recent, then I really doubt a player would want to save on a
map, only to rejoin the game later and found out that he has no safe exit
back and is surrounded by nasty monsters.

 Also, I don't know if I would ever really want an AI playing a character.
Suppose another player attacks you while you have left, and AI takes over.
Now AI thinks that usign that wand of lightning is a good idea, and uses
up.  You come back, to find out that your wand of lightning is out of
charges, and you needed it to kill the monster in the next room.

 Before any of this takes place, I think AI needs to be improved just so
monsters are much smarter (how often do you see vampires and other monsters
read scrolls that do them no good?)

------------------------------------------------------------------------------
Exp for levels:

 Experience is a little strange in crossfire in that how much experience you
get also depends on the relative level of the monster.

 If you notice, at first level you get a reasonable amount of exp for
killing kobolds.  At 10'th level, you get nothing.

 At the same time, if you are 8'th level and kill a troll (Say with an arrow
of assinating trolls) you get gobs of experience.  As you gain a few levels,
you don't.

 This is because the amount of exp you get depends on the relative level of
the monster compared to your level (I don't know if with teh skill code if
it is still over all level or skill level).  IT is pretty much monster
level/your level.  Thus, at 10'th level, you only get 10% as much exp for
killing a kobold as you did at first.

 This has some good effects and bad effects.  On the good side, it means
that you can't get to really high level by just killing monsters, since
eventually you get 0 exp for them (however, if exp was exponentional, it
would take a long time the other way).  On the other side, it means that it
can be frustrating at some levels, because the monsters you killed a level
or 2 ago don't really give you any exp, and you can't handle tougher ones
yet.

 Note that the above formula really makes a difference at low levels (going
from level 9 to 10 is a 10% difference.  Going from level 4 to 5 is a 25%
difference.  However, going to level 30 to 31 is around a 3% difference).
Thus, at low levels, the amount of exp you get for monsters drastically
varies one level to the next, while at high levels, it really doesn't change
much at all.

 This does tend to make it easy to gain levels fairly easily at some point -
once you can kill a high exp monster, it now becomes a quest just to find
them and kill them.

 I don't know if each level should be doubled, but I will concede that
things may be a bit flat right now (however, I would like to have the skill
code played out more to see how it works out).  So perhaps the exp should be
bumped up.  Do people think that relative exp for killing monsters is a good
or bad thing?

 --Mark