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

CF: misc notes.





Catching up on all my mail - this message is quite long, and contains various
not especially related topics.

 As a side note, any patches I received have been applied/merged in, but I
didn't respond to each individual message.  


> "E. Tobias Evans" <evanse@rpi.edu> wrote on Tue Mar 19 16:59:41 1996
>
>Also, I've noticed there are shloads of different kinds of weapons with 
>very little practical difference between them.  Why not make them act 
>more like real weapons.  For instance, assign them a quantity of 
>inertia depending on their shape and material that affects weapon 
>speed.  Also, durability and have them break down occasionally, 
>depending on the weapon, for instance a sword getting knicked or dull 
>or the chain on a morningstar breaking.   It seems like a waste to have 
>all those neat weapon symbols without any big difference between them.
>I'm not a comp.  Sci. type and these are just suggestions.  Thank you 
>very much for your concern.  

 Right now, the different weapons do have different speed values.  Use
a dagger and see what your weapon speed is.  Now, try picking up a chair.

 The weapon speeds were determined long before I ever got involved in the
game, but I will assume that the values chosen do correspond at least to some
level on physical values.

 As for breakage, this gets a bit harder.  In a real situation, a weapon that
has been used a lot should have a larger chance of breakage (stress, etc.)
This does get into a problem in which you have 20 different swords that
aren't grouped together simply because of slightly different usage.

 That said, you can just give weapons a constant chance.  But degradation
should probably be determined by what you are attack.  If you are attack
a blob, it is pretty unlikely that your sword will get damaged in any way -
however, if attack something in plate (or dragon scales), it probably would
be.  But how you determine each one gets pretty complicated (if you base
possible damage just on AC, this fails against monsters that have AC due
to high dexterity)

 So that pretty much leaves the idea of weapons just having a random chance
per any attack of being damaged (or perhaps, only chance of degradation
if a 1 is rolled to hit).  This isn`t that hard to do, but exact details
would need to be worked out.  The chance of a +4 weapon breaking should be
very small.

> Sam Glasby wrote on  Fri, 29 Mar 1996 00:26:45 -0700 (MST)
>Cc: sglasby@primenet.com
>        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.

 Unfortunately, docs seems to be about the last things updated.

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

 I haven't seen this - I'll have to try it.  A lot can depend on the
keyboard and key code mapping.

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

 It was certainly intentional that when using scrollmode the clearscreen
does nothing.  This was more an issue because there are quite a few areas
that clear the screen, and I found it quite annoying to have the screen cleared
all the time.

 I actually did put a scrollbar in the new client (it also deals better with
keeping track of colors in scrollback.)  I was going to put it in the server,
but had better things to do.  This is also because eventually because the
client is something that will be the default user environment, and it seemed
like a bit of a wasted effort to merge something that will eventually
go away.

>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

 Probably a nice idea.  For all the archetypes in place (and new ones,
for that matter), they can be left as is - when creating a new one, it isn't
too hard to figure out these values.  What would be a nice touch is to make
these easily setable in crossedit - just toggle a few buttons or something
and you get the values you want.  Just have the editor convert to this
number.

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

 All of this needs to be done - as previously said, docs tend to be the last
thing updated.

 If you do have questions about how something works, send me some mail.
I can't promise a timely reply, but there is a good chance I can give you
at least some useful information.



-- 
 --Mark