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.