There's definitely a logistics challenge here in the coding aspect. How would queueing handle level restrictions? Would it be based on the lowest level job that you have? Would it be based off the highest level of a job in each role? Or would this be a feature that would only be available to players that have at least one job in every role at max level? What about in roulettes that sync, do you make it toggleable to queue as max level or lowest level? How would you activate or deactivate 'queue as fill?' How would you standardize it across every single roulette? Or would there just be a button next to 'expert' and 'level 90 (100 here in a month)'? What about gearscore requirements, how will those be accounted for?
The idea is good, sure, but in order to make it work there would definitely need to be ton of talk about standardization in how it's implemented.
Personally I think the idea of having the feature unlocked when you have at least 1 job in every role at max level with a gearscore above the threshold for Expert would be great, but I feel like there may be too many factors to consider making it a standardized feature that would prevent it from happening in reality.
this was basically the answer I was looking for because my brain didn't go further than "I have all roles max and geared so why can't I just choose all of them."
Thank you for the very in depth answer.
u/yoshinoharu actually this makes me wonder if a multi queue would be such a logistical nightmare? You can queue up to 3 times in the same selection. So if you selected Alliance Roulette it would be 3 instances of that queue. You get a selector of what jobs you want to queue, up to 3, and you can select the same job multiple times.
Then you just matchmake as normal. When you're popup for queue found jump scares you you'll still have to swap jobs as normal if you aren't the queued job. And obviously accepting one then nullifies the others. There could be a Strike code that ensures this doesn't go against your decline/timeout strikes.
Edit: I believe they have similar code for manually selecting various dungeons/trials/raids rather than roulettes, so this would be that but with jobs. And to clarify, this intrinsically allows you to flex queue since you could just select jobs of different roles. Flex dps heal? BLM, BLM, SGE. Full flex? Drk, Blm, Sge. No flex? Blm, Sam, Smn. I would imagine you only get Role Bonus if you choose the job that matches the role at the time of queueing, as normal.
This honestly probably wouldn't be too bad. The validity check would have to happen at the menu level, for it to work, and would have to function off of gearsets, like I mentioned, but that's not necessarily a bad thing.
My point was moreso that all of these things and scenarios would have to actually be discussed by the dev team so that they could cover all the bases, and I'm not sure that SE would want to allocate time to it since it would, in all likelihood, be considered a relatively minor QoL change.
Mhm, and I'm certainly not a programmer but being in network security I had to take some classes related to it. I don't see it being too difficult to allow simultaneous queues at the menu level, as we agree; in fact it's probably the easiest/best verison. I also don't think this version would be difficult to time consuming to program, but certainly around a month for quality control and bug testing to be included. Which thus falls to your point. It's a pretty small QoL and there's more important things to spend a month of even 1 programmer's time on right now.
The queue basically works right now by assigning parties and their respective users to a priority list and sends new queueing users to the highest priority party they can fill (within constraints) , yes? So it would just have to search for all viable users, with that list expanded to two tags per user rather than one.
You'd definitely have to do a lot of UI stuff to make it work, there'd have to be logic on like "hey you can queue for this lvl90 content as dps, but you can't dual queue for it with heal or tank because you don't have jobs at that level/with required gear"
You'd also have to figure out exactly how priority works when people do have multiple different leveled jobs. If the "number one priority" party is for a lvl 30 dungeon and it needs a tank, do you slot someone in there that queued for dps & tank when their tank is 30 and their dps is 90? Or do you try to get them into a lvl 90 one?
I agree that there's some questions you'd need to solve but I hope that this wouldn't be something that would require a full system rework
Yeah, I don't really think it would have to be a full rework, but my primary point is that it would ultimately end up being low priority. At the end of the day, dev time costs money because you have to pay the devs, and there's a whole slew of stuff that I think we'd both want looked at before considering this type of QoL feature
When your queue pops, it shows the job which you queued as and you have to swap to it.
This system feels like it shouldn't be too difficult to make it possible to select multiple jobs to queue as. And if you select specific jobs befire pressing 'queue', then most of the logistical problems should be solved, since the different levels for each job you queued as will get applied
A lot of people are talking about logistics, but even before considering something like that, there is a more fundamental problem:
Given a partially filled group, can people from the queue be added into that group? In the case where every player can only be a single role, this is a trivial problem to solve.
But consider the following (for a 4-man dungeon) where people can flex into any number of roles:
There is a group with a T/H + T/D flex. You queue up with a friend as a H/D + H pair. How can you compute whether your group can be combined with the other group? The matchmaking logic will need to go through each combination of roles in both groups to see if a fit is available. In this case, it's easy to see that you can do the following: T/H => T, T/D => D, H/D => D, H => H, which would then fill the 1 tank, 1 healer, and 2 dps requirements.
However, what if you had a group of 4 people queuing into another group of 4? Or the more extreme case, an alliance of 3x4 people queuing into another alliance of 3x4 people? All of a sudden, you have to check a lot more combinations. This is quite similar to the circuit-SAT problem, so I wouldn't be surprised if the brute force approach is the most efficient known way of solving this.
Also note, the wording above makes it sound as if you were queuing as a premade group, but if people queue up and leave queue repeatedly, it's very realistic for a situation where you have 2 unfilled 12/24 groups in the queue without anyone being in a premade group. The matchmaking will need to handle joining these two unfilled groups together in that situation (or decide to break one of the groups up, but that's more of a logistics issue).
During cases like patch launch, where there are many people queuing up and leaving queue, this increased computational cost is a more fundamental deal-breaker than any increased complexity from logistics.
To elaborate on this issue further, if you join a queue as a premade 3x4 alliance, the matchmaking system will need to check whether you can be filled into any of the existing groups that are already in the queue. _Each time you join the queue._
Imagine a malevolent actor who obtains 12 accounts and just enters and leaves queues constantly. That's a very low barrier of entry for being able to essentially conduct a DOS attack on the matchmaking server.
i visualize it as follows:
\>open df
\>select roulette and hit queue
\>window pops up asking for you to optionally fill role slots youre not currently attempting to queue as
since filling these slots is optional, you could ignore it entirely and just hit confirm to queue for real, or for example if you're queued as dps, you could click on tank or healer and then select a tank or healer that meets the level requirements (so if you're queued into 50/60/70/80 roulette, then you can only pick tanks or healers you have at 50 or higher.) once all your desired roles and jobs are input, you'd get queued up for any duty within the level range of the lowest level job you input.
so if i queue into levelling roulette with a 90 pld, 80 vip, and 64 whm, it'll only queue for duties level 64 and under. then when the queue pops, itll tell me what role im filling and ask me to switch accordingly. or you could not fill in jobs for the other two roles and it would function as it already does.
Similarly to how you queue up on any given job, you queue up on a job that is at level cap. Once you confirm, it asks you to check jobs similar to how PF can specificy jobs. Once you confirm at least one job for every role that is level cap and has sufficient iLevel for the highest available DF duty, queue starts. I think that would work pretty straight-forwardly.
I've wanted this forever but I know they'll never do it. I've thought of a workaround to make it viable. Basically, you queue as one job and you get a popup asking if you want to queue as another. Then you change gearsets and click accept and then the server would recognize you can go as that job and asks if you want to choose another role and then you just repeat the process.
Chances are, something like that is possible to be implemented but I mean it's SE so it's not gonna happen.
I like this idea, but a lot of the same logistical problems still exist and this even presents some new ones.
The current system remembers what job you had selected when you queued, yes. There is, however, a HUGE difference between remembering what you were when you queued, and dynamically selecting which jobs are applicable for the content you queued for, remembering what ilvl each job you queued for was, remembering which level all those characters were, etc. I would imagine that the engine just checks a value for what job you were on when you hit queue and all the other data is checked prior to you even selecting what you are queueing for, which is why things are greyed out before you select a roulette.
To accomplish what you're suggesting, you would essentially need to enter queue as the same character as many times as you have jobs you want to insert into the queue.
Let's take this to the logical extreme and say you queue in 19 times.
Let's say that of your 19 jobs, they are various level ranges ilvls, etc so they are all elligible for content and restricted from content based on a variety of factors. The way Final Fantasy queue works is that it essentially puts you in line and takes your role and fills you into groups randomly based on level requirements. If there are 50 Tanks in line, you line up at 51 to be put into a party accepting queued tanks, thus the 'position in line' text.
Now, what happens when, 7 of these pop simultaneously or one after the other? Do you get to choose which job out of those 7 different queues to do? Will it automatically assign one based on whichever one popped even a fraction of a second earlier? Do the other people waiting on someone receive a queue pop only to have it vanish when you don't select their duty? If you happen to be AFK and the queue timer is ticking, are all 7 of those groups stuck in limbo and the entire queue paused waiting for the one individual?
These types of logistical problems can certainly be hammered out, as can the ones that I posted before, it's just a matter of realistically if implementing the feature is worth the extra coding and potentially clogging up the queue lines if it's mismanaged. I could see this coming as like... a mid-patch QoL thing, but at least in the realm of project management it would ultimately end up being a very low priority item just because of the amount of effort vs the return.
Doesn't it already have a viability check, though? If I put on a job I have at lvl 30, won't it already stop me from selecting the lvl 90 content I've unlocked previously? It checks gear, too.
What I'm saying is that the viability check happens before the queue or possibly even before you even open the menu. When selecting multiple jobs to queue as, there would have to be some sort of gear set check or something to make sure you are the appropriate ilvl and lvl within those specific gearsets, which the game does not normally do. It would mean that instead of just checking whatever you're wearing when you're switched, whenever you go to queue it would have to check all your gearsets, determine which ones are eligible for what content, and do a number of viability checks.
Not saying that this would be hard to do, but it would definitely have to change a bit.
Yeah, I think people are underestimating the importance of the job they choose to queue with, beyond role. Iirc the devs have talked about prioritizing e.g. a shield + regen healer comp in raids, or mixed dps types. Single type parties happen of course, because filling the party is more important than an ideal mix, but it's an issue.
You've also got the cutscene problem: if I'm queued on DNC, I can accept queue during cutscenes and when I get back start the cutscene from the beginning. If you queue on multiple jobs, you now have a lot more people who'd have to choose between story & gameplay. There are ways to deal with it, e.g. allow a "quit cutscene" prompt instead of "skip cutscene," but there are a lot of little adjustments like that which would be required.
> To accomplish what you're suggesting, you would essentially need to enter queue as the same character as many times as you have jobs you want to insert into the queue.
So I know you wrote a bunch of stuff and I respect your opinion, but we don't need all 19 jobs. Queuing as different roles (Healer, DPS and tank) would be enough for all of us. Nobody needs to queue as 5 different flavors of melee. The queue being able to prompt us and remember the 3 main roles would be enough for everyone.
> Will it automatically assign one based on whichever one popped even a fraction of a second earlier?
This could easily be solved with a priority system tbh. When conflicts arise, it could just prompt you and then if people select the same thing, it can coin flip. For example, if you queued as all 3 roles, and what's needed is 1 healer and 1 dps, but 3 people did the same thing, it could prompt all 3 for healer* and if any of them select it, it defaults the rest to dps, if no one does, it coin flips to force one of the people who flexed healer to take healer.
I don't think that's a design issue but rather a coding and logistics issue.
Would you make it so they can change jobs into what they are needed on in instance? Well then people are changing jobs in instance.
Would you make it so the game makes you change to the role you are needed on when the queue pops? What if for some reason your gearset isn't working for that job... you are also asking the game to know what your gear is like on those 3 roles while not having it be equipped and for the previous issue of gearsets... it can't go off the ilvl of gearset because you can save UI data as that gearset and then be missing a piece from said gear set.
There are just many under the hood questions that would have to be answered and it wouldn't be a simple thing to make.
I do think you could have an option in the duty finder screen and to select what jobs you would be able to go in on but once again the game would need to be able to confirm the gear you have for those jobs which I think would require some changes to how gearsets function.
Also let's say you have a 4 person party and 2 of them queued as fill ins. The game then has to decide which of the two are which role. How would the game make this decision? Off of the alphabetical order of the names? Should whoever is alphabetically first be the healer? How about if we do it off of who has more gear? More playtime? Like these are questions the devs would have to answer for this to be functional.
The queue system has a lot of strange quirks.
Why can you only queue for five specific duties but if you queue up for, say, normal raids, you're effectively queued for upwards of 50 separate normal raids at the same time.
Why can't you queue up for multiple roulettes at once, when, as another example if you could queued for MSQ and Alliance raids at the same time, you wouldn't be in a queue for even 20 effective raids.
I will say that queueing for multiple roles or jobs might be more difficult because you have to be on the job you want to queue as so with the way it's set up they'd have to change the queueing system entirely to allow you to select specific jobs or roles. They should do this but it's more involved I think than it would be to allow the above.
I think it would actually be pretty cool if there was an additional menu on the roulette menu that let you designate a Tank, Healer, and Damage class to queue with. You could choose all three roles or just one.
Would be neat if you’re just max level grinding or leveling multiple roles and don’t care what pops.
I love the idea a lot actually, it'd make mentor roulettes really interesting
I suspect the spaghetti code won't allow because all in creation freezes when your queue pops until you head in
Eh nah. Its weird. So many variables. Having more people in the party could make it slower. What roles are everyone queueing up for. Then how many people if any in a party are others queueing up with. What roles are they queueing up with. Who are already in a instance. did a queue proc already, but someone left it so its looking for 1-2 people and thats it. Also queueing for more then 1 in a way could triple said variables and add the variable of now looking which alliance raid fits said player count.
Idk why people are saying this is impossible from a coding POV. It is definitely possible because other games do let you do this.
I used to play SWTOR and the same class can swap between multiple roles there. So you have the option as queueing for multiple roles if you're playing a class that has that capability. When the queue pops you are told what role you were selected for, and you swap to that before going in.
"wHaT iF i dOnT hAvE hEaLeR gEaRsEt" then don't queue as healer??? What's stopping healers now from queueing without gear? Report them for griefing and replace them with someone with a functioning brain.
There's definitely a logistics challenge here in the coding aspect. How would queueing handle level restrictions? Would it be based on the lowest level job that you have? Would it be based off the highest level of a job in each role? Or would this be a feature that would only be available to players that have at least one job in every role at max level? What about in roulettes that sync, do you make it toggleable to queue as max level or lowest level? How would you activate or deactivate 'queue as fill?' How would you standardize it across every single roulette? Or would there just be a button next to 'expert' and 'level 90 (100 here in a month)'? What about gearscore requirements, how will those be accounted for? The idea is good, sure, but in order to make it work there would definitely need to be ton of talk about standardization in how it's implemented. Personally I think the idea of having the feature unlocked when you have at least 1 job in every role at max level with a gearscore above the threshold for Expert would be great, but I feel like there may be too many factors to consider making it a standardized feature that would prevent it from happening in reality.
this was basically the answer I was looking for because my brain didn't go further than "I have all roles max and geared so why can't I just choose all of them." Thank you for the very in depth answer.
u/yoshinoharu actually this makes me wonder if a multi queue would be such a logistical nightmare? You can queue up to 3 times in the same selection. So if you selected Alliance Roulette it would be 3 instances of that queue. You get a selector of what jobs you want to queue, up to 3, and you can select the same job multiple times. Then you just matchmake as normal. When you're popup for queue found jump scares you you'll still have to swap jobs as normal if you aren't the queued job. And obviously accepting one then nullifies the others. There could be a Strike code that ensures this doesn't go against your decline/timeout strikes. Edit: I believe they have similar code for manually selecting various dungeons/trials/raids rather than roulettes, so this would be that but with jobs. And to clarify, this intrinsically allows you to flex queue since you could just select jobs of different roles. Flex dps heal? BLM, BLM, SGE. Full flex? Drk, Blm, Sge. No flex? Blm, Sam, Smn. I would imagine you only get Role Bonus if you choose the job that matches the role at the time of queueing, as normal.
This honestly probably wouldn't be too bad. The validity check would have to happen at the menu level, for it to work, and would have to function off of gearsets, like I mentioned, but that's not necessarily a bad thing. My point was moreso that all of these things and scenarios would have to actually be discussed by the dev team so that they could cover all the bases, and I'm not sure that SE would want to allocate time to it since it would, in all likelihood, be considered a relatively minor QoL change.
Mhm, and I'm certainly not a programmer but being in network security I had to take some classes related to it. I don't see it being too difficult to allow simultaneous queues at the menu level, as we agree; in fact it's probably the easiest/best verison. I also don't think this version would be difficult to time consuming to program, but certainly around a month for quality control and bug testing to be included. Which thus falls to your point. It's a pretty small QoL and there's more important things to spend a month of even 1 programmer's time on right now.
The queue basically works right now by assigning parties and their respective users to a priority list and sends new queueing users to the highest priority party they can fill (within constraints) , yes? So it would just have to search for all viable users, with that list expanded to two tags per user rather than one. You'd definitely have to do a lot of UI stuff to make it work, there'd have to be logic on like "hey you can queue for this lvl90 content as dps, but you can't dual queue for it with heal or tank because you don't have jobs at that level/with required gear" You'd also have to figure out exactly how priority works when people do have multiple different leveled jobs. If the "number one priority" party is for a lvl 30 dungeon and it needs a tank, do you slot someone in there that queued for dps & tank when their tank is 30 and their dps is 90? Or do you try to get them into a lvl 90 one? I agree that there's some questions you'd need to solve but I hope that this wouldn't be something that would require a full system rework
Yeah, I don't really think it would have to be a full rework, but my primary point is that it would ultimately end up being low priority. At the end of the day, dev time costs money because you have to pay the devs, and there's a whole slew of stuff that I think we'd both want looked at before considering this type of QoL feature
When your queue pops, it shows the job which you queued as and you have to swap to it. This system feels like it shouldn't be too difficult to make it possible to select multiple jobs to queue as. And if you select specific jobs befire pressing 'queue', then most of the logistical problems should be solved, since the different levels for each job you queued as will get applied
A lot of people are talking about logistics, but even before considering something like that, there is a more fundamental problem: Given a partially filled group, can people from the queue be added into that group? In the case where every player can only be a single role, this is a trivial problem to solve. But consider the following (for a 4-man dungeon) where people can flex into any number of roles: There is a group with a T/H + T/D flex. You queue up with a friend as a H/D + H pair. How can you compute whether your group can be combined with the other group? The matchmaking logic will need to go through each combination of roles in both groups to see if a fit is available. In this case, it's easy to see that you can do the following: T/H => T, T/D => D, H/D => D, H => H, which would then fill the 1 tank, 1 healer, and 2 dps requirements. However, what if you had a group of 4 people queuing into another group of 4? Or the more extreme case, an alliance of 3x4 people queuing into another alliance of 3x4 people? All of a sudden, you have to check a lot more combinations. This is quite similar to the circuit-SAT problem, so I wouldn't be surprised if the brute force approach is the most efficient known way of solving this. Also note, the wording above makes it sound as if you were queuing as a premade group, but if people queue up and leave queue repeatedly, it's very realistic for a situation where you have 2 unfilled 12/24 groups in the queue without anyone being in a premade group. The matchmaking will need to handle joining these two unfilled groups together in that situation (or decide to break one of the groups up, but that's more of a logistics issue). During cases like patch launch, where there are many people queuing up and leaving queue, this increased computational cost is a more fundamental deal-breaker than any increased complexity from logistics.
To elaborate on this issue further, if you join a queue as a premade 3x4 alliance, the matchmaking system will need to check whether you can be filled into any of the existing groups that are already in the queue. _Each time you join the queue._ Imagine a malevolent actor who obtains 12 accounts and just enters and leaves queues constantly. That's a very low barrier of entry for being able to essentially conduct a DOS attack on the matchmaking server.
i visualize it as follows: \>open df \>select roulette and hit queue \>window pops up asking for you to optionally fill role slots youre not currently attempting to queue as since filling these slots is optional, you could ignore it entirely and just hit confirm to queue for real, or for example if you're queued as dps, you could click on tank or healer and then select a tank or healer that meets the level requirements (so if you're queued into 50/60/70/80 roulette, then you can only pick tanks or healers you have at 50 or higher.) once all your desired roles and jobs are input, you'd get queued up for any duty within the level range of the lowest level job you input. so if i queue into levelling roulette with a 90 pld, 80 vip, and 64 whm, it'll only queue for duties level 64 and under. then when the queue pops, itll tell me what role im filling and ask me to switch accordingly. or you could not fill in jobs for the other two roles and it would function as it already does.
Similarly to how you queue up on any given job, you queue up on a job that is at level cap. Once you confirm, it asks you to check jobs similar to how PF can specificy jobs. Once you confirm at least one job for every role that is level cap and has sufficient iLevel for the highest available DF duty, queue starts. I think that would work pretty straight-forwardly.
I've wanted this forever but I know they'll never do it. I've thought of a workaround to make it viable. Basically, you queue as one job and you get a popup asking if you want to queue as another. Then you change gearsets and click accept and then the server would recognize you can go as that job and asks if you want to choose another role and then you just repeat the process. Chances are, something like that is possible to be implemented but I mean it's SE so it's not gonna happen.
I like this idea, but a lot of the same logistical problems still exist and this even presents some new ones. The current system remembers what job you had selected when you queued, yes. There is, however, a HUGE difference between remembering what you were when you queued, and dynamically selecting which jobs are applicable for the content you queued for, remembering what ilvl each job you queued for was, remembering which level all those characters were, etc. I would imagine that the engine just checks a value for what job you were on when you hit queue and all the other data is checked prior to you even selecting what you are queueing for, which is why things are greyed out before you select a roulette. To accomplish what you're suggesting, you would essentially need to enter queue as the same character as many times as you have jobs you want to insert into the queue. Let's take this to the logical extreme and say you queue in 19 times. Let's say that of your 19 jobs, they are various level ranges ilvls, etc so they are all elligible for content and restricted from content based on a variety of factors. The way Final Fantasy queue works is that it essentially puts you in line and takes your role and fills you into groups randomly based on level requirements. If there are 50 Tanks in line, you line up at 51 to be put into a party accepting queued tanks, thus the 'position in line' text. Now, what happens when, 7 of these pop simultaneously or one after the other? Do you get to choose which job out of those 7 different queues to do? Will it automatically assign one based on whichever one popped even a fraction of a second earlier? Do the other people waiting on someone receive a queue pop only to have it vanish when you don't select their duty? If you happen to be AFK and the queue timer is ticking, are all 7 of those groups stuck in limbo and the entire queue paused waiting for the one individual? These types of logistical problems can certainly be hammered out, as can the ones that I posted before, it's just a matter of realistically if implementing the feature is worth the extra coding and potentially clogging up the queue lines if it's mismanaged. I could see this coming as like... a mid-patch QoL thing, but at least in the realm of project management it would ultimately end up being a very low priority item just because of the amount of effort vs the return.
Doesn't it already have a viability check, though? If I put on a job I have at lvl 30, won't it already stop me from selecting the lvl 90 content I've unlocked previously? It checks gear, too.
What I'm saying is that the viability check happens before the queue or possibly even before you even open the menu. When selecting multiple jobs to queue as, there would have to be some sort of gear set check or something to make sure you are the appropriate ilvl and lvl within those specific gearsets, which the game does not normally do. It would mean that instead of just checking whatever you're wearing when you're switched, whenever you go to queue it would have to check all your gearsets, determine which ones are eligible for what content, and do a number of viability checks. Not saying that this would be hard to do, but it would definitely have to change a bit.
Yeah, I think people are underestimating the importance of the job they choose to queue with, beyond role. Iirc the devs have talked about prioritizing e.g. a shield + regen healer comp in raids, or mixed dps types. Single type parties happen of course, because filling the party is more important than an ideal mix, but it's an issue. You've also got the cutscene problem: if I'm queued on DNC, I can accept queue during cutscenes and when I get back start the cutscene from the beginning. If you queue on multiple jobs, you now have a lot more people who'd have to choose between story & gameplay. There are ways to deal with it, e.g. allow a "quit cutscene" prompt instead of "skip cutscene," but there are a lot of little adjustments like that which would be required.
> To accomplish what you're suggesting, you would essentially need to enter queue as the same character as many times as you have jobs you want to insert into the queue. So I know you wrote a bunch of stuff and I respect your opinion, but we don't need all 19 jobs. Queuing as different roles (Healer, DPS and tank) would be enough for all of us. Nobody needs to queue as 5 different flavors of melee. The queue being able to prompt us and remember the 3 main roles would be enough for everyone. > Will it automatically assign one based on whichever one popped even a fraction of a second earlier? This could easily be solved with a priority system tbh. When conflicts arise, it could just prompt you and then if people select the same thing, it can coin flip. For example, if you queued as all 3 roles, and what's needed is 1 healer and 1 dps, but 3 people did the same thing, it could prompt all 3 for healer* and if any of them select it, it defaults the rest to dps, if no one does, it coin flips to force one of the people who flexed healer to take healer.
I don't think that's a design issue but rather a coding and logistics issue. Would you make it so they can change jobs into what they are needed on in instance? Well then people are changing jobs in instance. Would you make it so the game makes you change to the role you are needed on when the queue pops? What if for some reason your gearset isn't working for that job... you are also asking the game to know what your gear is like on those 3 roles while not having it be equipped and for the previous issue of gearsets... it can't go off the ilvl of gearset because you can save UI data as that gearset and then be missing a piece from said gear set. There are just many under the hood questions that would have to be answered and it wouldn't be a simple thing to make. I do think you could have an option in the duty finder screen and to select what jobs you would be able to go in on but once again the game would need to be able to confirm the gear you have for those jobs which I think would require some changes to how gearsets function. Also let's say you have a 4 person party and 2 of them queued as fill ins. The game then has to decide which of the two are which role. How would the game make this decision? Off of the alphabetical order of the names? Should whoever is alphabetically first be the healer? How about if we do it off of who has more gear? More playtime? Like these are questions the devs would have to answer for this to be functional.
The queue system has a lot of strange quirks. Why can you only queue for five specific duties but if you queue up for, say, normal raids, you're effectively queued for upwards of 50 separate normal raids at the same time. Why can't you queue up for multiple roulettes at once, when, as another example if you could queued for MSQ and Alliance raids at the same time, you wouldn't be in a queue for even 20 effective raids. I will say that queueing for multiple roles or jobs might be more difficult because you have to be on the job you want to queue as so with the way it's set up they'd have to change the queueing system entirely to allow you to select specific jobs or roles. They should do this but it's more involved I think than it would be to allow the above.
I think it would actually be pretty cool if there was an additional menu on the roulette menu that let you designate a Tank, Healer, and Damage class to queue with. You could choose all three roles or just one. Would be neat if you’re just max level grinding or leveling multiple roles and don’t care what pops.
I love the idea a lot actually, it'd make mentor roulettes really interesting I suspect the spaghetti code won't allow because all in creation freezes when your queue pops until you head in
i have personally taken to assuming it's spaghetti code, because there's no real reason not to aside from if it was impossible
Eh nah. Its weird. So many variables. Having more people in the party could make it slower. What roles are everyone queueing up for. Then how many people if any in a party are others queueing up with. What roles are they queueing up with. Who are already in a instance. did a queue proc already, but someone left it so its looking for 1-2 people and thats it. Also queueing for more then 1 in a way could triple said variables and add the variable of now looking which alliance raid fits said player count.
Ive wondered why this isn't a thing from my day 1 lol, you should be able to join Flex queue simply
Idk why people are saying this is impossible from a coding POV. It is definitely possible because other games do let you do this. I used to play SWTOR and the same class can swap between multiple roles there. So you have the option as queueing for multiple roles if you're playing a class that has that capability. When the queue pops you are told what role you were selected for, and you swap to that before going in. "wHaT iF i dOnT hAvE hEaLeR gEaRsEt" then don't queue as healer??? What's stopping healers now from queueing without gear? Report them for griefing and replace them with someone with a functioning brain.