• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

OTClient 1.0

does anyone have a clue how to fix this blinking creature issue?, also seem to have a problem with closing doors, it works fine on cip client
using version 7.72, tfs 1.2
ezgif-4-62483f479cfa.gif
no image
 
does anyone have a clue how to fix this blinking creature issue?, also seem to have a problem with closing doors, it works fine on cip client
using version 7.72, tfs 1.2

I fixed the animation, however in relation to the door, there is no way for me to test, very bad to find a stable and compiled version and that is why I do not intend to support the old versions unfortunately.

Sry...
 
Last edited:
why support talking to walking related changes wont be supported for old version ? :(
players also uses old distributions
 
why support talking to walking related changes wont be supported for old version ? :(
players also uses old distributions
my intention from the beginning was to stabilize the client and not take the trouble to maintain compatibility with old versions, however, as I said above, i fixed the animation.
 
my intention from the beginning was to stabilize the client and not take the trouble to maintain compatibility with old versions, however, as I said above, i fixed the animation.
yeah i noticed later my net it's a bit delayed .. dunno what happened... anyway im gonna test it right away
thanks for your job <3
Post automatically merged:

@Mehah

hello man .. how's going. I was testing the otclient and found a minor issue related to walking while using smart walking enabled
tested on tfs 1.3 772 downgraded by nekiro and otx3 based on tfs 1.2
Post automatically merged:

is when using diagonals
 
Last edited:
Incredible job!

Also guys, stop asking Mehah to fix compatibility issues with older protocols, he already stated that 10.98 is the focus.

Furthermore, think about this: if we have a fully functioning 10.98 OTclient, then that means that we can forget about the global client and take full advantage of OTClients modular nature...so we're free to downgrade the spr/dat/otb files (or use whatever other method) to make a 10.98 server look like 7.4, 7.7, 8.6 etc.
 
@Mehah Hello, you can do something about this problem. Already known from OTClient: Freeze and eventually crash when "There is no way." · Issue #840 · edubart/otclient (https://github.com/edubart/otclient/issues/840)
- when you click on the road behind the door (when something is blocking the way) the game client is looking for the way and then it gets LAG, if click more time lag is bigger!



i try change
C++:
g_map.findPath(m_position, destination, 50000, Otc::PathFindAllowNotSeenTiles); to g_map.findPath(m_position, destination, 10000, Otc::PathFindAllowNotSeenTiles);
lag is smaller but I don't know how it will affect the playing
 
@Mehah Hello, you can do something about this problem. Already known from OTClient: Freeze and eventually crash when "There is no way." · Issue #840 · edubart/otclient (https://github.com/edubart/otclient/issues/840)
- when you click on the road behind the door (when something is blocking the way) the game client is looking for the way and then it gets LAG, if click more time lag is bigger!



i try change
C++:
g_map.findPath(m_position, destination, 50000, Otc::PathFindAllowNotSeenTiles); to g_map.findPath(m_position, destination, 10000, Otc::PathFindAllowNotSeenTiles);
lag is smaller but I don't know how it will affect the playing

I'm planning to solve that problem in that month - it is connected with A* algorithm, which is trying to find a patch to the unreachable place.
 
Can't we just replicate the solution from Sayans in the optimized tfs? I mean, shouldn't client and server use the same logic for pathfinding?
 
Can't we just replicate the solution from Sayans in the optimized tfs? I mean, shouldn't client and server use the same logic for pathfinding?
I was actually wondering why his changes are not getting included into the main tfs repo to make it better, is he not allowing it or ppl dont have time to test it or what else ?
 
Walking system has been improved, it is now walking more smoothly and with more fps stability.

what about for older protocols the bug i posted was improved or the code for old protocols wont be supported anymore?
 
does anyone have a clue how to fix this blinking creature issue?, also seem to have a problem with closing doors, it works fine on cip client
using version 7.72, tfs 1.2

I've fixed it on my own copy of OTC v1.0, I will send you the fix later tomorrow.
 
yeah i noticed later my net it's a bit delayed .. dunno what happened... anyway im gonna test it right away
thanks for your job <3
Post automatically merged:

@Mehah

hello man .. how's going. I was testing the otclient and found a minor issue related to walking while using smart walking enabled
tested on tfs 1.3 772 downgraded by nekiro and otx3 based on tfs 1.2
Post automatically merged:

is when using diagonals
I've fixed it on my own copy of OTC v1.0, I will send you the fix later tomorrow.
that error was fixed. this is the error now diagonals issues with smart walking enabled
 
I was actually wondering why his changes are not getting included into the main tfs repo to make it better, is he not allowing it or ppl dont have time to test it or what else ?
They are cherry picking some bug fixes from time to time, but Saiyans is actually someone who knows alot of cpp and is rewriting several things that simply break backwards compatibility, which is a pre-req for actual tfs development plan.
This should not be a problem because considering you have the src of otclient, you can simply use latest protocol and remove the new features and program the tfs and otclient to mimic 7.4 versions, for exemple even using 12.4 version.

Besides this he's doing things in a pace way more agile than tfs can handle, let's us remember we are in tfs 1.3 for more than 2 years now? People is simply not reviewing nor testing PRs anymore, so they get stuck and the repo isn't evolving. I wouldn't be wrong to say very shortly tfs will be replaced for his version.

The thing is we always worried more about improving versions and keeping it backward compatible than to actually try to make something that is an engine apart from tibia world. Having this, would not simply improve our architecture, but would also make us work all in same version.
This means more tests, more opportunity for people contribute and more people would use this engine, outside tibia world.

In order to achieve it there are 5 main pilars we need to evolve and a bonus one that would be desirable:
  • AACs
  • Architectures and testing
  • Engine
  • Client
  • Sprites
  • Bonus: Use of new technologies trending

I would say Menah progress pretty much cover the client part, we just need to start making PRs in his repo to create modules, improve user experience and have the best client we can make. What saiyans is doing pretty much covers the engine part, we just need to support him to rework some parts of the src that doesn't make sense at all like itemType -> Item -> Weapon, for example or the division of classes and methods throughout the src. Things are too attached and that makes testing way more difficult.

Regarding AACs, we need to find out what exactly is going wrong with them, znote and Gesior made a huge work to make them look like RL Tibia and they have a lot of cool functionalities and so but there's been so many complaints of sql injection, exploits and other stuff that one can't simply trust to use them. Also it would be great if we had new layouts that don't necessarily are related to Tibia. By running simple tools like sqlmap or acunetix you already get a shit load of warnings about cross-scripting and other flaws.

Architectures and testing is about raising awareness of those points, coming from a team of regression testing I find myself frustrated to know we still trust manual testing and reviews when the vast majority of the src and client could be automatized with some useful unit/regression testings. Also we need to discuss archictures of both engine, client and overall architecture people are using. What works, what doesn't? While I can talk about the engine, I don't have the same experience for talking about overall architecture of hosting, for example. What tools and tricks to use to avoid ddos, iptables? which rules? This is something that we have a lot of different answers but none of them seem to work perfectly for all cases.

Sprites is something that is always in discussion, even when I talked about generating artificially using GANs there were people telling me to stop it because it would make spriters get away from the community and only benefit otadmins. I think we should try to invest in an initiative like peonso had in the past of creating a new spritesheet of just custom stuff to replace tibia strings once for all. That would be the default one when we talk about otclient.

Lastly, there is a huge list of new and trending technologies we could benefit. Machine Learning is something that is very easy to achieve with Python support and that open a door for infinite possibilities, why not try to make tfs compatible with calling python scripts?
I'm doing a master in data science and I see a lot of possibilities to use this learnings to solve some big problems, but since I haven't evolved much in having python support (with sklearn lib) to tfs, is something still that require a manual intervention to run.
 
They are cherry picking some bug fixes from time to time, but Saiyans is actually someone who knows alot of cpp and is rewriting several things that simply break backwards compatibility, which is a pre-req for actual tfs development plan.
This should not be a problem because considering you have the src of otclient, you can simply use latest protocol and remove the new features and program the tfs and otclient to mimic 7.4 versions, for exemple even using 12.4 version.

Exactly. I've stated this several times: once we have a fully working OTClient, be it for 10.98 or whatever protocol, then cip client becomes obsolete in most cases. And once we're free from the cip client shackles, then every distro could then be based on one single protocol, and just mimic the preferred version on the functional/graphical side.
 
@Mehah Hello, you can do something about this problem. Already known from OTClient: Freeze and eventually crash when "There is no way." · Issue #840 · edubart/otclient (https://github.com/edubart/otclient/issues/840)
- when you click on the road behind the door (when something is blocking the way) the game client is looking for the way and then it gets LAG, if click more time lag is bigger!


i try change
C++:
g_map.findPath(m_position, destination, 50000, Otc::PathFindAllowNotSeenTiles); to g_map.findPath(m_position, destination, 10000, Otc::PathFindAllowNotSeenTiles);
lag is smaller but I don't know how it will affect the playing

I talked to a friend who just published a book on Graph Theory, that one of the subjects is about 'search algorithm', he said he would help me solve this problem.

Can't we just replicate the solution from Sayans in the optimized tfs? I mean, shouldn't client and server use the same logic for pathfinding?

Yes, it should, that's how I fixed the walking system.

what about for older protocols the bug i posted was improved or the code for old protocols wont be supported anymore?

it’s not being my focus right now, maybe later.

Edit:
I just tested in version 8.6 and it's working fine, I don't know if the modifications I just made ended up correcting the problem, test with the latest clean revision of OT1.0

I'm planning to solve that problem in that month - it is connected with A* algorithm, which is trying to find a patch to the unreachable place.

Ohhh, thanks, all help is welcome.:D

In this last revision, I improved the walking system, it was causing some 'flicks'.
 
Last edited:
Sprites is something that is always in discussion, even when I talked about generating artificially using GANs there were people telling me to stop it because it would make spriters get away from the community and only benefit otadmins. I think we should try to invest in an initiative like peonso had in the past of creating a new spritesheet of just custom stuff to replace tibia strings once for all. That would be the default one when we talk about otclient.
Lastly, there is a huge list of new and trending technologies we could benefit. Machine Learning is something that is very easy to achieve with Python support and that open a door for infinite possibilities, why not try to make tfs compatible with calling python scripts?
I'm doing a master in data science and I see a lot of possibilities to use this learnings to solve some big problems, but since I haven't evolved much in having python support (with sklearn lib) to tfs, is something still that require a manual intervention to run.

Interesting to see someone with the same idea of using GANs to produce new sprites.
I've worked and written articles about generative networks in the past, though I never really thought about using them for Tibia until now...
I think it would be quite simple really, if we could grab every sprite frame and represent it as a 2D array in Python, I could see a functional GAN using OpenAI's network that produces new animated sprites.

But, like you said, this could make spriters deviate from the community. Though, as a researcher, I am interested in this topic, and it is still my plan to go about completing that project. I just have to figure out how to extract all the sprites and the individual frames.
Here's another idea I had: there is this thread in the forum that converts OTMB maps into JS files with a specific format, which can be used to have a GAN generating Maps as well :) Though, they would be individual pieces (maybe a 20x20 map) which could then be used as a idea starter.

And some other idea, though this one is not as simple, to have fully AI monsters in the game. This would use Reinforcement Learning, which I have worked with quite a bit in the past. The idea is quite simple (i sound so repetitive): A NeuralNetwork training under RL methods will fight against itself (for example, 2 rats will fight with each other, 1 rat is fighting via the NeuralNetwork's architecture, and the other one is Training the architecture). Thereafter, on every iteration, the former rat will then execute the trained network, and so on and so forth. Think about AlphaZero, same idea :)

I don't have that much time right now because I'm working on another article on molecular computation that has to be completed in less than a week (don't ask me how close I am to finishing it! 😳). But, my goal is to complete these projects.
Post automatically merged:

So I keep getting this error from mapview.cpp when I try to compile the client

Lua:
CMakeFiles/otclient.dir/src/client/mapview.cpp.o: In function `MapView::MapView()':
/usr/include/c++/7/array:94: undefined reference to `ViewportControl::ViewportControl(Otc::Direction)'
CMakeFiles/otclient.dir/src/client/mapview.cpp.o: In function `MapView::MapView()':
/otclient/src/client/mapview.cpp:77: undefined reference to `ViewportControl::ViewportControl(Otc::Direction)'
collect2: error: ld returned 1 exit status

I did comment out line 129 which was suggested earlier in the thread:
Code:
//if(!viewport.isValid(tile, cameraPosition)) continue;

I don't quite understand the purpose of this line. If it is true, it continues. If it is false, it still continues... ?
Anyways, here is line 77 that causes the error:


Lua:
    for(int dir = Otc::North; dir < Otc::InvalidDirection; ++dir) {
        const ViewportControl viewport(static_cast<Otc::Direction>(dir));
        m_viewportControl[dir] = viewport;
    }
 
Last edited:
Back
Top