Feedback:User/Morgaine

This is the personal suggestion homepage for Morgaine.

Create a suggestion

To begin adding a suggestion as user Morgaine, enter a name for the suggestion in the box below and press "Create":

(Are you not Morgaine? See Feedback:Getting started for how to create your own suggestion homepage and add suggestions!)
Still having problems?

Quick reference links[edit]

My suggestions[edit]

{entry removed as all suggestions have appeared now} (**)

(**) Added manually as hasn't yet appeared in automatic template listing -- wiki bug?

Issues for future suggestions[edit]

The following list highlights some problems, solutions, or issues which interest me. One day, one or more of these may lead to proper suggestions being written up. Anyone reading this should feel free to take anything from this list as input to their own suggestions. It would be nice if you let me know if you do this so that I can provide you with feedback and support your suggestion, but it's not required. Ideas are free.

PvE/PvP skills toggle[edit]

Provide a PvE/PvP toggle button somewhere on the UI to allow a user to choose whether to see the PvE or PvP versions of skills. The setting of this button should affect all skills displayed in the skills window, in all player and hero skill bars, and in skill monitor windows. The current situation in which PvE players are hampered when creating builds while relaxing in their guild hall because the PvP versions of skills are displayed is most unsatisfactory.

Make 'Sell' the default tab at Merchants[edit]

Players sell drops to Merchants vastly more often than they buy. Why then does everybody have to make that extra click to switch the Merchant window from Buy to Sell? For improved user-friendliness, I recommend that Sell be made the default tab.

Death Penalty rate limit[edit]

Limit the rate at which a player or hero/henchman can incur Death Penalty within a single encounter. Because foes in GW target monks preferentially, it sometimes happens that a monk ally emerges from a single battle with 45% or 60% DP while everyone else is fine. This is excessive because of the long period of recovery from such huge DP. I suggest that DP be limited to 15% per foe group, or 30% at most, or perhaps 15% DP every 5 minutes maximum. There really isn't any game merit in making the penalty on death harsher than this in a game which is intended to be fun.

Add campaign maps to the Travel boat menu[edit]

To the menu available from the Travel boat icon in the M world map, which currently has a single section labeled "Ports:", add a new section labelled "Maps:", and within this new section add 3 entries: Map of Tyria, Map of Cantha, and Map of Elona. This would allow people to map-travel directly from wherever they happen to be.

In addition to making travel more pleasant for players by reducing the number of hops required to reach an inter-continental destination, this would also have the effect of reducing the load on servers caused by the unnecessary intermediate zone loadings that everyone is forced to make.

Revise Embark Beach[edit]

Embark Beach is a total failure:

Its new functionality could have been provided without creating a new zone at all, namely by adding Zaishen Vanquish as a 4th quest signpost in the Great Temple of Balthazar.

The Travel NPCs in Embark Beach are a catastrophe, requiring extra running within an outpost that is inevitably laggy owing to player numbers, and the whole bad situation is made worse by the 4 NPCs being distant from each other instead of side by side. The selection of transport destinations offered by the Travel NPCs is a catastrophe too, replacing the delightfully friendly map travel by what is effectively an extremely unfriendly, multi-level in-world UI. What's more, only a limited selection of destinations is offered, and very often the outpost most appropriate for gathering a ZV team is not offered because it is not a mission town. As a Human Interface, it is hard to imagine a worse design, requiring multiple steps to achieve a very elementary function, and it contrasts very badly with GW's friendly map travel. The Travel agents are truly a total design failure, and if this were not a public wiki I would put this even more harshly. No, just no. This is the opposite of player-friendly design.

To make the situation with Travel NPCs even worse, the Embark Beach area seems to have been designed for maximum annoyance with its convoluted layout, making it very hard to discern where you are when you teleport in to some random part of it. It's not quite as appalling as Gate of Anguish in that respect, but it does seem to inherit the same desire to confuse. Why do towns have to be designed as puzzles? Aren't town designs vetted for usability? Towns should be designed to be helpful for players, not as exhibits of developer ingenuity nor for maximizing player suffering.

I know that any suggestion of this type would be rejected, but I would recommend swallowing one's pride, moving the ZV signpost to GToB, and withdrawing Embark Beach entirely. Since that will not happen because designers don't like being seen to be wrong, I offer the more political suggestion of replicating the ZV signpost in GToB, deleting the Travel NPCs from Embark Beach, and adding menu entries for maps of Tyria, Cantha and Elona to the Travel boat menu as described in the previous section, thus allowing people to map-travel directly.

To try to end this section on a positive note, Zaishen Vanquish is an excellent new quest line. It was virtually impossible to find help for VQ before, so this is a huge help for players who do not have a good set of heroes or prefer not to use them.

Trade window width controls[edit]

The 7-slot width of the Trade window has always been an unfriendly size owing to its mismatch with the inventory row width of 5. I suggest that the Trade window be given four radio buttons labeled 5, 10, 15 and 20, which expand the Trade window to the appropriate size for both participants.

Multiple selection from inventory for Trade[edit]

Allow multi-select from inventory so that any number of items can be placed in the Trade window in a single operation.

Extend the Quests window[edit]

What I've always felt was missing from the Quests window is a full list of quests per campaign. After doing all campaigns and all expansions on every profession, I like to complete every last quest too, but it is quite impossible to keep a tally of which quests you've done and which you haven't done on each character.

Perhaps two new folders could be integrated into the quest window? Something like:

Completed Quests -- quests which this character has completed
Unknown Quests -- quests not yet obtained on this character

Clicking on a quest in the Completed Quests list could show you the last state of the quest info, with all sections crossed out to show completion as usual. Clicking on a quest in the Unknown Quests window could just give the name of the campaign, zone, and quest giver.

I previously mentioned this kind of enhancement for the Quest window on TEF's Quest Log 2.0 page.

Remove unecessary restrictions on equipment packs[edit]

Remove the restriction on types of items that can be held in equipment packs. It serves no gaming purpose, and just adds an unnecessary annoyance.

Revise Summoning Sickness in Pre-Searing -- DONE![edit]

Remove the 60-minute Summoning Sickness from Igneous Summoning Stone, at least in Pre-Searing. It's hard to see the gaming benefit of such a huge cooldown period. Neither waiting out the 60 minutes nor exiting to start from scratch are player-friendly options. If some penalty for getting your impy killed is felt to be in order, then just trigger a short (5 mins?) Summoning Sickness when impy dies, as a period of mourning. ;-)

Yay! GW devs did this of their own accord in the 5th May 2011 Update, reducing the duration of the sickness to 10 mins everywhere, not just in Pre-Searing. Well done guys+gals! :-)

Remove irritating UI pop-up[edit]

