[crossfire] requestable party lists

[Brendan Lally]

On 4/24/06, Mark Wedel <mwedel at sonic.net> wrote:
>
>   Overall, the idea looks fine, but I haven't looked at the actual patch.
>
>   But a few other thoughts:
>
> 1) It could be nice to include the highest number party number in the stats
> command (only transmit when changed).  Since I recall that whenever a new party
> is created, the client can use this to know when in fact there are new parties.

party number doesn't exist anymore, it hasn't for a while, there was
an issue that it was possible to cause that value to wrap, and in so
doing duplicating parties, this was why I wrote a patch last summer to
treat parties by the pointer to the party struct rather than the
partyid

> 2) It could likewise be nice for the requestinfo party_list to take a parameter,
> which denotes to only send party info above that number.

You could give a name, and say only send parties beyond that one in
the linked list, but then what do you do when the party you send the
name of doesn't exist? (possibly changing the replyinfo to reflect
that fact?)

>   In this way, the client could keep track of what is last requested up to, and
> then can just request the new parties.

yes, this might even work if done by name, however it provides no nice
way to ensure that the player count even vaguely resembles reality,
nor any way to cope with parties that are obsoleted.

>   Normally, this isn't an issue, but I believe there have been cases where
> people have tried to abuse the server by creating hundreds of parties.  If with
> a relatively modest number of parties, you probably want to be able to only send
> the new ones.

Yes, I was the one who first mentioned that almost a year ago (the
thread 'large numbers of parties causes weirdness' from last April)
This is why parties with no members are now periodically removed.

If the creation of vast numbers of parties is a great concern, it may
well be possible to limit each player to a certain number of parties
(3 say) and, each time a party form command is received, count up the
number of parties they currently have.

>   Periodically I suppose the client could go through and request all the parties
> to figure out which are now defunct.  OR perhaps more to have something like a
> request active party type of thing, which really only needs to send the party
> numbers of the active parties.

I don't see how that can usefully allow player counts to be updated.

One more point, which is tangential to all of the others, should
parties also allow comments? I am thinking of ~50 characters to
describe any given party, to be sent as an extra field in the
replyinfo.