Jump to content


getMaNGOS Developer
  • Content Count

  • Donations

    0.00 GBP 
  • Joined

  • Last visited

  • Days Won


Olion last won the day on January 7 2019

Olion had the most liked content!

Community Reputation

30 Excellent


About Olion

  • Rank
    getMaNGOS Developer

Core Infomation

  • Core

Profile Information

  • Gender

Recent Profile Visitors

1,501 profile views
  1. It's funny that the code above outputs actually a packed GUID (without any compaction for zero bytes, thus the bitmask is 0xFF). So it's ok when filling a packed GUID field in a packet.
  2. 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.
  3. 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.
  4. 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.
  5. I apologize for the wrong opcode referencing. The following is correct for 3.3.5a (12340 build) client: SMSG_UPDATE_ACCOUNT_DATA_COMPLETE = 0x0463, while for older ones, perhaps including 8606 build, the older SMSG_UPDATE_ACCOUNT_DATA = 0x20C must be valid. To avoid such confusions, you better create the needed dumps for the proper version yourselves. Run a Mangos server wih set up WorldLogFile parameter in the mangosd.conf. The log file will contain the communication sequence with symbolic opcodes and unparsed other packet data. If you use the TC for that, you set up PacketLogFile in its worldserver.conf and get a binary file. You could parse it into a nice text form with the WowPacketParser utility. The utlity is capable to parse older data as well, for 2.4.3, in case you manage to get the binary packet log. An example sequence of actions at CMSG_PLAYER_LOGIN (i.e. at login by the chosen character) was presented here, once again for 12340 client. I could have misinformed you on the packet sequence as well, since had been referencing WotLK 12340 client. It looks like the login protocol was changed between 8606 and 12340 builds. Taking a 8606 packet log, I see SMSG_ACCOUNT_DATA_TIMES within the large responce sequence on CMSG_PLAYER_LOGIN. Also I see two CMSG_UPDATE_ACCOUNT_DATA without any server responce. So, analyse your own logs please. Good luck!
  6. Check your content of the `realmlist` table in the `realmd` DB. The `realmlist`.`address` string field is used to tell the non-local clients on what host to look for the mangosd server (aka realm server). It might be either a full DNS hostname resolvable at your friends computers, or an IP (specifically, IPv4?) address accessible to them. It looks like your table contains the string 555.555.555.555 here, which is not satisfactory.
  7. 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.
  8. Blizz have planned to teach a character some spells ingame. They have created the "Learn" counterparts for those spells. The Learn spells have spelleffect SPELL_EFFECT_LEARN_SPELL=36 and the spell id to learn in EffectTriggerSpell; they provide also the well known animation. It is why your spellids did not match. The learning process looks like casting a "learn" spell upon the character. You could find required spells with the SpellWork, for example (note that it needs access to the extracted DBC files, specifically, to the Spell.dbc).
  9. If you find somewhere a protocol description, let us know as soon as possible Until then, all that everyone had were sniffes. Today, sniffing the traffic between a server emulator and the client is the simplest way. There is a lot of sh*t set up at a player login. Below is a part of sniff for the WotLK client logging in a character.
  10. 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.
  11. The in-game space is realized as a set of maps. You're transferred from a map to another one via teleport (so called far teleport). It could be an instance entrance or ship/zeppelin teleportation. The maps are numbered sequentially (with some holes), this number is known as the mapID. The map list is kept in the client file Map.dbc, you could find some description of its content (3.3.5a client) here. A map can have a very large size (meaning, room), like the whole continent, Kalimdor (id 1) or Eastern Kingdoms (id 0) or Outland (id 530). Clearly, a more tight net is needed for many game mechanic implementations. An example of such mechanics is a spell enabled only in a part of the map. Such a smaller grain is called a zone, and further smaller one is an area. The data on these are presented in the client file AreaTable.dbc, described somehow here. However, a position on the map is defined by the mapID and coordinates X, Y, Z only. It means that the zoneID and areaID are subordinate, being actually calculated by the core from the position data. The smallest grain is called a cell and is implemented in the core by the similarly named class. The SMSG_CHAR_ENUM packet contains lots of information about the characters present on a given account. It allows the client to display "Select a character" screen since you've logged in. A necessarily large size of the packet made it the popular tool for DoS attack to the server. This was serious enough to budge the TC team to implement a rudimentary protection from this attack type.
  12. Sorry, too used to the TrinityCore structures. Yes, it's ok. The access level is controlled by `account`.`gmlevel` here, that has a reasonable default value (0 = user). Just try to reset the fileds mentioned above with an update like this (for MyUsername example player): UPDATE `account` SET `v`=NULL,`s`=NULL WHERE `username`='MyUsername';
  13. When you manually change (rather than create anew) user credentials, namely username and sha_pass_hash, then reset also v and s fields to an empty srting (NULL is disallowed there in the TC, though Mangos allows it). You might wish also to fill some other fields in the account table entry, for example, email, joindate, and expansion. Also, when you register a new user, you should define his/her permissions as well in the account_access table. IIRC no more information is needed to allow the user login.
  14. Olion

    WoW path

    It looks like path=patch, meaning the major client version. While the best developed one is TrinityCore 3.3.5a (WotLK), I cannot recommend it since they have used to break it substantially from time to time. Of Mangos here, Zero should be the most developed one, though it does not mean the blizzlike grade.
  15. If I remember correctly, none of the Mangos sources were adapted to the OpenSSL 2.0. If so, you need to stay at OpenSSL 1.1 which is not the default one for new system distributions. Check your OpenSSL version and try to downgrade it to 1.1 (which will rather be impossible), or try to install it along with 2.0.

Contact Us

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

Privacy Policy | Terms & Conditions


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®
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use