Re: Mist thoughts (long)

[mwedel@pyramid.com (Mark Wedel)]

>> 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)?
>

 This makes a bit of sense - obviously a DM character can not get on the
scoreboard, but being able to save a DM character could be very handy when
testing out maps.  Perhaps even a special 'save and quit' priveledge should
be granted.

 So I guess basically, the plan would be this:

 1) increase dm security by using name, password, and host/display name
access.  Any of these could be wildcarded.  For example, an entry like:

*:fireball:*

 Would just be like the old dm password option.  Something like

mwedel:magic:xmwedel

 Would restrict dm access to those named mwedel, and connecting from the
host xmwedel and providing the proper password.

2) Dm access over sockets (telnet session) would be allowed.  The telnet
stuff will probably go away when new client/server is done, but to add
support for dm of socket is just removing a couple lines of code (if it
involved a lot, I probably wouldn't do it.)

3) Once someone becomes dm, they can save their character, they just don't
go on the scoreboard.

 Anyone see any major problems with that?

>Client/server:
> 
>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.

 I am really glad someone is still doing serious work on the client stuff
(it is something I want to see happen).  From that last line above, does
that mean you plan to try, or you have tried?  IT seems to me it is more
just the effort of going throught and changing on all the code that uses it
more than anything else.

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

 The ideal thing would be a send image command (this could be very nice for
the future, in case support for special images is ever added.)  The problem
with that for magic mapping is that the spell uses different strategies
dependign if the system is color or not.  In the ideal world, the server
really should not care what the client is using (it just sends the data, let
the client dither it or whatever).  The problem I see with that approach for
the spell is that a dither magic mapping thing really may not be useful.

 (for a quick refresh on how magic mapping works:  On color systems, the
color of the object determines how that square appears on the magic mapping
spell (thus you can typically tell walls because they are all the same
color, and you know what they are).  For black on white, it basically just
draws the walls vs floors, and uses a choice of 2 stipple images or other
objects.)

 The problem I see with dithering is that the dither pattern for a wall and
floor could be quite close, even if the colors are different.  I also wonder
if we really want the client to deal with dithering and stuff (on the other
hand, we could just invoke some other image viewer (xv, whatever), and just
let that figure it out.  I may have to try capturing a magic mapping spell
and see what a black and white dithered results looks like.)

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

 Correct.  I think containers may also affect how some spells effect a
players items (like cancellation) - I don't know if it will descend into
containers or not.  Also, there are many specialized containers now (only
store certain objects, and weight reduction.)  From the code I looked over
(Assume it is erics), it looks like the idea was that the client would tell
the server to move item x to container y.  It just seems this doesn't work
quite right.

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

 Yes - I believe the only thing that depends on item order is improve
scrolls.  I think it would be nice for the server to be able to request a
list of items, and then let the player select them (this could be real nice
for stuff like identify - I want to identify x, y, and z first).  I suppose
that each time the client could send along the items that the applyer is
applyign to (like you said) - I like that idea in that it doesn't create
state in the server (if the server requests a list, it then needs to know
why it wanted that list when it gets it.)

 If applying items to items could be done in a clean fashion on the client,
I would really like it.  I guess for most things (identify), if it is not
supplied a list, it just goes in whatever order it wants.  For things like
weapon improvement, it could require an item/list to be provided or it
doesn't apply the item.

 In that way, a player doesn't need to know what cases he needs to specify
the item or not.  In the case of weapon improvement, it tells him.  In the
case of some spells, it just adds some functionality (in the case of other
spells, it does nothing at all.)

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

 Eric has said that a fair amount of the code is in place.  I will look into
finishing it up sometime I have free time (which might be quite a while from
now)

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

 Well, when I originally had time and did some work on client/server, I
added how much time each command takes.  Right now, I believe they either
take 1.0 time or 0.0 time (but there is nothing preventing them from taking
more or less.)

 What should probably be done on the server side is read all commands the
client sends and buffer them.  Have an option that the player sets on
whether he wants these extra commands executed (buffered) or thrown out
(flushed).

 And some extra timing/flags for certain commands that must always be
executed (can never be flushed).  Things like fire off and run off. 

 Also add some flags (in both commands on player setable) for commands that
can be executed out of order.  Most of these would probably be
administrative commands (who, maps, etc).  Thus, when you are paralyzed, you
could still do other things.  Also, there may be some other that fall into
this category (fire_off and run_off, for example.  Looking for those may
also improve perceived performance)

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

 Sounds great..

 --Mark