Please fix when someone leaves Party Finder.

When someone leaves the party in party finder, it sets the recruitment to allow only the same job to join the party to fill the slot of the person that left. Most people don't pay attention so you have all these party finders with slots open that only accept a single specific job instead of any job of that role.

This was annoying but not really an issue before cross world Party finder because you could just send the party leader a /tell to inform them that they need to adjust their party finder recruitment settings. Since you can't send /tells across worlds, these parties sit unfilled for a long time because the leader doesn't pay attention.

Even if you're someone that is aware of this issue and does pay attention when someone leaves, it's a hassle to have to change the recruitment settings every time someone leaves the party.

Please fix it so when a person leaves a party finder group, it automatically sets the recruitment for any job of the same role as the person who left instead of only the same job as the person that left.

Thank you.

I'm gonna necro this because I cannot BELIEVE this was not fixed yet

Seconded.
I've lost count of how many times this has tripped me up.

Well you can at least send tells across worlds now.
But this issue has always been the case of pre-existing party members that leave after the PF is formed. This is important in cases where you want a specific setup for some crazy reason.
Anyone who joins a PF but leaves before the PF is taken down and re-created, the spot remains it's original open style spot. While people who existed before hand their spot remains it's original job-specific spot.

Quote:

---

Originally Posted by Canadane

Well you can at least send tells across worlds now.
But this issue has always been the case of pre-existing party members that leave after the PF is formed. This is important in cases where you want a specific setup for some crazy reason.
Anyone who joins a PF but leaves before the PF is taken down and re-created, the spot remains it's original open style spot. While people who existed before hand their spot remains it's original job-specific spot.

---

The thing is, they shouldn't CHANGE the slot to a specific one if YOU YOURSELF didn't set it this way, upon the slot's occupant leaving the party. Actually, to make this the default behavior is 100% senseless, it's so much rarer to actually need that the spot be filled by the exact class that left. Even if that was the original intention, it's such a niche small percentage of cases that it's absurd to make it the default.

Quote:

---

Originally Posted by AlexionSkyllark

The thing is, they shouldn't CHANGE the slot to a specific one if YOU YOURSELF didn't set it this way, upon the slot's occupant leaving the party.

---

But, the thing is, you did set the slot to be one specific job only. It's not your fault; you had no say in the matter. When putting together the party finder, you were forced to accept that the already filled slots would be locked to the jobs that they started with.

https://i.imgur.com/oY0xFo1.png

There is, absolutely, 100%, a problem with the party finder, but the problem is not at the moment someone leaves the party, and the recruitment criteria should definitely not adjust itself when someone leaves, because some slots sometimes need to be filled by the specific job that left.

The problem is at the beginning, when the recruitment listing is created. The way the Recruitment Criteria interface should work is it should treat the filled slots like the unfilled slots, starting them as All / THDD / TTHHDDDD and allowing you to carve out unwanted classes, jobs, or roles from that starting point. Disallow carving out jobs to the point where the recruitment slots can no longer be mapped to the current party members, either by forcing the job that is already in each filled slot to be part of the allowed list for that slot, or by disabling the Recruit Members button if you carve out too many jobs to the point that recruitment slots can no longer be mapped to party members.


tl;dr: Yes, fix this; the problem is not when people leave though.

Quote:

---

Originally Posted by Rongway

Bbut the problem is not at the moment someone leaves the party, and the recruitment criteria should definitely not adjust itself when someone leaves, because some slots sometimes need to be filled by the specific job that left.

---

I challenge you to find anyone here who agrees with that quote.
When someone leaves the party, the slot should rever to back to WHATEVER YOU SET THAT SLOT TO BE WHEN CREATING THE PARTY FINDER ENTRY. If you CREATED that slot as being for a specific job, THEN it should stay that way when that slot becomes vacant. But if the slot was created as a "All DPS" or "Any", or whatever, it should REVERT BACK TO THAT.

Quote:

---

Originally Posted by AlexionSkyllark

