Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/09/2019 in all areas

  1. 2 points
    No, you're not right! Updatemask is used as part of client/server dialog to send changes to the client. Everytime an object field CHANGES at the server side (from the last time it's update was sent), the corresponding updatemask bit is set to 1. When an object changes server side, the updatemask is sent along with the changed fields (and only those) to the client. After the object update is sent to the client, the updatemask resets all its bits to 0. When you first create an object first time, ALL FIELDS MUST BE INITIALIZED, so the updatemask bits are all 1 and you send to the client all object fields. There is no field left unintialized.
  2. 1 point
  3. 1 point
    Where did you find that line? Please specify the file and line number, as I can't manage to find it anywhere in mangos one sources...
  4. 1 point
    UPDATETYPE_CREATE_OBJECT2 is sent for entities which have "position" in space (x, y,z coords), i.e gameobjects, corpses, creatures, players. The UPDATETYPE_CREATE_OBJECT is sent for entities without position, i.e items, bags
  5. 1 point
    mangosd.conf here you can change : Rate.XP.Kill = 1 Rate.XP.PetKill = 1 Rate.XP.Quest = 1 Rate.XP.Explore = 1
  6. 1 point
    I do not check top of the header (it can be done using the sources), but should note that a packed GUID has variative length. In your post, the whole structure uint8 packedGUIDMask # for example, 0xFF uint64 packedGUID is termed as "packed GUID". It contains a number of bytes (1 to 8) for uint64. The number is equal to the number of non-zero bits in the bitmask packedGUIDMask, thus the length of the filed is well defined.
  7. 1 point
    You could find the method converting 64-bit (GUID) data to a packed GUID here. BTW, 1.12 client does not use this, which was/is a usual compatibility issue while backporting handlers to it. A brief explanation. A GUID is 8-byte long; consider is as a byte array A where A[0] is the lowest GUID byte, ..., A[7] is the highest one. Create a side byte (the bitmask) this way: if A[i] is nonzero then i-th bit is 1, else the bit is 0. Then we can omit zero-valued elements of A from transfer (a packet), and transfer the bitmask following non-zero elements of A only. In the worst case (like items on a long-living realm) we get the 0xFF bitmask and will transfer 9 bytes instead of 8 (non-packed GUID). However in the best case (player GUID under 256), we get bitmask 0x01 and transfer only 2 bytes instead of 8. A packed GUID emerges by the protocol in packets that may contain a player GUID, saving bandwidth for several (zero-valued) bytes.
  8. 1 point
    I just leaving this here (yep, this is answering to my own question, but I will test it in nearest future and then will post the result here) (Thanks to Talendrys for link to this repo)
  9. 1 point
    An ObjectGuid is a 64bit number which uniquely identifies an entity (Player, GameObject, Creature, etc.). Though the only requirement is to be unique, current implementations try to encode as much information as possible into this number, to limit external queries. For example, datas taken from sniffs revealed that the most significant bytes from the Blizzard's GUID identifies the entity type. These bytes were named High Guids (because of their position in the GUID). Low GUIDS are simply entries from databases, or counters, which can help figuring what exact entity is. Technically speaking these High and Low GUIDS have no importance, and it's up to you how you define the ObjectGuid, as long it is UNIQUE.
  10. 1 point
    AFAIK the only difference between these two is the size. The compressed update may contain (and does, actually) updates for several objects at once. IIRC the compression is made simply by gzipping the packet data. Unsure if usual update SMSG_UPDATE_OBJECT may contain several updates at once, but perhaps it may as well. However I'm certain that these packets are fully interchangeable, i.e. equivalent. A compressed update becomes critical when you get an event-reach world around your character. It may be raiding a boss, a BG, just a capital with 200+ players so on. The updates are "broadcasted", i.e. sent to every player participant, and network bandwidth fades quickly.
  11. 1 point
    I have set WorldLogFile parameter, file was created but nothing write to it. File always empty. Maybe I missed something ? Can you please add part of your 8606 build log just as example ? (I mean that part where CMSG_PLAYER_LOGIN processes) WELL, I do not need this already, found the solution - I also should edit LogMask (set it to 65651 for including NETWORK information)
  12. 1 point
    you _must_ use the guid format that is expected to be sent by the client. If you chose the wrong one, the client will either crash (most likely) or produce total crap.. Edit: To be clear: This is a choice that was made by blizzard developers, and if you want to talk to the client, you must use the 'language' the client understands. This is nothing where you can chose.

Contact Us

To contact us click here
You can also email us at [email protected]

Privacy Policy | Terms & Conditions

Repositories

The Link to the master list
of MaNGOS repositories:
Copyright © getMaNGOS. All rights Reserved.

This website is in no way associated with or endorsed by Blizzard Entertainment®
×