Which engine is better right now for Tibia 12?

[drakylucas]

Hello all,

I think the question here is pretty simple and a lot of people already have this doubt.

Supposing the scenario where I want to make a Tibia 12.xx server, not necessarily with global map but just comparing the engine (not the data pack itself), which engine should I focus to use as a start point?

I know that TFS was the first one (at least famous) and the most complete for long time, but looking their github, there are some pull requests without any action for more than 5 years. They don't have almost any feature from recent tibia (for instance: store, prey, imbuements, charms, analyzers and so on). On the other hand, the code quality on TFS looks better than on otservbr (just comparing)

In otservbr github, we can see they have almost all features from current tibia, but it seems a lot of people "hate" the otservbr (I already saw people calling it "ot crash br"), and indeed, looking the canary repository issues, there are a lot of different crashes reported (but, seriously, mostly of these issues are not reproducible and are opened for months as well without a fix). Is it that bad?

And how about OTX? Does it still exist? I don't hear anything about it for a long time already.

What are your opinions? Which engine is better as a start point for you, considering you want a server using the recent clients (because of lots of reasons.. Side panels, automatically reload containers, hotkey bars)?!

 

[Codinablack]

OTX still exists. OTServ BR has many 12 features, but they have also had 12 support for much longer than TFS, and TFS just added it recently , yet already have added many features.

OTX is based off TFS, but made to be much more customized. TFS is optimized for being the best barebones cipbia copy.

Ultimately comes down to your needs, and who you have more faith in, which personally for me, TFS wins in every scenario for that, the TFS Devs are the Best team of devs out there, and that is my opinion.

Since 1.4 release, commits for 1.5 have been on FIRE. These guys put out so much work each day, and thats just on the commits that are ready for merge, remember most of these guys have custom branches where they are working out and producing more features BEFORE they submit a PR. They are most professional in this industry.

 

[Evil Puncker]

if you intend to run a rl map or want an engine with "lots" of features, you better going with otbr 100%

but if you know what you are doing and most likely going for custom/self content, I recommend tfs master

 

[skulls]

Hello all,

I think the question here is pretty simple and a lot of people already have this doubt.

Supposing the scenario where I want to make a Tibia 12.xx server, not necessarily with global map but just comparing the engine (not the data pack itself), which engine should I focus to use as a start point?

I know that TFS was the first one (at least famous) and the most complete for long time, but looking their github, there are some pull requests without any action for more than 5 years. They don't have almost any feature from recent tibia (for instance: store, prey, imbuements, charms, analyzers and so on). On the other hand, the code quality on TFS looks better than on otservbr (just comparing)

In otservbr github, we can see they have almost all features from current tibia, but it seems a lot of people "hate" the otservbr (I already saw people calling it "ot crash br"), and indeed, looking the canary repository issues, there are a lot of different crashes reported (but, seriously, mostly of these issues are not reproducible and are opened for months as well without a fix). Is it that bad?

And how about OTX? Does it still exist? I don't hear anything about it for a long time already.

What are your opinions? Which engine is better as a start point for you, considering you want a server using the recent clients (because of lots of reasons.. Side panels, automatically reload containers, hotkey bars)?!

That's a really good question, and tbh, there is no right answer to it.
I'm tired of those otbr vs tfs discussions, and I think they are pointless, and they are pointless for a few reasons:

1. Every single existing functional code base that is in there is, ultimately, tfs. Otbr and OTX just branched out too much and have their own personality, but the main system behind, the way things work, the system design issues, the lack of testing, observability and metrics, and the 20 years old design is a common root here, and you can't run away of that, unless you start something fresh (been there, done that not an easy or quick task).

2. Given that, there will be bugs and there will be crashes. There is no way, really no way, you can develop sustainable and consistent code without testing. Ppl can say whatever they want, untested codebases are as reliable as weather prediction - it can work, or not.

