Looking for the most Up-to-Date OTS Distribution with a Real Map

[vichoko]

Hello everyone,

I’m trying to set up a modern Open Tibia Server and want to use a distribution that includes anything similar to the real Tibia map. I’ve spent quite a bit of time searching and have only come across older OTS packages (e.g. TFS and similar) that ship with outdated versions.

Does anyone know of a more recent distribution that works with any version near 15.0?

I’d appreciate any pointers to repositories, guides, or community resources.
Thanks in advance for your help!

 

[Joriku]

Canary

 

[Sorky]

Canary

Yeah, if u want to lack compatibility with most tools, yeah
create your own engine but cut off from community

 

[Night Wolf]

Yeah, if u want to lack compatibility with most tools, yeah
create your own engine but cut off from community

can you point one example of a tool that compatibility would be lost?

 

[Sorky]

can you point one example of a tool that compatibility would be lost?

Otb, items.xml are different in there, which can cause many tools based on tfs not to act properly.
Not mentioning scripts that are not compatible.
Drama between tfs and canary is just hurting this community. I get points of both sides tho

 

[zbizu]

Otb, items.xml are different in there, which can cause many tools based on tfs not to act properly.
Not mentioning scripts that are not compatible.
Drama between tfs and canary is just hurting this community. I get points of both sides tho

tfs would move in the same direction with scripts if it could, it's just that the repository doesn't attract developers and reviewers that much anymore

moving to client ids in tfs was debated, though opinions were divided and the shift did not happen

for maps, Canary has its own mapeditor which you can find in the opentibiabr github

the otbm formats are not meant to be compatible between tfs and canary, in fact me and otbr devs have exchanged some concepts for the new format that would be supported by every tool, but there were difficulties in implementation of proposed file structures and the development did not continue

 

[Joriku]

Yeah, if u want to lack compatibility with most tools, yeah
create your own engine but cut off from community

Gitbook
Not sure what you mean by this, but zbizu has a good point.

Each tool existing for the older versions will "work" with canary ( Or use the updated older tools for canary ), you just cannot use client 13+ if you want to solely rely on the old school methods, turn to the older outdated 11 client, OTC client(s) if you want to use that.

The new tools works just as great as the older ones, there's not much you cannot do with canary nowadays that you can do on TFS.

And besides that, if you go for a real map using TFS, latest stable and/or latest build (un-stable). The amount of work you need to do to end up where canary is is too much to even bother.

If you don't like a system, or you want a custom system it's possible to add onto it. But lacking of tools, is a mad-man thing to say without "ever" really bothering checking out what's available.

And yes,
item.xml is still there, but items.otb is not. It's using direct-access onto appearances.dat directly from client 13, making it easier to simply edit or create missing items.

There really is no reason why there should be two separated id's when sprites do indeed directly link an item onto that sprite which you now know is that one sprite if you need to find it, not look through all the sprites to find the correct one with outdated tools.

The community, and mostly @Night Wolf and @zbizu has created and/or contributed onto, released free of charge btw.
Check this out

Keeping an old argument cause you don't like the country of Brazil is a wild thing

 

[Sorky]

Keeping an old argument cause you don't like the country of Brazil is a wild thing

Thats just a wild argument, where did I insult toward country?

 

[sharinn]

If you want something up-to-date regarding RL, use Canary. You have to keep in mind that a large part of the systems is written in C++, which makes it really difficult to modify anything to work even slightly differently. There are a lot of magic values or hardcoded things specifically for RL . From a developer's point of view, it's much harder to achieve customization.
From my point of view(someone who modifies system behavior related to RL), this engine is not the best for those purposes.

 

[Night Wolf]

If you want something up-to-date regarding RL, use Canary. You have to keep in mind that a large part of the systems is written in C++, which makes it really difficult to modify anything to work even slightly differently. There are a lot of magic values or hardcoded things specifically for RL . From a developer's point of view, it's much harder to achieve customization.
From my point of view(someone who modifies system behavior related to RL), this engine is not the best for those purposes.

As a non CPP developer, I can relate. But most of the conversions of those core systems (from Lua -> CPP) was to achieve a better integration with the base and avoid overengineering protocol and db integrations using Lua. As much as I like Lua, it really lacks a good integration with CPP. LuaJit was good, but it's not maintained for several years now.

Moving to CPP was not my favorite choice, but performance wise when you consider this and other 378562623 systems is a no brainer.
You should still be able to customize many things through callbacks though...

Post automatically merged: May 15, 2025

tfs would move in the same direction with scripts if it could, it's just that the repository doesn't attract developers and reviewers that much anymore

If I'm not wrong, tfs even did revscript before, no? We just followed a different way of doing it.

moving to client ids in tfs was debated, though opinions were divided and the shift did not happen

The real question is why we ever created "server id". I guess back in the day probably the early developers of TFS (Perhaps this was Mark himself?) they were afraid Tibia could update client ID list forcing them to re-do the entire mapping. So they made this "middle man" to reference server ID with client ID.
What the guys did for Canary was essentially just drop this old mapping file and use directly the client ID. This is the sole reason Map Editor has to be different.

Ideally, we would also drop otbm and other binary formats in favor of more future-proof and well tested solutions like protobuff and parquet.

 

[zbizu]

If I'm not wrong, tfs even did revscript before, no? We just followed a different way of doing it.


The real question is why we ever created "server id". I guess back in the day probably the early developers of TFS (Perhaps this was Mark himself?) they were afraid Tibia could update client ID list forcing them to re-do the entire mapping. So they made this "middle man" to reference server ID with client ID.
What the guys did for Canary was essentially just drop this old mapping file and use directly the client ID. This is the sole reason Map Editor has to be different.

Ideally, we would also drop otbm and other binary formats in favor of more future-proof and well tested solutions like protobuff and parquet.

otserv (the repo tfs is based on) was the first to do it. This is why RME has support for a dead OTBM standard that nobody is using today. The OTBM4 format that was part of the "revscriptsys" project never made it to the forgotten server. For more context, tfs was created BEFORE revscriptsys project, this is why the updated scripting system arrived so late to tfs.

the otb standard was created in early times of opentibia. Before 8.0, the items were moving a lot in the client. This is also why there are potions and jester outfit quest items at the beginning of the client id list today. OTB was serving as a guard mechanic that made importing old maps to new protocols as smooth as possible. As this kind of movement no longer occurs and various map conversion methods exist now, the team behind Canary was right to get rid of the otb file. The client/server item id issue is super easy to solve - all it takes is both teams agreeing on a header byte that would determine if the map is using client ids and a checkbox to set that in map properties dialog.

However, there are two problems that stop both mapeditors from becoming one again. First is the lack of backwards compatibility with spr/dat files in the Canary map editor (no code that supports both encodings - spr/dat and assets exists for rme codebase). The second problem is that the formats we've discussed have some obscure, non-standard libraries that are difficult to integrate with the C++ projects. As I mentioned earlier, a schemaless system would be perfect, but the json itself is too slow and too big (at least as long as the map is still saved as a single file). I see that libbson is available in the vcpkg now so it might be worth giving it a chance.