Add a "Do not notify me of this again" button to the popup window that says "You are repeatedly ordering your character to attack, when it is unnecessary to do so.". The GW UI has no visible indicator that Attack is enabled (other than in-world animation), nor is there any indicator of which target you are currently attacking (you may be attacking one foe while another is being targetted), so it is no surprise when players develop a repeat-attack technique to remove the ambiguities. It is extraordinarily irritating to receive a message about attack repetition being used when the UI's missing indicators are the actual cause of this mode of play.

Fix indirect path discovery faults in EotN towns[edit]

Enable or fix the inoperative indirect path discovery for click-running to trader NPCs in Rata Sum and other EotN towns, especially Asura and Norn. (It's working correctly in Vanguard towns.) Pathing to the new Zaishen Scout NPC works fine everywhere, and it has always worked everywhere for quest NPCs like Yulma and Lexx and for the Xunlai Chest too, so the lack of indirect path discovery for the original Asura/Norn trader NPCs like the Merchants and Dye Trader was probably just an accidental omission. Error in town configs? I bet different developers configured different towns, and this wasn't checked in overall QA.

To reproduce the indirect path discovery fault: Go to an affected town, like Rata Sum, and locate a Merchant. Then find a rock or stairs or other obstacle, and place yourself so that the obstacle is between you and the Merchant. Then locate the Merchant's tag again using the Alt key, and click on it. You will run directly at the obstacle and get stuck there, instead of an indirect path being discovered to take you to the Merchant. As a control experiment, do the same with the Xunlai Chest as target destination, which always works correctly.

Reward playing multiple professions[edit]

It is peculiar that that there are so many rewards in GW for "silly" pastimes like Drunkard etc, yet one of the most important activities in the game is not rewarded at all: playing more than one profession to completion. It is important because it broadens your knowledge of skills and gives you insight into how each profession really works, and so it makes you a better player. The Protector and Guardian titles already reward playing a single profession to completion, but each of those titles should really just be the starting point, 1/10 in a corresponding title line spanning all professions. Possible title names: Supreme Protector (achieved 3-campaign Protector title in 10/10 professions), and Supreme Guardian in Hard Mode.

Add position coordinates within each instance[edit]

It is very useful for many reasons to know exactly where you are in a map, as an x,y,z coordinate. It greatly improves the ability to document anything related to placement, including positions of NPCs and especially features that are not marked on the radar. Mapping out some multi-level zones like Wajjun Bazaar is especially difficult when you don't know your z-coordinate (height). For simplicity, the 0,0,0 origin should be entirely outside the instance map, the '0' value never being reachable on any axis --- this ensures that all coordinates use positive numbers only.

Implementation: The GW servers and the client almost certainly already know the character's position in the current instance as a coordinate. All that's required therefore is to display the current x,y,z values somewhere in the UI, for example on both the 'U' map and the radar.

Allow Guild Hall owners to move service NPCs[edit]

It is one of the worst aspects of towns in GW that the Merchant and Xunlai Chest have often been placed far apart or even at opposite ends of the district, seemingly to maximize player annoyance. While it's too late to do anything about public game towns now, the Guild Halls would increase significantly in user friendliness if their owners were allowed to move the hall's service NPCs around from their default locations. This could be achieved in a number of ways, perhaps using a "Start/Stop follow" method, or even better a "Click on ground and I will move to that position" approach. To avoid extra work on the NPC touch response, this movement mode could be started and stopped using comandline words similar to emotes, for example "/npc-move-start <npc-name>" and "/npc-move-stop <npc-name>", or alternatively just "/npc-move-start" and "/npc-move-stop" without a name, but followed by a single click on the desired NPC to select it. If such a mechanism were provided, I bet that the VAST majority of Guild Hall owners would place the Merchant and Xunlai Chest right next to each other. It would be such an obvious improvement to the existing situation.

Add "Percentage Zone Explored" to zones[edit]

Cartography is painful enough without the added hardship of uncertainty. I think it would be a good idea to remove the uncertainty factor by providing a Percentage Zone Explored value somewhere, for example in the "U" Mission Map title line. Any other value which corresponds to the amount of map uncovered would be equally suitable (eg. something related to acreage), as the GW community wikis would soon provide tables listing the maximum value found for each zone. I obtained the Legendary Cartographer title a long time ago, but I still remember the hardship, and anything that reduces it for players would be worthwhile, making the game more fun by providing better information. While I hear that there is some kind of add-on program to assist with Cartography these days, it should not be necessary for players to run the risk of using 3rd party software to achieve this hard title. It would help immensely if the game itself let us know how much of the current zone's map is uncovered.

Anchor the poor disoriented heroes/henchmen[edit]

When a team of heroes and/or henchmen is flagged half a radar's distance or more away from their leader, and then the flag is removed, they scatter in random directions like headless chicken, sometimes finding their way to their leader and sometimes going right off the radar entirely. This behaviour is very different to that observed when you simply replant the team flag at your feet,which leads them to your position directly. The difference between these two behaviors is unnecessary, and annoying, and requires you to replant the team flag (after swearing) so that the ones which headed off into the sunset can find their way back to you. I suggest that removal of the team flag be made equivalent to planting it at your feet when an H/H is distant from you, and equivalent to no flag at all only when they each come within agro circle distance of their leader.

Formalize H/H unflag scattering behavior[edit]

Heroes and henchmen "heading off into the sunset" when their flags are released at some distance from their leader is an accepted helpful exploit of the game mechanics, used for example in Dunes of Despair for getting them onto your side of the territory (via warp/cheat) after you've jumped the gap to a corpse with Necrotic Traversal. Since losing existing functionality is not desirable, yet undocumented behavior is not desirable either, I suggest that heading off into the sunset be formalized into a controllable feature in some way.

It isn't used often enough to merit another button on the radar (if it were, I would suggest "Warp"). In contrast, commandline options are almost free of implementation cost, so perhaps a mode in which remote H/H scatter on unflagging could be enabled by that means (eg. "/unflag-warp [on|off]"). It would then become cleanly user-controllable whether H/H scatter on distant flag releases, whereas currently it just contributes regular pain in normal gameplay.

Remove H/H flags from non-UI screenshots[edit]

When you use Shift-PrintScreen to capture the screen without UI adornments, any hero or henchmen flags that you have placed are displayed in the image as well, which ruins any attempt at composing a nice picture. They shouldn't be rendered in this "just the clean view" capture mode.

Address the worst cases of hero dumbness[edit]

We don't expect AI miracles from heroes, and even less brilliant tactics. However, it is reasonable to expect that the worst cases of utter stupidity could be avoided, because they create annoyance in the game. At least three come to mind at present:

When a hero has Frozen Soil on her skills bar, she should not recast it when one or more team members are dead. Who's side is she on anyway, the foes'?
When a charmable animal of very low level agros and attacks the team, the heroes should not open up their entire arsenal and vaporize it, wasting their long cycle-time power nukes and delaying the gameplay until they have recovered. A good strategy for the hero AI to use might be "If a foe is 15 levels or more below that of the hero, use only plain weapon attacks on it."
A Minion Master hero should instantly sense when his team gains agro and send his minions into battle. It is infuriating when the MM continues to blindly nurse his minions out of range of the foes, totally oblivious to the team getting slaughtered because of his absence. This should not require micro-managing by the player. If all members of a foe group can instantly sense agro, why can't our MM hero too? Who's side is he on anyway, the foes'? (This wasn't a problem until the dreadful update that made MM heros move away from the rest of the team.)

