SilverIce

+ don't forget that vertical\\horizontal speeds might be depend from distance to caster(caster position or center where those speeds has max values)

no, that flag should not be stored because it appears only in monster move packet

it can be used by spells, but some creatures can jump without any spells PS it is only animation fix, need move creature at server side

That patch makes jump animation for creatures, using right SMSG_MONSTER_MOVE format Who has been writing this patch? Please include either forum user names or email addresses. Me, but correct SMSG_MONSTER_MOVE packet format i saw in packet viewer by TOM_RUS. tested on flat surfaces http://pastebin.ca/1728713

what is wrong? why that patch ignored?

confirmed these packet its not self-send packets example(sniff): ------ CMSG_SET_ACTIVE_MOVER ------ 1655160100000007 my guid(unpacked) ------ MSG_CHANNEL_START ------ 8F16551601075EA70000CB080000 8F1655160107 my packed guid 5EA70000 spell id CB080000 duration ------ MSG_CHANNEL_UPDATE ------ DB0210BE5030F100000000 DB0210BE5030F1 other packed guid 00000000 cast time? ------ MSG_CHANNEL_START ------ DB0210BE5030F1638A0000D0070000 DB0210BE5030F1 other packed guid 638A0000 spell id D0070000 duration as you can see in example - i can receive these packets from other units Added: lets look at packed guid DB0210BE5030F1, 02 10 00 BE 50 00 30 F1 - it is unpacked version, "30 F1" - guid hightpart - HIGHGUID_UNIT (look at HighGuid enums) enum HighGuid { HIGHGUID_ITEM = 0x4000, // blizz 4000 HIGHGUID_CONTAINER = 0x4000, // blizz 4000 HIGHGUID_PLAYER = 0x0000, // blizz 0000 HIGHGUID_GAMEOBJECT = 0xF110, // blizz F110 HIGHGUID_TRANSPORT = 0xF120, // blizz F120 (for GAMEOBJECT_TYPE_TRANSPORT) HIGHGUID_UNIT = 0xF130, // blizz F130 HIGHGUID_PET = 0xF140, // blizz F140 HIGHGUID_VEHICLE = 0xF150, // blizz F550 HIGHGUID_DYNAMICOBJECT = 0xF100, // blizz F100 HIGHGUID_CORPSE = 0xF101, // blizz F100 HIGHGUID_MO_TRANSPORT = 0x1FC0, // blizz 1FC0 (for GAMEOBJECT_TYPE_MO_TRANSPORT) }; that mean, like pasdVn said, that not only players can be source of these packets

may be SMSG_BREAK_TARGET? Worldpacket data(SMSG_BREAK_TARGET, pguid_size) data.append( target->GetPackGUID() ); PS i not tested this

this condition placed in Unit::ModifyHealth

maybe there is some table with dependence between display id's and forms in .dbc? anyway thanks

In case one player don't see another player(i.e. that player is not in visible guids) update fields data won't be created

maybe, but it creates object for viewer, not updates it

deleted some unused and old functions changed logic of Object::SendUpdateToPlayer function - no sense update object fields for all players around (at SendUpdateObjectToAllExcept), because its already doing every world tick in ObjectAccessor::Update, so only create update packet building for object's viewer at Player::UpdateVisibilityOf if(target->isVisibleForInState(this,viewPoint,false)) { visibleNow.insert(target); target->BuildUpdate(data_updates); target->BuildCreateUpdateBlockForPlayer(&data, this); UpdateVisibilityOf_helper(m_clientGUIDs,target); target->BuildUpdate(data_updates); why not delete that function? it will call changed fields data building for all players around (here we must build only create data for viewer) http://pastebin.ca/1588540

this patch will correct show spell charges/stack amount Who has been writing this patch? Me SMSG_AURA_UPDATE_ALL and SMSG_AURA_UPDATE packets has almost same structure, but SMSG_AURA_UPDATE_ALL used to send all existing auras. It used when some unit became visible for player. that format was already corrected at [8029] - i just make the same changes for SMSG_AURA_UPDATE_ALL --- a/src/game/Player.cpp +++ b/src/game/Player.cpp @@ -18480,7 +18480,10 @@ void Player::SendAurasForTarget(Unit *target) // level data << uint8(aura->GetAuraLevel()); // charges - data << uint8(aura->GetAuraCharges()); + if (aura->GetAuraCharges()) + data << uint8(aura->GetAuraCharges() * aura->GetStackAmount()); + else + data << uint8(aura->GetStackAmount()); if(!(auraFlags & AFLAG_NOT_CASTER)) {

but why we need compare player and viewPoint, and compute cells twice? if player's farsight guid is empty veiwpoint its a player.. this mean that their positions are same.. just look at Player::GetViewPoint function

What bug does the patch fix? This patch fixes incorrect cell calculation: since player has viewPoint we need compute cells using that point. Who has been writing this patch? Me diff --git a/src/game/ObjectAccessor.cpp b/src/game/ObjectAccessor.cpp index 79b9d9c..268e07c 100644 --- a/src/game/ObjectAccessor.cpp +++ b/src/game/ObjectAccessor.cpp @@ -451,7 +451,8 @@ ObjectAccessor::UpdateObjectVisibility(WorldObject *obj) void ObjectAccessor::UpdateVisibilityForPlayer( Player* player ) { - CellPair p = MaNGOS::ComputeCellPair(player->GetPositionX(), player->GetPositionY()); + WorldObject* viewPoint = player->GetViewPoint(); + CellPair p(MaNGOS::ComputeCellPair(viwPoint->GetPositionX(), viwPoint->GetPositionY())); Cell cell(p); Map* m = player->GetMap();

no, it just makes player's controlled movement (like flee or confused movement) same as when player controlled by client

What bug does the patch fix? What features does the patch add? used more correct Player::Setposition instead of Map::Relocation at player's relocation in Traveller every relocation tick we need call CheckExploreSystem, update underwater state, update player position on minimap, etc. All that things doing in Player::SetPosition diff --git a/src/game/Traveller.h b/src/game/Traveller.h index dd58976..0116bea 100644 --- a/src/game/Traveller.h +++ b/src/game/Traveller.h @@ -141,7 +141,7 @@ inline float Traveller<Player>::GetMoveDestinationTo(float x, float y, float z) template<> inline void Traveller<Player>::Relocation(float x, float y, float z, float orientation) { - i_traveller.GetMap()->PlayerRelocation(&i_traveller, x, y, z, orientation); + i_traveller.SetPosition(x, y, z, orientation); } template<>

Here is my version of blink : http://pastebin.ca/1471849 How should it work: - This system creates horizontal line between unit and point (this point placed at same altitude, but 20 yards forward) and starts search intersection point with terrain map first. If that line not intersects with terrain it returns ending point - After that point have been found, system will attempt to find new intersection point with terrain vmap (such as buildings, etc.) - In case unit has specified movement flags like falling/flying/swimming, system will not perform hole and pit search on terrain. So, if player falls down the terrain and his falling time is lesser than 2.5 secs he will be teleported back to his previous safe location. Therefore, if unit's falling time is longer than 2.5 secs, this unit will be teleported forward, to his ending point. - In case unit hasn't specified movement flags like falling, flying or swimming (which means that unit walks especially on surface), system will scan terrain in attempt to find holes, pits and caves. When the hole, pit or cave is found, system should stop unit near this object . updated to 8072