[CF-Devel] bugs

[Mark Wedel]

  Note - when I say 'fixed in CVS', below, that may not literally be true - I 
still need to commit the changes, but that will likely happen in the next day or 
so after I make sure everything is working properly with no side effects.


Preston Crow wrote:
>
     
      I've noticed several bugs while playing at metalforge with gcfclient:
     
     >
     
     
     >
     
      When running, especially when entering a new map, the client often leaves
     
     >
     
      behind a copy of yourself.  In other words, when you move, the icon for
     
     >
     
      your character is left on the square you were just on.  My guess is that
     
     >
     
      this is some sort of race condition where you move to the next square
     
     >
     
      before the server has told the client everything about your view at your
     
     >
     
      previous square.  This happens quite frequently.
     
     
  I used to see this occasionaly, but was unable to reproduce it with the latest 
code.  I don't know if something was inadvetertently fixed, if I'm just unable 
to reproduce it, or something else  I didn't see it that often - I also need to 
dig further to see where the issue really is (in the server not calculating 
correct information, or is the client just not updating something properly 
because it is getting a new map command).


>
     
     
     >
     
      If you play with split windows, and try to manually enter a command, like:
     
     >
     
         'tell Friend Need any help?
     
     >
     
      it works just fine if your focus is on the info window (the window where
     
     >
     
      the input text box is), as you would expect.  However, if you do this with
     
     >
     
      your cursor in any other window (assuming you're using pointer focus, which
     
     >
     
      I expect most Unix users are), the apostrophe is interpreted correctly, but
     
     >
     
      the rest of the text seems to be ignored, and the client crashes on the
     
     >
     
      first space.  This is 100% repeatable.  If you have trouble reproducing it,
     
     >
     
      I'll rebuild (my binary is stripped) and get a stack trace in gdb.
     
     
  This is now fixed in CVS.


>
     
     
     >
     
      When you save the window positions and then restart, all the windows shift
     
     >
     
      down by the height of the titlebar, at least if you're using twm as your
     
     >
     
      window manager (I haven't tried anything else).  In my case, I just edited
     
     >
     
      the file by hand to subtract 19 from each y coordinate.  That's not
     
     >
     
      something we should expect people to need to do.
     
     
  Works properly with fvwm (that is, windows re-appear where specified).  I 
remember seeing something someplace that twm did something not quite right in 
that regard.  As of now, I'll just attribute this to a bug in twm.


>
     
     
     >
     
      When I have a container open and want to remove the top item, I
     
     >
     
      instinctively hit the comma key.  This results in some error message about
     
     >
     
      the container not fitting in itself instead of moving the item from the
     
     >
     
      container to my inventory.
     
     >
     
     
     
  There are two bugs in this area:

1) Server is trying to pick up the container into itself.  I made a trivial 
change so that it now will pick up the object in the containers inventory. 
However, the client is free to re-arrange the order compared to what the server 
things (and in fact, the unix clients do just that - they alphabetize it), so on 
to point #2

2) I've enhanced the clients 'take' command to have some smarts, and if the 
player has an open container, it will send a command move the top object as the 
client displays it to the players inventory.

  AT some level, the entire container issue on the client could get cleaned up. 
  At a basic level, all the server should need to know is what container(s) to 
put objects into that are picked up via auto pickup modes (and this is currently 
done by a container being applied).  The server really shouldn't need to know if 
a container is open so that objects dropped go into the container - in practice, 
that should all be handled by the client (move item from inventory to 
container).  Server will complain if move can't happen.

  This woudl also allow more complex handling - no reason why you couldn't have 
to open containers and just move stuff between them for example.  This requires 
the client to be a bit smarter, but not that much so.


>
     
      After applying a chest, the apply and examine commands ignore the items
     
     >
     
      that were just revealed.  The workaround is to either click on the item in
     
     >
     
      the look window or step off and back on the square.
     
     
  It wouldn't surprise me if there are other commands with similar issues.

  This was 'broken' when it was changed that the order of objects on the space 
isn't quite as important as long as we know the order to show them to the 
player.  Thus, whenever something changes on a space the player is on, he isn't 
automatically removed and re-inserted on top (making this change, as related to 
others, saves a bunch of cpu when talking about tons of spells flying about).

  I've put some code into the server so that objects from opening a chest go 
beneath the player, so it works properly.  However, there may be other cases 
where an object gets put on top of a player (like arrows).  The right thing 
would be for the client to always specify exactly what it wants to operate on.

>
     
     
     >
     
      When killing monsters in some pass-through walls (like the undead level of
     
     >
     
      the training tower in Lake Country), items from slain monsters show up
     
     >
     
      under the wall.  Such items are ignored by the active pickup mode and can
     
     >
     
      only be picked up by clicking on the individual objects.
     
     
  Fixed in CVS.  The stacking was a bit odd RE spaces that blocked view.


>
     
     
     >
     
      Something seems to be messed up with the Enchant Armour scrolls.  I'm told
     
     >
     
      that I'm not powerful enough to enchant things that I think I really should
     
     >
     
      be able to enchant.  This may be related to when I issue the 'skills
     
     >
     
      command and see some message about having something like 28473 out of 13
     
     >
     
      improvements (or whatever that message is; I can't bring it up from here).
     
     >
     
      At the very least, it would help if it would tell me something useful, like
     
     >
     
      "You must attain level 20 before improving this item."
     
     
  I've updated the message to tell you what level you need to be to be able to 
improve that armor piece.