I challenge you to find anyone here who agrees with that quote.
When someone leaves the party, the slot should rever to back to WHATEVER YOU SET THAT SLOT TO BE WHEN CREATING THE PARTY FINDER ENTRY. If you CREATED that slot as being for a specific job, THEN it should stay that way when that slot becomes vacant. But if the slot was created as a "All DPS" or "Any", or whatever, it should REVERT BACK TO THAT.

---

That's what I said.

If someone leaves and it locks the slot to that person's job, it's because you took the partyfinder listing down after they joined and put up a new party finder listing with them already in that slot. It locks to their job because that was the job that was in the party when the party finder listing went up. If you don't take the listing down after people join, you won't have this problem. If you take the listing down after someone joins so that you can update it, you will need to take it down and update it again if someone leaves.

My point is the problem is not happening when a person leaves. It's at the part where you're setting up your partyfinder listing because the current, incorrect, behavior is that when you're putting together a partyfinder listing all the filled slots get locked to the current members' jobs. The correct behavior would be to allow you to select jobs for each slot even when they are already filled. It is not a problem with the party finder locking a slot's job when someone leaves because you already yourself locked the slot when you posted your partyfinder listing. The behavior when someone leaves is correct: if a slot was set to one specific job when you posted the listing, it should stay set to that one specific job whenever that slot becomes vacant.

Unless it was changed (and it very well could've been, it's been a long while for me), the behavior was not as you described. If someone joined a PF as a SAM and decided to bail before the PF filled, then the vacated slot would be set to SAM only.

At least, that's how I recall seeing it work years ago, and having to remind folks to fix the listing if someone bailed so we weren't stuck waiting for one specific job.

Quote:

---

Originally Posted by Hasrat

Unless it was changed (and it very well could've been, it's been a long while for me), the behavior was not as you described. If someone joined a PF as a SAM and decided to bail before the PF filled, then the vacated slot would be set to SAM only.

At least, that's how I recall seeing it work years ago, and having to remind folks to fix the listing if someone bailed so we weren't stuck waiting for one specific job.

---

No, the behavior has always been that neither joining a party nor leaving a party affect what jobs are allowed for each slot.

The problem arises when people take down their party listings after people have joined so that they can update the remaining slots to be more or less restrictive. At that time, when they put the updated party listing up, all filled slots lock to the current party members' jobs as if it was a brand new party listing with the new number of people already in party, because that's what it is every time you take down and put your party listing back up, as far as the system is concerned. To fix the problem, we need to be allowed to set a range of jobs for each slot even when there's already someone in that slot, before putting up a party listing. That way, if someone leaves the party, the slot they left would show a range of acceptable replacement jobs.

Quote:

---

Originally Posted by Rongway

The problem arises when people take down their party listings after people have joined so that they can update the remaining slots to be more or less restrictive.

---

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).

Quote:

---

Originally Posted by AlexionSkyllark

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).

---

Did you even read anything I said.

Of course the current behavior is wrong. I said as much.

The thing is you're misidentifying where the behavior is wrong. I don't know how many other ways I can word this.

The problem is not when people leave. Slots that were set to specific jobs when the partyfinder went up should stay set to those specific slots because those are the slots the PF leader specified when they put the listing up.

The problem is when the PF leader is setting up a listing, slots that are already filled are automatically set to one-job-only and the PF leader isn't allowed to set a range of jobs for those slots. The fix would be to allow PF leaders to set ranges of jobs for slots even when they are already filled.

If you put up a PF listing once and don't touch it, people can join and leave as they please without affecting each slot's job range unless they were already in the party at the time you put up your PF listing. Therefore, the problem is not with people joining and leaving; it is with the party setup functions before you put your listing up. That is what needs to be fixed. Not the part where people join and leave.

Quote:

---

Originally Posted by Rongway

Did you even read anything I said.

Of course the current behavior is wrong. I said as much.

The thing is you're misidentifying where the behavior is wrong.

---

When the hell did I say that?
You accuse me of not reading your posts, but you're clearly not reading mine as well

