I should just add, after the above:
TLDR: simplest short term solution is limit pickup/drop to X items/action
(tick). X could be a setting, so one can play around to what seems like a good
value. This would require fairly minimal change to the code (just the pickup
and drop logic to track
So I had thought that in an ideal rewrite, there is 1 thread per map, and 1
thread per player (and maybe a few others that do stuff in the background).
That keeps things relative simple - you just have per map and per player thread
locks - if the thread has the lock, it can do whatever it
> slowing down the command processing from the client doesn't help out.
If I understand correctly, the problem is less that commands are not
processed quickly enough, and more that the drop command must be fully
processed before the server can tick again. Here's a different (and
probably flawed)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello everybody,
I've got some old arch.tar files from 2008 (crossfire-1.11), 2009
(crossfire-1.12), 2011 (crossfire-1.60), 2012 (crossfire-1.70) and maybe
some data from 2017.
Interested?
Klaus
Am 18.02.2021 um 07:20 schrieb Mark Wedel:
> On
On 2021-03-23 00:27, Mark Wedel wrote:
On 3/22/21 11:58 AM, Nicolas Weeger wrote:
Hello.
One issue that happens is server delays when dealing with big loot.
For instance a player selling some thousands rods can stuck the
server for
some seconds... Or even dropping many items on a big pile
5 matches
Mail list logo
