SilverIce

In [11825]. Thank you

It was added two days ago

Need implement gameobject_addon table that will hold additional per-guid gameobject data - in current case it's elevator's path rotation(four GAMEOBJECT_PARENTROTATION fields)

Thank you, nice catch This should be noticeable when server changes MOVE_RUN_BACK/MOVE_SWIM_BACK speed and it becames too low or grows unexpectedly

Creature::ForcedDespawn, RFD crashs should be fixed in [11777]

Fixed in [11777]. Thanks for reporting

I think now movement part of mmap code can be simplified alot or maybe removed at all

Gnarlee, that issue has been fixed in [11667]

MSG_MOVE_SET_COLLISION_HGT broadcasted to eveyone except mover: {mover_guid, MovementInfo, float height}. You may look at how it implemented here

In [11193]. Thank you very much kero99 and Undergarun

The problems that were reported by players are not such a big problem(already fixed) compared to CPU load problem, which is a mystery for me

We have taken the most effective parts from the both branches and merged them. It's even possible it would bring more performance than second branch! (It's assumption only, testing required) Please, compare: merged branch: https://github.com/SilverIce/mangos/tree/relocation_opt_merged with branch2: https://github.com/SilverIce/mangos/tree/visibility_op2_simplified

Thank you for tests, Undergarun As i can see from your post, AI notifications consumes much more CPU's power(~30%) than visibility update operations (~5% only) I will take look at it. Both branches(old_way and simplified) have this problem?

my congratz, zergtmn

Thank you very much for your tests branch1 compilation fixed now: i hadn't too much time to fix it earlier

fixed in [10819]

Thanks, i will wait for your test results Second branch updated, AI relocation notifications optimized little more

Seems i have found dependence: for example feral charge parabola have constant max height distance -- 0.49 Z max = ((Duration^2) * vertical_acceleration) / 8, Duration is movement time, in seconds example: Duration vertical_acceleration Z max feral charge: 0.166 145.16 0.4999 0.346 33.41 0.4999 death grip: 0.131 233.09 0.4999 0.315 40.31 0.4999 have fun P.S. that movement should also relocate player\\creature on server side, there shouldn't be any instant relocations like i saw in first post "GetMap()->CreatureRelocation((Creature*)this, x, y, z, o)"

No, transport teleports players in Transopt::Update (currently its safe, because it called from one thread) There are a lot of taxi paths that teleports players to another map

As i can see, you have recognized movement packets handlers as thread safe - almost all _QUERY_* handlers are threadsafe too.. most of them are constant queries to ObjectManager's storage

Both branches updated to last rev. Ambal is right, better to test branch2, it filters player's relocations in much effective way

Hi, This patch reduces amount of visibility update and AI relocation notification operations -- in this way you will get some performance speedup. In original sources these functions called too frequently - this wastes power of CPUs for nothing. We should filter redundant visibility update operations. Some statistics: optimization decreases amount of visibility update operations in 8-10 times(expected decrease in CPU utilization about 15-20%). Currently these are two different ways of how it should be optimized. The first way: Visibility and AI notification operations processed each N milliseconds. To avoid CPU spikes these operations processed simultaneously. Possible problem: as a result of fixed time interval between visibility updates, its impossible to increase frequency of these operations for fast moving players/creatures. branch1: https://github.com/SilverIce/mangos/tree/visibility_optimization_old_way Second way: Can't say too much. No problems with visibility of fast moving units: frequency of visibility updates scales with unit's speed. branch2: https://github.com/SilverIce/mangos/tree/visibility_op2_simplified Note: added few new config setting to find optimal parameters, so don't forget update your config files Also, these config options could be reloaded during runtime: you can experiment with these options without restarting I think second way is more progressive, but I don't know performance difference. Please, test the patches, feel free to comment, report test results..

As i can see - fix works, even with incorrect structure of empty pet name query packet

If my understanding is correct this is some kind of messaging system Idea is good as for me.. but i think manager shouldn't be instanced (one manager per map probably?) few months time ago i had written this - http://github.com/SilverIce/mangos/commits/singals_code_usage idea is same - few objects-listeners receives messages from object-observer and handle messages in own way ( it could be used to inform auras about interrupt/trigger events, inform AI etc)

Current code broadcasts packets even when object is not in world\\map. In most cases it cause no problems, sometimes it cause crashes(like packet broadcasting via SendMessageToSetExcept function). Patch shouldn't cause any server side problems, but possible some client-side bugs. Please test it and report http://paste2.org/p/915086