Michael Toennies wrote: > The effect gets mad, if you enter the dragon hangar! Do it! > The game start to be frozen!! Tray praying. You will see, that every second > you stay > in the hangar (and you only enter, do nothing) the server goes more down in > periodical steps. > If you leave, all is fine! > > Do it on the 95.7 server - nothing!! The effect is simply not in this > version and not in a version > <95.7 which i can remember. Actually, the performance seems very inconsistant. On my home system (dual p3-500, 256 mb ram), I went into the dragon hangar and wandered into the middle of the melee. Perfomance/cpu time of the server actually was not that bad (less than 10% of the cpu time). Since the client was on the same system, the big server was actually the x-server (taking around 40% of the cpu time). I'm not sure of these percentages are overall cpu time or that by cpu (ie, system has 200% cpu total). These numbers are what is reported by top. But at some point, the server started chewing up much more cpu time. And this started appearing in the output: BUG: get_attack_mode(): freed object Tracking this back, the bad object seems to go back to line 428 in server/monster.c (enemy). Stepping through the debugger, even at that point, the enemy it is passing has been freed. Further tracking reveals that find_enemy is returning a freed pointer. Final tracking realizes that the friendly object list has a free object on it, and it is using that. I'll put some check into get_nearest_player to check for freed objects and do something intelligent when it finds one on the friendly list (like not use it and update the friendly). I'm not sure how it got in that state originally, and I'm not sure if that is a factor at all in poor performance. But I'll put a fix in for that, and if it helps at all. IF nothing else, it fixes a potentially serious bug.