tibia/game - Tibia 7.7 decompiled game server

	Commit message (Collapse)	Author	Age
*	add `MAX_DEPOTS` constant + enable assertions in debug mode	fusion32	2025-09-13
\|
*	wrapping up for a public release	fusion32	2025-08-15
\|
*	fix most init and parsing bugs + critical bug with dynamic strings	fusion32	2025-07-16
\| \| \| \| \| \|	With an appropriate query manager, the server now starts up and seems to work but won't properly handle connections until we fix the problem with threads and signals described in `TODO.md`.
*	implement `crypto.cc` with OpenSSL + fix config loading	fusion32	2025-07-03
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	I considered reversing the original `vlong` implementation but OpenSSL is just simpler, more secure, and most importantly, is already there. I also made it so the key is now stored in a PEM file (`tibia.pem`) so it can be easily swapped without re-compiling. This was the last piece to build and run a working executable, except that we now need to implement a query manager for the server to communicate with. I was able to fix a small problem with loading the config before hitting the problem with the query manager, which was expected. The next task should be getting a query manager up and running before starting phase two of upgrading and fixing the server itself.
*	`query.cc`	fusion32	2025-07-02
\|
*	beginning of `query.cc`	fusion32	2025-07-01
\|
*	`reader.cc`	fusion32	2025-07-01
\|
*	`writer.cc`	fusion32	2025-06-30
\|
*	`houses.cc`	fusion32	2025-06-29
\|
*	most of `crnonpl.cc`	fusion32	2025-06-24
\|
*	`receiving.cc`	fusion32	2025-06-23
\|
*	`sending.cc`	fusion32	2025-06-22
\|
*	`connections.cc`	fusion32	2025-06-21
\|
*	beginning of `communication.cc`	fusion32	2025-06-19
\|
*	finish `crplayer.cc`	fusion32	2025-06-18
\|
*	more work on `operate.cc`	fusion32	2025-06-13
\|
*	more work on `operate.cc`	fusion32	2025-06-12
\|
*	impl `TCreature::Move` which was absolute hell + some tidying up	fusion32	2025-06-08
\|
*	some work on `crmain.cc` and `cract.cc` + merge creature headers	fusion32	2025-06-06
\|
*	merge creature headers	fusion32	2025-06-05
\|
*	more spells	fusion32	2025-06-03
\|
*	impl some spells and create `info.cc`	fusion32	2025-06-02
\|
*	add a small Go script to generate the Makefile	fusion32	2025-06-01
\|
*	done with `crcombat.cc`	fusion32	2025-05-31
\|
*	rename/create some files	fusion32	2025-05-28
\| \| \| \| \| \| \|	The most annoying thing with C++ classes being in their "own" header file is that it makes it easy to create cyclic dependencies. We might end up merging all creature related header files into the original `cr.hh` that shows up in the original's debug information.
*	impl all remaining containers	fusion32	2025-05-28
\|
*	more object functions	fusion32	2025-05-26
\|
*	linux Makefile + fix most compilation problems	fusion32	2025-05-25
	I wanted to see if the compiler had any problems with the code so far and added a few stub definitions so that each file would properly compile. We still fail when linking but we're able to to find and fix compile time errors.