Quote:

---

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

---

Do you disagree with that statement?

EDIT: OK, I'll make this more clear:
WHENEVER A PARTY FINDER IS CREATED, ANY PREVIOUSLY OCCUPIED SLOTS ARE LOCKED TO THE CLASS OF THE PERSON WHO WAS OCCUPYING THE SLOT.
THIS BEHAVIOR IS WRONG AND NEEDS TO BE CHANGED TO LOCK TO THE ROLE OF THE PERSON PREVIOUSLY OCCUPYING THAT SLOT. If that slot was occupied by a Paladin, it should revert to a TANK slot upon that person leaving, as an example. THIS is how the PF should work.

How is this not fixed? It's been what, eight years this has been occuring? I know for a fact this bug/awful behavior has been around since ARR. Each year it becomes that much more frustrating with some of the low patience swirling around.

Quote:

---

Originally Posted by AlexionSkyllark

EDIT: OK, I'll make this more clear:
WHENEVER A PARTY FINDER IS CREATED, ANY PREVIOUSLY OCCUPIED SLOTS ARE LOCKED TO THE CLASS OF THE PERSON WHO WAS OCCUPYING THE SLOT.
THIS BEHAVIOR IS WRONG AND NEEDS TO BE CHANGED TO LOCK TO THE ROLE OF THE PERSON PREVIOUSLY OCCUPYING THAT SLOT. If that slot was occupied by a Paladin, it should revert to a TANK slot upon that person leaving, as an example. THIS is how the PF should work.

---

That is still wrong.

When a slot is freed, it should absolutely not expand to anything it was not originally set as. If I tell the PF I want a slot to be specifically an AST slot, under no circumstances should it allow anything but an AST in that slot. The moment someone leaves is not the problem.

When you set up the party finder, it should allow you to say "this slot that is occupied by my paladin friend should be a tank slot". It is the moment of setup that is a problem. The game does not let us tell it that the slot occupied by the paladin should be more than just a paladin slot. That is the problem that affects setup and re-setup. The problem has nothing to do with people leaving.

Quote:

---

Originally Posted by Rongway

If I tell the PF I want a slot to be specifically an AST slot, under no circumstances should it allow anything but an AST in that slot

---

The thing is, I DIDN'T tell anything to the PF. Having an AST previously occupying the slot when the PF is formed is NOT equivalent to "telling the PF this is an AST slot". Our problem here is on what you consider should be the DEFAULT BEHAVIOR. For the vast majority of cases, people do not want a specific class in a slot, and therefore falling back to the role SHOULD BE THE DEFAULT BEHAVIOR.

It is the people who want a specific class in the slot (the absolute minority) who should need to manually set the slot everytime the slots of the PF free up. Not the opposite.
And no, we should not be forced to set the slot to a role slot manually for every slot every time we setup a PF with people already in the party. Having an automatic role fallback makes 99% of people happy, so that's what should be the default behavior.

I tried to articulate this with my last post but Rongway is correct that it seems that you're misinterpreting the issue.
Nobody is saying there isn't a problem, but a fundamental understanding of how the system works is the first step into fixing the issues at hand.

Quote:

---

Originally Posted by Canadane

I tried to articulate this with my last post but Rongway is correct that it seems that you're misinterpreting the issue.
Nobody is saying there isn't a problem, but a fundamental understanding of how the system works is the first step into fixing the issues at hand.

---

I understand how the system currently works. And that is the issue, the system is flawed in a fundamental level. It needs to change its core behavior to the one I describe if it is to fix the issue that the vast majority of players are having, without placing an extra burden on them.

Quote:

---

Originally Posted by AlexionSkyllark

When the hell did I say that?
You accuse me of not reading your posts, but you're clearly not reading mine as well

---

Alexion, with all due respect, please carefully reread what Rongway wrote in their precious replies before yelling at them; I understand your frustration with the current system, but the exact cause and specific code to address is more accurately based on what they wrote.

