VladimirMangos

In fact errors in last MysteriousSouL's post related to core. First possible fixed in [10332-10333] Second just some changed spell data after switch possible. Ofc, it need fixed, but can't affect any other except this spell work. Something later. Not have personally time for it.

Some auras applied independently for both weapon, but we not save item connected to aura at aurra save. in result at loading aura lost connection with cast item and considered in checks as "another weapon" aura, in result we have some "cheating" double buff result for 2h weapon. but it also in result this character can't save. Must be fixed into [10332-10333]

Lol thread closed.

When you plan code changes you must ask: 1) what problems with current code? Array for example. 2) what will be improved in code/in performence/in error catching/later code support if change in planned way... 3) what losses will be from code changes (less clean code, performence losses, hard error catching, more hard support ) (2) must be > (1) + (3)

with any player basic energy regeneration.

Lol, just guid how not need write bug reports... I am glad for you that you can repeat, but maybe write _what_ buf you cast.... In fact totally not important is this with all buf that _you_ tst or not happens. Please always write what specific spell you use for repeat.

Then possible fixed in [10319]

I meaning that in mangos nothing changes in character list show code long time.

Possible fixed in [10319]. For other impossible find any useful info by only crash daya without repeating steps. [added]Thread will closed at any attempt add more unrelated by crash data crashes to discussed.

Ah, i see. I read that some account_data form pre-3.3.5 create problems with 3.3.5 client. But this in some way can affect server if client start work incorrectly. I suggest drop account_data for this account (you will lost macros, some other settings reset to default). And look at affect.

uint8 mostly used in placers where original value stored in uint8 field, in packet from client, or send to client as uint8 field, sometime if it good pack with other small fields in less size structure...

In [10317]. Thank you

In [s0088]. Thank you

It done already by creature_model_info.modelid_other_team (used specially for totems currently)

As Lynx3d point ot me old Aura::IsDeleted als has been broken from start (i forgot set to true) line in my commit It still need at holder level because must prevent calls for example spell boosts at apply if aura removed at apply by some reason. I think your fix correct. I look related code for be sure. [added]In [10315] thank you I add IsDeleted() check to SpellAuraHolder::ApplyAuraModifiers for sure that if aura holder вудувеув at some aura apply next auras in holder not wrongly applied after holder deleting.

Before aura can be listed in Unit aura list sometime after deleting because locked and in recursive code possible cases when it need checks in past. Now single way access aura from unit is holder way (aura mods lists updated at delete directly) and holder remove also pointer to auara at delete. Possible case when aura deleted from own aura apply/update code in like case instead check deleted flag possible use new fast way access code for holder auras: aura->GetHolder()->GetAuraByEffect(aura->GetEffIndex()) Main isDeleted functionality moved to holder list that replace aura list. I will drop field in next commit. Thank you for catch outdated code.

You better find why in your code for pet called random movegen apply when mangos master code cleary not allow this for default movegens.

And how this related to mangos case? I already write:

In [10312]. Thank you

Nothing in referenced rev. range modified in character login code.

about vector/array... if you have fixed elements amount and need always existed storage then array can be better.

But function return GetSummonPoint(x, y, z, orient); in summon case that set for all existed summon types... Ok, except used for EffectSummonPet. But MotionMaster::Initialize call selectMovementGenerator that always select follow movegen for unit with owner...

mangos-0.12 in proccess slow move step by step sync with mangos master (backporting appropriate commits and commit parts). In result any mangos-0.12 changes different from mangos master accepted only in case some code part expected to be different for 2.4.3 client in result client differences. movegens expected to be exactly same work (except client flags) in mangos-0.12 and master. So if some porblem exist in mangos-0.12 and not exist in mangos master then or (1) some commit with fix not backported, or (2) backproted wrongly. So best way compare related code work in mangos-0.12 and master and detect problematic code differecnes. If related not backported commit not high dependent from early commits i can backport it in prio for fix crash if you point to like commit.

How install UDB must be read at UDB site.

In fact existed mangos code must place all > 85 player in same bg instance as 85 player level. So if any problem then this is problem with client...