MM hero separation: Checkbox and/or agro sensing[edit]

The dreadful update for MM heroes mentioned in the preceding paragraph appears to have been devised by someone who doesn't use MM heros personally and hates minions, otherwise they would never have made such a destructive change. Whatever the motivation, it has made MM heroes a pain to use because you have to micro-manage them or else their minions frequently don't join in battle at all. Quite often the hero continues nursing his minions outside of agro radius of foes, and the fighting is all over by the time he decides to catch up. What's the point of that stupid mechanic? Why doesn't the MM hero sense agro, just like MM foes sense agro on their team and immediately come forward into battle? The change has made him have no team affinity, because team affinity seems to be accomplished merely by being all together in the same spot and hence all getting agro at the same time. This change has BROKEN the agro mechanic when MM heroes are used, and it's a very clear bug.

To fix this without treading on the toes of people who hate minions, I recommend adding a checkbox to control whether a player wishes her MM heroes to separate automatically from the rest of the team. Whether or not such a user control is provided, the failure of team affinity on agro needs to be fixed anyway. Even if the MM hero and his minions are out of agro range having a private party, the hero should immediately rush forward and join battle when he senses team agro. Note however that just this agro fix alone isn't really enough, because the laggy minions will not be getting early agro and so will not be doing a good job of blocking foes. It would still need micro-management to keep the MM hero together with the team, which is why a checkbox to disable separation is quite important. This has been a big issue for me over the years, and a source of much frustration ever since the update.

Show the ranger pet's experience bar[edit]

The heading says it all. When leveling a pet, it's very annoying to not see its experience bar because there is no feedback for the progress being made. The grind itself is a bad experience (like all grinding), but not seeing the bar grow as a small reward just makes it worse. It can disappear again at level 20.

Don't lose map travel paths on reconnect[edit]

Currently the character's red dotted travel path on the mission and world maps disappears when you suffer a disconnection and then reconnect. This is very unfriendly, particularly when trying to do cartography or vanquishing the area. I suggest recording the dot positions locally on the client computer, and remarking the maps with this data after reconnection.

Allow the Mission Map to be saved[edit]

It would be very useful to be able to save the mission map with its red dotted travel paths as an image file on the client machine, for future reference by all characters on the account.

Don't forget mapped areas of underground maps[edit]

Having to rediscover the map details of caves, dungeons and other underground areas each time that you visit them serves no gaming purpose whatsoever and is annoying, to the detriment of the game. Since these areas do not contribute to cartography, there may be no history stored server-side to implement this, but if this is the case then at least record the data client-side. This is good enough, as those who value that map information will look after it.

Return To Previous Town, from GToB and EB[edit]

It's one of the more irritating aspects of the Grand Temple of Balthazar and of Embark Beach that you cannot return directly to your previous town as an implicit destination, like you can from the Guild Hall. This is a totally unnecessary limitation. It adds hassle and travel time as you travel via other towns to return to where you were, and it may even break up your team if it contains more than 4 or 6 members and you have to travel via Kamadan or Lion's Arch. Losing the team setup is so annoying that sometimes Embark Beach is used as an intermediate destination merely to avoid travel via non-8-man towns. Much of the problem would disappear if GToB and EB provided a "Return To Previous Town" option in the map Travel menu. This would be easy to implement since the client certainly knows where you were last.

Going beyond this particular problem with GToB and EB, if clients held the names of towns you visit in a tree structure, you could select "Return To Previous Town" from absolutely anywhere, including GToB and EB, which would make travel much more flexible generally.

From a server-side perspective, it's worth noting that all this unnecessary travel via intermediate towns is not only an extra hassle for players, but also creates an increased load on server resources. If designers have no interest in making the player's travel easier, they should at least be swayed by a desire for good design which doesn't waste company resources! (Hint hint. :P)

Improve user choice for WiK and WoC[edit]

Winds of Change is causing much hardship for players by modifying spawns in regular Cantha areas to elite WoC power and providing no means of temporary opt-out. This prevents WoC characters from engaging in normal Factions activity in those zones, helping other players complete quests, or simply opting to re-live classic Cantha. This is very much to the detriment of the game and of player choice and fun.

I suggest the following changes to address the problem. This applies as much to WiK as to WoC, but it is much more important in the case of WoC because of the overwhelming power of the WoC spawns.

Each of these storylines (WiK, WoC, etc) should appear as a primary quest in the Quests window. which can be abandoned at will when in a town. Abandoning one of these primary quests disables their corresponding spawns from appearing in the zones affected, so the areas revert to classic mode. The storylines cannot be advanced without their corresponding primary quests present.

Then, when a character wishes to advance a particular storyline, the appropriate NPC in some city is approached and the player clicks on the NPC's option "Remind me, what was the problem here?". After being explained the local troubles, the player is offered the primary quest again and is back on track at where the storyline was left off. Very easy to arrange from a player perspective.

From an implementation perspective, this should be quite straightforward to achieve because all zones are already instanced and parametrized by storyline state. A character's position in the storyline is already saved, so using that state data can be optional, enabled and disabled at any time. It's just a matter of loading the state or not when entering a zone where it applies, and that can be made conditional on whether the relevant primary quest is active or not.

Such user choice would be immensely helpful to players. Many characters are currently compromised and cannot be used for normal campaign activities because their WoC storylines are in progress, which can be a cause of distress and is at the very least not helpful nor fun.

This has become my first official suggestion: Morg-01::Improve user choice for WiK and WoC

Improve and simplify Templates Manager rename[edit]

The Rename option in the Templates Manager window is currently implemented in a way that is quite unhelpful and inflexible, and at the same time the design has complicated the code by using an additional popup box. This suggestion increases usability while at the same time eliminating unnecessary graphics code. (Simplifying the client is always a benefit for large codebases like this one.)

Firstly, identifying the problem areas: (i) The Rename Template text entry box is not pre-populated with the old name, so a lot of retyping is required instead of just an edit when long descriptive names are given to builds. (ii) The rename text entry box is narrow and is not resizeable, so trying to rename builds that have long descriptive names is like keyhole surgery, and very unfriendly. (iii) The popup box is modal and disables everything else in the UI --- modality reduces the usability of an interface and should be avoided if at all possible. (iv) Yet another popup box is an unnecessary complication.

