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

They Jump??? Never seen a creature jump before this is gonna be cool. But what kind of mobs jump anyway or do they jump from Height A Height B?. Anyway this is some cool feature.

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

and i wonder why is that ... since hots still heal at your max health, and your max heath isnt increasing, the condition (target->health>=target->maxhealth) must be checked somewhere to prevent adding excess health :confused:

this condition placed in Unit::ModifyHealth

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

anyway thanks

Check 2 chars in one group trevel at boat.

Client in past has been sometime unhappy when data send in different order.

Also what about cases when one player in tick see another char but another not see first yet (update will send at next tick) and first char start attack another char.

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