Leaderboard

You installed core for The Lich king expansion but put database for LEGION!

Hey Undyne, I know this answer comes late but propably it may help you a bit. At first I wanna make clear, that I'm not a professional on this topic. I know something but not as much as e.g. Shauren. Yes you're right. There was no leak. The software has been written from scratch. The game itself is delivered as common executable binary file and many assets such as 3d models, maps and their terrain information, a client database, images/videos and the ui (the ui components are delivered as addon such as the third party addons). The most important part of the client data are: Maps Client Database I don't know much about the map files and can't tell you something about their structure but their are used to create server side map information for collision calculation and path finding of npcs. The client database contains static information about some ingame content. In 3.3.5 the client database tables are stored in DB2 and DBC files. The files contain information about spells, skills, races, basic item stuff and much more things. Other data for example quests, loot, ingame objects like creatures or gameobjects and their spawn positions are not available in dbc files. Last year I've written a small php library for DB2 file reading. Maybe this is interessting for you https://github.com/Caydan/php7-db2 Client and server communicates via a tcp connection. The traffic of this connection can be catched and evaluated. Each message has an own id in its header. TrinityCore call these ids opcodes. They are used to identify a message which allows us to read the message into the right structure. A list of all patch 3.3.5 opcodes can be found here https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Server/Protocol/Opcodes.h The CMSG prefix means client to server message. SMSG means server to client message. Here an example for you: A player walks through the world and meets a quest giver. The client doesn't know anything (title, description, rewards etc) about this quest but its ID (let it be the ID 120). The client sends now a message CMSG_QUEST_QUERY which contains the ID 120 to the server. The server answers to this request with SMSG_QUEST_QUERY_RESPONSE which contains all information the client needs to display the quest. It is possible to catch the traffic between client and server on retail realms and use the messages to populate the server side database. TrinityCore uses https://github.com/TrinityCore/WowPacketParser to parse the raw data into text files which are readable to humans or in some cases directly into SQL. The opcodes are changing very often when the client gets updated. Also there are information inside the messages which have to be interpreted. Blizzard likes it to use flags e.g. the npc flags. The npc flags can be used to tell a creature to be a vendor, questgiver, inkeeper, banker etc. Blizzard stores this information as 32 bit integer. All these opcodes, the meanings of every bit of a bitmask or different enums are not provided by Blizzard. All these information has to be gathered by reverse engineering the Wow.exe. This can be done by loading the executable into a disassembler like IDA. It will translate the machine code into assembly. Now you have to research millions of lines of assembly code and try to understand what it does, how the client interpretes different messages etc. This kind of research is very fascinating but can also be very frustrating. Hopefully I was able to help you a bit. Cheers