VladimirMangos

-Iquote exist only for GCC 3.5 or later as i remember... So you will break other OS with more old system compiler GCC version.

Must be GM.Chat in config. Lost line in commit ... [added] typo fixed in [6754], thank you for report.

what problem?

In rewrited form patch in [6740]. Thank you

"Data Base Client" Where you find this meaning? Why not "DataBase Content"?

In [6735]. Thank you

So before fixing this local problem need solve more generic problem with like spells. Creating table for custom spells please not suggest.

I think feature useful but can be implemented in partly different way. GM can do GM tasks in chat independent from in game GM state. Chat and in game mostly not dependent. So better add chat gm state independent from in game GM state with new option # GM.ChatLoginState # GM chat mode at login # Default: 2 (last save state) # 0 (disable) # 1 (enable) I will make change in this way...

No, 45401 and 45403 not have any spell proc auras and so adding this data useless. Instead must be spells that _triggering_ this spells casting. I not check 45401 case, but for 45403: spell triggred at enchantment applied from item 34538 (spell 45395) enchantment id = 3265 base at SpellItemEnchantments.dbc this applied spell 45396. Bad side for this that spell 45396 not exists

support

Talent is spell castead at learning and character loading. So if you in code not allow casting spell then this talent will not work but let apply talent points. If you want not allow apply telent points then you must not allow this in WorldSession::HandleLearnTalentOpcode

Similar patch already commited in [6710]. Anyway thank you

Pathc in [6696]. Thank you

Patch in [6690]. Thank you

Patch in [6687]. Thank you

Patch in [6687]. Thank you

Patch already in svn with some changes (added weeks ago). Added base at mangos.ru version.

For redirection need know redirect target in Unit::AddThreat this possible 2 ways: a) from aura (not work without changes: aura self casted and store redirect target data) :cool: from new variable in Unit (need initialize at spell cast) b1) if it initilize in effect then - we can have problem with not reset it at aura remove in case aura apply fail (aura applied after reset in current code) - at aura save and loading we will not set correctly redirect target - at spell cast if old aura active redirect target will be lost at old aura remove (aura remove before new apply but after redirect effect apply), cooldown prevent this for normal player but not for GM. b2) if it initilized in aura then - we not have like problems, but need way to get correct target in aura (aura self casted and then not have any target information for redirect target) a, b2 is hack, b1 isn't safe

repaired? It never work before in any mangos revision... Unclear how better implement it. Main problem: caster side aura not have information about target at apply (most important) and remove. For speed we can store redirection target guid in Unit field, but this will be very not safe code: effect called for target and caster aura for caster In mangos pet-target effects apply algo we will have call effect _before_ aura apply. This create problems: at load from saved data target lost (liitle problem for short working spells) But if aura failed to apply or replace other similar aura (caster/target aura versions) then we can in result or lost correct setting at aura replace (effect called before aura replace code) or have target setup at infinity time (until relogin). I have some "working" version but don't want add its as totally hack-like. Anyway name update patch applied in [6664]. Thank you

Patch in [6662]. Thank you

In [6625] with small variable names cleanup. Thank you

Are you sure? See other aura tick cases. Its always send full health/power amount (instead really gained) to heal/energize but real amount for lost. I think this is correct way as i read somewhere...

Fixed in [6617]. Thank you for pointing

just note: always use ++expr; instead expr++; ++expr is more fast version Real bug: who will be initilize uint8 team_points[2] to 0 and better use int for like local counters - memory used not important but access to uint8 more slow that for int Patch with chnages in [6614]. Thank you

anyone, waiting theluda for fix.