Brainy

I want to work on a 'new classic' TrinityCore

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

If you tell me what exactly you wanna do, I will write down a small script which does it. Do you just want to renumber the account ids to use unused account ids? Or do you simply want to merge two account databases?

Just change the account ids and database names for following queries and run it on your mysql console. Be sure that no user is logged into the affected account while you're changing the ids. SET @OLD_ACCOUNT_ID := XXXXXX; SET @NEW_ACCOUNT_ID := XXXXXX; UPDATE auth.account SET id = @NEW_ACCOUNT_ID WHERE id = @OLD_ACCOUNT_ID; UPDATE characters.characters SET account = @NEW_ACCOUNT_ID WHERE account = @OLD_ACCOUNT_ID;

Can someone give me the address offsets for packet send/receive functions in 7.3.2.25549 x86/x64 client?

You can also buy very cheap dedicated servers at https://www.kimsufi.com (its an OVH company)

I still don't understand why you are using an old 7.1.5 version. Upgrade your TrinityCore to the HEAD commit and connect with the 7.2.5 client.

Use the latest TrinityCore for client version 7.2.5

Check the address in your auth.realmlist table. It must be your public IP

To answer your question. Yes it isnt a problem to install both libraries. But please notice that you are using an unsupported version of trinitycore

In world database you will find different character template tables. Just put your data inside. After that you can use the template system on the character selection screen. I'm not sure but maybe you must apply a rbac permission before you are able to use it. But maybe its just at my local branch.

Create a custom item and write an ItemScript which levels the user. You can also create a custom spell with a dummy effect using hotfixes. Then just create a spell script and let your custom item use the created spell.

Maybe nobody wants to update it or just doesn't have time But seriously if there really are issues with 7.3.0 it would be nice to know which kind of issues

I've found this article https://hackmag.com/uncategorized/deceiving-blizzard-warden/ Topic can be closed

I wanna start to do some research for Warden. Does I understand it right, that the server sends information about an offset and the data length to check to the client, the client checks its memory for that offset and sends the result to the server? What does warden_checks.type mean? How it is possible to protect the warden responses from getting manipulated? Is there any technical documentation for Warden? Thanks in advance!