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

Mark Wedel mwedel at scruznet.com
Wed Jun 28 01:21:12 CDT 2000


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.  I think at one time I had
attempted to write the client in to do that, but it did it incorrectly on enough
items it appeared more annoying than the usefulness gained.

 A better approach would be to only send the name when the number of items
change which also causes a change in the plural form (basically, if old or
number of items =1, resend name).  The problem with that approach is that the
function that updates the client doesn't know the old value, and even many
calling functions don't explicity know the value.  I suppose an old_nrof field
could be added to the object structure and use that to know if we should update
the name or not.

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

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

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

>
     
          Wont send command search - window oversized 186 175
     
     >
     
          Wont send command search - window oversized 189 178
     
     >
     
          ---etc---etc---etc---
     
     >
     
          Wont send command search - window oversized 236 225
     
     >
     
          Wont send command search - window oversized 236 225
     
     >
     
          Wont send command search - window oversized 236 225
     
     
 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.

 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.

>
     
       2x Got update_item command for item we don't have (5794)
     
     >
     
       2x Got update_item command for item we don't have (5908)
     
     >
     
       2x Got update_item command for item we don't have (5908)
     
     >
     
       2x Got update_item command for item we don't have (5794)
     
     
 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.

    
    


More information about the crossfire mailing list