3. If you have a stagnated code base, that has been there for years working only in fixing some bugs, it will be obviously more stable. It is not a metric of better or worse, it's just a matter of logic. If you add things to an untested codebase, you will break things. Take TFS as an example, just compare how many issues were opened from 2021 to now (~200 issues opened in 1 year) and between 2019 and 2021 (~121 issues opened in 2 years). So start bringing new features/things and bugs will come, that's a fact, that's how faith based development works.

If you don't care a lot about new features and you only care about stability, pic an old version of tfs, like ~1.3, and be happy with it. It's stable -ish, in the sense it was there for ages and iterated over the critical bugs.

If you wanna new features and don't mind risking some bugs/crashes, then both otbr and tfs 1.4+ would fit. They are definitely different and both has pros and cons:

OTBR: Is in the journey of improving the way things behave, bring new features and innovation for 2+ years, has an active open discord where a lot is announced and support is given. My personal opinion, they are a bit more open minded and focused on solve deeper questions (like how to bring test driven mentality to ots world, the broader usage of protobufs - disclaimer here, Nekiro from TFS also did an amazing job with protobufs). Also, they've recently split the datapack from the codebase, then you can use lightweight canary to do non-global related stuff, what I find great.
TFS 1.4+: Recently started to bring innovation again, but slowly. It was the first base available, so it has some name/tradition.

In the end, both are good choices, both will have bugs but also will give you the flexibility you need. If we don't change the mentalities and focus in the things that really matter, those pointless me vs you discussions will kill the community from inside.

And please don't use the word professional relating to any ots code base without tests, I feel personally offended.

Those are my 5cents.

 

[Night Wolf]

Your question is very valid but to answer that I need to explain how TFS started and how other projects started so you can understand the context of having multiple repositories. Please note this is MY PERSONAL VIEW of things and it might be heavily biased towards the experiences I had in the open tibia community since 2005

In the beginning the community was very fragmented because a lot of servers were being developed in parallel on top of leaked projects, to try and create a community TFS was created. The idea was awesome, a place where everyone could contribute and then releases would be sent to server admins, everyone would be using the same version of a software so reporting would be centralized and the team of devs would know clearly what is the backlog of issues to work on for the upcoming releases. Theoretically it would make a single project and end the crazy parallel market of bases being sold.

What could go wrong?

Well, it's a bit easier for us to point exactly what went wrong looking at the past but to be fair the main problem was how this idea was implemented. You see, latest release was only being shared in Premium Board of otland and GitHub didn't existed back then. That of course created 2 difficult situations for devs and otadmins:

• No documentation or history at all: There was some effort from a few devs to try and document a couple of areas, but mainly they had to choose between fix things and trying to implement new functions. This means it was hard for anyone trying to catch up with the project even to contribute, also this was very restrict to a couple of people.
• Because the latest was only shared to premium members, the market got even worse. Now people were not selling parallel projects but rather the SAME "official" repository. They paid premium board and could re-sell the latest releases to other people who were not around otland, especially in other OT communities. Plus, the idea could only sustain itself it everyone was using the same base and now people downloaded servers from parallel sources or from the releases of "free" tfs and the bug reports devs received were not clear if were from latest release or not, increasing the workload they had to do in order to find out if the bug was really in latest version or people were just using an outdated one.

Now, fast forward a couple of years. The situation got worst and now the team of developers has changed almost entirely. People grew old and couldn't stand anymore this vicious cycle of doing 3, 4 times the effort required to replicate and correct things while still trying to push latest tibia version and features. New devs didn't had the background of changes nor knew if bugs being reported were in latest version and if were already confirmed or denied by previous developers. Lack of communication created a harsh environment for the project development.

