OTclient 1.7

[lodjuret]

hi, New to this world!
I have followed a guide here for fun and manage to get 1.7 TFS up and running.
Which OTclient should I use? It doesn't work with normal otclient. thank you very much!

 

[Sorky]

I used mehah and it worked, the main branch should also work.
I was using 1.7 from tibiadev tho

 

[vestr]

You guys know where to find a map editor for TFS1.6 Client 13.10?

And lodjuret i use mehah otclient also it worked.

 

[M4rcin]

Mehah is full of bad practices (very recent, approved commit here), I suggest you avoid it because it's beyond repairing.
You will be much better off connecting using protocol 11 using OTCV8, or even adding newer communication from Mehah, as that part should mostly work, but I would not trust it with anything more complicated.

 

[Sorky]

Bad practice because it added a 2 vector map, and adding a third dimension would need another 24 enums? Are you gonna add 3d sprites to Tibia or what?

 

[M4rcin]

Bad practice because it added a 2 vector map, and adding a third dimension would need another 24 enums? Are you gonna add 3d sprites to Tibia or what?

There are no vectors, nor maps in this commit, and I clearly meant a different SIZE_

... and we’re going off-topic now. Please remember this isn’t some scammer’s Discord - you’re already breaking the first rule of this forum.

 

[Mehah]

Mehah is full of bad practices (very recent, approved commit here), I suggest you avoid it because it's beyond repairing.
You will be much better off connecting using protocol 11 using OTCV8, or even adding newer communication from Mehah, as that part should mostly work, but I would not trust it with anything more complicated.

Oh no, you really came here to talk trash about the code written in OTCR, seriously. Have you even seen what a mess v8 is? Saying it’s much better than OTCR already says a lot about your level of programming knowledge. I might as well pull out some “really beautiful” v8 code.

otcv8-dev/src/framework/core/graphicalapplication.cpp at 3d32139512cc4576b105682c3579f18fe0d534e4 · OTCv8/otcv8-dev

OTCv8 Development repository (source code). Contribute to OTCv8/otcv8-dev development by creating an account on GitHub.

github.com

otcv8-dev/src/framework/graphics/drawqueue.cpp at master · OTCv8/otcv8-dev

OTCv8 Development repository (source code). Contribute to OTCv8/otcv8-dev development by creating an account on GitHub.

github.com

otcv8-dev/src/client/outfit.cpp at 3d32139512cc4576b105682c3579f18fe0d534e4 · OTCv8/otcv8-dev

OTCv8 Development repository (source code). Contribute to OTCv8/otcv8-dev development by creating an account on GitHub.

github.com

otcv8-dev/src/client/localplayer.cpp at 3d32139512cc4576b105682c3579f18fe0d534e4 · OTCv8/otcv8-dev

OTCv8 Development repository (source code). Contribute to OTCv8/otcv8-dev development by creating an account on GitHub.

github.com

https://github.com/OTCv8/otcv8-dev/blob/3d32139512cc4576b105682c3579f18fe0d534e4/src/client/mapview.cpp#L155

 

[M4rcin]

Have you even seen what a mess v8 is?

So you and Zbobu decided to create even more of a mess and not use language features, but manually write down 70 enums?

 

[Mehah]

So you and Zbobu decided to create even more of a mess and not use language features, but manually write down 70 enums?

Me, stirring up trouble?! The only mess here is the code you keep defending.

 

[M4rcin]

OTCR is the ONLY choice nowadays, period.

I am sure there are other choices, and other ways to load a texture without writing down hundreds of lines per texture size, but it's ok if you guys are not aware of that yet. We all start somewhere.

It outperforms OTCv8, it has more features, more fixes, more support.

... and more enums, that's for sure.

 

[jeanphilip]

This is completely garbage!

OP, don't listen to this M4rcin character, you can search yourself and see he only ever speaks to trash talk, purely toxic troll in the most sincere form of the word.

OTCR aka Mehah's IS THE best option out there, because it's the only one that is actively maintained, supported and undergoing development.. OTCv8 barely gets any updates to it, ever... Even if you visit OTA, you will find most the ones who used to live by OTCv8 are even switching over to OTCR, even Oen himself recommends it (oen is the current and only maintainer left for OTCv8)

TLDR;

