[CF List] Re: [CF:1366] CF 0.95.6: Character lost at sea, odd behavior following recovery

[Frank McKenney]

>
     
      Frank McKenney wrote:
     
     >
     
      > 
     
     >
     
      >   - 'Inventory:' items are no longer pluralized... until I drop them.
     
     >
     
      >     Once an item moves ot the 'You see:'  window, it gets pluralized.
     
     >
     
      >     If I pick it up again, the plural vanishes. E.g.,
     
     >
     
      > 
     
     >
     
      >     "20 gold coin" -> "20 gold coins" -> "20 gold coin"
     
     >
     
     
     >
     
       This is more because the client is supposed to handle the
     
     pluralization of
>
     
      words.  This was done somewhat to conserve bandwidth (save
     
     transmitting the
>
     
      names when the only thing that has changed is the number.)
     
     >
     
     
     >
     
       However, the client doesn't do that right now.
     
     
Okay. So this was not a result of somethign __I did during installation.
Got it.

--snip-- 
>
     
      >   - When picking up items, the 'You see:' window will frequently
     
     reset
>
     
      >     itself to display the top item on the stack rather than the items
     
     >
     
      >     surrounding the on(s) I picked up.
     
     >
     
     
     >
     
       Do you mean the scroll bar resets, or something different?  Which
     
     client are
>
     
      you using?
     
     
Sorry, thought I included that in my original message. Client and
Server 0.95.6.

Assume you walk up to a location with your typical post-combat 
Pile-o-Junque(tm). The top item in the window is initially the first 
item on the list, but you scroll down looking for "interesting" stuff.

Let's say there are three items in a row you want to pick up. You pick 
up the first, it pops into your 'Inventory:', and the 'You see:' window 
gets redrawn at the same point in the list, but without the item you 
just picked up. So far, all is normal, working as expected.

Then you mouse-click on the _second_ item. It, too, gets transferred to 
your inventory, and the 'You see:'  window gets redrawn.  _This_ time,
however, the top item in the 'You see:'  window is the item(s) on top of
the Pile-o-Junque.  So...  you scroll back down, finally relocate
the second item, and pick _it_ up.  Zap!  The 'You see:'  window is
redrawn to show the _top_ of the Pile-o-Junque(tm), and you've lost your
place again.

This is one example. The window "reset" may occur after you pick up the 
first item, or not until later - or not at all. It does occur fairly 
frequently, however.

>
     
      >   - The client dumps some new messages to stdout/stderr (I can't tell
     
     >
     
      >     which, since I'm capturing both):
     
     >
     
      > 
     
     >
     
      >     Playing on server type  Crossfire Server
     
     >
     
      > 
     
     >
     
      >     Couldn't open /dev/dsp: No such device
     
     >
     
     
     >
     
       the /dev/dsp means it didn't find a sound card/driver for your
     
     system.  Not
>
     
      critical - sounds are strictly optional and not used all that
     
     extensively
>
     
      anyways.
     
     
Right.  I just wanted to offer an "anchor" so you had some idea of
where the mesages were appearing.

>
     
      >     Could not find match for a sacred text of turn undead
     
     >
     
      >     Could not find match for a holy symbol
     
     >
     
     
     >
     
       Harmless but annoying.  The client tries to sort items of a similar
     
     type
>
     
      together (so all your weapons are together, all your armor, etc).  To
     
     do this,
>
     
      it parses the item_types file from which it makes it classifications. 
     
     Not all
>
     
      names are in that file - especially as new items are added.
     
     
Okay.  Not a problem for me as long as it doesn't represent some
insidious corruption problem (;-).  When one installs a "released"
version of something one does not know well, one tends to assume any
oddities are due to one's own clumsiness.

>
     
      >     Wont send command search - window oversized 186 175
     
     >
     
      >     Wont send command search - window oversized 189 178
     
     >
     
      >     ---etc---etc---etc---
     
     >
     
     
     >
     
       I'll remove those warnings.  With the split, it is theoretically
     
     possible for
>
     
      any number of commands to get cached by the server if you type them
     
     quickly or
>
     
      the character has a very slow speed. In order to keep a bit better
     
     interactive
>
     
      performance and not have the server get too far ahead, they use a
     
     mechanism so
>
     
      that if the client has sent so many more commands than the server has
     
     yet to
>
     
      process, the client won't send more commands to the server - that is
     
     what the
>
     
      above descibes.
     
     
Does the presence of these messages indicate that commands _were_ 
getting lost? Or just that I was approaching some limit?

I ask because of another "bug?"  I was about to report regarding lost
input.  Let's say I have a key (say 'P') defined to 'use_skill praying'
five times and I press 'P' four times quickly.  Under 0.93,x, this would
advance my 'Grace' value, if possible, by 20.  With 0.95.6 this will
often give me less than 20, and it _felt_ like this was worse in
situations with some activity (animation, e.g.  of your favorite
horde-of-choice).

>
     
       this can really happend if the key repeat rate on your system is
     
     pretty fast -
>
     
      each key generates a command to send to the server, and if you hold
     
     that key
>
     
      down, it is very easy for the client to have sent hundreds of commands
     
     to the
>
     
      server that have yet to be processed.  This mechanism is to try and
     
     limit that
>
     
      to a reasonable number.
     
     
I have been careful in most cases to use tap-tap-tap so I have some feel
for how many keystrokes I'm sending. 

What you are describing sounds like a "command buffer full" situation
and the server deciding to ignore input until things "calm down" a bit.
My server/client machine is a lowly 486DX4-100 which ran 0.93.x just
fine, but I realize Much Has Changed Since Then. It may simply be that my
machine doesn't have the horsepower CF 0.95.6 requires.

Still, I'd like to see how far I can get with it (see also: "glutton for
punishment" (;-)). Is there a "control knob" somewhere I can tweak to
control how/when the server makes this decision?

>
     
      >  2x Got update_item command for item we don't have (5794)
     
     ---snip near-duplicates--- 
>
     
       Those are more a problem/mystery.  IT basically means that the server
     
     believes
>
     
      the client has some object that the client does not think it has. The
     
     cause
>
     
      should be tracked down and fixed, since it means the client & server
     
     are not in
>
     
      a consistent state.  My guess on the cause of these is that an object
     
     in the
>
     
      players inventory has changed its tag value because it merged with
     
     something
>
     
      else, but the client still thinks it has the old tag value.  IT also
     
     means that
>
     
      try to access this object on the client won't work because the server
     
     won't
>
     
      claim any knowledge of it.
     
     
It sounds like these messages could be occurring because of the 'Arrows
Of Mystery' (;-) problem I reported at:

    
     
     http://bugzilla.real-time.com/show_bug.cgi?id=27
     
     

Can't drop them, can't sell them, can't fire them... um. Come to think 
of it, I never _did_  try _firing_ one (;-).

...

I realize this is taking up a bit of your time.  Is there a list
somewhere of these little 'quirks' in 0.95.6 that I can check before
posting here and "Bugzilla"?



Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
E-mail: 
     
     frank_mckenney at mindspring.com