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

Misc notes/thoughts.




 This contains a few not esepcially related thoughts, that I might as
well toss out.

 First, as with the recent discussion of conversion to c++, I just gave
a quick try, and the main issue looks like it will be the naming of 
elements/structures that conflict with c++ (ie, class and protected are the
ones it immediately died on.)  I have a feeling that an initial conversion
to c++ would not be all that hard, but would incorporate a lot of changes,
since those structures/elements are used all over the place.

 Second:  Dm mode.  How many people actually use this?  I looked into this
after receiving a bug report, and noticed that the security for it is really
quite dismal.  Before, it was a global password, which probably wasn't all
that great.  But now, it just does a quick name check.  Since you can set
your name in the initial telnet command, this really just ammounts to a simple
password.  But even more the problem is that the name everyone iherits by
default is that that the process runs under.

 This, if I set up a server and run it under an account called master, and
also have master in the password file, then by default, any player can
become dm without doing anything special except typing 'dm.  This is
probably worse than before.

 The other thing is that you can not become dm from a socket.  I actually
find that somewhat annoying when all you want to do is reset a map or
something.

 So I have 2 questions:  Any reason not to just go back to a global
password for dm access?  It gives just as good security as exists now.  Or
should dm protection be improved (also include authorized hosts/displays
to become dm from.  Or may add passwords in addition to just names - at
least it would be 2 things that need to be guessed.)  The other is, is there
really any reason to restrict dm access from sockets?  Ok.  That is more
than 2 questions.

 Third:  Message output.  A few days ago, I think I said I would probably
come up with something that would do paging.  But what someone just mentioned
made a lot of sense - add a scrollbar.  Originally, it was my opinion
that this is somethign that is better suited for the client (actually,
it is still my opinion, but the client is going anyplace right now.)  I'll
have to look at the code, and see how generic some of the scrollbar code
is, and if it isn't very generic, make is so.  I guess things will also be
a little funky between scroll vs wrap (wrap is still useful, because scrolling
can take a bit of time/bandwidth if you are getting a lot of messages,
while wrap takes very little, so there is reason to keep in place.)  Any
suggestions/thoughts on this?

 Thats all.

 --Mark