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).
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