OTCR is the ONLY choice nowadays, period. It outperforms OTCv8, it has more features, more fixes, more support.

View attachment 96151

otcr is mehahs otclient? Where is the url repo? Would like to mess with it. Could you attach it here? Thanks in advance

 

[Beatss]

I am sure there are other choices, and other ways to load a texture without writing down hundreds of lines per texture size, but it's ok if you guys are not aware of that yet. We all start somewhere.


... and more enums, that's for sure.

It’s genuinely amusing to see you call Mehah’s code “unfixable,” especially when OTClient Redemption is the only fork in active maintenance, receiving real updates and actual bug fixes. Yes, truly outrageous behavior from a developer: caring about the project, improving it, and keeping it alive. Terrifying stuff.

You highlight “bad practices,” “too many enums,” “messy code,” yet forget the small inconvenient detail that OTCR works, is updated, and is used by most people who need a client that doesn’t fossilize. But of course, for someone who seems far more interested in nitpicking code aesthetics than delivering functional software, I can see how that would be upsetting.

And the whole “just use V8 because it’s better” speech… well, anyone who opens the V8 repository and looks around quickly notices the charming architectural chaos. Legacy chunks everywhere, inconsistent patterns, and layers sewn together over the years like a Frankenstein patchwork. But sure, if you want to label that as superior engineering, go ahead.

Meanwhile, Mehah is doing the boring, unglamorous work that real programmers do. Refactoring, fixing regressions, maintaining compatibility with recent protocols, implementing features, keeping the project alive. You know, the kind of stuff that actually matters when you maintain a client used by thousands of people.

But by all means, keep repeating that his code is “beyond repair.” The entire community actively using OTCR must be wrong, and only you have unlocked the ultimate wisdom of software engineering. A lone enlightened mind among the mortals. All that’s missing is your own contribution to demonstrate how things should be done.

In the meantime, everyone who needs a maintained, functional, production-ready client continues using OTCR and appreciating the fact that Mehah exists. Without him, the alternative would be relying on abandoned forks and opinions like yours, which, while entertaining, do very little to keep a real project running.

 

[Mehah]

I am sure there are other choices, and other ways to load a texture without writing down hundreds of lines per texture size, but it's ok if you guys are not aware of that yet. We all start somewhere.


... and more enums, that's for sure.

​

Dude, you’re hung up on enums, you’re like those guys who keep saying they won’t be with a woman who has stretch marks or varicose veins. Seriously, man up!

Post automatically merged: Nov 20, 2025

otcr is mehahs otclient? Where is the url repo? Would like to mess with it. Could you attach it here? Thanks in advance

GitHub - opentibiabr/otclient: An alternative tibia client for otserv written in C++20 and Lua, made with a modular system that uses lua scripts for ingame interface and functionality, making otclient flexible and easy to customize

An alternative tibia client for otserv written in C++20 and Lua, made with a modular system that uses lua scripts for ingame interface and functionality, making otclient flexible and easy to custom...

github.com

 

[M4rcin]

Dude, you’re hung up on enums, (...) Seriously, man up!

I’m just curious why, instead of letting the code rest and improving it when a better idea comes, you guys force something out and then defend adding 70 enums just to load one texture.

Wouldn’t constexpr or some macro be better instead of writing it all down?
If you need that many enums, maybe it shouldn’t be an enum at all?

Or should I just “man up” and add another 140 lines if I want to load a 512x texture?
Another 280 lines if I want 1024x support?

There are no deadlines here, the PR was open for only 3 days. It's easy to see what happened - one of the contributors got excited and merged it prematurely. No one competent verified the PR,

You guys now see, this is the reason why your code quality deteriorates - you rush things, you'd rather defend your code instead of improving it, faced with critique, you cope with whataboutism and some virtue of "keeping repo alive" ... and this is why I suggest anything from the past will be better, but I get someone inexprienced might diagree with me, and thats perfectly fine.

 

[Mehah]

I’m just curious why, instead of letting the code rest and improving it when a better idea comes, you guys force something out and then defend adding 70 enums just to load one texture.

Wouldn’t constexpr or some macro be better instead of writing it all down?
If you need that many enums, maybe it shouldn’t be an enum at all?

Or should I just “man up” and add another 140 lines if I want to load a 512x texture?
Another 280 lines if I want 1024x support?

