[crossfire] Bug [ 1735459 ] Ground view missing face updates

[Andreas Kirschbaum]

Mark Wedel wrote:
>   The server has no memory what it has sent to the client, save for
> the map. To remember what it has sent to the client would require that
> for each player, a complete copy of the spaces contents to be recorded
> as last sent.

I was not aware of this. But remembering the ground view attributes
should not be that much a problem (given that we have an always
allocated 64K buffer for output data). The inventory view may be a
problem since there is currently basically no limit for the number of
inventory objects.


>   Note that in some/many cases, the server may send upditem/deltim
> commands to the client for objects it hasn't sent. That isn't terrible
> - the bandwidth of the item commands, unless you are on a large stack,
> usually won't be that costly.

I think this is a behavior that should be "fixed" since it makes it
impossible to detect actual bugs:

Until now I did add checks to all the clients I wrote/fixed (a bot,
jxclient, and possibly gtk client) to print a warning whenever such an
impossible condition happens. If such "violations" are actually supposed
to happen, at least the protocol specification should be updated so that
it explicitly allows such inconsistencies.

But allowing such inconsistencies, the client-side checks do not make
sense and should removed. Which in turn means that we would not be able
to detect actual bugs when incorrect upditem or delitem commands are
sent.


>   Checking to see where the object is in the stack of 50 viewable
> objects of the client is a costlier issue. Other than walking the
> object list (following the below pointers), there isn't any easy way
> to know if the object is in the viewable list or not.

One could argue that more efficient data structures could be used. But
that probably is not necessary:

a) The server only walks the list of 50 objects if the object is a
candidate to be updated; this should not be happen too often.

b) The current solution is (if I did understand it correctly) to always
send all objects. In this case, both checking the remembered list and
sending all objects have linear complexity. But checking the remembered
list should be much less expensive than resending all. Therefore the
code would become more efficient despite the linear search.


>   I suspect that a lot of code, including Ryo's recent changes,
> presume that the objects in question will always be in that stack of
> 50. That is simple, and doesn't waste too much bandwidth.
>
>   What I'd really like to do at some point is limit number of objects
> on a space to 50, so this is never an issue. But with spell effects,
> that would likely cause problems.

And don't forget players exploiting this for example by dropping random
loop near a generator to prevent it from spawning new monsters.


Andreas