[CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug

Mark Wedel mwedel at scruznet.com
Wed Jul 5 23:19:32 CDT 2000


Frank McKenney wrote:

>
     
      > 2) Stepping on a square with lots of objects on it (piles of sold
     
     >
     
      > stuff in shops
     
     >
     
      > for example, or if you have a narrow hallway and are killing a bunch
     
     >
     
      > of monsters
     
     >
     
      > on the same space)
     
     >
     
      > 3) Picking up that large pile of stuff.
     
     >
     
     
     >
     
      I've seen (2) and (3) after some combat in the Hall of Bones in the
     
     >
     
      "Ruins of Euthville" (can't believe it took me six _months_ to get the
     
     >
     
      pun!).  A guy can get killed while the server is still sending millio...
     
     >
     
      thousan...  hundre...  well, anyway, a _lot_ of "you can't pick
     
     >
     
      something up because you're already over your limit" messages.  Too bad
     
     >
     
      these can't be combined into one big "You failed to pick up 6,324 lbs of
     
     >
     
      assorted junk because you forgot to eat your Wheaties for breakfast"
     
     >
     
      message.
     
     
 Yeah - there isn't a perfect solution.  Possible idea are:

 1) Have piles fall over to other squares if they get too big.  This limits the
size of any one pile, but may not work really well in some cases like hte hall
of bones where many spaces may have big piles (stuff may end up falling over to
be all over the map or the like).

 2) Client only sends some number of items on any one space.  This complicates
things in that it adds complication to get the full stack of items (does the
client request it?  And if so, then it will probably re-send the initial small
stacking)  The problem is more that I don't really want to have the client have
to keep track of what it sent.

 One option might be to do something different if the character is running (more
likely to happen in combat).  Having lags is not nearly as big a deal if the
character is safe.  For that reason, fixing up delays in pickup is not a high
priority (and as actually realistic - it should take some signifcant amount of
time to pick up 20 items).  But the pickup speed can easily be fixed right now
by setting your pickup code appropriately so you don't pick up tons of stuff.


>
     
      The numbers _do_ get bigger.  Last time I checked, after 36732 ticks
     
     >
     
      (221.821) the longest tick was still only 1914 (2 secs).  I may hack the
     
     >
     
      client to report any ticks longer than (say) 500 ms to the "info" window
     
     >
     
      just so I can get a feel for when they occur.
     
     
 The times command actually comes from the server.

 The longest tick time can be sort of meaningless on a single player server - a
long map load or anything that blocks the server will create a long tick time.

 More important in my mind is the last 100 tick stats after doing combat or the
like - combat has lots of active objects & updates, and is also the most
important in terms of performance.  Performance while selling stuff really is
not all that important.


>
     
      Um.  Er.  Actually, the 486DX4-100 only takes about 20 minutes to build
     
     >
     
      the server (configure & makes), which puts it half the throughput of
     
     >
     
      your Sparc 10.  Now, if only I could write _documentation_ that fast
     
     >
     
      (e.g.  my "compilation" of information on the command window).
     
     >
     
     
     >
     
      Then there are the two Sun3/60s in the basement I never found the time
     
     >
     
      to get running...
     
     
 The 3/60 is really a dog by modern standards (its a 20 mhz 68020).  In terms of
crossfire, it may be sufficient now to run a black & white client, but xpm
display will likely be too slow.

    
    


More information about the crossfire mailing list