Some time ago I read the last released summit meeting minute
and one of the topics discussed was the difficulty logistics pilots have with the watchlist being limited to only 10 people.
The minute also contained a statement from CCP that, while acknoledging that some pilots have valid reasons to need a larger watchlist, they could not simply raise the limit, as this functionality would start taking more CPU power than it should.
This subject is also one of the items of the current CSM crowdsourcing and one of the replies
in one of the original threads suggests that perhaps raising the limit of some players in the fleet would already acomplish alot.
This proposal is to go exactly on that direction, letting the players decide who in their fleet need more ppl in their watchlist and who could do well with a shorter list to compensate.
It goes like this:
- FC chooses B (base value) between zero and ten
- FC selects L (a group of pilots, such as logistics) to receive the benefit
- For all pilots not in L, the watchlist becomes limited by B
- For all pilots in L, the watchlist limit is increased by ((10 - B) * (size of the fleet - size of L))/(size of L). The value is truncated and the reminder is distributed in round robin.
- If there are no pilots in L, then all pilots have the standard limit of ten.
A few notes:
- The scope of this OP is only the maximum size of the watchlist. It's not meant to discuss if it has all the necessary info logistics pilots need to do their job, nor if it woult scale well with a much larger number of people in it.
- Letting B be variable may be overengeneering. Fixing it at some reasonable value may be enough.
- I won't discuss how the UI will acomplish this OP, but it needs to be easy for the FC to select/deselect the pilots that need a larger watchlist and it must be visible for all pilots their current watchlist limit.
- On a side note, if this is really taking that much server CPU then perhaps the algorithm implemented is sub-optimal, because by fixing the size of the list it should have a linear behavior. Or perhaps this is already the case, but the code is still doing unecessary operations like creating the same message multiple times instead of using a memcopy (if one pilot is being watched by many others, the message could be created at most once per tick). Maybe there is one or two "low hanging fruits" here for team Gridlock explore.