[crossfire] Ground and container view

[Mark Wedel]

On 07/11/11 11:47 AM, James Lopeman wrote:
> The container change works out fairly well on the GTK2 client. It also
> prevents disconnects when you have a bag full of rings and such.
>
> Unlimited ground view and container view have a large number of issues.
> Even inventory view CAN ( and has ) caused client disconects.
>
> Containers like ground can hold huge lists and its safter and more consistent
> for them to be .. consistent.


  Certainly the current implementation prevents some issues, but it is a bit of 
a hack.  If one applied the 'click here to see next group of objects' to the 
players inventory, that would be really odd.

  And I still hold by the statement that it would be better of the client to 
have all the data, and let it decide how it wants to display it - having the 
breaking down long stacks of the objects on the server isn't ideal.

  A better approach, and one that probably works for all cases of a long list of 
objects, is to have the server send the list of objects, and when it reaches 
some amount, it sends some special marker to say that there are more objects on 
this space/in this container (and container could be players inventory), and in 
that marker is an object tag - probably the next one to send.

  The client could then have some command which basically amounts to 'send me 
the next batch of objects, starting with tag X.  The server then does so if 
applicable (eg, if the player has moved to a new space, and object X is no 
longer below them, it doesn't send anything or maybe sends an error code).

  This would work pretty good, because the client wouldn't get that marker until 
it had read all that data - which means that data isn't queued up on the server.

  One problem with the current look view method is that the server stores the 
current position of the look stack - which means that the current method would 
not scale very well for general case.

  In the ideal case, the client could also say how large it wants those batches 
- if on a slow connection, you may want to limit it to 10 objects - after all, 
if you are in combat and moving through an area, you don't want lag caused when 
you step onto some huge pile of objects.  If on a LAN, you might want that value 
to be 50 or 100.

  These changes probably would not be that hard - pretty much all the code is in 
place - the only thing that may be necessary is slight changes to make the 
marker more clear.  When the server responds to the clients 'send me next 
batch', it would not send the clear stack command - it would just send the next 
batch, and repeat as necessary.

  In theory, right now, the client could intercept the more/previous items in 
the stack, and apply them, and when it gets them, don't actually clear the stack 
and add onto it, but this requires adding a lot more complexity than just 
tweaking the protocol a little bit.

  The other thought I had, which I think is more work, is have a method where 
the server just sends the objects tags for what is in the container (eg, sack 
<tag1><tag2><tag3>....<tag500>) - since each tag is only 4 bytes, unless we are 
talking thousands (and potentially tens of thousands) of objects, you would 
never run into a case of filling up the server.

  The client could then use some method to get information (requestitem 
<tag1><tag2>...) - this is pretty much the same way as it deals with images - 
the advantage here is that the client could make these requests as it sees fit, 
and it provides a very efficient method for the server to state everything on an 
item or space.  As noted in my other e-mail, one problem with the floor is that 
stacking there has to remain consistent between client and server.  So when a 
player drops an object, the server has to re-send the entire contents for the 
ground view, which includes name, face information, etc.

  With something like the above, the server could basically send the entire 
floor look in not many bytes.  But this is much more complicated for the client 
- it basically has to keep orphaned objects around for some amount of time - the 
protocol would basically be as is now - when the client gets that command for 
the floor contents, it starts from a clean floor, but in fact, if the player is 
just dropping an object and not moving, many of those objects currently on the 
ground will be re-used.

  This is probably a lot more complicated than it is worth, because tracking 
stale objects becomes much harder.  For example, server sends the stack of 
objects to the client, and the client requests the full info on them.  The 
player then steps off the stack, and a few ticks later, steps back on, and 
server sends the tags again.  The client still has the tags, but neither the 
server nor client really know if any of those objects on that space have changed 
(hit by a lightning bolt and maybe the number of some have decreased, etc).