• 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!

Difference in displaying floors/levels in game - OT distributions vs real tibia (picture)

forumek

Member
Joined
Jan 14, 2019
Messages
61
Reaction score
22
OT distributions vs real tibia:

0.jpg

As you can see, house on the left, house on the right and depo is showing different floor/level whilst characters are on the same sqm.

That spot is just an example, differences are on the whole map because of the way these distributions are handling it. Every OT distribution is affected so you can compare other spots yourself with real tibia if you want.

This is a significant mismatch for a real map servers

What is the cause of this and where?
 
He's right tho. It's inconclusive to say the cause is on the server side if you don't use the same exact client and version on the comparison.

It doesn't mean that you are wrong, it's just unproven/inconclusive. The burden of proof is on you, since you are the one raising this.
 
Please don't write such a nonsense. It wasn't smart.
and I can say the same to you, please don't write such a nonsense and don't negate the correct answer.

It is handled client-side and cipsoft changed how client calculate last visible floor.
Here are screenshots using the same map and different client versions:
12.40
2.jpg

10.98
1.png
 
and I can say the same to you, please don't write such a nonsense and don't negate the correct answer.

It is handled client-side and cipsoft changed how client calculate last visible floor.
Here are screenshots using the same map and different client versions:
12.40
2.jpg

10.98
1.png
Use 12.40 client and it will be the same
It is not handled client-side.
Post automatically merged:

Here is the proof:


Pay attention at 18-19 second mark when he step in on that sqm

Video is from Apr 16, 2015 so Tibia 10.70 at that time

So it was handled like this on real tibia from the beginning, TFS and other similar distributions handling it differently
Post automatically merged:

@fabian766 Did I say something funny? or you have nothing to say
Post automatically merged:

Come on people , instead of solving the problem together you are trying to dismiss me. I understand that not everybody pays attention to such details and these primitives and who cannot comprehend it are just laughing which is sad.
 
Last edited:
Alright let’s think about this for more than 5 seconds:

The server handles the map and the client handles the rendering of it.

That alone should be enough to dissuade your doubts but you might argue on:

Sure, the server could potentially consider the player’s position, the map surrounding them and calculate the way it wants the client to render, but then how will it let the client know how to render this?

Yeah- send it over as well with the map description. It’s extra data transfer and extra compute power.

On top of this, the server still has no control over what the client chooses to do, as it would still send the description of the floors above (I assume this is still true in newer versions of tibia).

Do you really think that the company implemented a change which impacts $$, introduces a lot of programming headaches, and changes the schema of a well working protocol, for arguably no added value?

That’s why they are all laughing, and trying to tell you... it. is. client. sided.

(And if it weren’t, I shift my laughter to CipSoft for such an idiotic move)
 
There is no need for explanations because this random video proves it


uploaded in Apr 16, 2015 so client was 10.70 back then and you can see even back then house on the left righ and depot was showing different floor/level
and as everyone knows we are using the same client as CipSoft
So how you explain this that we have it displayed differently in 10.98 or any other version?
 
Honestly if I were to guess at a simple solution based on the information in this thread..
Is that there is are invisible tile(s) with no functional use above the character in cipsoft map, in order to aid with small / awkward area's of landscape.

Since the client doesn't care whether or not a tile above the character is invisible or visible, it would render the scene differently simply based on the fact that the tile exists.

At that point, having the mapper include those tiles is practically trivial, after learning where they are required.

This would be my solution to this problem.
 
Honestly if I were to guess at a simple solution based on the information in this thread..
Is that there is an invisible tile(s) with no functional use above the character in cipsoft map, in order to aid with small / awkward area's of landscape.

Since the client doesn't care whether or not a tile above the character is invisible or visible, it would render the scene differently simply based on the fact that the tile exists.

At that point, having the mapper include those tiles is practically trivial, after learning where they are required.

This would be my solution to this problem.
Thanks for pointing this out. This would be the only other possible explanation.
 
Thanks for pointing this out. This would be the only other possible explanation.

It's not, see below.

There is no need for explanations because this random video proves it


