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 is not noticable client side, I found it while coding related stuff.

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

Due to recent changes (spline movement) it will take me bit longer to fulfill my side of the agreement.

All movement logic will have to be made from scratch. The good news are that the result, as I see it, will be more centralized, clear code.

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]

I have do idea what third packed is used for...

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)

PD2: After changing Visibility.AIRelocationNotifyDelay or Visibility.NotifyPeriod from lower value to higher... and tip .reload config CPU don't decrease from 100% of CPU use until next server reboot / crash.

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)"

I'm not sure if we have taxies teleporting to other maps (or this packet is for transports too?)

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