Forgottenserver: Health bar question

[Luckey1729]

I wanted to ask if this is a client-sided issue. This did not occur until I updated my source to newest (used to be ~1700.)

I've also noticed that health/mana bar for players now stop at 65535 instead of "overlapping" if anyone is interested.

[marksamman]

The health bar is most likely a server issue with large numbers. I'll see if I can reproduce it soon. Health/mana bar stopping at 65535 when you have more HP/mana than that is intentional because 65535 is the highest value we can send in the protocol.

[Zbizu]

can be send as % then instead of actual value

[WibbenZ]

@Zbizu has a good point.
If the value is over 65535, then we return the percentage of the health / mana.
That would also help high exp servers, same goes for player healths etc.

[Codex-NG]

This compiled fine, I never tested it tho.
In protocolgame.cpp

http://pastebin.com/6JRycCgd

[ranisalt]

It is not useful at all to scale integers to an integer percentage

Edit: hmm I see what was done there, it might actually work but stuff on client will be messy

[Codex-NG]

All i did was take code which was made for an entirely different distro and adapt it to 1.2, so blame the original author :p

https://otland.net/threads/jak-wysylac-hp-i-mane-w-procentach.181560/

Btw instead of criticizing someone, why not contribute a version you deem suitable.

[gugahoa]

It was feedback, don't take it as an offense.

[ranisalt]

So let me explain to prevent further misinterpretation: if you use an integer to behave like a float, you will lose a precious amount of precision. Suppose a player has double the maximum value, ~131k HP, then you can only represent half of the possible values. This is usually not desired.

The code @Codex-NG proposed will work nicely, but it can only represent round percentage values up to 100. That means if that player has 116k HP, roughly 88.5%, it is only possible to represent as 88% (~115.3k) or 89% (~116.6k). Not really significant, but about the HP healed by an ultimate health potion, and that's the loss of precision I was talking about.

The correct solution would be to modify the client to handle larger values, 32 bit are enough to handle up to around level 286 million knights using Tibia hp gain amounts. Unfortunately you can't do that with Tibia client, but you can indeed do with OTClient.

[Tarliton]

Sorry to interrupt, but can't you just send to the player the aproximate percentage as an integer and on the server you treat those values as a long long int, long int or anything you want?
I mean the player would just see that he has 88% of life but in reality it would have 88.X or 89.X. If you need to treat his hitpoints as percentage he would have so many that it wouldn't matter if he sees 88% or 87%. What matter is on the server, not on the client.

[ranisalt]

Yes, yes, that's what I said. The server is more flexible than the client already :+1:
Here's what OTClient does: https://github.com/edubart/otclient/blob/master/src/client/localplayer.h#L149
It holds as double probably to not handle numerical limits.

As a side effect it's nice not to know exactly how close to death you are, it kind of breaks the statistics :laughing:

[Codex-NG]

@ranisalt I see what you are saying now about loss of precision both in your explanation and now my recent understanding of integer division.

The formula should be casted to a decimal value and then rounded up this way you gain rather than lose value.

A simple example is.
msg.add<uint16_t>(uint16_t( ( int32_t) std::ceil( player->getHealth() * 100 / (double) player->getPlayerInfo(PLAYERINFO_MAXHEALTH) ) ));

If double is too small for an int32_t then use a larger datatype.