uploaded in Apr 16, 2015 so client was 10.70 back then and you can see even back then house on the left righ and depot was showing different floor/level
and as everyone knows we are using the same client as CipSoft
So how you explain this that we have it displayed differently in 10.98 or any other version?

I saw your video but the problem with it is that the character is not standing still before entering the square in question.

Let's elaborate: if you click the map, the server will stream the packets that make your client move the character right after the other (only accounting for step duration), and the client then shows you character moving. In that scenario, there is a delay between what the server sends and when your client gets it, called latency (more commonly referred to as lag).

This is different when you walk on demand (move using the keyboard), and particularly, when you're standing still and are taking your first step. When you do that, the client performs the first step and starts showing it to you right away (character movement animation), and "in parallel" actually lets the server know of your request to move. The server then sends your client the acknoledgement and actual movement of your character, and signals your client that it's ready to perform any other movements.

Now, there is also another thing in play here called Jitter, which is the variation of latency between packets being received. When you autowalk, your client is receiving a stream of movement packets in succession, and these often take different time to arrive. This causes some "stutter" which you actually can see if you pay close attention to your video: there are certain "double" steps that the character performs.

You wanted an explanation, here's a plausible one: Your client got the acknowledgement for your character stepping into the square north of the one you're asking about, and proceeded to start the animation for that movement (and hiding the floor in the process).

Sadly, your video is still not conclusive, so try again if you'd like- you're the one who's wasting a lot of time chasing a red herring :)
 
It's not, see below.



I saw your video but the problem with it is that the character is not standing still before entering the square in question.

Let's elaborate: if you click the map, the server will stream the packets that make your client move the character right after the other (only accounting for step duration), and the client then shows you character moving. In that scenario, there is a delay between what the server sends and when your client gets it, called latency (more commonly referred to as lag).

This is different when you walk on demand (move using the keyboard), and particularly, when you're standing still and are taking your first step. When you do that, the client performs the first step and starts showing it to you right away (character movement animation), and "in parallel" actually lets the server know of your request to move. The server then sends your client the acknoledgement and actual movement of your character, and signals your client that it's ready to perform any other movements.

Now, there is also another thing in play here called Jitter, which is the variation of latency between packets being received. When you autowalk, your client is receiving a stream of movement packets in succession, and these often take different time to arrive. This causes some "stutter" which you actually can see if you pay close attention to your video: there are certain "double" steps that the character performs.

You wanted an explanation, here's a plausible one: Your client got the acknowledgement for your character stepping into the square north of the one you're asking about, and proceeded to start the animation for that movement (and hiding the floor in the process).

Sadly, your video is still not conclusive, so try again if you'd like- you're the one who's wasting a lot of time chasing a red herring :)
OMG I can't believe that you are saying this. You complicating this too much and act like a noob
 
OMG I can't believe that you are saying this. You complicating this too much and act like a noob

Thanks! I have 5 years working in the Networking field for Microsoft, and I believe I know how this shit works, but I guess that's not enough credentials for an eminence like yourself :)
 
The only logical explanation for this, since none of these answers please you, is that tibia characters are based on height.

If your character is over 6ft (GM outfit), you'll see the roof and 2nd floor, if your character is under 6ft (normal outfit), well, you'll only see the ground floor.
 
It definitely is client-side. Server sends all those floors regardless and it's client's role to "choose" what to display. It is determined by objects' properties in Tibia.dat (such as top order, block missile etc.). You can change client's "behavior" by messing with those settings.
You can also 'hack' client's camera to show any chosen floor (called level-spy).

Possible explanations on why it's different in the example above:
  • different Tibia.dat
  • differences on the map
  • different client version (they could have changed some rules about that, but I kinda doubt it)
 
Last edited:
I'm done. I see there is no point in arguing with you all.

There's no point to argue. What I'm saying is 100% confirmed, as I have done all of that myself:
  • messed with what client shows by changing stuff in Tibia.dat
  • wrote level-spy programs
  • dismantled tibia map packets
It is purely on client side. When you're on the surface server always sends map of all floors from 0 to +7 to the client.
 
Last edited:
Back
Top