[crossfire] Healthbars

Brendan Lally brenlally at gmail.com
Fri Mar 19 13:24:53 CDT 2010


Hello,

The following is a proposed addition to the crossfire protocol to
enable the clients to show monster health bars.

Rationale: Currently there are lots of combat messages sent during
combat, but no real way to know whether your character is 'winning'
in a battle, by displaying health bars above monsters, it is possible
to get a quick visual indication of what is happening, without the need
to read lots of combat messages.
Additionally, the 'flags' I describe below, allow clients to present
information about creatures that in game terms should be obvious, but
which is not currently visible to the client.

In order to implement this, the following is altered.

A setup command 'healthbars' is added, if a client request it with
argument '1' then the server will send healthbar information to the
client, if they do not, then there is no visible change. 
	[Possible expansion, if the setup flag is sent and confirmed,
	expect that the client will ignore attack messages ('you cut
	foo', 'you miss foo', etc)]

The map2 command is extended to have another type of data that may be
sent. type 4 is a healthbar. There follow 2 bytes, the first is the
hitpoints as a proportion of maxhp, the second is the flags that apply
to the hitpoint bar.

The healthbar is sent for an alive creature that is either a monster or
a player. It is sent whenever a face changes on the square, or always
if the creature is below their maximum health. The client should show
healthbars until the information for the square is updated.

The first byte has a value between 0 and 255, 128 means that the
creature is at full health, above that means the creature is above max
health (which doesn't normally happen, but potentially might be
possible) 128 has been chosen because it is a multiple of 32 (the size
of the tile), so calculating the length of a bar should be trivial for
clients.

The second byte provides information about the flags that apply to the
creature, this is a bitmask, currently the values that are used are:

Bit 1, creature is another player or belongs to another player.
Bit 2, creature is friendly (someone's pet)
Bit 3, creature is unaggressive (townsfolk and the like)

Clients are required to ignore any additional flags that they do not
understand.

In interpreting the first two bits then:
00 => a normal monster
01 => another player
11 => another player's pet
10 => the player's pet

The remaining bits are reserved for later use, the intention being that
they should correspond to effects that are on the creature in some way.

Provisionally, the suggestion is to include
* Monster is moving slowly (slowed or paralysed)
* Monster is poisoned
* Monster has some form of beneficial effect working on them

Currently I have a working implementation against the server, and
Ragnor has created a modification to jxclient to handle this, that
leads to something like the following in use: 
	http://imagebin.ca/view/wD2lvaI.html

Since that screenshot was taken, some additional work has been done to 
change the colouring of the bars to reflect the flags that are sent.
the creature has (eg, that sage has been hit, so is now hostile, should
have a different colour to the non-hostile townsfolk) 
There may still need to be something done from a display perspective to
have the bars offset to appear in the bottom of the cell
above the creature's face (although I do not suggest using such an
offset in the data sent from the server.).

Brendan



More information about the crossfire mailing list