On 8/27/05, Mark Wedel <[EMAIL PROTECTED]> wrote:
In that case restricting the height of the stack to 3-5 objects or so, and then use "falling over" to adjacent squares that have 2 less objects or more (this will cause nice mountains of junk to form that have peaks, similar to how items stack in the real world), and not counting no_pick and weight 0 objects should work speeding up the server.
Catching up on various points:
I have no plans, no do I expect to see any work on making crossfire multi
server distributed. The work to do that would be huge. At minimum, the game
almost needs to be thread safe, so why not just do that? With multi thread/core
processors hitting the market soon, it makes more sense (sun's 32 thread cpu
will be out sometime soon for example).
For item stacking, since the issue here is related to performance, it would be
raw number of items that don't merge. This may be hokey, but the goal here is
to improve efficiency by reducing number of objects on the space, so we don't
care actual nrof, weight, volume, whatever. We just care if the number of
objects is above X, objects should spill over. This also helps out on the
client interface aspect.
In that case restricting the height of the stack to 3-5 objects or so, and then use "falling over" to adjacent squares that have 2 less objects or more (this will cause nice mountains of junk to form that have peaks, similar to how items stack in the real world), and not counting no_pick and weight 0 objects should work speeding up the server.
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
