Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/16/2018 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 need rather to send the confirmation that the server have handled the update successfully. This is a short responce packet. For 1.12 client, it would be probably the opcode SMSG_UPDATE_ACCOUNT_DATA = 0x20C, while for 2.4.3 it is SMSG_UPDATE_ACCOUNT_DATA_COMPLETE = 0x0463, Just remember this is a dialog, a query - a responce. On the TBC (2.4.3) client, the next packets represent another dialog phrase: CMSG_READY_FOR_ACCOUNT_DATA_TIMES SMSG_ACCOUNT_DATA_TIMES with the only difference that here CMSG is a short query and SMSG is a longer responce.
  13. 1 point
    I believe the table you are looking for is playercreateinfo_spell this will allow you to assign spells to players on startup. It has been some time, but I believe table playercreateinfo_action will allow you to place the spells in specific actionbar slots. Hope this helps.
  14. 1 point
    Not being an expert on handling the packet at this level, I would still advise do not take a risk with this operation: dec %= 0x100 The modulo op in Python is quite a thing. Use bitwise operation instead: dec &= 0xFF Unsure if it helps, but it is the only difference from the referenced Java code I've managed to spot.
  15. 1 point
    Replacing ACE is not a trivial thing to do. Maybe before trying to do anythig like that it would be better to ask for help with the errors you get with ACE. You should try post the errors you get when trying to compile your core. Also it would be good to post your system information and installed dependency information, such as versions. At the moment we dont know for example what debian you are running, what the errors were, what mangos you are compiling etc.
  16. 1 point
    To clarify this further.... There are situations where we know the packet is a certain size but we don't know the meaning of everything in the packet.... i.e. Packet is 8 bytes long 0-1 Id Field 2-5 Size of object 6 Allegiance Flag 7-8 Unknown
  17. 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®
×