This culminated with a community that found bugs, fixed by themselves or paid others to do it mostly because:
1. Reports were not being taken seriously. One part because devs were occupied with other stuff and couldn't stop to check every single report, especially because there's a big chunk of them caused by local modifications.
Second part because the devs were egocentrics piece of shit that considered themselves gods just because they knew the bare basics of Lua and cpp and understood barely the architecture of the project.
2. Greedy: The environment for servers was always harsh. OT numbers has started declining and the servers had to compete heavily against one and another. It lead to most servers fixing critical issues as a way to show "stability" advantage towards competitors.

With all this context, it's easy to understand why most of the projects of this community are singlely maintained: It takes years to understand the architecture, learn the languages involved and start contributing.
By the time you're actually there most likely you won't have time anymore and you will know FOR SURE that you'll end up doing it all by yourself because other devs are not sharing their work, just to be crushed by competitors that knows hidden bugs and also don't share information.


Now, TFS has been in an almost freeze state for a couple of years. It was even hard for professional devs (seriously, I'm not joking) to get their PRs approved or their bug reports taken seriously. I've participated myself in a couple of other open source communities and it was easier for me to get my PRs approved at Nvidia than in TFS. In other side you have a very tiny team that claims this is because they have high standards (yes, higher than NVIDIA!!)
You can find a shit ton of topics saying "this is bullshit" to how TFS has been dealing with things but the truth is we lack devs, we lack maintainers, reviewers and testers. And this isn't exclusive to TFS, all other projects suffer the same as many of here says every now and then: the community is dying.

Because of how hard it was to contribute to TFS, new initiatives have been created: OTX, OTBR, PyOT, SharpOT, Optimized TFS, among others...
At the same time every now and then we still had projects leaking and new bases being formed on top of those already improved projects.
This creates a mixture that is:

• discouraging to every project maintainer to know their work is not being used or that they are doing it all alone.
• discouraging to devs who don't know which initiative to support and where to start
• bad for otadmins that don't know what to choose and where to get support
• bad for otadmins don't know how they can contribute to the projects they use
• bad for players because they have to deal with not updated and unstable servers

In each of the initiatives we had one aspect in where it diverged in both proposal and vision for future with TFS, and that's why they became their own projects at some point.

• OTX: Wanted to include more custom systems that nearly every otadmin includes in their servers but would never be accepted in TFS because it is not "global tibia stuff". TFS could open a custom branch or ask people to include those systems as "optional" with default configuration in config Lua being set to "FALSE" so we would have the custom options there but whoever wants to do a global would have it as default. Because they were not open to this, a new project started.
• OTBR: Wanted to simplify and improve the source code to include newest versions and features, regarding if that would break backwards compability
• PyOT: Make a cleaner source and architecture using Python
• SharpOt: Make a cleaner source and architecture using C#
• Optimized TFS: Now this is possibly the best project we had in this community since I joined it and I could never thank @fabian766 enough for driving it. The goal was to rework the source entirely to optimize it to the fullest, regardless of breaking backwards compability.

You see, TFS has been for years rejecting contributions because it would "break compability with previous TFS versions" but dragging this anchor that is the support to previous versions has its own costs.
1. It's hard to keep updating it thinking about how servers of TFS 0.2 will be affected. Honestly we should break compatibility every now and then to force people to get their bases updated, otherwise regardless of how much work we put into development and fixing things it will never reach end users.
2. The code is a spaguetti of conditions to handle every single version of tibia and tfs.

Now recently they finally moved to the latest tibia protocol, breaking (FINALY!!) the backwards compability. There isn't much of us around and splitting efforts between two bases (or branches in this case) is still BAD in essence, but at least it shows an evolution from their side that they didn't wanted to risk before.


Now, to your question, which base to choose between TFS and OtBR?


And the right answer is: BOTH!
Despite all the fights betweens devs, both projects have their value and what you see in reality is that both still feed from each other.
As @skulls pointed out, the very essence and architecture of both bases are the same and they share common issues. Being it open source, when we see a critical issue being fixed in one of them, we don't even need to communicate, the other part will propose the correction in their supporting base as well.

Now, I'm personally closer to the OTBR team and I sense that they work in a better format (discussing between actually doing things, having a clear definition of roadmap and what is the future they want to achieve). Can it be because I'm closer to OTBR folks and I don't see the side of how TFS devs are doing this? Of course!

Because of the reasons stated above, and the fact that we are trying to understand the past so we don't fall into the same mistakes (again and again), if I were to start today I'd start with Canary, regardless if it was for a global 12.X or a custom project.
The way I see, Canary is the future of otserver community and the team is working really really hard for this future.
We acknowledge what is wrong and what needs to be changed, we want to bring otadmins and users into this cycle and have a more inclusive project for all of us, plus we have more people helping (there's always space for more) and Majesty simply does an immense job to catalog and create extensive tutorials in both english and portuguese for every process and tool.

 

[Nekiro]

If you know how to code take barebone tfs with protocol 12 and code your stuff. (that would be the choice I would take. I prefer to know what I have in my own server)
If you dont know how to code take otbr, because you have stuff already there.
Both choices require you to know how to code though, otbr has issues and tfs has no features.

 

[Night Wolf]

If you know how to code take barebone tfs with protocol 12 and code your stuff. (that would be the choice I would take. I prefer to know what I have in my own server)
If you dont know how to code take otbr, because you have stuff already there.
Both choices require you to know how to code though, otbr has issues and tfs has no features.

by your logic why you don't code everything from scratch since you need to know what do you have in your server? Wouldn't be better if you could only turn on/off features in config.lua and trust that those work?

Also, what you mean in your last sentence, tfs has no issues? otbr is the only repository that has issues? This doesn't make any sense at all...
It's exactly that kind of attitude that stray away good developers from the main repository.

 

[Nekiro]

by your logic why you don't code everything from scratch since you need to know what do you have in your server? Wouldn't be better if you could only turn on/off features in config.lua and trust that those work?

Also, what you mean in your last sentence, tfs has no issues? otbr is the only repository that has issues? This doesn't make any sense at all...
It's exactly that kind of attitude that stray away good developers from the main repository.

Mhm, I definitely wrote that in my last post.

 

[Peonso]

@Night Wolf, your vision is really biased. People parrot there are/were special requirements for TFS PRs, when they were pretty basic, stuff wasn't merged by lack of community involvement, there wasn't enough people reviewing PRs. That's on the community, not on the project.

There is a reason why all those projects are never based on each other, but always pick a solid base that is there for close to two decades now.

Regarding the topic, unless any other option has a exclusive feature that I NEED, I would do what all those other projects do when they start, pick the most updated TFS.

 

[Dip Set]

@Nekiro i love that quote, otbr has issues any tfs has no features. That is a great summary

 

[drakylucas]

After reading all the answers, I decided to pickup otservbr canary repo as base instead of TFS.

Why?
They already have more features implemented, they have a good code quality as well (including bots in github to check for potential issues, code style, etc), it seems they have more testers for pull requests and, the main reason, their support is pretty awesome. I needed some help past days and, after sending them a message in their discord, they helped me a lot and very quickly.

 

[Dip Set]

Your question is very valid but to answer that I need to explain how TFS started and how other projects started so you can understand the context of having multiple repositories. Please note this is MY PERSONAL VIEW of things and it might be heavily biased towards the experiences I had in the open tibia community since 2005

In the beginning the community was very fragmented because a lot of servers were being developed in parallel on top of leaked projects, to try and create a community TFS was created. The idea was awesome, a place where everyone could contribute and then releases would be sent to server admins, everyone would be using the same version of a software so reporting would be centralized and the team of devs would know clearly what is the backlog of issues to work on for the upcoming releases. Theoretically it would make a single project and end the crazy parallel market of bases being sold.

What could go wrong?

Well, it's a bit easier for us to point exactly what went wrong looking at the past but to be fair the main problem was how this idea was implemented. You see, latest release was only being shared in Premium Board of otland and GitHub didn't existed back then. That of course created 2 difficult situations for devs and otadmins:

• No documentation or history at all: There was some effort from a few devs to try and document a couple of areas, but mainly they had to choose between fix things and trying to implement new functions. This means it was hard for anyone trying to catch up with the project even to contribute, also this was very restrict to a couple of people.
• Because the latest was only shared to premium members, the market got even worse. Now people were not selling parallel projects but rather the SAME "official" repository. They paid premium board and could re-sell the latest releases to other people who were not around otland, especially in other OT communities. Plus, the idea could only sustain itself it everyone was using the same base and now people downloaded servers from parallel sources or from the releases of "free" tfs and the bug reports devs received were not clear if were from latest release or not, increasing the workload they had to do in order to find out if the bug was really in latest version or people were just using an outdated one.

Now, fast forward a couple of years. The situation got worst and now the team of developers has changed almost entirely. People grew old and couldn't stand anymore this vicious cycle of doing 3, 4 times the effort required to replicate and correct things while still trying to push latest tibia version and features. New devs didn't had the background of changes nor knew if bugs being reported were in latest version and if were already confirmed or denied by previous developers. Lack of communication created a harsh environment for the project development.

This culminated with a community that found bugs, fixed by themselves or paid others to do it mostly because:
1. Reports were not being taken seriously. One part because devs were occupied with other stuff and couldn't stop to check every single report, especially because there's a big chunk of them caused by local modifications.
Second part because the devs were egocentrics piece of shit that considered themselves gods just because they knew the bare basics of Lua and cpp and understood barely the architecture of the project.
2. Greedy: The environment for servers was always harsh. OT numbers has started declining and the servers had to compete heavily against one and another. It lead to most servers fixing critical issues as a way to show "stability" advantage towards competitors.

With all this context, it's easy to understand why most of the projects of this community are singlely maintained: It takes years to understand the architecture, learn the languages involved and start contributing.
By the time you're actually there most likely you won't have time anymore and you will know FOR SURE that you'll end up doing it all by yourself because other devs are not sharing their work, just to be crushed by competitors that knows hidden bugs and also don't share information.


Now, TFS has been in an almost freeze state for a couple of years. It was even hard for professional devs (seriously, I'm not joking) to get their PRs approved or their bug reports taken seriously. I've participated myself in a couple of other open source communities and it was easier for me to get my PRs approved at Nvidia than in TFS. In other side you have a very tiny team that claims this is because they have high standards (yes, higher than NVIDIA!!)
You can find a shit ton of topics saying "this is bullshit" to how TFS has been dealing with things but the truth is we lack devs, we lack maintainers, reviewers and testers. And this isn't exclusive to TFS, all other projects suffer the same as many of here says every now and then: the community is dying.

Because of how hard it was to contribute to TFS, new initiatives have been created: OTX, OTBR, PyOT, SharpOT, Optimized TFS, among others...
At the same time every now and then we still had projects leaking and new bases being formed on top of those already improved projects.
This creates a mixture that is:

• discouraging to every project maintainer to know their work is not being used or that they are doing it all alone.
• discouraging to devs who don't know which initiative to support and where to start
• bad for otadmins that don't know what to choose and where to get support
• bad for otadmins don't know how they can contribute to the projects they use
• bad for players because they have to deal with not updated and unstable servers

In each of the initiatives we had one aspect in where it diverged in both proposal and vision for future with TFS, and that's why they became their own projects at some point.

• OTX: Wanted to include more custom systems that nearly every otadmin includes in their servers but would never be accepted in TFS because it is not "global tibia stuff". TFS could open a custom branch or ask people to include those systems as "optional" with default configuration in config Lua being set to "FALSE" so we would have the custom options there but whoever wants to do a global would have it as default. Because they were not open to this, a new project started.
• OTBR: Wanted to simplify and improve the source code to include newest versions and features, regarding if that would break backwards compability
• PyOT: Make a cleaner source and architecture using Python
• SharpOt: Make a cleaner source and architecture using C#
• Optimized TFS: Now this is possibly the best project we had in this community since I joined it and I could never thank @fabian766 enough for driving it. The goal was to rework the source entirely to optimize it to the fullest, regardless of breaking backwards compability.

You see, TFS has been for years rejecting contributions because it would "break compability with previous TFS versions" but dragging this anchor that is the support to previous versions has its own costs.
1. It's hard to keep updating it thinking about how servers of TFS 0.2 will be affected. Honestly we should break compatibility every now and then to force people to get their bases updated, otherwise regardless of how much work we put into development and fixing things it will never reach end users.
2. The code is a spaguetti of conditions to handle every single version of tibia and tfs.

Now recently they finally moved to the latest tibia protocol, breaking (FINALY!!) the backwards compability. There isn't much of us around and splitting efforts between two bases (or branches in this case) is still BAD in essence, but at least it shows an evolution from their side that they didn't wanted to risk before.


Now, to your question, which base to choose between TFS and OtBR?


And the right answer is: BOTH!
Despite all the fights betweens devs, both projects have their value and what you see in reality is that both still feed from each other.
As @skulls pointed out, the very essence and architecture of both bases are the same and they share common issues. Being it open source, when we see a critical issue being fixed in one of them, we don't even need to communicate, the other part will propose the correction in their supporting base as well.

Now, I'm personally closer to the OTBR team and I sense that they work in a better format (discussing between actually doing things, having a clear definition of roadmap and what is the future they want to achieve). Can it be because I'm closer to OTBR folks and I don't see the side of how TFS devs are doing this? Of course!

Because of the reasons stated above, and the fact that we are trying to understand the past so we don't fall into the same mistakes (again and again), if I were to start today I'd start with Canary, regardless if it was for a global 12.X or a custom project.
The way I see, Canary is the future of otserver community and the team is working really really hard for this future.
We acknowledge what is wrong and what needs to be changed, we want to bring otadmins and users into this cycle and have a more inclusive project for all of us, plus we have more people helping (there's always space for more) and Majesty simply does an immense job to catalog and create extensive tutorials in both english and portuguese for every process and tool.

I actually read your whole post, as long as it was, it is very well thought out. A great synopsis of the history and reason behind these forks. Good contribution

 

[SorketROrk]

Hello all,

I think the question here is pretty simple and a lot of people already have this doubt.

Supposing the scenario where I want to make a Tibia 12.xx server, not necessarily with global map but just comparing the engine (not the data pack itself), which engine should I focus to use as a start point?

I know that TFS was the first one (at least famous) and the most complete for long time, but looking their github, there are some pull requests without any action for more than 5 years. They don't have almost any feature from recent tibia (for instance: store, prey, imbuements, charms, analyzers and so on). On the other hand, the code quality on TFS looks better than on otservbr (just comparing)

In otservbr github, we can see they have almost all features from current tibia, but it seems a lot of people "hate" the otservbr (I already saw people calling it "ot crash br"), and indeed, looking the canary repository issues, there are a lot of different crashes reported (but, seriously, mostly of these issues are not reproducible and are opened for months as well without a fix). Is it that bad?

And how about OTX? Does it still exist? I don't hear anything about it for a long time already.

What are your opinions? Which engine is better as a start point for you, considering you want a server using the recent clients (because of lots of reasons.. Side panels, automatically reload containers, hotkey bars)?!

I think that if you have some goals in mind, maybe some requirements from the engine then compare and see for yourself to find what is best suited for you. I don't think it matters really, well... it depends on your goals tbh. You will most likely have to add some code yourself to get what you want.

I highly doubt any of the engines mentioned are bug free or have all the features you are looking for. But it shouldn't be hard to deal with and achieve what you want!

It's not just that. There was always an estigma with devs who aren't active in otland. If you're not in the cool kids club, your ideas are rejected, and that's it.
Look how much time many of devs have to chit chat in forum and discord, enough to be able to chase discussions with another project just for the sake of doing so... Are you saying this can't be used for review? What about discussions on roadmap of tfs? What is the development going forward? What about backwards compatibility? The project is made by the community, don't try to treat it as two different things. Now when you have some kids treating a project like it's 4th grade, mocking people that open issues, ofc we won't feel like contributing. By the way, recently I asked epunker to give credits to a very simple code he cherry picked and the guy entered defensive mode, wrote a wall of text in github with images trying to justify he had identified the issue by himself showing a issue that was completely unrelated to the PR he clearly cherry picked and then he banned me from the repository. A simple phrase like "hey, I'm glad you're improving the project with the same PR as Eduardo did for otservbr, but please be mindful about crediting next time" was enough for me to live rent free inside the guy's mind until the point he had to ban me. Yes, in github..
Now, this wasn't the first time. Most of the critical issues that we face in this community were pointed by me years and years ago. I'm not a future teller, I just worked as tester, test coordinator and test manager, and have the "nose" for things that are smelly. Do you know what were the typical comments I've heard from the maintainers? "you're using addevent wrong, of course it will. Crash", "you can't detect a callstack overflow, a PR trying to identify that would never be merged", "this is standard behavior", "this is breaking backwards compatibility", "you're using the function wrong" (when I was clearly using it right).
Hell, @gesior himself wrote more times about how to use addEvent so it didn't crashed but never proposed a root cause solution so it didn't crashed. You know why?


You're completely wrong, for every leaked base there are countless versions and adaptations being used and sold. If you count them all there is way more servers running out there that are custom based, and people just update every year or so once a relevant commit is merged on tfs


The most updated TFS is otservbr. Don't you get it?

Post automatically merged: Mar 3, 2022

This is stupid to think, of course tfs has features and issues. They just don't have developers that want to contribute and know how to identify structural issues.
In one hand you have very good developers that are naturally busy with their carrers and barely show up to do anything, in another you have a couple of bootlickers that want to act like they are incredible contributors when they barely had 6 months studying the basics of programming. It's only natural that even if I propose a gigantic improvement, this would never be approved. Who would review it? Nekiro? Epunker? Those guys can't even form an english sentence that makes sense. Should I wait 2 years until anyone with enough knowledge of software engineering appear to do another miracle for the project?

You mention several good points here. I've been around for far too long and clearly see what you mean. But I have to say that developers who focus on teamwork without judging others for their "lack of fame" are the ones that go on ahead to make great ideas come to life!

The other ones on the other hand.. are stuck in a dark place they have created themselves, maybe even without realizing this. 8/10 devs who are skilled in my opinion, have attitude problems and think highly of themselves for some reason.. as if they did not start from the bottom at one point..

I've also been there.. regarding the "cool kids club" and I can clearly tell when talking to these individuals that they have no intention of being helpful and taking action when it really comes down to it. Its more like they want you to know that they are superior in one or another way, denying proposals/ideas that funny enough, come to be introduced later on under their own name

I hope that one day, some will realize this and change for the better.

 

[Kaspar]

The thread starter's question:

"Which engine is better right now for Tibia 12?"

The conclusion he/she drew:

"After reading all the answers, I decided to pickup otservbr canary repo as base instead of TFS."

Thread is therefore concluded and will be closed.

Congratulations and thanks to you who could have a civilized discussion without attacking people personally.
And a good bye to Night Wolf for personally attacking people, thus breaking our rules here on OTLand yet again.

Take care guys and have a nice day!
Really good weather out here in Sweden these last weeks, hope you all enjoy the upcoming Spring!
And remember, liking one engine more than another, does not make you a bad person! And vice-versa. Please just stop insulting eachother.