Maintenance for the week of April 6:
• PC/Mac: No maintenance – April 6
• PC/Mac: No maintenance – April 6
Group Finder grouping players of disparate levels
-
Iccotak✭✭✭✭✭
✭✭✭✭
Well if the queue is taking too long maybe find friends or guild mates to get into the dungeons faster0 -
Oreyn_Bearclaw✭✭✭✭✭
✭✭✭✭✭If you want veteran players out of normal dungeons, then they need to incentivize veteran dungeons. In other words, increase the transmute and increase the XP, and perhaps split the queue between DLC and Non DLC because the former has a much higher failure rate.
Nobody wants to fail a dungeon after 20 minutes in the queue, and nobdoy wants to run a vet dungeon for rewards when you get the same thing from a normal in a fraction of the time. Most vet players wanting to clear new or difficult content avoid the group finder like the plague. Until that happens, Vet players are going to use Random Normals for their rewards.3 -
Kaartinen✭✭✭Join a guild or make friends. PC and Xbox have lfg capabilities. All of the tools are available to you.
A random quick queue is exactly that.0 -
ForzaRammer✭✭✭✭✭
✭Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com1 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com2 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
deleted221106-002999✭✭✭✭✭
✭✭Group Finder is not the place to learn dungeons. It's simply a tool to find a group to run a dungeon. Nothing more, nothing less.
If anything expects anything beyond this, they are in for disappointment.
If your goal is to actually learn a dungeon, join a guild or make friends with the same goal. Don't expect three strangers from GF to do what you want to do.
So much this.
There would be a lot less threads complaining about fake roles, mismatched groups etc if the simple reality of the facility the random group finder actually provides was recognised, although it can be frustrating at times to experience.
If you're looking for specific results using the tool then good luck with that. If you want guaranteed roles, guaranteed slow-down for quests, guaranteed <insert_your_preference> then pre-form your own group.
As an aside, the group finder actually more or less works now. Kind of. Last thing anyone wants is for some well-intentioned dev at zos-central to go fiddling around with it as that'll likely end in months to years of a truly broken utility.6 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.0 -
renne✭✭✭✭✭
✭✭Only issue I have with group finder is if you’re a DD it’s takes forever to queue. If you’re a tank or a healer, instant pick up. Only issue I have with who I’m grouped with is fake tanks, fake healers. Like, tired of getting “healers” with bows shooting light attacks and acid spray and not actually playing the role they queued for. Or Tanks who are actually DD’s for pvp and no taunts. And lately, for whatever reason, DD’s using S&B.
You know, you call it an issue but for some reason last night (so like 12 hours ago Aus time) when I was running through all my 50+ toons for the normie rando XP, for one DPS the queue popped immediately, and for another within a minute and that was scary. What's going on with the queue if it's popping that quick on a DPS???
My favourite though, was on my full healer getting Moon Hunter Keep with a tank who was a werewolf which is the biggest red flag. Yes, I know there's a set they could wear but the word is "could" and they definitely weren't. That dungeon is painful enough even on normal without the "tank" not taunting and the bosses being dragged all over the place, or me constantly getting aggro because I'm the healer.
On the other hand, we burned the shapes boss so quickly I got a PS trophy for it, so... ¯\_(ツ)_/¯
Group Finder: it's always a mixed bag.1 -
zaria✭✭✭✭✭
✭✭✭✭✭
Dps queues suddenly become much longer, outside of that pushing fakes into veteran will not be pleasant.ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Only upside it that the smart ones know you don't want to fake heal darkshade 2 or fake tank selenes.
However they runs with guilds anyway. Had an epic run this weekend in people of tamriel.
We was farming normal dlc for gear and quest skill points. So we did an random dungeon, if it was not an dlc we ported to next on list.
Grinding just make you go in circles.
Asking ZoS for nerfs is as stupid as asking for close air support from the death star.0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com2 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.
It’s by design to make it harder to match for LOM to achieve performance gain, as well as stop people who specifically que it waste my time.
Remove features completely is a great way reduce computation. Select only 1 dungeon is perfect fine for those who just want to do the pledge dungeon anyways.
A feature work to my disadvantage is a feature I advocate to remove.
0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.
It’s by design to make it harder to match for LOM to achieve performance gain, as well as stop people who specifically que it waste my time.
Remove features completely is a great way reduce computation. Select only 1 dungeon is perfect fine for those who just want to do the pledge dungeon anyways.
A feature work to my disadvantage is a feature I advocate to remove.
Ok. Clearly this isn't about queues. Or performance.
You're just complaining because you don't want to do hard content. And you want to be rewarded for that.
Too bad.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.
It’s by design to make it harder to match for LOM to achieve performance gain, as well as stop people who specifically que it waste my time.
Remove features completely is a great way reduce computation. Select only 1 dungeon is perfect fine for those who just want to do the pledge dungeon anyways.
A feature work to my disadvantage is a feature I advocate to remove.
Ok. Clearly this isn't about queues. Or performance.
You're just complaining because you don't want to do hard content. And you want to be rewarded for that.
Too bad.
Too bad for you because the last poll i saw, majority of player don’t want dlc dungeon from random.0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.
It’s by design to make it harder to match for LOM to achieve performance gain, as well as stop people who specifically que it waste my time.
Remove features completely is a great way reduce computation. Select only 1 dungeon is perfect fine for those who just want to do the pledge dungeon anyways.
A feature work to my disadvantage is a feature I advocate to remove.
Ok. Clearly this isn't about queues. Or performance.
You're just complaining because you don't want to do hard content. And you want to be rewarded for that.
Too bad.
Too bad for you because the last poll i saw, majority of player don’t want dlc dungeon from random.
Polls or not. ZoS makes the call. And they want people playing their new content.Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com0 -
El_Borracho✭✭✭✭✭
✭✭✭CP means nothing.
If you want to run a dungeon with a group of people your skill level or above, make friends or join a guild. Group finder is for people who want to run a dungeon and don't care who they run it with.0 -
ForzaRammer✭✭✭✭✭
✭allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »Zos’s spaghetti code is not even running smooth with this basic feature, op requested unnecessary features will negatively impact game performance.
If anything zos should remove random dungeon completely, just move the exp elsewhere, like pledge. This will not only stop people getting liar of massalork from que, and also reduce server load.
What player is like ‘oh please surprise me with a dungeon, I don’t even know what dungeon I want’?
Me? I like that.
Perfect, then randomly sample a dungeon name.
If you are too lazy to write 4 lines of code. Here is what zos can do.
Add something called random dungeon sampler, basically sort dungeon name alphabetically. Sample an integer in the index range. Display that name of dungeon at that index.
Then player can proceed to que that dungeon via specific que.
The benefit of doing random is that you potentially get paired with people who want to do specific dungeons. Filling roles they need to do that.
Me just putting in a single dungeon only matches me in the event that I happen to pick that specific dungeon.
I don't know if you've ever tried that for a specific dungeon, but the wait time is bad. Like. Really bad. Do not recommend.
So you are saying just because you qued just lair of massalork, 3 other people who happen to que random at same time, must do lair of massalork or waste 15 min.
On top of this, it also put more stress on the server.
Damn right people who qued LOM should be only matched with people who qued LOM.
Why? Random dungeon is just = don't care which dungeon. I definitely prefer something like Lair vs Fungal 1, but I'll take either when I chose random. That's the point of random.
So to you, a truly uniformly random selection is bad? But letting some dude who qued specific dungeon (thus pick the dungeon) at the same time as me queing random que is good?
What you like is not truly random index. It’s a constant value index that I am not shown.
I'm saying that I'd rather have a group get built. Using the GROUP FINDER than wait forever because you don't like LOM.
Do you want increased wait times? Because that's how you increase wait times.
What increased wait times? Certainly not for FG1.ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
So your solution is to let players only
1. Select only one dungeon
2. Wait until 3 other people have also selected said dungeon
3. Field infinite amounts of anger generated by these 2 decisions.
How about this?
Do what you suggested, but instead also have a "I'll play whatever" queue. That will fill these empty spots quickly instead of waiting for hours for your 4th dps to show up. Maybe call it... "Random Dungeon" queue or something like that.
By taking that queue away, you increase wait times.
Regardless of the actual mechanics of how the dungeon finder actually work. Your suggestions will by their nature make it more difficult to match with people. And I'm certain that this system is far more complex than you might think, because if there was a "simple fix" they'd have done it by now.
It’s by design to make it harder to match for LOM to achieve performance gain, as well as stop people who specifically que it waste my time.
Remove features completely is a great way reduce computation. Select only 1 dungeon is perfect fine for those who just want to do the pledge dungeon anyways.
A feature work to my disadvantage is a feature I advocate to remove.
Ok. Clearly this isn't about queues. Or performance.
You're just complaining because you don't want to do hard content. And you want to be rewarded for that.
Too bad.
Too bad for you because the last poll i saw, majority of player don’t want dlc dungeon from random.
Polls or not. ZoS makes the call. And they want people playing their new content.
Solo bg, alliance lock campaigns are just 2 examples of zos actually listened.0 -
El_Borracho✭✭✭✭✭
✭✭✭ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
Dude.... what?
Right now, it takes much, much longer to queue for individual dungeons than it does through the group finder. Now, imagine adding in having to find a player at or near my CP level
HARD PASS1 -
bmnoble✭✭✭✭✭
✭✭One point you need to remember, while there may be many DPS of every level in the queue most of the tanks and healers in the queue are at CP level, not saying there are no under level 50 supports leveling but far too few if your planning to separate the queue based on levels.
That and the plenty of fake tanks and fake healers mean even if a low level group queue just lets support roles join them, it will be flooded with fake roles after a quick easy run, resulting in an even worse version of the same problem we have now.
Also just because a player is under 50 by no means, means they are new, plenty have their entire CP assigned while under level 50 making them a lot more effective than someone on a fresh account.
That all said if someone is hoping to learn a dungeon with a group from the group finder they are going to be disappointed, all the finder does is put you in a group, you got no guarantee that three other people are going to want to do what you want to do. The bare min you can get out of most such groups is doing the quest even if it means rushing through the dialogue, even then you get groups that will ignore even doing that much.
Only real way to solve the problem is to group with guild mates or form a group in zone chat.0 -
ForzaRammer✭✭✭✭✭
✭El_Borracho wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »allhailskippy wrote: »ForzaRammer wrote: »On top of this, it also put more stress on the server.
You're gonna have to back that one up.
Before i explain, i must ask, do you code at all? I am mediocre at best on coding, but i understand how simple que works, and only remove from the head the que is less computation than allowing removing from middle of the que.
Yup. Professionally.
Please also factor 3 distinct roles in your queue explanation.
And the fact that there are 20 something dungeons to select from.
Essentially my solution is 6 simply que for each dungeon, 2 for each role, low prio and high prio, no cross check between different dungeon, only check if que is empty with in same dungeon. To encourage behaviour lower ram usage, only allowing que 1 dungeon at a time, player can sit in more than 1, but pre ready check check should be auto fail.
On your screen you can see if you are qued, which means server is already tracking it. When a player que a dungeon, an obj is added to a the end of the low prio que based on role, check the other 5 que. If at least 1 que for all 3 role is non empty, select the first element in que, high prio over low prio.
Player who ready checked but did not join dungeon is moved to the back of high prio que. player who failed ready check is not in that que anymore. No need to remove player from the middle of anyque, simply auto fail the ready check when 1 of the player status does not meet requirements.
Tell me, how exactly can the current system not do cross check between different dungeons?
Dude.... what?
Right now, it takes much, much longer to queue for individual dungeons than it does through the group finder. Now, imagine adding in having to find a player at or near my CP level
HARD PASS
Yes, my solution will definitely result in longer que in non pledge dungeons. That’s by design to improve performance.
Why not just form your own group for non pledge dungeons? There is no que for vdsa or vbrp anyways, I honestly don’t mind removing dungeon finder completely.
In craglorn, the tank gets way more leverage on who to pick, higher skilled dd are way more likely to be chosen over lower skilled dd.
This is great, the least chosen role deserve the most leverage. The more capable player gets to go first.0 -
allhailskippy✭✭✭✭✭ForzaRammer wrote: »Yes, my solution will definitely result in longer que in non pledge dungeons. That’s by design to improve performance.
Slow things down to make them go faster. Got it.ForzaRammer wrote: »Why not just form your own group for non pledge dungeons? There is no que for vdsa or vbrp anyways, I honestly don’t mind removing dungeon finder completely.
Cool. You do that. Rest of us will carry on. Me, I'd like to see a queue for both of those places.
Hireling Wanted! - An Elder Scrolls Tale https://hirelingwanted.com1
