Do you know why the TFS team on Otland doesn’t want to rush things like Canary does? Because rushing only causes bugs, memory leaks, and poorly implemented features. Canary might have some cool 12.x+ protocol features, but it’s full of problems. On top of that, it uses a bunch of unnecessary files it would be much better to keep everything in the original files and only adapt when needed.
TFS, on the other hand, is carefully planned and comes with the new network system, which follows the same structure as module.cpp and .h for communication. This allows mixing a bit of C++ with almost full Lua support, making it possible to send data properly to the client.
I tested this myself: on OTC Mehah and OTCv8 (my custom client running on TFS 1.7 8.60), I implemented the Forge system. For Mehah, I ran it with TFS 1.6 13.10 and the Forge worked perfectly. It wasn’t easy it took a lot of work but I managed it thanks to the new network system, which recognizes Forge and sends it correctly to both the CIP client and the OTC Mehah.
TFS is designed with stability in mind, avoiding headaches, memory leaks, and broken features. For me, TFS is the better choice right now. It doesn’t matter if it has fewer features what matters is that it’s stable and 100%. Canary often breaks things and causes issues from time to time… I’d rather stick with something stable
Note: I’m already working on TFS 1.6 with protocol 14.05. I’m still trying to upgrade it to 15.x soon, and then I’ll implement the missing systems like
Imbuements, Charms, and the Wheel of Destiny.
OTC MEHAH.
View attachment 94392
Otcv8 custom
View attachment 94393