This suggestion is simply to reuse the Save to Skills Template window for the Rename window, with the Save-related buttons being replaced by those for Rename. This approach has the following benefits:

The Save window already provides a suitable text entry box.
The text entry box already has the required width for your template names and is resizeable.
The Save window already pre-populates the entry box with the old name ready for editing.
No extra popup window is needed, and modality is eliminated.

Summary: Benefits all around. I was quite surprised at the current unhelpful design for Rename.

Add search box to Skill Templates windows[edit]

I have over 2,000 templates in my skills folder, 99% of them my own creations and all of them working reasonably well (I don't store failures). Even though I name the templates very descriptively, including the names of the skills they use, it's a bit of nightmare finding the build I want among that many lines.
It would assist finding templates enormously if a Search box could be added to the windows of the Skill Templates manager (at least the Load and Save windows). Consistent with the way in which Load operates, this would be most helpful if the Search filter brought the matching template lines to the top of the list and shown in bold, while non-matching lines remain below and greyed out.
Others might like more advanced search facilities than simple text matching on template names, but it would be a lot more work and seems unlikely to be be considered for GW1.

Extend the reconnect-after-disconnect time limit[edit]

GW's ability to reconnect after a disconnection is a wonderful feature which recognizes that Internet connections are not guaranteed to be reliable, and it keeps the fun going even when ISPs go down temporarily or backbone routers fail and routes have to reconfigure to use fallback paths. Unfortunately, the 10-minute limit for outages is a bit too restrictive, as many line outages or computer mishaps take longer than this to fix. It would be of benefit to players for this time limit to be extended, as it's so disappointing to lose an ongoing session through no fault of your own.

If there is a worry that this could be abused in teamplay then perhaps add only another 5 minutes, which would still help quite a bit. However, when the player is playing alone with his or her H/H team, then why not extend the maximum period of disconnect time significantly, to cater for really bad outages? Disconnected players are not very common as a proportion of those with currently active sessions, so extending the time limit wouldn't require much extra resource to be held server-side.

I've not yet mentioned a specific time limit which I'd like to see, because there is no "ideal" time limit (unless possibly unlimited time, but I'm not proposing that because it would require server-side session state to be serialized and stored in order not to tie up an active server forever, and it would require that state to be reloadable onto a new server, which is a much harder task to accomplish than simply extending the time limit parameter). Certainly 20-30 minutes to an hour would provide a very helpful recovery time.

Allow game session state to be saved and restored[edit]

The preceding section dealt with short-term interruptions of gameplay caused by problems with connectivity or client crashes. As mentioned in the last paragraph, long-term interruptions or deliberate extended pauses of gameplay cannot be handled in the same way because keeping a server running a session for which the client has no current need is a very bad waste of server-side resources, and should not be expected.

Nevertheless, there are numerous good reasons for pausing gameplay indefinitely as a deliberate choice made by the player, so much so that it is very common for single-player games to provide a game-save facility. GW could provide this too, both for single players with H/H companions, and also for multi-player mode. How to handle the extra complications with multiple players is described below.

Both single and multi-player modes would require the same common machinery: session state would need to be frozen, serialized and stored, and a means would be required for such stored session state to be reloaded onto a server to create a restarted session. This is no simple task, but it's not really rocket science either. Rather, it's just a significant amount of work, which is the main hurdle. Because it requires substantial change to the core infrastructure of the game system, such work is best tackled when new core infrastructure is being developed, and hence GW2 comes to mind.

This facility could be activated simply through selecting a Save Game Session operation from the menu, in PvE combat zones only. (Saving game state makes no sense at all in towns, and probably no sense in PvP battles either, although PvP players should be the judge of that, which I am not.) In multi-player mode, the operation would need to be performed by all players, in the same way that /resign needs to be performed by all players before it is activated. There is no need for any accompanying animation, although everyone lying down to sleep and snoring loudly for a few seconds would be funny. :P

Activating a stored session can be handled in many ways. The mandatory "reconnect to active session or abandon" approach that is appropriate after disconnections is not very useful here, because game saves offer the possibility of deferring the restart an arbitrary length of time, and doing something else in-game first. To make the most of the facility, I suggest that the saved session appear as a large graphic icon in the character select screen above the character slots, with a thumbnail image showing the last captured visual at the time of game save and a title of Resume Saved Game. A player can then just choose a character slot as normal for a brand new game session, or choose the game-save icon to resume the saved session.

Multi-player mode has the additional complication that when the first player of a team resumes a game, the other players are not yet present. This could be handled in at least two different ways:

In the same way as guild scrimmages are started, a timer would begin, and a message Waiting for remaining N players to join would be displayed, where N decreases as more players activate the operation. When all players in the old session have done this, N is zero and the saved game state is loaded. This approach is rather simple, with no corner cases, but it is not very flexible, and to be fair it is really quite player-hostile. Not recommended.
Alternatively, allow just a single player alone to reactivate a saved game session, the other players showing as "disconnected" until they arrive. There should be no reconnect time limit for missing players while the session is active, because the start time of this period of "disconnected" state is not under the control of the missing participants, and hence a time limit would be unfair. (They are not really disconnected anyway ... they just haven't resumed their saved session yet.)

If all the current participants of a resumed game session leave the zone when there are still one or more participants who have not yet resumed the saved session, then the zone session state is again serialized and saved at this time, ready for resumption if the missing participants choose to do so later. This is highly flexible, and fair to all participants. If no player has yet to resume the session, the saved game state can be deleted completely from the servers.

Expiry of saved game sessions is an important consideration, primarily because game updates will often invalidate previously saved game state. This is a matter for game designers to determine. The simplest (but not very friendly) approach is to delete all saved game sessions at every update, but hopefully a less draconian approach could be implemented, such as only delete saved sessions if they contain state which an update in the game code has actually made invalid. A player attempting to resume a saved session that has been deleted should be given a useful message, such as "This saved game session was deleted for reason <invalidated by game update> on <date-of-update>".

Given such a facility, an important question arises: What happens when a player who has paused a game changes their inventory items and then resumes the game? For example, having run out of inventory space, they could pause, sell-up, then resume. How should this situation be handled? There are two opposite alternatives:

Disallow any state-change in a resumed game: On resuming a game, your state is reset to exactly the state at which you paused it, which would maintain the current status quo. This means that if you sold up loot before resuming, it would still appear as present in your inventory (perhaps marked as frozen) so that you do not gain materially from the pause. The same applies to your weapons, armor, and skills: you re-enter the session as you left it. (Any frozen items are deleted when the session is terminated or the game-save is expired.) It's clear that this would be very messy to implement, all for the sake of retaining the status quo.
Allow state-change to a resumed game: This would have a major impact on the nature of the game because it would bypass the current freezing of choices on entry to a fight zone. Although this would be an important change, it is a benign one in the non-competitive PvE game, offering players more options and much flexibility. It would be equivalent to allowing arbitrary change of build while in an instance, but it goes beyond that since a player could resume a game session after obtaining new skills which they did not possess earlier.

Lastly, the above mechanism clearly allows for multiple saved game sessions per account. Although I do not feel strongly about it, perhaps others do. If so then at least one game-save should be available per character in the account, or even multiple saved sessions per character.

Left-click transparency for modified mouse events[edit]

There is a problem in the GW client with mouse events which carry modifiers. This is a little hard to explain (it's aimed at developers who know how graphic clients are implemented), but perhaps an example or two will help illustrate the issue:

Left-click on the H/H party flag button, then left-click on a skill icon in a hero skills bar. The party flag is not planted at the spot on the ground underneath the skill icon. (For that matter, nor is the skill activated, it's disabled.) In contrast, if the second left-click is on the hero's health or energy bars, the flag is planted correctly on the ground underneath it, because planting an H/H flag on a health or energy bar makes no sense so the bars are made correctly transparent. It's a problem of lack of event transparency for a mouse click which carries a semantic state modifier, in this case "Carrying an H/H party flag".

Position the mouse over a skill icon in a hero skills bar, and press-and-hold the right-mouse button. The mouse pointer disappears (correctly, because you're now in camera pan mode and the pointer is not relevant), and moving the mouse (with right-mouse still held down) moves the camera around as expected. But with right-mouse still held down, now press left-mouse. Instead of moving your character forward as happens everywhere else in the scene, left-mouse tries to activate the skill despite being in camera-pan mode and there being no mouse pointer. This is a problem of lack of event transparency for a mouse click which carries a semantic state modifier, in this case the "Camera pan enabled" semantic modifier or the "Holding down right-mouse" low-level modifier.

These are both examples of the client's mouse event handling not being aware of a semantic modifier on the left-click mouse event. Semantic modifiers are common, often for visual feedback employed when the mouse pointer is changed to identify a high-level activity being performed. This is done in the GW client in various places, for example when you mouse-over the inventory window and see the pointer change, which is one of the simplest cases of semantic modifiers affecting mouse operation.

Unfortunately, the semantic modifiers "Carrying an H/H party flag" and "Camera pan enabled" are not being passed to (or are not seen by) the left-click mouse handler, and so this mouse handler acts as if the left-click were unmodified instead of making the skill icon transparent to the action. As a result, an incorrect event is being activated by the upper levels of the client. (An alternative implementation that is also common performs all semantic processing in upper layers and leaves the mouse handler free of semantic state; in this case the bug is in the upper layer event processing as it is not properly dealing with all the possible semantic states. The issue is the same whichever type of implementation is being used by ArenaNet.)

This is a really annoying problem, frequently giving rise to "WTF, these mobs are hitting me and I can't move, what's going on?" . Well, what's going on is that right-mouse was pressed while hovering over a skill icon, which is generally not noticed because it is irrelevant (or should be) where you click right-mouse, since camera pan is not related to screen position as it's always implicitly centered on player position.

Short version: This is an UI bug. The left-mouse event is not discriminating properly between simple left clicks and left clicks modified by semantic conditions.

Make hero items and skills visible out-of-team[edit]

Currently there is a very annoying constraint on access to the weapons, armor and skills held by heroes: they can be accessed only when the heroes are in your team. That is an unnecessary restriction with no gameplay benefit. It only makes life harder for players, requiring first that one team slot be freed up, then a hero added to the team to check its build or access its items, then the hero removed from the team, and finally the real team member added back again. This game of musical chairs is a total pain, and not needed.
I suggest that the hero windows (weapons, armor, skills) for all the heroes you possess be available at all times, even in a fight zone. The only difference in a fight zone is that the windows of heroes who are not in your team cannot be modified, but they are still available for examination.
Note that this does not change the fighting capability of a team at all. It just greatly increases the convenience by removing the game of musical chairs through the limited number of team slots.
Given this facility, it would become possible to have buttons for "Open All Hero Items" and "Open All Hero Skills", at a glance showing every item or every skill bar possessed by all your heroes (a column for every hero, with items or skill bars displayed vertically), making hero item and skillbar reference so much easier.
This would make the perpetual question of "On what hero did I store that item?" a thing of the past.
This would also end the common request "Can you drop a hero please so that I can get something off one of mine?". Such a situation should not be necessary, because there is no inherent reason why your hero must be in your team before you can interact with him or her, just as you can trade with another player without needing them to be in your team. In a full 8-player team it's even worse of course, since getting something off a hero requires a player losing their place, which is totally daft. In a nutshell, this is a failed game mechanic by design, a totally unnecessary abd arbitrary restriction, and it should be fixed.
I know that a significant change like this would not be accepted for GW1 because all important development is on GW2 and the benefit to Anet would be minor, merely removing an in-game annoyance in an old game. However, a future GW2 enhancement may add AI sidekicks, just like Nightfall did quite late in the evolution of GW1. If this were to happen, then I suggest that hero windows be handled more flexibly as outlined here.

Improve target and text colouring[edit]

Colour coding of targets in GW is really unhelpful: almost everything that isn't red is green. This makes it very difficult to pick out unique dropped items, allies that you're meant to heal but which don't appear beneath the group members list (for example the tree singers in Song and Stone), NPCs in general, spirits, minions, and so on. There is no reason why colours should be so limited.

Green unique items probably have to remain green just because of their traditional name, but they could at least be made to flash so that they stand out, or mapped to some other colour. User options are the best approach for this purpose: let the user select the colour of each kind of target in the Options->Interface window.

These target colours should also be used when displaying the names of the corresponding persons or items in the chat window. Dull green for all text is singularly unhelpful.

Remove downarrows from Zaishen Scouts[edit]

The green downarrow displayed above Zaishen Scouts in all zones contributes nothing and is just an annoyance, as it suggests that they are offering quest completion. This NPC offers a service which is not conceptually different to that offered by merchants, Xunlai Agents, crafters and all the rest, none of which have the green downarrow. Remove it for consistency and to reduce annoyance.

Remove repeatedly-required shrine "paperwork"[edit]

How many times have you found yourself already deep in a zone when you suddenly realize that you forgot to get the shrine bounty so half of the benefit from your killing has been wasted? It is a matter of principle that for fun gaming, repeated actions that require no challenge should be reduced or eliminated, as they just add "paperwork" without contributing to the enjoyment. Obtaining shrine bounties is of this nature.
Concrete proposal: If you are in the vicinity of a shrine (close enough for it to register for resurrection purposes) then any bounty offered by the attending NPC should be granted automatically.
Blessings offered by /kneel-summoned avatars of the gods are excluded from this because they require a conscious choice of blessing. This contrasts with the NPCs which offer bounties for Sunspear, Lightbringer, and EotN points which require no user selection. Clicking on one of the latter NPCs should merely provide a storyline explanation of the bounty that was obtained automatically on proximity, but not be required every time as this gets extremely boring fast.

This has become my second official suggestion: Morg-02::Remove repeatedly-required shrine "paperwork"

Offer half reward for NM books after HM threshold[edit]

Unfortunately it happens somewhat frequently that the threshold reputation rank beyond which NM books can no longer be handed in (rank 5 for Lightbringer, rank 8 for the other reputations) is achieved by accident or by not monitoring the ranks (common for new players who don't even realize that there are books), which leaves the player with a useless book and much wasted effort. Sometimes this happens during a ZV or VQ teamed with other players, and if you realize that you're about to hit the HM rank threshold then the only solution is to quit the team, which is socially unacceptable. There should be an alternative.
I suggest that this problem be addressed by allowing NM books to be handed in regardless of your rank, but the reward being reduced when your rank is beyond the HM threshold. It's easy to find lore to match this situation, perhaps something along the lines of "Well this is certainly an impressive record of achievements, but it would have been more impressive for one of lesser standing. (Reduced reward offered.)"

Stop the frenzied re-stacking of target names[edit]

When several foes, allies, or other targets are in the same location, their names are stacked vertically, which is fine. What is not fine is that as soon as one of them disappears or a new one appears, the entire vertical collection of names is re-rendered and the vertical position of any given target name on the screen moves up and down like a demented hopping frog. This causes players an utter nightmare as they to place the mouse on a specific target in a highly dynamic situation.
The above behavior is completely wrong, a very clear implementation bug. Should anyone try to claim that it's "working as designed", then it's a design bug. Either way, it's completely wrong, and surely nobody sensitive to player frustration could desire such bizarre behavior.
There are many ways to implement more player-friendly name stacking. Here are some design principles which are likely to be shared by many of them:

Names rendered in a vertical stack are organized in "slots", each slot having an integer offset with respect to the base of the stack. ("Slot number" is a good term for the offset.)
Once a particular target's name is rendered in a given slot in a name stack, it is always rendered in that slot, and must never be re-ordered. Even if all other targets in that name stack have disappeared, it is still rendered in the same slot it was assigned when it was first rendered.
The stack of slots is rooted at some base position, which is used when there is only one target name to be rendered at this location. The stack can be a normal unidirectional stack (growing either upwards or downwards with respect to its root), or it can be a bidirectional stack (growing both above and below its root). In both cases, the root itself remains fixed.
Once a given target is rendered in a slot above or below the root, it is always rendered in that slot, for as long as the target exists. (Resetting name stacks when they go out of target range is OK.)
When a target disappears permanently from a scene (for example, a foe dies and its resurrection is not possible), its slot in its name stack is vacated. A vacated slot in a stack can be re-used BUT ONLY BY A NEW TARGET appearing in the scene, never by moving an existing target from its current slot into the vacated slot. Furthermore, if slots are reused in this way, there must be a time interval of at least a couple of seconds between successive assignments, to avoid a player trying to click on one target and getting a different and unexpected one instead.
The above set of rules handles well-behaved name stacking for the case of static targets and a static player. To complete the solution requires addressing what happens when different name stacks come together through movement of targets in the scene, or when the player moves and causes names in different name stacks to come together through change of perspective.
The simplest method of handling a dynamic scene in which targets and players move around is to disallow name stack merging. When two name stacks come together (for example, when foe and ally groups join in battle), the names of all participants remain in their respective stacks, and the two stacks are rendered at different vertical screen positions. When an individual target moves away from the rest of its group members, its name is rendered vertically above it, but at the height corresponding to its slot within its own group's stack. Consequently, name stacks never grow, but only vacate their entries as foes die or players disconnect, and the two or more name stacks in the scene cannot interact. This would would work well in GW1 with its small group sizes and limited number of foe groups.
An alternative method is to allow stack splitting and growth by splitting off a target's name from its group stack into a new stack when the target moves more than a certain distance from the other members of its group. ("Distance" here is actually angular separation from the camera's point of view, not 3D distance.) The target's name then occupies the base slot of its new name stack, and other members of its group could do similarly and join this new stack if their position is appropriate. The key behavior which must be preserved is that as long as a target has its name in a given stack, its name will always be rendered in the same slot in that stack, so that there is no frenzy of name re-renderings at different vertical heights. A target leaving one stack would not alter the rendered positions of other names in that stack, and its movement away from its group stack would be very similar to single target name movement as currently implemented.
Finally, for simplicity I described keeping name stacks separate by rendering them at different heights on the screen. In an actual implementation, a more flexible approach should be used: non-overlapping name stacks would more generally be 2D-tiled on the screen, and tiling is a well-known operation so the above methods can be implemented without significant difficulty.

Undoubtedly there are many other possible designs with the same good properties, this is just one. But the current implementation has very poor dynamic behavior, and needs to be replaced by a better one.

Give boss corpses a visible name[edit]

Since the corpses of bosses remain forever in an instance, it would be helpful if they bore a visible name so that one would know immediately which boss died before one arrived there. (This happens quite often in the Jade Sea, for example, where the Outcasts fight most other foes.) Of course it's not hard to determine the name of a dead boss with the help of the wiki, but the game should really stand alone in this respect and be more informative.

Preserve GW1 for posterity[edit]

GW1 will continue as a viable and supported game well into the future after the release of GW2, as ArenaNet has informed the community on many occasions. This is great news, because it's a great game and a treasure in the annals of online gaming. However, one day the business interests of the company will claim that supporting GW1 servers is too costly for the dwindling rate of GW1 sales, and support will stop. When it does stop, it would be a great shame for GW1 to be lost and abandoned in the mists of time.

I would like to propose that GW1 be saved from the demise that commercial products usually suffer when they are end-of-lined. This can be done quite easily by open sourcing the game to the developer community. End-of-lining is unlikely to happen any time soon and therefore the technology of GW1 will be obsolete by the time it does happen, so there should be no competitive secrets left in GW1 by the time support is terminated.

There is significant precedent for this approach to preserving an important gaming legacy. The highly respected id Software open sourced both their DOOM and Quake series of games over a decade ago, and that decision has kept both titles alive for devout fans without any detriment to the company profits. Indeed, the status of id Software and of their lead John Carmack was much boosted by their decision to release the source code for each engine once the code base is 5 years old. It secured their place in the history of gaming for eternity, living games that can still be experienced personally and not just lifeless static descriptions.

The GW community has contributed an immense amount of value to this title, on this wiki among other places. It would be nice to think that, eventually, when there is no longer a financial reason against it, that the title be offered back to the players as a historic landmark worth preserving in community-maintained code, not just in our memories.

Add love interest between Merchant and Xunlai Agent[edit]

The title of this section is intended as a joke. However, there is a serious side to it. In the vast majority of GW towns and outposts, the Merchant and the Xunlai Agent are so far apart that their feelings of utter hatred for each other are very tangible ... or perhaps what has really happened is that ArenaNet recruited a towns layout developer from Sony Online Entertainment, a games company well known for its motto of The Customer Shall Be Made To Suffer.
Seriously, the two most common GW activities when in a town are to visit the Merchant and the Xunlai Chest. Why then are they not right next to each other? Even worse, why are they in most cases on opposite sides of the town? Conspiracy theories aside, some layout designer with GW-wide responsibility has got this extremely wrong.
The official suggestion that would arise from this topic is obvious: "Place Merchants and Xunlai Chests close to each other in every zone." Since such an extensive revision is not going to happen in GW1 because most Anet resources are being dedicated to GW2, let's make this a GW2 recommendation: In every GW2 town or outpost, make it clear that Merchants and Xunlai Agents (or their GW2 equivalents) are madly in love with each other and always within touching distance.
FFS developers, care for your players. Place these two important services side by side.

Indicate presence of pet on relevant skills[edit]

Players with many characters who use pets on some of them, or on some heroes but not all, often find themselves entering a zone with a pet build only to find themselves or their heroes petless. There should be some way to know whether a pet is currently charmed on a character in advance of leaving a town.
I suggest that for those skills which cause your animal companion to travel with you, namely Charm Animal, Comfort Animal (PvE), and Heal as One (PvE), a field be added to the full-length description indicating the species of pet currently charmed by this character, or "none" if no animal companion is currently charmed. (For example, "Current pet: Melandru's Stalker".)

Make the hidden early drop bonus visible[edit]

Certain types of drop for the making of elite hero armor, namely Stolen Sunspear Armor (SSA), Ancient Armor Remnants (AAR), Mysterious Armor Pieces (MAP), Primeval Armor Remnants (PAR), Deldrimor Armor Remnants (DAR) and Cloth of the Brotherhood (COB)), start off with a very high drop rate which then rapidly dwindles to almost nothing until you do better in the corresponding challenge. It is almost impossible to know the state of the early drop bonus unless you keep detailed records of the number of drops received by each character in each challenge.
Keeping records is a total pain and hence generally not done, which leaves the player with uncertainty about the state of drop bonuses across all of her characters. This uncertainty is annoying and unhelpful when trying to armor your heroes for HoM, and it should be remedied by making the game provide a tally of the drops for each character.
There are many possible ways of making the desired information visible, some easier to implement than others, some more informative than others, and some a pain in themselves (for example having to ask an NPC how far the current character has advanced is a pain in itself, involving character switching and travel). For the highest amount of information, least amount of player pain, and smallest amount of work required by developers, I propose the following solution.
Add an account-wide textual command, /elitedrops, which iterates over all the characters of the account and for each character displays the number of special drops received of each type. For example, using the 3-letter codes given in the first paragraph of this section:

Timid Mesmer: SSA 3, AAR 4, MAP 6, PAR 0, DAR 2, COB 1

Love Anguish: SSA 0, AAR 0, MAP 0, PAR 529, DAR 0, COB 0

This very compact form of output requires very little software effort to generate, avoids the unnecessary pain of character switching and travel, and is highly informative. If additional clarity is desired, a heading could describe the meaning of each XXX code.

Fix Special Ops quests reward condition[edit]

Captain Langmar's three "Special Ops" quests (Special Ops: Dragon's Gullet, Special Ops: Flame Temple Corridor and Special Ops: Grendich Courthouse) have an explicit reward of "1,000 Vanguard reputation points" and an implicit reward condition of "if in Hard Mode or with Ebon Vanguard Rank 7 or less". Unfortunately, the condition is not mentioned in the in-game quest information.
When the quest is completed, the message "SUCCESS: 1,000 Ebon Vanguard faction earned" appears in large green letters, but the 1,000 reputation points are silently lost if the condition was not met.
This unfriendly reward mechanic is clearly a bug, in that either the points should be earned when the success message is displayed, or the success message should not be displayed at all. The message should not lie.
Moreover, either the condition itself is a bug and the 1,000 points should be earned regardless of rank as in virtually all other EotN quests, or else the condition is by design but the quest information is missing the very important condition. As it stands, this behavior is very unhelpful because the decrypted message is lost so the quest cannot be restarted.
If the condition is by design, then one solution would be to make Langmar refuse the teleport if anyone in the team is above rank 7 and HM is not set. (Langmar's rejection when the condition is not met could be: "That Charr force is too weak for someone of your reputation, so I'll send some of my younger fighters to deal with it.")
Another possible solution is for Langmar to give the reward on completion of the quest, instead of the reward being given automatically. The quest would then remain in the Quest Log for retaking if the condition was not met the first time. (Langmar's refusal to offer the reward when the condition was not met could be: "My information is that you killed only some young recruits, and the veteran Charr force still remains to be stopped.")
Personally I suggest that the condition be removed altogether and the reward be made unconditional, like most other quest rewards. If a player chooses to save up her Encrypted Charr Battle Plans until she is rank 8 or higher to make obtaining reputation a little easier, that should be just fine, because this is a reward that reduces the EotN grind. Grinding is never good, and is not in the GW spirit as so often stated by ArenaNet staff.

Fix lack of continuity in WoC[edit]

The lack of a Primary Quest for Winds of Change results in many continuity problems. For example, on giving you the reward for completing A Chance Encounter, Miku will tell you to speak to Guardsman Qao in Kaineng Center, the NPC who gives you the followup quest A Favor Returned. Unfortunately there is no record of this link between quests in the Quest Log because WoC has no Primary Quest.
What if the player needed to exit immediately after taking the reward, or her PC crashed, or Miku's advice simply scrolled off the chat window? The result is total loss of continuity within the game. Without checking the wiki for advice, players would be unable to continue the storyline. This is not good at all.
A Primary Quest should be added to Winds of Change, just like there was one for War in Kryta, always detailing the next step to be taken. It's a necessary element for continuity between storyline quests.

Remove 30-day update limit for storybooks[edit]

If a Storybook is not in inventory at the time that one of its tasks is accomplished, an NPC will fill in the missing page for you at a charge of 100g, but only if the task was completed within the last 30-60 days.
This time limit is very player-unfriendly. It adds Grinding to the game, since any tasks which were accomplished further back in time have to be repeated --- what is the merit in that? ArenaNet staff have on many occasions stated that grinding is not something they want in GW.
I propose that the time limit be removed altogether. The 100g price paid for not having the storybook in inventory can be rationalized on the grounds that the freed inventory slot makes room for another drop, but the need to redo tasks has no reasonable justification at all.

Make treasure chests transparent to NPCs[edit]

It happens all too frequently that NPCs which are required to accompany you on a quest get stuck on a badly spawned chest, and the quest then cannot be completed without exiting and reentering the zone. It is not the player's fault that NPC pathing is not clever enough to handle the situation, so this is unacceptable. The player may have played everything perfectly up to that point but cannot prevent the NPC getting stuck, and is being penalized for technical inadequacy in the game mechanics.
As an example of this, The Apostate travels through the Domain of Fear and you're meant to follow him. Unfortunately the ravine through the mountains is a chest spawn point and he can get stuck on it, as happened on a character of mine just now. This does not contribute to fun in the game.
Although the problem could be solved by making NPC path handling more intelligent, the simplest solution by far is to make chests physically transparent to NPCs, so that getting stuck on one just cannot happen to them at all.

Make shrine NPCs transparent to non-players[edit]

This is quite similar to the preceding section. The shrine bounty attendants act as a physical obstacle to quest NPCs, pets and minions, and with great regularity they get stuck between the shrine and the shrine attendant. This has no in-game purpose, and only serves to annoy players when they discover that their quest NPC or pet is greyed out, stuck far behind.
As in the preceding section, this problem could be fixed by making NPC path handling more intelligent, but that is a lot of work. Far easier yet equally effective is just to make the shrine attendant physically transparent (phantom) to the moving NPCs and pets.

Reward or Remove Anniversary Storage[edit]

So many of us have been with GW since launch, support the game wholeheartedly and play it continuously, yet we are rewarded with a disabled 4th Anniversary Storage tab just because we happened to be away for a short period some years ago. This is a very poor way to reward faithful supporters.
It would be nice to get a second chance at obtaining this extra vault pane, but if that is not possible, then at least remove the useless tab completely so that we are not reminded of our misfortune daily.

This has become my 3rd official suggestion: Morg-03::Reward or Remove Anniversary Storage

Improve Drop Quality in Elite Zones[edit]

The elite zones in the game have truly uninspiring drops from ordinary foes, so poor that it's not even noticeable that you're in an elite zone judging by the quality of drops. It shouldn't be this way, it's just not fun.
I suggest that the sheer boredom of drops in elite zones be spiced up a little. There are many ways of doing this, either true improvements like giving them better modifiers or significantly higher merchant value, or else just vanity benefits like nicer skins that don't appear in non-elite zones.
Either type of improvement would help. Currently the drop quality is just sub-par and plain boring, and isn't commensurate with the greater difficulty of fighting in elite zones.

End the Duncan Closed Door Disaster[edit]

The Zaishen Bounty quest for Duncan the Black has just finished, leaving behind it a trail of frustration, wasted time, and tarnished reputations for players who can't count up to 5 and/or are caught lying to their teams. That this is a disaster is not an overstatement --- it is probably the biggest disaster of design in the GW1 game mechanic.
Description of problem: The Last Hierophant is a 5-part quest fought in the EotN elite dungeon Slaver's Exile, the 5th part of which entails killing Duncan the Black. The dungeon is reached by travelling from Umbral Grotto through Verdant Cascades and running into the dungeon portal. Once inside the dungeon, there is either an open portal to Duncan's zone or else a closed door blocking entrance to it --- the door is closed unless every team member has completed the preceding 4 parts of the quest by killing 4 bosses. Completing the first 4 parts draws lines through the names of the first 4 bosses in the quest log for The Last Hierophant, which is commonly referred to as being at "4/5".
Unfortunately, there is no way of knowing whether all team members are at 4/5 until the team has run or fought its way to the dungeon and then sped over to Duncan's door. The sight of a closed door is so frustrating that it is very common for monks to quit at that point. It may have taken half an hour to assemble a team with the right skills for this elite zone, and it's all time and effort wasted and nothing achieved.
To make matters worse, it is not possible to determine which players were not at 4/5, and the guilty parties almost never own up to being at fault. Sometimes the guilty party quits at that point, and the remaining players can exit the dungeon and reenter to prove that the remaining 7 were all at 4/5, but this is only barely helpful since the team is now down to 7/8 and needs to return to Umbral Grotto for an 8th, especially if it was a healer. And on obtaining the 8th, there is no guarantee that the same won't happen again.
Unfortunately it is much more common that more than one player is not at 4/5 and yet they all insist that they are, so nothing can be determined about the truth and the team has to disband completely ... only to suffer the same thing again on the next attempt.
It's beyond a disaster. I've been in teams that have gone through this process 5 or 6 times in a row, wasted 2-3 hours, only to finally disband in utter frustration at the futility of it.
This game mechanic is BROKEN. It needs fixing. There are I believe 66 days to the next Duncan the Black (Zaishen quest). That should be the target date for a fix.
My suggested fix, requiring the least possible amount of developer work:

Add a console text command:

"/duncan"

which writes to group chat a descriptive message such as:

"<player-name> has completed N/5 parts of The Last Hierophant"

The above suggested fix requires no extra graphics, no buttons, no window alterations, no callbacks, and doesn't even have to be conditional on owning EotN. It merely needs to look up "The Last Hierophant" in the active quests list, and if present, identify the number of parts completed. It probably can't get any simpler than this. From my experience of 3D game client programming, it could probably be designed in an hour, implemented in 10 minutes, and QA'd in a day.
From the player's perspective, this would be phenomenal, since team members who do not meet the requirement for entering Duncan the Black's portal can be rejected immediately on joining the team. In fact, they can check themselves even before joining (let the command write to private chat if not in a team).
Please please please do this. The frustration we suffered during the last 24 hours was just dreadful. It was not the mountain of fun that we expect from this great game.

This has become my 4th official suggestion: Morg-04::End the Duncan Closed Door Disaster

Misc Notes[edit]

I'm loving the 7-hero update! This gives me many months of extra tinkering to find new 7-hero teams with the maximum synergy between them. Great stuff! :-)

The BIG question of course is whether GW2 is going to be utterly dreadful because it has removed heroes from the game entirely and replaced them with .... nothing. Such a fantastic game element, thrown out with the bath water, I'm appalled. This is probably the worst design decision Anet has made for GW2, bar none. My forecast: this design choice will make GW2 extremely limited, player-unfriendly, annoying as hell (because random people are often annoying) and a lonely experience. Our heroes were our friends, and they were far better friends than the average pickup team member.