VladimirMangos

3.x client have talent preview mode that first let set learned talents and then learn its all in one step. or... yes

apply to characters DB sql updates in range 10051+1 to 10342.

Most easy way "instancinate" part of map (area) is use phases. So find not used dummy aura spell, implement it at apply set phase and remove remove it, and auto-appy aura ar area enter using data in spell_area table.

LordJZ meaning: not need access to DB when all data already in memory. I test case without reload respose show and it show as expected. in instantly and if player relogin If you known special case when this not work, then please describe this step by step. Ok, i find in current code redundent Db access and in another cases, so will cleanup its.

In [10352]. Thank you. With small changes mostly code style.

Useless discussion. As already say client have 2 login mode now, and and in one email _must_ be but in another (old, used mangos) it forbided as account name. For switch to new way login must be implemented new bn.net 2 login system. Is it totally not real currently. Thread closed. Some ppl forgot: this forum not for discussing blizzard products, but only for discussion mangos core work. If some one not see difference then this his personal problem. Closed.

About first spell part of patch. First, I find this note "Just as a fun note. Let a warlock equip this to see if it would proc and it WILL proc for warlocks. He got the +600 haste buff.". Possible this applied to all caster classes as one from cases. Second. Curretly 2 spell cases look like mixed duplicates. Possible 2 cases maybed: make own versions for spels with more compressed switch format. Or make static array array[MAX_CLASSES][3][2] instead... then check from duplcate proc also can be make as loop for class-specific spell cases...

Hmm, related second fix, i not see your patch and add in [10349] own version. But looking at your version after see that forgot about no offhand case. So this small fix included from your version in [10351]. When i read comments i not see any references for select weapon by next attack time.

Just useless discussion. How you will count, in rabbits or monkeys? Something work, something not... Closed.

Mangos core without patches not have this bg working...

Implemented into [10349]

Is all listed problems fixed now? Or can be clarify what from not fixed yet?

Above has been reference to spellmod related editing for fix and this help, so crash not related in any form to account_data and login. spellmod case fixed. I will not allow make from thread poster personal crash log with unrelated crash problems. Closed.

for normal instanced BG you can use: .debug bg on/off that make auto start bg at first character in queue.

Already fixed in [10346]

i already fix it in [10347], but already recieved achievements still will be applied...

Thank you for reporting. Fixed in [10346].

I at this moment can only say (not check real sources) that if fake player class usage remove then i have lot less resistance against adding ahbot to core. Ofc, for real comments i need look sources at some moment...

while(GetPlayer()->GetMotionMaster()->GetCurrentMovementGeneratorType()==FLIGHT_MOTION_TYPE) check top movement generator. GetPlayer()->GetMotionMaster()->MovementExpired(false); remove top movegen unconditionaly except single case: if (empty() || size() == 1) when it single existed movegen. This is impossible in normal way becase player always has idle movgen as most deep. ofc, if as you say, "custom patches" modify something in movegens in wrong way it can be sources of problem.

.ticket command fixed in [10341]. Thank you for report other most be fixed in prev. commit.

Must be fixed in [10340].

yes, this is cleary see at proper test, but problem has been in absent this test I will fix this case and look similar cases.

Your report absent most important part: example tested command... I am for example can't reproduce crash You can include or skip own generic conclusions and etc but if you make report you must if possible provide _exactly_ way for repeat problem. Because as always conclusions about _all_ something heppen (.learn command use crash always) proved as wrong just by random test. So better provide exactly tested data instead conclusions. [added] Ok, i find way repeat, but as i say this not all cases, but specific. So all what i write about still good recommendation for reports. More checked info and only optional conclusions as addition.

when you send unknown for client player guid, client ask name info proccessed at server side in WorldSession::HandleNameQueryOpcode so you can overwrited it. I not like by self using fake players, but agree that use fake guid at least better that use fake player object. I am not 100% sure that this possible and ofc will required modify handlers for this case.But if possible this will better. Still not find time make tests with some creature use in this way...

First add term spell application as all auras from same spell cast applied to some target. This can be single aura or up to 3 auras. Some spell can have one aura at one target and another at another target (2 application at different targets) In short: before we store each auras effect of spell application independent;y, so when we need for example remove or find another aura from application then we need search in all auras list and sometime select wrong auras because its not has been connected in any way. Now we have aura holder as storage for all auras for some spell application. This let easy access to another auras in applications and remove all auras from application in one step without its search in list. aura holder list replace old aura list. For server side aura holder let store common data for all auras in spell application in single place (holder) instead duplicate data (with possible desyn errors and etc) in aura objects. From client side view aura holder is what you see as buff/debuff icon for character or target. So aura holder adding made server objects structure more similar visible client objects structure.