There are no deadlines here, the PR was open for only 3 days. It's easy to see what happened - one of the contributors got excited and merged it prematurely. No one competent verified the PR,

You guys now see, this is the reason why your code quality deteriorates - you rush things, you'd rather defend your code instead of improving it, faced with critique, you cope with whataboutism and some virtue of "keeping repo alive" ... and this is why I suggest anything from the past will be better, but I get someone inexprienced might diagree with me, and thats perfectly fine.

Now I get it, you’re making all this fuss because of this PR: feature: support large spritesheets by Zbizu · Pull Request #1445 · mehah/otclient (https://github.com/mehah/otclient/pull/1445)

With all due respect, go find something better to do. Or better yet, since you’re criticizing other people’s contributions, why don’t you open a PR yourself and offer a better solution?

 

[M4rcin]

why don’t you open a PR yourself and offer a better solution?

Because you don’t require quality. Any work put into this branch is lost because it will be superseded by commits like that.

 

[oen432]

While Marcin is being very offensive instead of supportive, he does have a point. OTCR needs better PR reviews, this is another one that was merged when it shouldn't feat: dragging item icon by SkullzOTS · Pull Request #1466 · mehah/otclient (https://github.com/mehah/otclient/pull/1466), memory leak was added just few hours ago.
But yeah, Marcin should have just point out the code quality in the PR itself instead of bashing on the entire OTCR repo here on otland.

 

[M4rcin]

While Marcin is being very offensive instead of supportive, he does have a point. OTCR needs better PR reviews, this is another one that was merged when it shouldn't feat: dragging item icon by SkullzOTS · Pull Request #1466 · mehah/otclient (https://github.com/mehah/otclient/pull/1466), memory leak was added just few hours ago.
But yeah, Marcin should have just point out the code quality in the PR itself instead of bashing on the entire OTCR repo here on otland.

I couldn’t, I found it after it was already commited. Would I meet with a different reaction there? I don’t know

I might be mildly offensive but I myself I am also offended by that commit.
70 new enums for one texture? For real? You guys are better than that.

 

[Mehah]

While Marcin is being very offensive instead of supportive, he does have a point. OTCR needs better PR reviews, this is another one that was merged when it shouldn't feat: dragging item icon by SkullzOTS · Pull Request #1466 · mehah/otclient (https://github.com/mehah/otclient/pull/1466), memory leak was added just few hours ago.
But yeah, Marcin should have just point out the code quality in the PR itself instead of bashing on the entire OTCR repo here on otland.

I’ve just reviewed the PR and I really didn’t see any memory leaks. At most, what happens is that a new widget is created every time Display is called instead of reusing the one that’s already instantiated.

In practice, this is not really an issue, because the object is a shared_ptr coming from C++, and the client has a GC that runs periodically to clean up objects that are still hanging on the Lua side. On top of that, this GC already fixes a pretty serious memory leak that exists in the sound system implemented in Lua.

otclient/src/framework/core/garbagecollection.cpp at a6ee8100c6546deb2de2fe2b5ace045036a63da4 · opentibiabr/otclient

An alternative tibia client for otserv written in C++20 and Lua, made with a modular system that uses lua scripts for ingame interface and functionality, making otclient flexible and easy to custom...

github.com

And I just saw that it's been fixed: fix: prevent WARNING: Lua warning: member function call skipped becau… · mehah/otclient@a6ee810 (https://github.com/mehah/otclient/commit/a6ee8100c6546deb2de2fe2b5ace045036a63da4)

Post automatically merged: Nov 21, 2025

I couldn’t, I found it after it was already commited. Would I meet with a different reaction there? I don’t know

I might be mildly offensive but I myself I am also offended by that commit.
70 new enums for one texture? For real? You guys are better than that.

You’re so annoying, did you ever snitch on your classmates for cheating at school?

 

[M4rcin]

In practice, this is not really an issue, because the object is a shared_ptr coming from C++, and the client has a GC that runs periodically to clean up objects that are still hanging on the Lua side. On top of that, this GC already fixes a pretty serious memory leak that exists in the sound system implemented in Lua.

... unless it's referenced elsewhere, then the GC won't clean it.

I think this concludes this thread.
You are so repulsive with your personal attacks, no wonder there is no one above coffee table height IQ to review, thus over these several years, you have never learned.