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

[Mark Wedel]

Andreas Kirschbaum wrote:
> Nicolas Weeger wrote:
>>> At some level, it is very easy to fix - if player is on a space, and
>>> anything (including face) on that space change, we just send all the
>>> contents of that space again to the player.
>> Why all items? Don't items on a space get a tag, that can be used to
>> simply send this item's update to clients?
> 
> I agree: the server should remember which items and attributes he has
> sent to the client. (Which IMO already have to be implemented in order
> to make the item/upditem/delitem/delinv commands work right.) Using this
> information, the server is able to issue correct upditem commands for
> changed ground objects.

  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.

  Instead, the server has some idea what is has sent to the client based on 
current state of events.  The client knows that first 50 items of a stack will 
be sent to the client when a player moves to a space.  And so it also knows that 
if something changes on those items, it can just update the relevant fields. 
However, the server has to know what has changed - you can't simply say 'object 
foo has changed - send client updates'.  The code has to say 'nrof in foo has 
changed, so update nrof in client'.

  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.


>> The bug isn't important enough to warrant the fix.
> 
> I somewhat disagree here: the bug is at least (slightly) confusing. For
> example, go into Beginners and follow the instructions of the first
> handle ("Type an A to open"). This applies the handle but the ground
> view does not change until you move off and on.

  Also for things like spikes and gates, it may be hard to see that they are 
still moving if your character is on top, but if properly updated in the look 
window, becomes very clear they are still going up and down.


>> Also, one should consider the case where the modified face is not
>> visible because the map layer is full (can happen if many objects).
> 
> Map layer does not apply here since it is the ground view. But still:
> the ground view holds only a maximum of 50 objects.

  Which, just as a note, was a limit put in purely for bandwith and socket 
limitation issues (current max size of a socket packet server supports is 64K, 
so can't go more than that.  You also don't want to be sending too much data at 
once to client, as that also then causes lag (sending 64K of data over a 1.5 mbs 
link (fairly typical DSL speed) would take 400 ms. Given a standard game tick is 
120 ms, fixing things so that larger amount of data can be sent at once may not 
be a good thing).

  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.

  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.