VladimirMangos

This not most bad end: most bad, end up with corrupted character data saved in DB. That why better crash and _prevent_ save corrupted data that prevent crash and save corrupt by bug data. And then safe for restart in same way as mangosd restart safe after crash.

Mangos recently have good progress to prepare per-map threads code run in correct way without redundent locks and unsafe case. And cleary it need still more work. So ateempt _now_ do map threading too early. It unsafe and not provide full power. It also required hack lock adding in redom lines. Before 1) Pool system per-map rewrite 2) Creature/GO per-map guid generation/use (stuck by (1)) 3) proper locks for chat/group/guid/mail code 4) proper locks for global player list 5) Make per-map thread ready BG manager code 6) maybe something more

done for 0.12.

Thanks for fix versions. I add in [8754] rewrited version for more wide problematic cases.

If say specially about spell system: not exist in many cases so thing as single spell fix. Spells work base at spell effects, spell auras and spell proc event code that shared by many spells while it casted and affects apply. So touch code "for one spell" can change many spells work. Ofc, can exist simple cases for one spell really.

In [8753] attempt fix in another way.

If you read thread then you find sollution. No see reason repeat it each thread page.

Some guidstypes recently moved and will be moved more into per-map mode. This for example meaning that each map will have own guid counter and in general will affect only specific map/instance copy until unload. Ofc continents still moslty loaded always, but and in continent this also help slowdown guid counters increase. Not implemented yet move guid generationfor creatures/GOs to per-map mode also let not generate dynamic guids for static instance spawn, that also slow creature/GO guid counter grow. Possible item guids can be per-player. I not reseach this case but i think this possible and not remember real need in global item guids counting. Global guid counters still need for : player guids, pet numbers (maybe per player), guild ids, and auction ids (maybe per auctionhouse).

In [8748] and 0.12. Thank you. To all posters: Please not post patches to this thread! Only links if patches posted some where in another thread. Except maybe short hack patches maybe. I pin topic and add clarify about hack way fixes.

Implemented in [8747] in another way.

I can pin thread, if author plan have it up-to-date (remove oudated/unneeded options).

ObjectMgr::GenerateLowGuid - cleary outdated patch that not support recent move vehicle guid per map generation.

Crash report above reference to Creature

This is not easy do in one step. Or you meaning that `data` must be used instead?

What you meaning? It must be added with support for all platforms.... have add and then broken all not supported yet platfomr typs not acceptable.

Because name field not good describe stored value. And if someone use script this very easy fix... And if someone use script and don't know how fix so easy porblem then he must learn maybe something... instead just brainless use it.

In [8732]. Thank you

Until client accept this 0 version this is not important.

Added in [8728]. Thank you. In added version i rename 'online' field instead adding new. Ofc, this broken any scripts base at this field name, but i not care about anyone problem who can't fix some simple change

I mostly note about next time, i download already patch and review/test it

Just for note: please use another text hosting site, for example as github user you can use http://gist.github.com/ _infinity_ time persistent patch hosting possibility [added]About patch: nice idea indeed. But in fact you not need new field in DB You can use `online` for store realm id. I will add patch with like simplification.

Not sure that this good way (adding some vars in Aura) just for support 4 auras. As i look (2 cases) this glyph spells have spell like http://www.wowhead.com/?spell=63975 with scripting support. Poosible gliph just triggering apply this aura to target (up to 3 stack size)? and script affect increase duration of at fixed amount. Applied script aura not have duration itself and expected to be remove at targeted aura remove (last in stack) and then most good place remove in Aura::HandleSpellSpecificBoosts

In [8684]. Thank you!

Must be fixed in [8661]

Like checks is temporary fixes for stacking problem that expected in result fixed in some way as suggested in referenced thread in prev. post. In like case better make checks more clear show original source of problem (in most cases SpellIcon value).With this change in [8650]. Thank you