VladimirMangos

So current functionality incorrect anyway. 1) I think patch correct 2) for ritual summoning created same second step portal In meeting case first player click of meeting stone GO -> cast 61994 -> creating GO 179944 -> click by second player -> cast player summon spell ? In ritual case cast 698 -> creating GO 194108 -> 2 clicks -> cast 61993 instead not existed 62330 -> creating GO 194097 (stable 10 min portal) -> first player click or ritual portal -> cast 59782 -> creating GO 179944 -> click by second player -> cast player summon spell ? Problem in "cast player summon spell ?". In recent GO 179944 data click spell is 59782 that create similar portal and to infinity... Old data have 7720 that will work. Anyway this need resolved by confirmation щиту from data wrong/outdated

Ok, i resolve GO data absent problem with help DB devs providing testing data. So no problem now from this side.

Main problem for me currently for review or fix in another way is absent GO template (Entry: 194108) in DB. So waiting DB update...

Patch in [7326]. Thank you

Not best way for check. Maybe it can be checked in same way as current exopecption by spelle family name/flags pair?

this is not mangos-prefered way.In most cases we prefere do integrity check and restore expected state for character data at character loading. In code version added in [7325]. Thank you for pointing to problems and way to fix show.

In [7324]. Thank you

In [7323]. Thank you

Ok.Maybe i wrong or something chnage from times when i use reload scripts. Any way currently impossinle this do in result existance AI objects allocated in script DLL

In [7321] frozen aura state will remove only if no other frozen auuras at raget. Is or not some auras stacked nother question.

In [7320]. But i not sure that generic spell damage code work correct currently: Spell::EffectWeaponDmg correctly calculate spell effect damage and assigne it to Spell::m_damage BUT when m_damage finally converted to real damage in Spell::DoAllEffectOnTarget in part: Called That call And app,y to spell damage that include spell bonuses already spell bonuses one more time.... I think melee/weapon check at speel damage school is wrong. Related spell have holy damage but it _still_ weapon damage I will discuss this with DiSlord.

You are right as often. I testing another version. Also note that i also make errors and ApoC (thanks) fix its. That for what team exist also. I not expect negative way interpretation of my post. I just attempt show why this incorrect way.

Anyway why used hardcoded percent value if this percent stored in spell data... [addded] Also patch cleary wrong for "a chance to deal {0.45*Min Weap Damage+0.45*0.23*SpellPower} to {0.45*Max Weap Damage+0.45*0.23*SpellPower} additional Holy damage" Instead apply 0.45 to spell damage (note: this is not harcoded value but part of spell effect data) patch apply 0.45 to total bonus _and_ in result we have: weapon damage _corectly_ by spell effect code have applied 45% bonus and then total bonus lost 65% percents so for weapon bonus part. So is wrong way.

What about stacked auars at target and remove only one from? For example root and stun... remove one from its will remove frozen state.

In [7314]. Thank you

This is _not_true_, i personally reload scripting lib in past and more recently and if AI objects not created this is not problems. script lib reloaded and replaced.Exist some specific for Windows/Unix. In windows case you need reload with new name script lib used that allowed by command. Ofc, maybe some additiona code required for current used numbering for scripts name schame...

More correctly: can even be relaoded in past. After adding AI classes this motly impossible without crash. AI classes allocated at script DLL side and can't be correctly recreated at scriptlib reloading, and more: it still pointed in Crearture data. [added]Ah, already remarked. At reloading we also lost AI state and this in some cases important like scripted instances...

ok, please post in thread when ready...

its not saved but calculated by quest completness state and level for loaded player. So answer: never. And please _avoid_ next time creating threads in random unrelated forum sections.

its not saved but calculated by quest completness state and level for loaded player. Anyway, what do this thread in this section...

mangos-0.12 branch not planned to be deleted. It can be stop updated at some moment in future in result increasing problems with patch backporting but not deleted.

In [7300] added similar patch suggested by balrok. But thank you anyway

Hmm, strange this is not expected and no any changes in commit that can affect DBC extraction.Maybe your old DBC has been not full propertly extracted prev. time...

Starting from [7298] MaNGOS support only client version 3.0.9 (9551) at master branch (Client 2.4.3 still limited supported at mangos-0.12 branch) This is monor client update switch. You need update DBC files. Maps files same as for 3.0.8a (if you regenerate its for [7291]) so not need update. This is checked. Vmaps files also expected same (but not checked) Tag planned for adding for simplify find last 3.0.8a supported commit

this is _not_ mangos choice, this is client instability and strange spell system calculations in some cases for levels > 100