Explanation of manual cluster queue priority system

• I'm sorry, but this is horribly designed and FAR too confusing. We shouldn't need a muilti-paragraph forum post to explain a cluster priority system.

This needs to be designed with end user in mind, not from a development standpoint.
• ProfessorZee wrote:

I'm sorry, but this is horribly designed and FAR too confusing. We shouldn't need a muilti-paragraph forum post to explain a cluster priority system.

This needs to be designed with end user in mind, not from a development standpoint.
This. The system just gets more complicated and convoluted with every iteration, without ever solving the problem satisfactorily. The huge majority of your playerbase havent a clue how this works and are just frustrated and confused by it.
Midgard
T8 Fibre, Ore, Hide, Wood & Stone Gatherer
T8 Gathering Gear Crafter
T8 Bags & Capes Crafter
• @Korn

Korn wrote:

2. Based on the players from the alliance who are in the queue or already in the zone, the system calculates how many total player slots that alliance will get in the zone in the upcoming queue cycle. The calculation is based on the average IP value of the players in the queue or zone. This calculation is not affected by any manual queue priority settings.
For instance, if 3 alliances, A1, A2, A3 with respectively the average IP of 1250, 1350 and 1550 try to zone in, how many player of each will be able to zone in ?

The post was edited 1 time, last by grul ().

• So.. Because your servers are not enougth, some alliance members will be kicked out whenever your greatness deserves it.

It's very 'sandbox' that the one who arrived first will may be the last who gets in. And it's very funny when this one who arrived first can't get in until figth it's over.
• Korn wrote:

Hi all,

here is a short explanation of how the manual cluster queue priority system works.

1. The cluster queue in general works on an alliance level.

2. Based on the players from the alliance who are in the queue or already in the zone, the system calculates how many total player slots that alliance will get in the zone in the upcoming queue cycle. The calculation is based on the average IP value of the players in the queue or zone. This calculation is not affected by any manual queue priority settings.

3. Once the system has calculated how many total slots an alliance will have in the zone, it checks if the current number of alliance members in the zone is higher or lower than that. If it is higher, some members will be kicked form the zone. If lower, some members can enter the zone.

4. The system then determines players to be added to or removed from the zone based on the following:

Entering (if there are fewer players from the alliance in the zone than the alliance has slots)
• The system will pick the player from the alliance in the queue with the lowest party priority number. (priority number = the actual number that you choose in the cluster queue UI)
• If there is more than 1, pick the one with the lowest party member priority number.
• If there is more than 1, pick the one with the highest average item power
• Repeat the above until the all slots are filled
Kicking from the zone (if there are more players from the alliance in the zone than the alliance has slots)
• The system will pick the player from the alliance in the zone with the highest party priority number (if nothing is set here, it automatically counts as the highest, i.e. 100)
• If there is more than 1, pick the one with the highest party member priority number
• If there is more than 1, pick the one with the lowest average item power
• Repeat the above until all excess players are removed
Note that the above means that if no manual priorities are set, the cluster queue works exactly as before

Tipps on how to correctly use manual cluster access settings
• The absolute value of the priority number you set does not really matter. There is no benefit from setting everyone to "1" for example. The only thing that matters is order of the numbers that you use.
• Each party should have a unique party priority number. If multiple parties have the same party priority number, the system essentially considers them to be one large party and won't differentiate between them.
• If you want to structure your manual cluster queue in such a way that individual guild structures are preserved, a good way to do that is to reserve party priority ranges for each guild, such as 1-9 for guild A, 10-19 for guild B, 20-29 for guild C, etc. If each guild has 3 parties, you'd use priorities 1, 2 and 3 for guild A, 10, 11 and 12 for guild B, and 20, 21, 22 for guild C. This ensures that guild A will zone in fully before the first players from guild B can zone in, with guild C only zoning in after everyone from guild A and B has already done so.
• For individual parties, depending on what your aims are, you'd probably want to give custom priorities to critical roles such as party leader, tank and healer. Again, here, if you want absolute control, use each number only once. It's probably fine if you just assign a custom number to absolute key roles such as leader, tank and healer and leave the reset unassigned - which means that the system will automatically sort them based on average item power.

The system priorities people in the queue when they have party members already in the zone.

I was watching an allys stream and saw multiple people from that party die and get back into the zone 3 times in 3 different cycles while we waited something like 10 minutes, we gave up and left.

my ip was higher than the people zoning in, the only difference was my 5 man party was queued and not in the zone. queue priority was 1 for the party and each member.

This prevents people from having a go in the fight and people who have already had some fun get to go right back in.

Not fun or fair.
• Korn wrote:

Hi all,

here is a short explanation of how the manual cluster queue priority system works.

1. The cluster queue in general works on an alliance level.

2. Based on the players from the alliance who are in the queue or already in the zone, the system calculates how many total player slots that alliance will get in the zone in the upcoming queue cycle. The calculation is based on the average IP value of the players in the queue or zone. This calculation is not affected by any manual queue priority settings.

3. Once the system has calculated how many total slots an alliance will have in the zone, it checks if the current number of alliance members in the zone is higher or lower than that. If it is higher, some members will be kicked form the zone. If lower, some members can enter the zone.

4. The system then determines players to be added to or removed from the zone based on the following:

Entering (if there are fewer players from the alliance in the zone than the alliance has slots)
• The system will pick the player from the alliance in the queue with the lowest party priority number. (priority number = the actual number that you choose in the cluster queue UI)
• If there is more than 1, pick the one with the lowest party member priority number.
• If there is more than 1, pick the one with the highest average item power
• Repeat the above until the all slots are filled
Kicking from the zone (if there are more players from the alliance in the zone than the alliance has slots)
• The system will pick the player from the alliance in the zone with the highest party priority number (if nothing is set here, it automatically counts as the highest, i.e. 100)
• If there is more than 1, pick the one with the highest party member priority number
• If there is more than 1, pick the one with the lowest average item power
• Repeat the above until all excess players are removed
Note that the above means that if no manual priorities are set, the cluster queue works exactly as before

Tipps on how to correctly use manual cluster access settings
• The absolute value of the priority number you set does not really matter. There is no benefit from setting everyone to "1" for example. The only thing that matters is order of the numbers that you use.
• Each party should have a unique party priority number. If multiple parties have the same party priority number, the system essentially considers them to be one large party and won't differentiate between them.
• If you want to structure your manual cluster queue in such a way that individual guild structures are preserved, a good way to do that is to reserve party priority ranges for each guild, such as 1-9 for guild A, 10-19 for guild B, 20-29 for guild C, etc. If each guild has 3 parties, you'd use priorities 1, 2 and 3 for guild A, 10, 11 and 12 for guild B, and 20, 21, 22 for guild C. This ensures that guild A will zone in fully before the first players from guild B can zone in, with guild C only zoning in after everyone from guild A and B has already done so.
• For individual parties, depending on what your aims are, you'd probably want to give custom priorities to critical roles such as party leader, tank and healer. Again, here, if you want absolute control, use each number only once. It's probably fine if you just assign a custom number to absolute key roles such as leader, tank and healer and leave the reset unassigned - which means that the system will automatically sort them based on average item power.

I used to play this game quite alot, in early beta stages too. This update is 100% what ruined the game for me and I haven't played ever since. I wasn't part of the huge Blue Army Alliance, and really enjoyed my time. It made me sad because I really liked this game and it has turned into something else entirely.
• Is this still up to date?