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

[Mark Wedel]

Andreas Kirschbaum wrote:
> 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.

  It sort of depends on the design idea.  Do we try to send updates by 
remembering all the state of everything we sent, or do we try to send updates 
based on changes we know about.

  It was an intentional design decision for many reasons not to hold state on 
the server for updates sent to the client.  In many ways, holding state is 
actually more complicated - if you try to hold all state, this also means you 
try send add and remove objects based on this state.  And if for some reason the 
stack of objects the player is on gets resorted, figuring out all the changes 
could be O(n^2)

  It would be much more complicated for the server to try and figure out object 
state based on stored output buffer - you'd basically need to come up with a new 
'mini' object type that stores the attributes we send to the client, and thus 
compares the values.  That in itself isn't really hard, but I think adds a layer 
of complexity that isn't really needed.

> 
> 
>>   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.

  I agree they should probably be fixed.  But there may be some cases where it 
is really hard to deal with, but I can't think of any off the top of my head.

> 
> 
>>   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.

  You might be surprised how many ways could result in an object needing to get 
updated to the client.  So this may not be as rare as you might think.

> 
> 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.

  Except there is no remembered list, so that would all have to be new code. 
I'd argue that right now at least, the number of cases with 50+ objects on a 
space is low enough that just not trying to handle it at all is the most 
efficient (but perhaps somewhat buggy).

  If this is seen as a major bug, probably the easiest and most efficient thing 
to do would be to just make up an array/hash that stores the object tags for 
those we have sent - then it is very quick to know if we have sent a specific 
object or not, and is also very quick to clear (don't need to walk a list, don't 
need to worry about freeing name pointers, etc).  But I'd rather look at ways to 
deal with large stacks of object, as the click here to see more/prev method to 
me was always really just a hack.

> 
> 
>>   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.

  I'd put the limit on pickable objects.  Say we limit 30 pickable object per 
space.  If more than that, they fall the neighboring spaces (which is somewhat 
realistic - see how much junk you can make in a pile before it falls down to a 
neighboring space).  One could expect that on any given space, the number of non 
pickable non spell objects would be pretty low (5 maybe?).  Now there could be 
more than 15 spell effects on a space, but the player can not interact with them 
- it can be nice to see in the look window what the effect is.  But saying that 
a character can only discern the first 10 would make perfect sense (if you're 
being hit by 30 things at once, you probably wouldn't be able to figure out what 
all of them were).

  It might be even nicer to try and merge those spell effects in the client view 
in some way (5 slows, 3 fires, etc), but that adds yet more complication, and 
some limit of number to send would still be necessary, as there could always be 
more than the defined limit on a space.

  The only real issue here is what happens once spaces get to their limit of 
objects.  I should be able to drop objects on a space an fill up an entire 
dungeon (supposing I had enough non mergable objects) - there has to be a limit 
to how far they would travel - like to a neighboring space.

  Now for players, one could do something like 'there is no space to put that 
object', but what about cases where there is a monster on a pile of stuff that 
dies?  Its stuff should go someplace.

  Another alternative is maybe that the player can only see the first 35 items, 
and print a message like 'there is more stuff on this space you can't see'. 
After all, that is also somewhat realistic - if you have a huge pile of stuff, 
you probably can't see the stuff at the bottom - you'd need to dig through it to 
see it.


> 
> 
> Andreas
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire