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
