No, the problem arises when someone leaves a party AFTER IT HAS BEEN FILLED UP. Because when putting said party BACK in party finder, instead of REMEMBERING WHICH SETUP THE FINDER WAS WHEN THE PARTY WAS CREATED IN THE FIRST PLACE, it ASSUMES A PARTY CREATED WITH ALL SLOTS LOCKED TO THE CURRENT JOBS
this is WRONG behavior
The system should NOT behave like that
The system should remember how the party was FIRST created, and retain THAT composition. It's not a NEW party, it's still the SAME party that was created before. Only it was filled up, wiped a couple of times and then some prick quitted, so you need to find a replacement. It should NOT lock the party to the current jobs in this situation, it should REMEMBER THE ORIGINAL SETUP FROM WHEN IT WAS FIRST CREATED
What you are doing here is describing how the system works and WHY the problem happens. And you are correct, the behavior you describe is precisely the reason why the problem happens.
And the behavior you describe is what is WRONG, and it's what SHOULD BE CHANGED.
The IDEA and the DESIGN behind how the party finder works and the hows and whys of it locking jobs to slots - this should be CHANGED. The solution should NOT need extra input from us, the users. At our side, it should work EXACTLY AS IT IS NOW, but WITHOUT the behavior you described, and ALWAYS remembering the ORIGINAL composition of the party, regardless if it was taken down and put back, or if it was filled and then reposted after someone left. IT SHOULD ALWAYS AND FOREVER REMEMBER THE ORIGINAL FORMATION UNTIL THE PARTY DISBANDS COMPLETELY OR THE LEADER MANUALLY CHANGES A SLOT (and that change should also stay in the slots FOREVER UNTIL THE PARTY DISBANDS).


Reply With Quote







