VladimirMangos

You sure that in DB stored _full_ player guid? With big chance it must be uint32 low guid part In like case read must be ObjectGuid(HIGUID_PLAYER, fields[1].GetUInt32()) This immortant if at some moment mangos start use !=0 player high guid part.

Expected that remove spell already remove dependent spells also... if bug exist then it in removespell code. For normal cases i not remember like problem so in general dependent spells for like cases removed propertly. Check .unlearn for same spells and you will see that dependent spells also unlearned.

Topic moved to The Community Cafe

Why not in spell proc for dots...

Possible sollution: use in follower movegen calculated from target movegen expect/future pos instead current not updated and possible outdated position. Because player in normal state have idle movegen this can be implemented in clear way: follow/chase/etc movegen ask target top movegen for expected "right" pos instead use formal possition. Don't know how this will affect CPU usage from other side.

old mangos svn in git format: https://github.com/VladimirMangos/mangos-svn/commits/master

nice idea)

Possible need add exclude killing player at logout if he at battleground. But this can allow cheating with it for avoid leave some impotent position at BG in result die by close client and relogin. So maybe instead exclude need add alternative code for BG case: teleport to local graveyard pos. [Not have sources for fast search exactly function when this done that i not remember, sorry]

This problem related to way how we reset active mover. Mangos reset active mover base at internal data. Possible case when client send active mover reset request (that can be cheating or not cheating) after real reset happens in core. In result we have like error. This has been discussed in past. One from way is reset active mover in referenced handler as expected by normal bliz-like way but only in case when some flag set at in-core reset need check. This can resolve another existed problem: sometime server receive movement packets from client for active mover _after_ in-core active mover reset. It's ignored currently but this can add some desync in coordinates maybe other problem sometime.

You need not function code but places where it used in code because I not sure that function code change is safe. Do search.

Look for cases where in code use checks with IsRaidOrHeroicDungeon() and change in your way where appropriate (look code context). This not only changes required in fact because normal mode for maps not have reset time data as I remember in DBC/DB. But possible DB can be used for overwrite it.

Happy New Year!

Many bonuses required just proper data in DB for spell_* tables. So you also can check content of DB.

I remove spam. Please not comment spam posts, just report. Happy New Year

In this form look good from my view. In past i see less clear version when code moved to WorldObject that has been more problematic.

Possible this related not to item problems but to problem with skill spell known state for fist weapon. Table `playercreateinfo_spell` store know from start spells for class/race pairs. including 203 'Unarmed' that let as i think use fist weapon. I suggest check is this spell wrongly known by affected classes

As i remember this just future fix warning: I am and NoFantasy (in DB dev mode) hass different views how fix this (DB/core sides selection). Because low prio in result it still in current state.

Independent how you write order of fields initialization C++ required call initialize code in order of declarations. If initialization order affect code work correctness then warning can show real bugs. So better fix code to expected order (with check that this will provide correct code work). Disable warning will just hide _real_ problem possible. P.S. Oh, faramir118 already clarify this) P.S.2 And evilatwow ^^

He meaning that if you add custom starting items then its not equipped to character because default gear use same slots early. Only way avoid adding gear from DBC is modify related code in Player.cpp. In fact easy change must be if you want totally ignore default gear.

sart13, clearly for me you not for help at forum but just for trolling. Grow up own ego by bashing project?

Can't comment any real code because I left active development. Just can share some generic notes/suggestions base at my memory about mangos code

It clearly that reorder time dependent and will dependent in any case from amount guids in DB. Proper table keys can allow make this more fast. Other dependent from implementation details.

It mostly related to memory use and impossibility create new guids at some moment. Possible 2 way: reorder guids at server startup. This already used for group guids and some other as i remember. Alt. way as you suggest collect free guids and re-use its. This case more dynamic work and not req. server restart, but it have bad side: store like free guids can need lot memory. Ofc, maybe better way mixed: reorder at startup and then collect and reuse guids.

What you will do if need overwrite wrong high level req in dbc?

as i read warden for 1.* different and no way get data (modules) for it.