[crossfire] Ground and container view

[Mark Wedel]

On 07/10/11 03:20 AM, Nicolas Weeger wrote:
> Hello.
>
>
> Because I use JXClient which displays contents of a container like the ground
> view, I changed the server to enable browsing container items like the ground
> view, with arrows for "next and prev group of items".
>
> I just realized the GTK client displays contents of a container as children of
> that container, instead of the ground view.
>
> Thus my changes conflict with that, and introduce "paging" for GTK when there
> was none.
>
>
> Now I'm wondering, GTK doesn't limit the number of displayed items in
> containers but the server does limit to 50 the number of items in the ground.
>
>
> This behaviour doesn't make sense IMO - either the ground should display
> everyhing like containers, or both should be browsable.
>
>
>
> So I'm wondering what's the correct fix for that:
> - should server limit items for ground and container view? if so then clients
> should be adjusted
> - should there be no limit? note that currently the server will limit to 100
> for ground view, but no limit for containers...

  So to go into some background on this:

  Way back when, the ground view would display all items.  The problem was that 
if the item had a huge number of different objects (typically in apartments), 
the amount of data that needed to be sent for a ground view was large enough it 
would overflow the output buffers on the server.  The server catches than, and 
presumes it is a slow or otherwise poor client, and drops the connection.  So 
users would get into cases where when they moved onto such a space, their 
connection would just drop.  The solution to this was to limit the amount of 
objects we send at the ground view to 50.  That number was arrived at through 
some analysis based on size of ItemCmd, and I also believe that for non image 
cache users, how much image data might get sent.

  Now containers (and for that matter, the players inventory) could have the 
same issues.  I suspect they typically don't because there are limits on amount 
of stuff (based on weight) that can be put into a container or the players 
inventory - this effectively puts some upper limit on number of items.  Now it 
certainly is possible that this number of items could be too large, but it just 
doesn't seem to happen much.  I suspect some of this may be because in the case 
of inventory of containers, the objects may share the same image much greater 
than the pile of artifacts in the players apartment.

  I also believe that the socket logic has been improved since the original 
problem, such that the server has additional buffers and thus more data needs to 
get generated before the buffers fill up - I think when the problem originally 
happened, the server was just using the size of the OS's buffer, which was 64k.

  So to answer your questions:

I believe there should be no limit for number of objects in ground view - the 
reason that limit was put in place was due to socket limitations, which _may_ no 
longer exist.  However, there could still be potential cases where a limit is 
reached - 1000 objects, or 10,000 objects etc on a ground space may go above 
even the larger buffers now in place.

  For containers, if this was an issue, a limit could be put on the number of 
different objects in a container beyond just weight (limit it to 100 or 200).

  Forcing cache mode for clients would also help this - the amount of data in an 
itemcmd isn't too large - maybe couple hundred bytes (assume 256)?  So 200 * 256 
= 64k  It is when sending images (and potentially animation sequence, such that 
one objects may be 4 images) that you really start using up space.

  In the ideal case, the server really shouldn't care anything about containers 
or ground view.  What I mean by this is that the client would have the contents 
of the container, and it is totally up to the client on how to display that (in 
the ground view, as a child, as a pop up window, etc).  The extent of this would 
be that when the player activates a container, the client would send a request 
to get the contents of the container.  The client could in fact send such a 
request for all containers in the players inventory when the user logs in.

The server would have to some sanity checking in this case (can the player in 
fact open this container (locked chest for example)).  Likewise, whenever the 
player tries to use an object, it would have to same level of sanity checking 
(is this container still accessible to the player, and can the player still 
access it (did not leave the key behind)).

Likewise, some method of moving entire contents of one container to someplace 
else could be done - right now, that seems to be done based on active containers 
and open containers, if the container is on the ground or not, etc - basically, 
the client doesn't have anything to do on it, and I think the client could be 
designed to have a much better way to do this (the client could right now 
iterate through all the items in the container, but ideally you want some good 
primitive like 'dump all items in the sack into the chest'

Some amount of logic in the server is left over from before the client/server 
split and how things worked then (which was when you opened a container in your 
inventory, it would show up in the ground view).  There is also some commands 
still in use which require specific item ordering or view (apply below pretty 
much requires that the server and client agree on what is 'below').  In the 
ideal case, apply below should basically be removed or implemented in the 
client, with the client saying what items to apply - in this way, the stacking 
of objects below the player is not important.

That is relevant because the protocol does not have any good way to preserve 
stacking or insert an item in the 5th position in a stack.  So back to the 
ground view, this means that when the player drops an item, it basically has to 
clear and re-send the entire stack of items on the ground.  So I think that 
might have been another reason why a limit on ground stacks was applied - simply 
because otherwise if you had a big stack, dropping items would result in a large 
amount of data being sent.

I don't know if that answers your question or not :) - but in short summary, I'd 
say that the limiting of ground stacks to 50 items with next/previous buttons is 
a bit a hack (one which I wrote) and should go away if possible.  After all, the 
client already has scroll bars - so it has its own way to present the data.