Making of TC

Recommended Posts

Hey, I'm new to WoW and not really an experienced programmer, but this project has caught my eye. So, I have some questions if someone wouldn't mind answering me.

How is this core possible? From what I understand it is completely written from scratch and there aren't any source code leaks from blizz. I'm curious about how the connection between the client and the server is made - since the client is unmodified and we don't have the source for it. All the content Blizzard created... is it integrated into this core? I mean, I'm sure that no one rewrote all the quests, all the respawn position for the mobs, etc. Maybe this data is stored in the client and not the server how I thought...

I'd appreciate if you could provide some more information about the making of Trinity Core. It's an interesting subject to talk about.Thank you!

Share this post

Link to post

Share on other sites

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

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.