<br><br><div><span class="gmail_quote">On 8/27/05, <b class="gmail_sendername">Mark Wedel</b> &lt;<a href="mailto:mwedel@sonic.net">mwedel@sonic.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>&nbsp;&nbsp;Catching up on various points:<br><br>&nbsp;&nbsp;I have no plans, no do I expect to see any work on making crossfire multi<br>server distributed.&nbsp;&nbsp;The work to do that would be huge.&nbsp;&nbsp;At minimum, the game<br>almost needs to be thread safe, so why not just do that?&nbsp;&nbsp;With multi thread/core
<br>processors hitting the market soon, it makes more sense (sun's 32 thread cpu<br>will be out sometime soon for example).<br><br>For item stacking, since the issue here is related to performance, it would be<br>raw number of items that don't merge.&nbsp;&nbsp;This may be hokey, but the goal here is
<br>to improve efficiency by reducing number of objects on the space, so we don't<br>care actual nrof, weight, volume, whatever.&nbsp;&nbsp;We just care if the number of<br>objects is above X, objects should spill over.&nbsp;&nbsp;This also helps out on the
<br>client interface aspect.</blockquote><div><br>
&nbsp;In that case restricting the height of the stack to 3-5 objects
or so, and then use &quot;falling over&quot; 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.<br>
 <br>
</div></div><br>