CF: A union of like interests

[Sam Glasby <sglasby@primenet.com>]

----
	Hello, all.  Subscribed to the list recently
after compiling Crossfire again on my Linux box.
(I intend to do some development...hopefully of
a substantial nature, adding to Crossfire).

	Coincidentally, I noticed that on Usenet,
rec.games.ultima.dragons was approved & added at
roughly the same time, and I subscribed.

	Hence, when I saw the Ultima folks
making noise about how nice it would be if someone
wrote an Ultima-type game with an editor... :-)
I pointed them to Crossfire resources, and if any
are seriously interested in the idea, they will not
be starting from scratch.  Seems to me our two 
communities have a lot in common.



	Regarding Crossfire development:
	--------------------------------
	I have a perfectly wonderful Linux box (Epithemus),
with a comfy GCC + Emacs setup (with RCS of course!)
and plan to do development work on Crossfire,
as a labor of love.  (I've wanted a multiplayer
roguelike/Ultimalike which was editable for years,
and Crossfire is even under GNU license...color
me happy!)

	I have played some Crossfire on my lonely box
(dynamic IP via PPP to primenet.com, or dialup
to other local Linux boxen), as well as over
a 14.4 PPP line (14.4 on the other end, so the
USR 28.8 on my end doesn't help :-( ) and found
that multiplayer method too slow.

	So, I have some ideas on interface niceties,
config files, and so on, and I've read all the docs
that came with 0.92.3, but I'm not familiar with
the overall structure of Crossfire, and the docs
are somewhat sparse.  Obviously, we need to write more
and better, and more up-to-date, docs.

	What else is needed, on nicety/interface
levels, as well as low-level within Crossfire
(client/server/editor)?

	I have some thoughts I'd like to bounce off others,
and get some feedback...and how many of the coding
folk listed in credits/source are on the list these days?

Interface Nicety problems:
--------------------------
o I observed (with 0.91.8, and moreso with 0.92.3)
  some problems with keybindings from def_keys
  which I believe are related to overlapping of
  keybindings on the same key, one with, and one without,
  a mode (like Run-mode) applied.
  Example:  '<' bound to "rotateinventory -1"
            ',' bound to "pickup"
  '<' acts like it is unbound...until manually bound
  by player.  In 0.92.3 I had this problem with 'A'
  also!  (Hard to play without that!  :-)
  Has anyone else seen this?

o "clearinfo" does nothing when "scroll" is on.
  Sounds intentional, given the appearance of "scroll"
  (text hugs bottom), I propose a more configurable 
  behavior:
  scrollmode on/off (by "scroll" and "wrap") determines
  whether the text in message window scrolls, or wraps
  from bottom-->top.
  clearmode on/off (by "cleartop" and "clearbottom")
  determines whether text hugs the top of the screen
  (and then goes down, to scroll or not as per scrollmode)
  or or hugs the bottom of the screen, to scroll
  until window full, and then scroll/wrap as per scrollmode.
  Both current behaviors (scroll on/off) could be achieved
  in this fashion, as well as one which I would favor
  for default..."scroll" + "cleartop", wherein text
  sticks to the top after "clearinfo", and then scrolls
  down, scrolling when the window fills.

  Something could be done with an X scrollbar also.
  (particularly for long texts...like "unbind -g")

o It would be a major change, but likely worthwhile
  as far as human-readability goes, to convert the
  parsing of archetype files from using decimal
  representation for values (stuff like
  immunities: 1235672), to something which would
  take also:
  Hex representation as per C (immunities: 0xFF34AE7B)
  and/or octal, and
  Symbolic notation with logical operators:
  immunities: AF_FIRE & AF_MAGIC & AF_CONFUSION

  This would be a big job, but perhaps worthwhile,
  drawbacks include the time & effort to create
  this code and convert the archetypes (though
  the latter could be automated, or obivated
  since the parser could still take decimal 
  representation), and the increased size of
  the archetype files.  One could develop a byte-compiled
  version, to be recompiled on the fly if the
  source was newer, but again that's a lot of work.

  Also true is that the functionality of the symbolic
  notation (very helpful to comprehension) could
  be implented on the editor level...turning number
  soup into readable texts.  Probably the least
  amount of code to add.


	At any rate, I'd like to do, or help with these
and any other changes which folks are working on,
and I am also interested in writing documentation.
I see a big need right now for programmer-level
documentation on how Crossfire works (data, control
structure, etc.)
	I plan to start such a document as I explore the
source (and keep notes on what I find), if anyone
has notes/docs of that sort, send them to me and I shall
add their content to whatever sort of doc I end up 
creating.  I also have thoughts about revising/updating
some existing docs.

	Hope to hear some feedback...I look forward to 
the 1.0 release of Crossfire, surely it will be a game to
rival any in existence!

Sam Glasby <sglasby@primenet.com>