I will just skip the current drama in the thread and I play this game since heavensward, even before party finder was a thing and currently this party finder error occurs anytime you join with a pre-formed party, regardless you filled the jobs or not, regardless if the person who leaves was on the pre-formed party or not. and please note, that if you put up a pf for a specific duty it will automatically set the roles for whatever duty you are gonna do. I have been experimenting this for a long while.

Quote:

---

Originally Posted by MellowMink

Alexion, with all due respect, please carefully reread what Rongway wrote in their precious replies before yelling at them; I understand your frustration with the current system, but the exact cause and specific code to address is more accurately based on what they wrote.

---

Rongway asks for a solution that adds extra steps for everybody just to benefit the extremely small minory of people who may, by any chance, explicitly want a specific job for that slot. This shouldn't be how this is fixed.
Role shouled be default. Period.

And I DID acknowledge that the issue happens when the PF is formed, and not when someone leaves. And that's why I said he's not reading my posts.
What I vehemently disagree, however, is with his PROPOSED SOLUTION. We should not have to manually set each of the 8 slots in our PFs every time we set one just to have it fallback to a role when people leave. This should be the default.

You can’t fix a problem without first knowing the exact specifics of what the problem is, and the solution has to be based around that problem rather than something that’s technically unrelated, hence Rongway’s helpful replies.

Quote:

---

Originally Posted by MellowMink

You can’t fix a problem without first knowing the exact specifics of what the problem is, and the solution has to be based around that problem rather than something that’s technically unrelated, hence Rongway’s helpful replies.

---

Not gonna lie, I found Rongway's reply not helpful at all and I agree with Alexion. I think both of you did not fully read/understand his post

Quote:

---

Originally Posted by Drip

Not gonna lie, I found Rongway's reply not helpful at all and I agree with Alexion. I think both of you did not fully read/understand his post

---

My very first post in this thread, which hasn't been edited since September clearly explains the problem and how it should be fixed. Other people's replies as recently as March clearly show that they did not read that first post, because their replies keep suggesting that PF should work the way I explained in that first post, while alleging that I do not support PF working the way I explained it should in that first post.

Quote:

---

Originally Posted by Rongway

The problem is at the beginning, when the recruitment listing is created. The way the Recruitment Criteria interface should work is it should treat the filled slots like the unfilled slots, starting them as All / THDD / TTHHDDDD and allowing you to carve out unwanted classes, jobs, or roles from that starting point.

---

The major point is that the whole reason we're having this argument is that there's a problem with the way the PF setup window works, and not the way PF handles people leaving.

I'm bumping this, tired of this **** as somebody who lives in Party Finder.

They should fix this so the party leader CAN MANUALLY FRKN SET THE ROLE WHEN SOMEONE IS AFK. THis system sucks ass

Quote:

---

Originally Posted by Rongway

If you put up a PF listing once and don't touch it, people can join and leave as they please without affecting each slot's job range unless they were already in the party at the time you put up your PF listing. Therefore, the problem is not with people joining and leaving; it is with the party setup functions before you put your listing up. That is what needs to be fixed. Not the part where people join and leave.

---

I don't think this is true.

I'm in a PF right now that had no slots specified when it was opened. A DNC joined the party, and then left a few minutes later. Their spot is currently locked to DNC.

I'll give a guess as to how the current system works on the technical side (I don't actually know, but it's fun to guess)

Let's suppose the most space-efficient way they could implement PF: that each PF slot is a bitset: one bit for each job/class, and then 1 bit for "filled". For unfilled slots, filled=0, and the bitset is set to allowed roles. For filled slots, filled=1, and a single bit for what job fills that slot is set, so PF viewers can see what the party composition looks like.

To solve the issue mentioned by OP (which I think is probably worth doing), they would need to introduce an additional value per-slot that says what the currently filled job is (ony looked at if filled=1). This would add probably 8 extra bytes to each pf listing response, 24 for alliance raids, which isnt all so bad I think.

Sorta armchair coding here, but I think it would amount to an extremely small change of the code to get this working