From what I remember pyot had support for instances without a custom client. But in a limited way that the sec map format supported instances. Then the game server decided which instance to serve and all the clients received that single instance. It was a nice way to allow changing environments and did so in a way that made it easier for someone to map. The server knew when to load and unload sectors and when to change instances. So that was a goal of the system if the current source code says otherwise.Instances would be cool, but the official Tibia client would need to be dropped in favor of an open-source client that could handle instances properly.
+1 less work and less software for a OT creator and player. Custom clients are amazing technology wise. The fact that one or few developer can make such functional clients is amazing. However I don't want to download a damn custom client for every OT I log into. It was great when I had one client installed and an IP changer. It was possible to switch between cipbia and OTs easily. Most OTs at the time were focused on keeping up with the latest client version. Now the community is very splintered between all different client versions that each player enjoys the most. I like tibia and the custom takes people have on tibia not some total different mmorpg that might as well be zezenia. TFS refusing to support newer protocols is a real pain and makes the splintering worse.Unfortunately, I think you're right. And I think the reason for this is that the official client is recognizable; users are used to the look/layout and know how to use it. They get the same experience, more-or-less, between Open-Tibia servers and official servers when it comes to the client. Plus, for server developers, it's one less thing they have to maintain.
There are several client 11 features I would like to see in more OTs. Features such as the sprites, cyclopedia (map, bestiary, charms), ingame shop, and market would be beneficial. Features of lesser importance might be prey system, news, friends, inspect, and house auction system. I could imagine playing deathzot and be able to see the custom monsters and items in the cyclopedia.
On topic about a flexible server engine for Tibia and not reinventing a client, map editor, or new game. This thread confirms that developers have preferred languages. Devs wants to use the language they like most or are interested in learning. Every language mentioned so far is capable of getting the job done no doubt. What would be your goal with a modern engine? You mention it could be tough for the community to change scripting languages. So you must have some thoughts in mind about what this modern engine should accomplish. The goal will affect the decision of technology chosen besides just the language used to code the server.
- Just looking for a new code base which is easier to maintain?
- Must it support existing lua scripts?
- More players online at once? Not many servers surpass 1K players as it is. More performance is fun but for what gain.
- Less system resources required to run the engine?
- Lower bar of entry to run a server for greenhorn devs?
- Drop all usage of XML because "John Doe" finds it annoying to work with?
- Single engine to support multiple client versions at the same time?
- A engine which can make better use of containers?
- Does ease of migration from the old engine to the new engine matter?
- Quickest to a usable engine?
See Asynchronous HTTP API with lua bindings by djarek · Pull Request #2010 · otland/forgottenserver (https://github.com/otland/forgottenserver/pull/2010) it might interest you.For me as a web developer tfs lack restful api. Imagine changing game state from website(e.g. voting for today's event). JWT for authorization should be just fine. With it community could create some new, fun stuff and admins could manage their server from admin panel. Just a concept I've been thinking on.
Another thing I was wondering, apart from tfs itself, is creating strictly a back-end service(without any template generation) for tfs, so there is a possibility for community to use any framework to implement their front-end solutions, but this is different topic.