Has this always been this way? party members change+block party dungeon?

[Astarae]

I have never noticed this before -- but had it happen 3 times today and once yesterday on both HM and CS.

 

I selected the dungeon (HM/CS), and then invited people to come.  At least 4 times, I've had someone else join my party who couldn't

do CS/HM, who forced my selected dungeon to be deselected.  This shouldn't happen.  If I am inviting people to a party and a group of 5 people all join at once, I can't even tell who is blocking the dungeon -- but someone in that group had done it before and it knocked everyone else out of the dungeon being select.  

 

Someone who can't do a dungeon shouldn't be able to join a party that already has the dungeon selected and is "advertising" for party members for that dungeon.    This has to be a new bug, no?  At the very least, its a bad dynamic, since someone can join with a group and you won't be able

to tell who is blocking selection of the run.  Why are party members able to block the listed dungeon for everyone else?

 

 

[ElectricPotato]

Mouse over the dungeon that was deselected in the list.  The player(s) that cannot participate  names should be listed in red text in the tooltip. Cordially use party chat to inform them that they are locked so that they don't get upset and try to spam rejoin. Kick them from party if they haven't left under their own power.

[Dru Lockheart]

Maybe they have event weapon equipped which expired, but they didnt realize it yet :D

[Astarae]

1 hour ago, Dru Lockheart said:

Maybe they have event weapon equipped which expired, but they didn't realize it yet :D

The weapon isn't what blocked them -- they participated in CS or HM and then tried to go a 2nd time in the same day to the same dungeon and are not allowed to.  Then they joined a group that had already selected and was recruiting for a dungeon they could not go to.

 

What I don't see is why they were allowed to join in the first place.  If someone selects 'no duplicate classes', for example, it doesn't

let duplicate classes join and force that option to "off".  They don't meet the qualifications of the group, so they can't join.  How would them joining on a blocked-dungeon (they can't do duplicate a dungeon run to a once-per-day dungeon), so they should be excluded.

 

Thanks for the tip, E.P., but many times it is difficult to get the number of people you want and more than once I've had people turn around and leave because they looked at the dungeon I was going to and if it wasn't selected, they assumed something was wrong and we were't going where I was recruiting for or I didn't know what I was doing, etc...  From the time I posted the announcement "HvOrb: normal loot bidding",  I had at least 4 or 5 people join and quit (for whatever reason), and at least 1, maybe 2 left when the destination dungeon got turned off.  Maybe unrelated, but its also the case when there are alot of runs and alot of traffic on the chat/announce window, it is not impossible that they will miss it.   

 

It seems like a huge abuse potential that some random person could spam the join option and lock a group out of going to some dungeon they were blocking.  People's patience, when joining, and in the dungeon, has been lower than the usual low levels, since the ascendant patch.  So that makes me a bit more paranoid when there is high turnover in group-joins.

 

It is certainly a design bug to prevent them from joining in some cases where they don't meet requirements (like disallowing duplicate classes) but not when a dungeon is selected that doesn't allow duplicate visits in the same day.

 

The problem wouldn't just be with those who've already done a 'restricted dungeon', but also with those who sometimes can't do some dungeons due to level or not starting (or completing) some side quest.  Could this be fixed?

 

 

[Amarathiel]

It is most likely designed as a performance optimization and not a bug since player can freely change the selected dungeons at any point so it is faster in terms of performance to just deselect the selected dungeon if someone can't enter it for whatever reason. If the server has to do a checkup as to weather he is locked to HM or CS every single time a person enters any room, it would probably increase the stress and overall response times on the server as a whole as it now has to do these tasks as well on top of everything else it does simultanously. So yea, that would lead into slighly more laggy gameplay :P

The less checkups or calculations server has to do, the better it will be as this game already is too CPU heavy.

[Astarae]

This isn't true: "since player can freely change the selected dungeons at any point".  Once they entered, I could no longer select the dungeons they were blocked from. 

 

As for the server doing a check -- it already does a check -- if it didn't, it wouldn't disable the dungeons they are locked out of.  I.e. every dungeon that anyone is locked out of gets an 'X' by it indicating I cannot select that dungeon.  That check isn't just done on the dungeon I've selected, but on all dungeons which has to take considerably more CPU-checking than just checking the 1 (one) dungeon that was selected.  The dungeons that people are locked out of is sent to everyone in the group to update their display and, in this case, remove

them from the dungeon selected.  Now all those peoples' clients have to update their status that the dungeon they were removed from is no longer on the chosen dungeon list.  Overall, knocking everyone out and updating their lists with someone's dungeons who can't go to the invited dungeon is far more expensive in terms of CPU resources than only blocking the one person who cannot enter.  

 

A similar server check is already done w/r/t classes.  If the "no duplicate classes" checkbox is checked, they will be prevented from entering and rejected.  That check has to be done in "real time", since it needs to compare their class with everyone who's already joined, vs. only checking if the group already has a selected dungeon and not joining because of that.

 

The current features that are supported don't indicate that they are looking at resource-usage optimization as a reason for not including this feature -- in fact just the opposite.  *sigh*