[CF-Devel] client issues

[Mark Wedel]

dnh wrote:
>
     
     
     >
     
      I agree with all these points.
     
     >
     
     
     >
     
      Although I haven't actually got it to crash lately, long ago I did manage
     
     >
     
      to crash it with a large pile, but I thought it was fixed. Preston, what
     
     >
     
      version were you using?
     
     
 There is a general issue that the server will only let the outgoing data buffer
get so large before the server gives up on the client and closes the
connection.  This limit is 128K plus whatever buffering the OS does.

 So if you have a very large stack, and do something (like identification) that
causes lots of data to be sent, I guess the connection could be closed for that
reason.

 If thats the case, there isn't a lot to do but increase the size of the output
buffer.  But what I'm more interested in is whether the problem is a protocol
violation error, or some problem with the client (like some hard coded idea of
how much data it might get or the like)

>
     
     
     >
     
      I can't believe I forget to tell Mark about the phatom item problem, it is
     
     >
     
      defn there. I also turns up alot when you use the drop all command.
     
     
 I have a feeling dropall makes it apparant (that you have a phantom object),
but that is different than the cause.

 Basically, this phantom object problem can happen anytime the server removes an
object from the players inventory but does not tell the client it has done this.

 So the problem/fix is not being able to do something that makes these phantom
objects easily noticable, but instead the actual cause of the phantom object in
the first place (for example, one a while back was the demon icor - it slowly
decomposes and disappears, but the function that removed it did not tell the
client)

 It would not be hard to add a 'resend inventory' command to the
client/protocol, where the server basically tells the client to clear the
inventory and re-send it all.


>
     
     
     >
     
      I too would like a 'fire command, I have a golden unicorn horn but to
     
     >
     
      actually use it requires way to much work, its far better just to invoke
     
     >
     
      the prayer.
     
     
 It could certainly be argued that the range types should purely be a client
convenience issue, and that all actions are done through a 'fire direction
<spell/object>' protocol style command.  And the range is handled by the client
more as a memory feature.