zergtmn

I've never seen related bugs because I try to avoid dangerous code. When I need to initialize one field with another I just write it in constructor body. In this case order of initialization cannot be altered by accidental field rearrangement (that happens sometimes). Btw, VC++ doesn't have such warning at all. In reality even standard libraries cannot be compiled without warnings under /Wall.

I don't see point in bothering about this type of warning ('a' will be initialized after 'b'). This one I'd always leave disabled.

That is totally unreadable.

UNIT_FIELD_BASEATTACKTIME is just array of two int. SetUInt32Value(UNIT_FIELD_BASEATTACKTIME, main hand attack time); SetUInt32Value(UNIT_FIELD_BASEATTACKTIME+1, offhand attack time);

MaNGOS doesn't have SpellFamilyFlags.test<> stuff. And the way chosen is wrong.

CMake support on Windows is not finished afaik. Use project files from \\win subfolder.

That's just small speedup and reduction in number of memory allocations. From Schmoo's crash dump I can see that AuctionSorter predicate is not strict weak ordering. That's the problem.

Probably item was cached by client already so you need to reset cache from client side (by deleting Cache folder) or from server side (changing ClientCacheVersion in mangosd.conf).

Problem already fixed in 11621, you should upgrade asap. Unfortunately it is impossible to restore items that were sent by mail during bug presence

Well, it is another mount.

Ground mode was added in 4.0.1.

Patch is partially incorrect, rage is set to zero after preparation phase ends.

Check latest revision.

Fixed in 11589.

To deal with ASLR something like http://paste2.org/p/1441229 can be used.

Your revision is 400+ revisions older than MaNGOS master. You should recheck it with latest revision before posting bug reports.

For 4.1: Pointer offset: 0x00D03F14 Session key offset: 0x508

We have CreatureFlagsExtra for custom flags, like CREATURE_FLAG_EXTRA_CIVILIAN, CREATURE_FLAG_EXTRA_GUARD and etc.

Actually problem is that we don't handle SMSG_MOVE_SET_COLLISION_HGT (0x516), CMSG_MOVE_SET_COLLISION_HGT_ACK (0x517) and MSG_MOVE_SET_COLLISION_HGT (0x518) packets. SMSG_MOVE_SET_COLLISION_HGT is sent at mounting and dismounting (just before SMSG_DISMOUNT). Structure used in 12340: packed guid of player + dword packet counter + float collision height. CMSG_MOVE_SET_COLLISION_HGT_ACK is sent by client as reply. Structure: packed guid of player + dword packet counter (same value as in SMSG) + MovementInfo + float collision height (same value too). I have do idea what third packed is used for... Collision height is dependent from race and gender. For dismounting it can be taken from CreatureModelData.dbc. For mounting we must calculate it somehow taking into account mount height also. I currently don't have exact formula, only approximation.

Pet GUID erased from m_guardianPets twice: once in Pet::Unsummon and second in Unit::RemoveGuardians. Second can cause crash if m_guardianPets become empty.

I don't know reason behind adding caster check, for me it looks logically incorrect. Check removed in 11469, thank you.

Fixed in 11389

Fixed in 11299.

This means 11217_01_mangos_creature_addon.sql was incorrectly applied or you have custom changes to creature_template_addon that use old-style format for auras. After 11217 valid format is 'spellId1 spellId2 ...'

Artists make them. You can use Difference Clouds filter in Photoshop to generate a heighmap and then export it as single channel raw grayscale image. It is the simplest format to work with. To calculate vertex height at any point of terrain you'll need to find interpolated height from heightmap (for example, using bilinear interpolation) in 0.0..1.0 range and multiply it by maximum height of terrain.