Re: [crossfire] Handling massive loot

2021-03-24 Thread Mark Wedel

I totally agree that my proposed fix is a pretty big hammer to fix the problem, 
but it is a simple way to do it.

It might not be that hard to add some logic (even on the server) of something 
like like 'repeat last command until successful/complete'.  So you could do a 
dropall, and it drops 10 items/tick, and keeps doing so until there is nothing 
more to drop.  Same for pickup (though in that case, there would be a change in 
behavior, as you would have to sit on the space until nothing is left to be 
picked up, and this might be non obvious if you have different pickup modes set 
(value density), because there might still be a bunch of items on the space, 
but nothing that matches the pickup criteria.

Now this actually works reasonably well - at each players tick turn, the socket 
can check if the player has issued any new command - if so, it executes that, 
thus breaking the sequence of repeating the command.  To me, it would be really 
annoying to do something like 'drop all', and be frozen with no way of 
interrupting it until everything is dropped, which could be many seconds if the 
limit/tick is low.

As far as trees/linked lists - I was thinking more on how things are organized 
on the map, not queuing things up to dropped.  If map spaces were trees instead 
of lists, it is possible that the finding matching object to merge would be 
fast enough that dropping lots of objects would not be an issue.

In fact, I don't actually think that the time go through the inventory to find 
matching items to drop/pickup is the issue - I think the actual issue is the 
time to insert them into their destination.  So in case of a pickup/dropall 
that happens over several ticks, just having the exact same logic now (looking 
at source for object that matches criteria) is probably fine, and there isn't 
any need to build a temporary list of objects that match the criteria.

Building a temporary list has potential problems - mostly make sure it stays in 
sync, making sure it is properly cleared/initialized each time (if there is 
some bug where it isn't cleared, such that the player does a dropall, does 
something else that changes inventory, and does the dropall again, if the 
server thinks this is a continuation of the existing dropall because something 
wasn't cleared, good chance you are going to get some odd behavior)


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Handling massive loot

2021-03-24 Thread Robert Brockway

On Wed, 24 Mar 2021, Nathaniel Kipps wrote:


This is definitely a very blunt fix, and thus has blunt consequences.
For example, let's say a player *did* need to pick up 1000 items. If
they're limited to 10 items per tick, and the operation returns after
those ten items, they'll have to issue "get all" 100 times before all
the items are retrieved. I think it's definitely better to only
inflict a time penalty, not a time penalty + UI penalty.


This is probably a good time to remind everyone that CF supports scripting 
client and server side.  I feel like this isn't mentioned enough.  I've 
written scripts that could be adapted to deal with that.


Eg, here is a simple shell script to pray a number of times:

$less praylots
#!/bin/bash

case $1 in
"")
echo "Please specify a number of times to pray"
exit 10
;;
*)
NUM=$1
;;
esac

for I in $(seq $NUM)
do
echo "issue 1 1 use_skill pray"
done

I'm not really commenting on Mark's proposal but faced with this situation 
I would script it.


Rob
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Handling massive loot

2021-03-24 Thread Nathaniel Kipps
MWedel, thanks for the feedback. :)

> The game could then display something like 'you have picked up/dropped all 
> you can right now', and player then has to repeat that action on the next 
> tick.

This is definitely a very blunt fix, and thus has blunt consequences.
For example, let's say a player *did* need to pick up 1000 items. If
they're limited to 10 items per tick, and the operation returns after
those ten items, they'll have to issue "get all" 100 times before all
the items are retrieved. I think it's definitely better to only
inflict a time penalty, not a time penalty + UI penalty.

> Linked lists are also not particularly efficient when dealing with having to 
> search them

I understand that trees are much better for random sorts, insertions,
and lookups, but I'll point out that I proposed a linked list simply
because it will only ever have items appended to the end, or processed
in a linear fashion. Although, maybe there's a penalty to deleting
items from the front of the list or something.

--Nathan
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire