[crossfire] Container dropping behaviour

[Mark Wedel]

On 09/26/10 03:48 AM, Nicolas Weeger wrote:
> Hello.
>
>
> In relation with bug
> https://sourceforge.net/tracker/?func=detail&aid=2007078&group_id=13833&atid=113833
>
> I will implement the following changes if no one objects:
>
>
> - when dropping a container, just drop it on the floor with its contents ;
> locked status applies, ignore if it is opened or not
> - use the 'empty' command to actually empty the container to the ground
>
>
> This makes containers behave like other items in relation to 'drop'.
>
>
> For avoiding mistake purposes, I'll also prevent dropping a non empty
> container in a shop ("you don't feel like offering the contents of your bag to
> the shop owner"). So to sell a full container, first sell the contents, then
> the container.
>
>
> This would mean adding an 'empty' client-to-server command (like 'drop'), and
> update clients to send it when for instance ctrl-right-clicking on an item.

  I don't think any protocol changes would really be needed here - whild not 
most efficient, on the issue of an empty command, the client could just do 
something like:

  for object in sack
    C->S move 0 object_tag 0
   done

  That isn't totally efficient, but for the number of objects typically in a 
container, still isn't very data.

  Conversely, the client could check to see if the object is applied and 
set/clear that status depending on intended behavior - unapply object before 
dropping it.

  I guess I'm more in favor of having the client do this type of work instead of 
the server - arguably, the drop command itself should get removed from the 
server, and the client do that processing.