Guild Wars 2 Wiki talk:Projects/Cartography/Archive 4

List of x in y

I came across these while added data to the area pages and wondered what are we doing about these articles? I don't see the point of them, personally, as they don't tell anything new and the pages are very, very cluttered, for example [[List of hearts in Ascalon]]. But at least that article has more use than this seemingly pointless one, List of scouts in Ascalon. I would've stuck a delete tag on both of them but I wanted to make sure others weren't wanting to keep them for whatever reason. — Andrealinia 11:17, 2 October 2012 (UTC)

I was under the impression we were intending to delete them. However, my opinion is this:

• List of hearts in <region> - unnecessary and far too large, seems to be already intended to delete.
• List of hearts in <zone> - possibly useful, but needs massive concision to make the actual articles non-redundant. These are archaic aftermath of pre-BWE documentation where folks thought hearts wouldn't get their own pages, though originally they were the List of hearts in <region> articles they were divided by zone due to the former's size. In short: Might be worth keeping, but needs reformatting
• List of skill challenges in <region> - Fairly redundant though could be useful for searching where skill challenges are throughout a region or particular zone without having to wade through the location table (which shouldn't be an issue). Can keep or delete.
• List of skill challenges in <zone> - redundant with Location sections on zones, no need to keep. Delete.
• List of events in <zone> - redundant with the ==Events== section of zone articles. Seems to be aftermath of the transcribing tables obsession we've culled but haven't cleaned up yet. Delete.
• List of points of interest in <zone> - same as list of events - redundant with zone articles, aftermath of transcription obsession that's been culled, hasn't yet been cleaned up. Delete.
• List of locations in <zone> - same as the two directly above. Delete.
• List of vistas in <zone> - Another aftermath of the transcribing tables obsessions, though a little more helpful. However, unnecessary division with the below lists. Delete.
• List of vistas in <region> - might be useful for those interested in vistas en masse, so potentially keep. Would require tossing the above (vistas in <zone> lists) into these articles since they're currently transcribed in.
• List of waypoints in Blazeridge Steppes - seems to be yet another aftermath of transcribing tables. Unhelpful. Delete.
• List of scouts in <region> - of all list of <map marker> articles, this is perhaps the third most helpful. However, it's still unnecessary as scouts can be completely ignored in the game - they're really just redirector NPCs. I'd rather have the scouts listed in the Locations section of zone articles than these obscure lists. If kept, needs reformatting. Edit: Actually, it seems that the list of hearts also denote the scout for the heart therefore these lists are completely redundant with those lists. Delete.

Konig/talk 12:45, 2 October 2012 (UTC)

I agree with your summarisation, with the exception of the skill challenges cos you seem to have missed out your comment on it :P — Andrealinia 13:03, 2 October 2012 (UTC)

Ack. Fixed. But basically my points are dumbed down to: "in <region>" lists sans scouts and hearts in the Mists can provide useful, however "in <zone>" lists are all pointlessly redundant thus should be deleted. Konig/talk 13:18, 2 October 2012 (UTC)

I'm new to this so I apologize in advance, but where would you want me to put Karma Merchants then? I recently had to travel back to Cursed Shore and talk to every Karma Merchant one by one until I found the item I was looking for. I thought it would have been nice to have a list of Karma Merchants somewhere which I could spin-off into individual merchant pages and the items they offer. — Eidelion 22:32, 5 October 2012 (UTC)

There are literally thousands of karma merchants in the game, making a "List of karma merchants" would be insanely huge and numerous regardless of how you cut it. It's best to leave that to listing them on the individual area pages under the NPCs section, as we're doing. Konig/talk 23:14, 5 October 2012 (UTC)

I guess I was thinking more along the lines of having the lists be zone specific rather than one large list page. From the discussion though it sounded like that was vetoed so I'll start on the areas. (Orr first since that's where I had my issues) — Eidelion 23:39, 5 October 2012 (UTC)

About the renaming

I'm not too fussed but I'd rather just leave it. I've come to recognise this as being "Project Cartography" rather than a project called "Cartography". — Andrealinia 15:42, 2 October 2012 (UTC)

It's the only project with "Project" in its name, which looks odd on the list of projects. It doesn't really bother me either, though. —Dr Ishmael 13:47, 3 October 2012 (UTC)

Haha, well either way - if someone wants to move it they can :) — Andrealinia 07:09, 4 October 2012 (UTC)

Done. Yoshida Keiji (talk) 11:14, 23 October 2012 (UTC)

Denoting levels

Though this was discussed briefly before, I felt the need that this needs to be re-examined. As I've been reformating zone articles it came to my attention that the "effective level" which we use to denote areas' level on zone articles is rather... pointless. Here's why: When you're going to look up an area, you won't be interested in what level you'll be downscaled to. Rather, you'll be interested in the level you need to be to survive in the area. E.g., telling me that Wychmire Swamp downlevels to 16 is completely pointless to me as a level 10. Some areas, such as Shaemoor Fields have a very wide level range (levels 2 through 5), but the "effective level" denoter only states level 5. Does that mean I must be at level five to survive there? No. So why should I care that I can one-shot those Plain Wurm Hatchlings at that lvl 2 heart? Quite simply: I don't, nor will anyone else.
I suggest we denote the levels differently as <lowest level of hearts/events> — <effective level>. E.g., Shaemoor Fields on Queensdale#Locations would have this denoted for the levels: 2 — 5. Opinions? Konig/talk 10:59, 3 October 2012 (UTC)

I have no issues with this. I believe that having the level range of min - max is the most beneficial format. However I believe that – is supposed to be used instead of — when in between numbers. — Andrealinia 12:14, 3 October 2012 (UTC)

I argued against this before, and I will do so again. The only valid "effective level" of an area is the downscaling/DLA level. You can always "survive" an area when 2 or 3 levels below that; immediately after the tutorial you're a level 2 character in a level 4 area, so it should be obvious from the start. Heck, I ran my level 17 ranger through Iron Marches and completed a level 54 heart in Champion's Shield on my way to charming a Juvenile Hawk in Ebbing Heart Run, so you could say I "survived" that whole zone at level 17 (I didn't actually do very much, but I didn't die). A lot of areas don't have any hearts or events at all (Obsidian Run, The Infestation), which means you're going to default to the DLA level anyway.

I would think that "survivability" differs for different players and characters, too. If I take a profession I'm familiar with like warrior and build for tuf/vit and always have rare crafted armor ready for him at each tier, I can probably survive content 5 or 6 levels higher than me, even up in the 20s or 30s. If I instead take an elementalist (that I've hardly played at all) and build for pre/critDmg, I'll probably be barely able to survive content at my level. Furthermore, if I'm running content solo, my survivability goes way down; if I'm running in a zerg, it goes up. In conclusion, I think "survivable level" is too subjective for us to document it. DLA level, on the other hand, is purely objective and should be documented.

One more thing: if we have the DLA level in the infobox but also have heart/event levels listed with them, like on Gunbreach Hills, then it should again be bloody obvious that you don't have to be at the effective level to survive the area. —Dr Ishmael 13:30, 3 October 2012 (UTC)

"but also have heart ... levels listed with them" I don't truly mind one way or the other, but this quote also holds true for the zone pages. The levels of the hearts is also alongside the effective level. — Andrealinia 13:41, 3 October 2012 (UTC)

"The only valid "effective level" of an area is the downscaling/DLA level." True. However, it is not the only valid level. Allow me to elaborate: I wish to rename "effective level" into "levels" and denote the minimum suggested level and the downscaled level.

"You can always "survive" an area when 2 or 3 levels below that; immediately after the tutorial you're a level 2 character in a level 4 area" Technically, you enter in a level 2 area, with downscaling maxing at level 4 or 5 (depending on which zone). And yes, you can survive high levels, if you know how to avoid all combat and damage. That, however, is irrelevant to the suggested level for doing tasks or the level to expect to be able to survive in while fighting.

" A lot of areas don't have any hearts or events at all [...] which means you're going to default to the DLA level anyway." There's more than one means to find out a level of a zone. All enemies are at the shared suggested level of an event or heart or is one above it, with the exception being unique mobs meant to be really easy or really hard and when there's a zerg in the area. For instance Demongrub Pits has no events, but based on the enemies you can tell that the area's level is 16-17 (17 being the downscaled level). But the number of areas like this is fairly small.

"but also have heart ... levels listed with them" Except that not every zone has a heart (and/or skill challenge) to denote the area's lower levels in each area. Furthermore, area pages' infoboxes have been going with suggested level (minimum level of hearts/events/skill challenges/foes) to the downscaling level. Those that I've seen with level denotions at least.

Obviously my terminology was wrong in using survivability leve-oh wait, I didn't use "survivability level" merely "to survive in the area" which you shouldn't try to split hairs with going "lul I can dodge the everything with max tuf/vit armor" - sorry if I sound rude, but your response just came off to me as something a jackass/smartass would respond with. So allow me to use official terminology suggested level (e.g., the level placed in parentheses) as the minimum. Konig/talk 14:36, 3 October 2012 (UTC)

We obviously have different ideas on what this data point should be representing. I see the purpose of listing area levels as simply stating what level you will be downscaled to while in that area, a wholly objective data point. Your purpose of showing what levels are survivable or appropriate for the area is somewhat subjective and is already accomplished by listing the levels of hearts, events, and foes in the article itself, and I don't think that needs to be absorbed into the area's infobox.

No, you didn't specifically say "survivability level", I devised that term that as a simpler way of saying "the level you need to be to survive in the area"; you misinterpreted my quotation marks as quoting you instead of denoting a made-up term. Where is "suggested level" used as an official term? I don't remember seeing that anywhere, but my memory sucks. —Dr Ishmael 15:42, 3 October 2012 (UTC)

Sure, showing the "survivable" or "appropriate" level can be subjective... if that's what I was referring to. Seems you're not getting what I mean. By level of an area, I am talking about the level the area was designed for. That is to say, the level range shown through the parentheses of the heart, event, skill challenge, or personal story - though the latter is irrelevant in this particular discussion, these numbers are all the same. They are the suggested level of the activity. While a skilled player can survive higher level areas, and have an easier time with better equipment, that is irrelevant because they are still below the suggested level.

As to it "being accomplished already" - in a way, yes, in a way, no. Yes, the range of levels is - for most areas - denoted in some manner through the activity or enemy levels, however, this is not universal. Furthermore, restraining ourselves to listing the full level range of an area by these five different places (infobox showing effective, hearts, skill challenges, events, and NPCs) which is, in other words, spreading out the level range across the entire article (and lacking it completely for some places on the zone articles) is detrimental to the purpose of the wiki - to inform the readers - as it is forcing them to look throughout the area article, unable to merely look at the zone article, for the levels they are expected to be at for the area in general, rather than for the activities of it.

Regarding "Suggested level" being an official term - I saw it used some point in the past, regarding specifically the level of personal story steps, though I don't recall the exact placement (most likely from one of the demos). I haven't seen it post-release though. But I never really claimed it was an official term, I'm merely utilizing this as the number in parentheses which denotes the level which the activities are very clearly designed for (for personal stories, they match the downscaled level). Konig/talk 18:52, 3 October 2012 (UTC)

No I'm not understanding what you mean because you seem to have changed what you meant. Initially, you said: "you'll be interested in the level you need to be to survive in the area", which is equivalent with "survivable level". Now you're saying you just want to show the range of levels of things you'll encounter in the area. If that is what you really mean, then fine - I still think it's a pointless summary stat that doesn't really tell me anything I can't already figure out from glancing at the area page. However, I ask that you don't combine it with the effective level, which is a completely distinct data point. —Dr Ishmael 19:24, 3 October 2012 (UTC)

I don't understand how effective level is different? Surely it's just another way of saying "the max level you can be for that area"? — Andrealinia 20:06, 3 October 2012 (UTC)

(Edit conflict) Since trying to elaborate is apparently not getting the point across, and you're hung up on the use of a single word twice, allow me to quote my first comment to show that I never changed what I meant.

"<lowest level of hearts/events> — <effective level>"

What I meant is simply what I've been stating: the expected (or suggested) level(s) of your character. That is to say, the levels the content was designed for. With the downscale as the maximum range. Konig/talk 20:08, 3 October 2012 (UTC)

And as a further example, Gunbreach Hills is levels 2 – 4, with 4 being the effective level and 2 being the lowest level of the content, and Ascalon City Ruins is levels 12 – 14. — Andrealinia 07:08, 4 October 2012 (UTC)

This just doesn't work there's too many factors: effective level, hearts, events in the area, events partially in the area, events that pass through. Notice how only the effective level belongs to an area, the rest belong to hearts and events, where they currently are. If just a little bit of a collecting event's 'ring' is in the area does it count as being in that area? ~~Preau 09:36, 4 October 2012 (UTC)

I don't get why it's so hard? Hearts are always in the same place, events start in a particular area. I doubt that a level 15 event will pass through an area with a level 2 heart, unless that area's an effective level 15, in which case the levels would have been 2 – 15 in the first place. The issue with whether an event is "in" a particular area is kind of separate to this discussion but, for the record, I would only class an event as being "in" a particular area if it starts there. After all, if I'm waiting for a particular event I'm hardly going to want to wait in the area it passes through - I'd want to hang around in the area it starts in. Therefore, each event would only be classed in one area. — Andrealinia 10:36, 4 October 2012 (UTC)

I would argue that the areas of an event depends on where the focus is, rather than where the radius of the ring is. As Andrealinia said, it's a separate discussion, but typically you won't see a major level difference in the event's suggested level and the area's levels - even if it goes through multiple areas. If there is a level difference, that difference is usually gone by the time you enter that radius. At that, it's usually even just 1 or 2 level difference, or is merely passing through and there's no actual fighting there. This is why I'd go after the non-zerg foe levels (unlike in GW1, GW2 foes are always the level of or 1 level off of the expected character level, rarely 2 level difference for the challenging-intended NPCs) - or alternatively to hearts. There really isn't that big of an issue since I don't think any event ever exceeds the effective level, nor goes under the typical suggested level of other activities and foes in the area. Konig/talk 11:20, 4 October 2012 (UTC)

(Reset indent) I remain unconvinced that there is anything useful about showing this level range in the infobox, however you want to define it or whatever you want to call it. You're already having to make judgment calls and assumptions about what you consider to be part of this range ("the exception being unique mobs" / "the areas of an event depends on where the focus is"). Sure, the raw data (event/foe/etc. levels) is all objective, but you're being subjective in how you aggregate it.

Like Preau said, the effective level is the only thing directly linked to an area, everything else has a nebulous relationship with the area it appears in. That's why I think effective level is the only thing we should show in the infobox: it's the only thing that distinctly describes the area, rather than describing content within that area.

Bah, I'm not wasting any more time on this. —Dr Ishmael 14:14, 4 October 2012 (UTC)

"The area where the focus is", So for an escort event that passes through 4 areas where would that be? The start? the end? the area with the most stops for something? There is just no way to define what area an event belongs too if it happens in more than one area. Same for Hearts, often the heart giver is in another area than the main focus of a heart. ~~Preau 17:32, 4 October 2012 (UTC)

You know... going off the reasoning's that both you, Preau, and Ishmael are giving for not listing levels we might as well not bother listing hearts or events on area pages either, because you don't know what area they're in. — Andrealinia 17:46, 4 October 2012 (UTC)

Going off your logic we might as well include dungeon levels, one of the areas in Plains of Ashfors is level 35 right? Hearts dont define the area level, they define the heart level. ~~Preau 18:26, 4 October 2012 (UTC)

Excuse my language, but Preau, now you're just being fucking stupid - and an asshole - with that last one. A dungeon is its own instance, its own location. While the entrance to Ascalonian Catacombs is in Plains of Ashford, none of the level requirements are actually inside Plains of Ashford. That's like arguing that because there is a level 28 personal story step featured in the Queen's Throne Room, that the level-less instance is level 30 irregardless. It's just plain stupidity and not the same situation.

Few escort quests go through areas that is not close to level of said escort event. So it'd count for all of them, but the level of the event will be in all area's ranges. It's that simple, really.

@Ishy: I'm not being subjective, actually. One must realize that there are levels created for zerg events - for example, in Cursed Shore, you'll seldom find a level 79 mob, and you'll seldom find a level 81 or 82 enemy. But they exist naturally. Gather 10 players or more together, and you'll find level 84 enemies solely because there's that many players around. That's what I mean by "unique mobs". By the "focus" of an event, I mean where the event actually takes place, rather than where one can see the event happening. For instance, from [{Godslost Swamp]], you will be able to see the event Drive back Underworld creatures by destroying portals in the monastery active - similarly, from the Eldvin Monastery, you'll see Defeat the shadow behemoth active. However, doing things in the areas do not affect the respectively mentioned events at all. This kind of scenario is what I meant. Clearly you're not understanding my words, deciding to split hairs unnecessarily, are just that idiotic (which I know from past experience of dealing with you, you are not), or are too damn stubborn to change things. I don't really care which, but please stop arguing as if I'm saying something I'm not just because of my word choice - my meaning is pretty damn clear. Konig/talk 18:41, 4 October 2012 (UTC)

Still there's no area defined by the game for events that span multiple ones. That means we would be making up data. As I've asked before which one are you going to pick for escort quests. ~~Preau 18:48, 4 October 2012 (UTC)

(Edit conflict) God, why am I even here, I said I wasn't wasting any more time on this...

@Andrea: I never said that. Hearts are listed by the area that the NPC is standing in. Events are listed by where they start or end. That's great, that's logical, I have no problem with that.

@Konig: I never said anything like that about events either. Anet set things up so you can "see" events from a distance, that's how you know they're happening, but the event itself only happens in a small, well-defined space.

If you want me to stop twisting your words, you could at least show me the same respect by not putting words in my mouth. I know this is pointless, but let me state my case one final time. The downscaled/effective/DLA level is a direct property of the area. The suggested level of an event/heart/etc. or the level of an NPC is not a direct property of an area, it is the property of a thing that appears in that area. Combining a direct property with derived/secondary properties is not a proper means of displaying data. That's all I'm saying. —Dr Ishmael 18:58, 4 October 2012 (UTC)

@Preau: Why pick one? Why can't escort events that go through multiple areas count for each area? The event will always be in that area's level range after all.

@Ishy:"I never said anything like that about events" You did in the claim that I'm being subjective, by quoting a line I said regarding events.

"the property of a thing that appears in that area" which is, in turn, a direct property of the area (the "thing" that appears in said area, that is). Therefore, by logical deduction, the level of the "thing" that is in the area is thus a property of the area. It affects what level an average player should expect to see and be at in a given area. Whereas the downscaled level is merely what one would be pushed down to and thus hardly relevant to the intended audience of the wiki. Konig/talk 20:29, 4 October 2012 (UTC)

I fucking give up. You refuse to realize that a direct property is different from a derived property. —Dr Ishmael 20:49, 4 October 2012 (UTC)

I don't want to see this derail into an argument which it is in danger of doing so please, if you are a bit annoyed and reading this, nothing is meant to be offensive or argumentative.

I hope we can gree that it is very rare events or hearts will appear in an area that is above the effective level. If one were to assume that nothing does (because it is rare that events or hearts do) then it could be stipulated that the effective level is just another way of saying the maximum level of an area. In such a case it could be said that it is beneficial, to the average wiki user, to know the minimum level of an area as well as the maximum. Consider the following scenario: Bob just created a character. He's got to level 10 and is looking for somewhere interesting to go by browsing the wiki. He wants a level appropriate area but also wants a challenge. He goes to the Plains of Ashford page and looks down the list, automatically excluding anything below Loreclaw Expanse because the maximum level is 13. What Bob just missed was the fact that both Ascalon Basin and Ascalon City Ruins have level 11 and 12 content. One of those said areas has an entrance to a jumping puzzle that Bob would have loved to have done but thought he was still too low level to do (because the only level shown was the maximum level). Instead he picks Devast District and was really disappointed because it wasn't challenging enough. With the new system Bob would have considered Ascalon Basin, done the jumping puzzle, thoroughly enjoyed himself on guild wars 2 and come back to the wiki for his next exploration adventure. ^_^ — Andrealinia 22:05, 4 October 2012 (UTC)

I actually do not get the argument at all. The is the level you get from dynamic level adjustment and that one we can document, because we see to which level our character gets adjusted. But a survivable level is nothing you can get into hard data. My level 14 guardian walked around in thie Brisban Wildlands just fine, my engineer hadn't survived a minute trying this. It could be that the guardian is better than the engineer or that I became better with the time and my guardian is my second character, anyway do we write in this article that level 14 is just fine for the Brisban Wildlands that sounds silly to me becau it is called a level 15-25 location. But perhaps I did misunderstand something. - Yandere 22:22, 4 October 2012 (UTC)

You don't get it either. Effective level is a direct property of an area. The level range of the content in that area is a derived property of the area. They should be documented separately. That is all. —Dr Ishmael 22:42, 4 October 2012 (UTC)

@Yandere: It's not about survivability. It's the level denoted in parentheses of hearts, skill challenges, and events that I'm talking about. Konig/talk 23:16, 4 October 2012 (UTC)

Ok... What is wrong with the level denoted in parentheses? This is pretty much where this information belongs, because it ia a property of the heart to have a level. - Yandere 23:19, 4 October 2012 (UTC)

Because we shouldn't force someone to look all over an area article to find the level range said area is designed for (regardless of being able to survive there or not), and IMHO, denoting the effective level is of no help (regardless of whether or not it's a "direct property" or not) since once that's in effect there's not really any interest in it. Konig/talk 23:24, 4 October 2012 (UTC)

The effective level is a good benchmark for survivability, when I am scaled down everything is fine. When I am not scaled down I should start thinking where to go and if the area is survivable. At least this is how I have played the game until now. So if I get past the first 15 level or so, I am most of the time leveled down and am not really concerned with beingo low level. the effective level is more or less the only interesting level information at least for me. - Yandere 23:51, 4 October 2012 (UTC)

Can't we have both on pages? Knowing what level I'm (possibly) going to be downleveled to, as well as what level of content is around are both helpful information, in different ways. Manifold 23:57, 4 October 2012 (UTC)

I proposed that compromise above (19:24, 3 October 2012), but it seems to have been ignored in the larger argument. —Dr Ishmael 23:59, 4 October 2012 (UTC)

(reset) So basiclly just put an extra column there with the title survivability level? - Yandere 00:09, 5 October 2012 (UTC)

I'm really confused why having "Levels: 2 – 4" or "Levels: 15 – 25" isn't a compromise.... because the 4 or the 25 is the effective level. So you're showing the effective level and showing the level of the content all in one. Please take a second to look at Gunbreach Hills. Look at the infobox, where it says "Levels: 2 – 4" all that's being proposed is going to the zone page Plains of Ashford and changing the column "Effective Levels" to "Levels" and changing (in this example) the Gunbreach Hills table cell from "4" to "2 – 4". It seems so silly to have a new table column. Hell change the header if you want to "Min Level – Effective Level" but even that seems like overkill. — Andrealinia 07:45, 5 October 2012 (UTC)

From what I surmise, the effective level is the level you will get downscaled to in an area. As for a suggested level, areas are designed so you play content a couple levels below the effective level. Most enemies are a couple levels below the effective level unless they get scaled up. The relevance of the level values in hearts and events come into play if you're too low a level to complete them. You can play through (almost) any content in a zone if you're with in the zone's level range. I've been pretty running through content 7-8 levels above my level, so I'm not sure what a level range is suppose to denote.--Relyk 08:39, 5 October 2012 (UTC)

Like Andrealinia said, I fail to see how denoting the level range isn't a compromise. People seem to think that I want to remove the effective level from articles - I don't. That's just the max range. What I want is effectively to denote what both the suggested level (or rather, the lowest suggested level) to the effective level of an area. A level range.

As an example, Shaemoor Fields would be denoted on Queensdale as being levels 2-5, rather than level 5. 5 is the effective level, where it's denoted currently - 2 is the lowest content level for the area. In the case of escort events, they affect all areas they pass through, because they're always within that level range. For instance Escort the trading post caravan to Claypool starts in Altar Brook Vale and passes through The Heartwoods (the event itself stops prior to reaching Township of Claypool if I recall correctly), therefore Altar Brook Vale would be 7-8 (or w/e the effective level is, since its not denoted) as its heart and the escort event are both level 7 but there's another event that's level 8; The Hearthoods would be 7-10 (or w/e the effective level is) as there's a level 10 event there as well.

Despite the arguments, it's actually quite easy and quite objective for how to denote a minimum level and maximum level. Despite recent comments, I have ALWAYS wanted both denoted. Konig/talk 10:26, 5 October 2012 (UTC)

"I've been pretty running through content 7-8 levels above my level, so I'm not sure what a level range is suppose to denote." Anyone can run through an area, but completing an area is different and this is what the level range would help show. — Andrealinia 11:40, 5 October 2012 (UTC)

Combining them isn't a compromise because it conflates them into the same thing, which they aren't. People aren't going to understand the "Min level – Effective level" convention unless you make that the column header or the label in the infobox, which is indeed overkill. —Dr Ishmael 12:50, 5 October 2012 (UTC)

But people will understand what "Levels" (what the column header and label in the infobox will be and is for the latter) means. And that's what we're denoting - the level range of the content of the area. I am really not able to comprehend how you're so against this. It's the same damn thing as saying that Queensdale, on a whole, is level 1-17 content, or that Brisban Wildlands is 15-26 (yes, there is a level 26 area there, despite the map's connotation). Konig/talk 14:35, 5 October 2012 (UTC)

I just want to add that I read somewhere (but can't remember where) that on this wiki points of view should be back with reasoning to get your point across. This is what myself and Konig have done to help you understand why we support this change. However to all of you against the change, I respect your personal opinions, but all I can see is it being said "You can't do that" or "You shouldn't do that" and no reason why other than "it won't be understood" which, to be honest, is very silly to say. I don't know how anyone looks at "Levels: 2 – 5" and sees anything other than "This area is designed for levels 2 – 5". — Andrealinia 14:55, 5 October 2012 (UTC)

Running through was suppose to mean completing the area, sorry if this somehow implied different. You can still play the content below the minimum level of the content in the area. Level range of content in an area can be inferred from the renown hearts and NPCs, it's not important information to players actually completing the content. As long as you are within the level range of the zone, the level range of any area is irrelevant. You can be level 15 and complete level 25 content. I'm not quite sure if its possible to get credit for events (at or) above 10 levels for events. The level range isn't a fixed number, it would just be a suggestion inferred by players using information from the game; you aren't required to be within that level range to complete content in the area and listing a range would imply otherwise.--Relyk 23:44, 5 October 2012 (UTC)

Thank you Relyk, for providing an argument against that actually makes sense and has reasoning to it. Personally I'm now on the fence about the matter. I think it would be nice to have but I do see that it could imply something that isn't true. If both is wanted a compromise could be having "Content Levels" and "Effective Level" — Andrealinia 10:38, 6 October 2012 (UTC)

"As long as you are within the level range of the zone, the level range of any area is irrelevant." By this argument, I propose we remove the level column from zone articles and, in turn, refuse to denote levels on area articles' infobox. Since the information is already on the page strewn across everywhere, it is clearly not important enough to denote the level you'll be downscaled to either, since you can complete content at any level it seems.

To be serious though, I disagree with you Rylek, that so long as your in the zone's level range it doesn't matter. The average player will not be able to complete level 25 content at level 15, or level 15 content at level 2. Not solo, at least. You can join a zerg, certainly, but we shouldn't cater to that kind of scenario. During the BWE, as a guardian who has good survivability, I was being defeated a multitude of times in level 23 content at level 14 - with 3 others around that were the content's level (20-25 range). If you're one of the players who are alone in the area, you may be able to complete hearts and events that don't require fighting, but you will not be able to fight mobs without a lot of difficulty.

On the other hand, we denote effective levels already, which once you're at is 100% irrelevant. It really doesn't matter what the effective level of an area in Queensdale is once you're level 15, or of Brisban once you're 25, or anywhere once you're 80. It's far less helpful than denoting the range of intended content in a single place (<---main point right there) than only denoting the effective level and having the rest strewn about multiple pages. The wiki is meant to inform players, not make it a task to find the information helpful to you. Konig/talk 12:18, 6 October 2012 (UTC)

My only crunsh with the x-y annotation is that it implies a relation between the two numbers whe there is none. It is simple to imagin an area where the minimum level of events and hearts is 24 and the effective level is 22 so it would be 24-22 which is totally correct. Usually the dash implies something like x<y and here I see a problem, the implication is I think always true at the moment but this can change any time. We have at least one 80-80 area where the effective and the minimum level are equal and must be stated as 80-80 for consitencies sake.

I am not opposed to list the first number but I think it gives a wrong implication in what relation thi stands to the effective level which is in fact independent from the first one. - Yandere 10:59, 7 October 2012 (UTC)

Except that there is never a case where the effective level is lower than anything else in the area (except buffed foes formed from zergs). At best, the effective level is the same as the highest heart/event level. I do not think that an area which has one level throughout requires x-x over just simply x. E.g., I would list Aurora's Remains as 26, not 26-26. There's no need for "consistency's sake" in regards to having two numbers. The minimum level isn't really independent given that the effective level is either the maximum level of content, or just above it. Your two worries are, imo, unnecessary as the first is a non-existing situation and the latter is merely preference. Konig/talk 12:07, 7 October 2012 (UTC)

I just wanted to point out that isn't hard to imagine. Of course, there is no such a case in the game. The problem I have is this: There is no dependence of the two numbers implied, just because "there isn't such a case". We can only gather data and present them. To present a implication which isn't given in the game is problemtic in my book. Heck I wouldn'T mind to present three numbers: the minimum event level, the maximum event level and the effectiv level; perhaps like this: x-y (z). I will agree with you that the is arelation between x and y but I see no imidate relation between x and z nor y and z. - Yandere 12:32, 7 October 2012 (UTC)

But... that never happens and it never will if you think about it logically. The level of events is meant to be the level the designers want you to be. To make the effective level beneath such would be the same as saying "this is content we don't want you to complete" at which point they might as well do the same as they do at Fort Vandal - stuff it to the brim with level 80 champions in a level 24 area. Unless it's intentionally uncompletable content, it will never happen (with events). Konig/talk 14:18, 7 October 2012 (UTC)

It is quite common to see monster two level above you in the personal story. And the personal story also has an effective level attached, which is called recommended level for some strange reason. But they want you to finish the personal story. So perhaps they will bring hearts in some expentions follow that logic. They are ment to be finished but ty are also ment to be hard. I mean Orr is more or less designed to annoy you, if they included hearts there I am pretty sure they would follow such a logic. Perhaps the center of the crystal desert for example. As I said it implies something which isn't 100% true. - Yandere 16:37, 7 October 2012 (UTC)

Monster level != event/heart/personal story level. There's a vast difference, as you'll never see a personal story that's a higher level then they intend you to be (e.g., there will never be a level 81 personal story level until the cap is raised). Monster levels is another matter entirely, especially since they're flexible in regards to going up. Konig/talk 17:28, 7 October 2012 (UTC)

And that is EXACTLY the same argument we're using: effective level != event/heart/personal story level. But for some reason you don't consider that one valid. —Dr Ishmael 18:50, 7 October 2012 (UTC)

Except that it's not the same argument. Within a single area, effective level remain constant. Within a single area, event and heart levels remain constant. Enemy levels, however, only have a constant minimum - they will increase as more players gather. This is why I said to use event and heart levels, rather than monster levels. Enemy levels would only be used if and only if there are no hearts or events in the area, and only utilizing the average normal (read:not affected by a large number of players) level of said enemies in said area.

While yes, effective levels are not event/heart levels, both levels are stable and constant', whereas that is not the case of monsters which can and do exceed the effective level. Konig/talk 22:03, 7 October 2012 (UTC)

Monsters still scale up without changing level, especially bosses like the Fire Elemental and dragon champions. As far as minimum/maximum monster level and effective level, the difference is never more than 2-3 for an area. If someone is looking at an area, they should know that if the effective level is 8-10 levels above there level, it's going to be a bad day. After all, any enemy above your level gets a red name, purple for 10+. I don't think that information is helpful for new players as it's going to be just as hard at level 22 as it is at level 24 from their current level. The difference just isn't worth noting until getting up to a difference of 6-8. If I can completely ignore the level range for completing the content, knowing that the difficulty of the area will correspond with the effective level (the level the area was designed for), I don't consider that relevant enough for anyone looking for information about an area. If players want information on what level they should be before entering an area, that would be more appropriate to elaborate on in the dynamic level adjustment article.--Relyk 19:35, 9 October 2012 (UTC)

I would hope to see the effective level, or the effective level minus 2, just because it is easy to compute and does not require compiling the various heart and event levels. I am wary of how accurate event levels are, or whether they properly reflect the area level. Jimmgrogan

In the article on Experience, it notes that experience gained by points of interest and vistas is directly related to the level of the area. That means we can know the level of the area by finding the experience gained by discovering a point of interest. Jimmgrogan

Area boundaries

Bloodtide Coast map with area boundaries

For your consideration. I plan on creating a map like this for all zones, and even if we don't want them as the primary map on zone articles, they can go somewhere else. I already have the screenshots I need for the 45+ zones (and I'm starting to re-explore the low-level zones on other characters), but since they take me a while to make I'd like to get feedback on this before continuing. —Dr Ishmael 23:28, 13 October 2012 (UTC)

I think this is a good idea and wouldn't be against using this as the main image (either replacing the current maps or as new ones - though I think we should get some clean maps in the future) - it is certainly better than having 2 map images in the infobox as Bloodtide Coast currently has. Just a note - we have a "cheat sheet" for Harathi Hinterlands, Lion's Arch, Timberline Falls, and Fireheart Rise, before you go and work on them from scratch. Konig/talk 02:46, 14 October 2012 (UTC)

I think they are very nice the white lines are not as intrusive as those on the "cheat sheet". I think it would be a good idea to put tse on the main articles. I think there would be a great synergy between the location table and these maps. - Yandere 06:16, 14 October 2012 (UTC)

I also really like this, I love the basic approach to it instead of the overwhelming look of the 'cheat sheet' ones. — Andrealinia 07:38, 15 October 2012 (UTC)

Very nice, this one is actually readable as opposed to the so-called "cheat sheets". I'm wondering though, what is your method for obtaining these lines? Because some areas have very unexpected borders. ~~Preau 10:37, 15 October 2012 (UTC)

"Map of Bloodtide Coast with area boundaries drawn in. Boundaries determined by taking screenshots of each area as they were discovered." That's what Dr Ishmael wrote when he put the image up :) — Andrealinia 11:56, 15 October 2012 (UTC)

In more detail: as I explored the zone, I took a screenshot of the map immediately after discovering each area. I progressively composited these images in GIMP, one area at a time, drawing a line around the edge of the area before adding the next area's image(s). The lines are as accurate as I could make them, although I did fudge them slightly in a couple places where a marker was really close to the edge in order to make it obvious which side it was on (Stormbluff Waypoint is the only one I can remember, now).

The "unexpected" borders are precisely the reason why I wanted to do this, so that people aren't confused as to why, for example, Breekeelee is in Sanguine Bay and not Laughing Gull Island, which, if you didn't know the boundaries, wouldn't make sense. —Dr Ishmael 12:52, 15 October 2012 (UTC)

Sounds like a great way to do it, definitely the best option as picture for each explorable zone. ~~Preau 21:55, 17 October 2012 (UTC)

(Reset indent) Ooh, here's a question: should I be in the zone when I take screenshots for the base map, or not? The only good thing I can think of is that NPC icons appear when you are in the zone. However, this could also be a bad thing - NPCs can move around, and the icons follow, so I may not capture them in their normal positions. Also, a lot of NPCs are tied to events, so I wouldn't be able to capture all of those. Third, being in the zone also makes event indicators show up, and depending on the event, I may have to wait a long time for it to finish. Last, since I have yet to complete Arah story mode, my personal story icon appears at the nearest portal out of the zone. So I guess I'll start off doing out-of-zone maps (which is what I did for Bloodtide), and if anyone really wants to see the NPC icons, I can always replace the base layer. —Dr Ishmael 23:13, 17 October 2012 (UTC)

I'd generally say no, because then you'll also include the player cursor, any party members (including pets, minions, etc.), nearby events, and personal story markers. Furthermore, some NPC icons only show up within a certain radius, so you'd need to make multiple images to get them all if that were your goal. Though this is personal opinion, I don't think vendor NPCs are important enough. Maybe for area maps (and include resource nodes on those), but not zone maps. Konig/talk 23:21, 17 October 2012 (UTC)

I'm already using uMod to remove most of the "decoration" from the map, including the cloud layer (FINALLY found those textures today!) and the player cursor. I could extend it to event markers, but that would require on-the-fly adaptation as I encounter new events with markers I haven't seen before. (Dammit, I could also get the personal story marker, why didn't I think of that before?) But I agree with you, NPCs aren't important enough for the zone map. —Dr Ishmael 23:51, 17 October 2012 (UTC)

Borderlands and battlegrounds

The 3 borderlands and the eternal battlegrounds are also explorable zones, which is why I would like to add them to the nav. Obiviously the effective level coloum is unnecessary because you are always scalled up to level 80
The borderlands have basicly an identical geography and have many things in common. That is why I like this article so much: Borderlands. The the greatest diffrence between the ((Blue World)) Borderlands, ((Green World)) Borderlands and ((Red World)) Borderlands are the skill challenges. It is always one commune, one eat and one fight, but they are circled around on the maps. Even the vista cinematics is identical on all three maps. So how do we wanna aproach the borderlands pages?
The Eternal Battlegrounds aren't problematic. I just think the (Red World) notation isn't really that great, but that is just me. - Yandere 06:39, 14 October 2012 (UTC)

I would prefer keeping the Borderlands as separate articles, as the location names are all different even if aesthetically they're all the same. And as you said the skill challenges also differ.

The ((Red World)) and whatnot comes from the BWE, when those were the names. Thing is, (()) seems to be used for unfinished text in development (there was a charr bartender unfinished in the same style), so that's probably what the case was then. However, now, there's no way other than using this during-development naming in order to differenciate the three areas. There's enough of a difference, especially given the fact that to the map completion they are three different locations, to mandate separate articles IMO.

As to considering them explorable zones - I'm on the fence for this. The explorable zone nav is mainly used for PvE, and IMO should stay for PvE. It'll also help keep bloating it down. However, we run into the issue with the WvW areas being needed for map completion and thus they would then fit onto said nav. Don't matter much either way so I'll go with majority there. Konig/talk 06:35, 15 October 2012 (UTC)

The biggest difference is the fact the areas have different names in each zone. I'd put a separate block in the nav labeled WvW, and label the PvE portion PvE, Explorable zones, Zones, Tyria, or equivalent.--Relyk 22:31, 17 October 2012 (UTC)

The ((Red World)) thing. I assumed that there is something like this, but I would shorten this to Red World Borderlands or just Red Borderlands. The parenthesis just look odd. When I remember correctly the jumping puzzles there had names like Ruby Sanctum etc. so we could also call these Ruby Borderlands, which would definitly be my favored. My point is, nobody will search for ((Red World)) Borderlands. You will always reach these aritcle by link, so you could give them a better name. And imo everything is an improvement.

On the nav issue: I put everything which is needed from map completion with the exception of the cantry onto one nav. Look for yourself, if you like it or not: User:Yandere/Template Sandbox. I think it is not relly worse than the old one, but as Konig said the old one was pretty bloated, so that's not saying much. - Yandere 00:09, 18 October 2012 (UTC)

I'm liking Yandere's template for the navigation. Looks a lot more organised with it being less cramped. 178.78.64.132 00:23, 18 October 2012 (UTC)

I don't really like the table format, with the individual entries organized by row/column. It implies a record/field relationship that doesn't exist: Black Citadel, Queensdale, and Eternal Battlegrounds have nothing in common. What was wrong with the simple inline-bulleted lists? If the box itself is too narrow, we can make it wider (would require updating Common.css, but we can do it). —Dr Ishmael 00:46, 18 October 2012 (UTC)

I totally see you point, that was something I wasn't really happy about. The main reason I choose the table was indeed th width. As I added the WvW zones and the cities to tha nav just to see how it looks I realized, that the nav would become to tall and looked really cluttered. That's why I went for the table format were I could put every "region" in one row without a break. Yeah, Cities are not really a region. I am pretty tired. I hope I am writing somewhat cohesive stuff. - Yandere 01:03, 18 October 2012 (UTC)

In game, I see people referring to the borderlands either by who owns it, or simply "Red Borderlands" "Blue Borderlands" etc. Renaming after the jumping puzzle - that's just as unlikely to get searched as ((Red World)), especially in the case of Sapphire and Emerald - the word "World" is also unnecessary. I'd just move them to Red Borderlands, Blue Borderlands, and Green Borderlands.

As to the suggested nav bar... I don't like it. At all. It feels like there's no true order to it - it just feels like a list of locations. Furthermore, cities don't really need to be in the same nav bar (it was actually discussed a while back to keep them separated because they're functionally different, though this was before map completion, and to help reduce the size). I would much prefer to keep cities in their own nav, and do the same for WvW areas (maybe all PvP areas can go into a single nav?). Konig/talk 01:38, 18 October 2012 (UTC)

Maybe have a "related" line at the bottom of the nav that links to things like City, World versus World, Map completion, etc.? I remembering using a line like that in a number of navboxes on GuildWiki. —Dr Ishmael 01:48, 18 October 2012 (UTC)

That could work, depending on how it's formatted. Konig/talk 01:49, 18 October 2012 (UTC)

Yep, that's a nice suggestion. I am all in for that. I will go and build a nav for the world vs world location.

One question on this point. It seems to me as we have a consens on the boraderlands naming? - Yandere 07:04, 18 October 2012 (UTC)

I made the Template:Mists nav. I think it works well. - Yandere 08:13, 18 October 2012 (UTC)

I like the navigation bar. It seems to be straightforward and simple to use as well as on par style wise with all the other nav bars that I've seen. — Andrealinia 12:58, 18 October 2012 (UTC)

Hurray for standardization

I just wanted to say that all explorable zones, pvp zones and cities now have a location table. Some are extremly empty and have to be filled with information, but at least they are there and ready to be used.
There are still a few missing on dungeon pages, but that will probably be done when all dungeons recieved the location, story, exploration split. Konig is doing a gread job there.
There is still a lot to do, but I just wanted to point your attention to this little milestone since there was quite a discussion going on regarding this standard. - Yandere 10:03, 21 October 2012 (UTC)

Yay! I've been working through the Area pages and trying to get them sorted but time has been preciously short at the moment >_< — Andrealinia 08:15, 22 October 2012 (UTC)

I'll be finishing up the basic layout of the last 3 dungeon articles sometime this week, and will try to enter each one to fill out what I can for those I haven't. After that, I'll help in filling out the zone articles, then move to Areas, then PoI and finally landmarks.

If only we can have a better (and consistent) design for the Event tables though. *sigh* Konig/talk 15:25, 22 October 2012 (UTC)

Denoting non-fighting Skill Challenges

Figured this is the best place to put it. See Talk:Malchor's Leap for the premise of this. Basically, the articles for "Commune with" and "Examine the" as well as the "take the <item>"/"eat <item>" skill challenges are 100% made up by the wiki. Not only this, but they more or less duplicate the very information that is on the object or item that's linked to the skill challenge. As such, it seems silly to create these wiki-made skill challenges and merely link directly to the item or object when there's no actual skill challenge event. Opinions? Konig/talk 22:44, 22 October 2012 (UTC)

"I'd much prefer just having 1 article with a gallery at the bottom for the various statues, but it's troublesome for denoting which are skill points." Do you mean having on page entitled "Statue of Melandru (Skill Challenge)" and having one called "Statue of Melandru" ? This makes the most sense to me. In the Statue of Melandru page have a gallery with all the pretty pictures with the locations as subtitles and on the skill challenges page this can also be split up to provide more detail on each section... or just combine them all into one article called "Statue of Melandru" with a section in that page for all the skill challenges of said name and details on the area etc. Does this make sense? My coffee hasn't kicked in yet :P — Andrealinia 07:21, 23 October 2012 (UTC)

The more I think about it I would prefer one catch all-article which has a section for each individual statue and a gallery with all the diffrent models. This way you actually find the information you are looking for. Because I doubt that anyone is really searching for a specific statue, but will either go to the zone/area article to find it or will search for "Statue of Melandru". Both approaches should result in finding the information so the "Statue of Melandru" article should at least be linked to every individual statue page. But as I said I do not think that these devision is really necessary. I should also increase my coffee input. - Yandere 07:48, 23 October 2012 (UTC)

Well with that line, I was actually meaning one singular Statue of Melandru - the gallery holding skill challenge locations and the five or so different models there can be (GW1; GW1 branded; Circular; Circular tarnished; Circular Corrupted). Though splitting between skill challenge and non is fine too, since they're functionally different enough (and there's only 1 skill challenge statue model). But that's actually a different matter than what I was talking about for this section - what I wanted to discuss was actually how to denote them on the zone and area articles, which in turn means how to denote them - generally - on their own articles (since the statues are one of two unique circumstances around skill challenges - the other being when objects and PoI share names which isn't limited to skill challenges - I figured a separate post-this discussion would be in order there). Konig/talk 08:20, 23 October 2012 (UTC)

Ohhhh, I would just denote them Statue of Melandru. Especially since the details would be on the statue's page. — Andrealinia 08:32, 23 October 2012 (UTC)

In due course, every skill challenge will have its own image, its own map, its own walkthrough on how to get there, and its own advice on how best to fight it, since they're all different. It should be pretty clear that each such encounter merits its own page in the tried and very effective GW1 style, which also has the benefit that the entries in zone object boxes will directly link to their corresponding wiki page rather than to some general monstruosity. Morgaine 14:50, 23 October 2012 (UTC)

But these don't have anything to fight. So all you would have is a location, map, image and how to get there. There's not really any reason how to have the gallery of random other ones at the bottom as well. But regardless I don't see anything wrong with having a Statue of Melandru (Skill Challenge) page, but that would still be denoted as Statue of Melandru on the area/zone pages — Andrealinia 15:40, 23 October 2012 (UTC)

Even if they have nothing to fight, it's still wrong to link to a generic page after having drilled down to a specific object in the zone box. It's abandoning one's current descent through the search tree and climbing to the top of another tree to start from scratch. It's bad on principle, as well as annoying to those who are trying to find something specific. Morgaine 18:20, 23 October 2012 (UTC)

I'm a bit confused as to how having a page called Statue of Melandru (Skill Challenge) is a generic page? — Andrealinia 18:56, 23 October 2012 (UTC)

Ok, if you want specific pages for every single Statue of Melandru in the game, which has a functionality, I would still say that it is good to have a Statue of Melandru overview page. So you can work your way down from two diffrent trees. - Yandere 19:05, 23 October 2012 (UTC)

That's fine, there's nothing wrong with generic pages. But the generic page should be linked to from the specific pages that one has found through direct links from the zone's objects box. That way the search tree is never expanded again before you've found what you want, and is only expanded if you happen to be interested in general features of this set of objects. Morgaine 19:16, 23 October 2012 (UTC)

(To Andrealinia): If one has already narrowed one's search to zone, area and specific object (on the zone page), then to click on the object's link and be landed on a page that is not specific to the object means that the page is generic. The new page has reset the search tree which you had narrowed down to one single object, and you have to begin narrowing down again to the item you wanted despite having already done so earlier. That would be a clear fault or mis-design. The way search is supposed to work most efficiently and elegantly is that you narrow down the set of possible items as you traverse down the search tree (never expanding the set, only reducing it), and eventually you hit the exact item you want. Then, if that item belongs to a generic set, the leaf of the tree links up to the generic page for that set. Done this way, readers obtain what they want quickly, never have to repeat a search, and the search tree is only reset for them if they want to find general properties of objects. Morgaine 19:11, 23 October 2012 (UTC)

Even for the challenges which aren't about defeating a specific enemy or enemies, there is usually something in the area that needs to be defeated. There is usually at least one Veteran monster in the area, along with maybe a few other smaller mobs. For instance, the Ascalon City one usually has a Veteran Ascalon Ghost nearby. There are very few points which are usually unguarded in some way, so that is something to consider in this matter.--Rognik 19:23, 23 October 2012 (UTC)

Indeed. And what's more, each entry will have its own picture, map, and how to get there, even if there is nothing to fight at the location. It all points to needing page-per-object, as worked for us so well in GW1. Morgaine 19:32, 23 October 2012 (UTC)

(Reset Indent) "If one has already narrowed one's search to zone, area and specific object (on the zone page), then to click on the object's link and be landed on a page that is not specific to the object means that the page is generic." So we're not talking about the skill pages at all? Because if you read Konig's post "there's only 1 skill challenge statue model" then having a page entitled <Statue Name> (Skill Challenge) isn't generic at all. In fact it is a specific example. The one and only skill challenge associated with that statue. — Andrealinia 20:59, 23 October 2012 (UTC)

There can be many top-level generic pages, one for the world or each zone, one for skills, one for races, one for skill challenges, etc etc etc. But once you've picked one and you embark on a descent down the search tree, you're progressively refining your search to become more and more specific (presumably because you're trying to find some particular thing, not roaming aimlessly through the wiki). Each specific thing will of course belong to one or more generic pages, which is why a specific page will typically link back up to the top-level pages relevant to its type. Each of of those top-level pages forms the root of another tree of links. So what we are creating therefore is a forest of search trees all of which share their leaves, ie. pages about specific objects. If there is only one "<Statue Name> (Skill Challenge)" then this is a leaf of one or more trees. It will belong to various top-level trees, such as "Skill Challenges", "Statues", "World Completion", a zone page, and so on. So to answer your question, yes we are talking about skill pages, but we're also talking about many other pages at the same time, because each leaf of the tree has multiple parents. Morgaine 21:44, 23 October 2012 (UTC)

What? You've completely confused me... I thought this discussion was on how to denote the skill challenges on the area pages (I suggested Statue of Melandru which I've not heard anything against) and what to call them (Again, the suggestion being Statue of <Name> (Skill Challenge) which no one seems to be disputing either) — Andrealinia 07:38, 24 October 2012 (UTC)

I think what Morgaine is against is the latter you suggest and would prefer, for instance "Statue of <name> (location)" instead. To this, I find it unnecessary. Amount of models is irrelevant, dialogue is irrelevant, and we can hold multiple maps for locations. To this extent, I say that any division is unneeded. However, to backtrack a bit, "it's still wrong to link to a generic page after having drilled down to a specific object in the zone box" - but is an article about all statues of the same name truly generic? It's still about a fairly specific thing: all Statues of Dwayna, for instance. The skill challenges themselves is merely communing with them. Your claim of having to "start from scratch" is false because it'll be on that very page irregardless.

However, this is all rather irrelevant to the reason why I started this discussion. This discussion was intended for how to list them on zone and area articles and in turn, whether or not we should be making up "events" for these skill challenges like Examine Temple of the Ages or "Commune with Ancient Energy Source" - to which there seems to be a complete agreement.

On the matter of these very unique-situation shared-name objects, I think they should be either divided by zone, or - and IMO, effective enough - by purpose (e.g., skll challenge and everything else - effectively, two pages per). All in all, I think the former would be easier to navigate the page itself, but the latter would be easier to manage and navigate the whole. So it's really and solely a question of what we want: to have simpler pages about the individual, or to have still-understandable pages about the kind. It's more or less like saying if we should make individual page for each and every Veteran Aatxe encountered. Of course, if we document these per zone, we'd turn Statue of Melandru into a disambiguation page. But we'd end up having 5-8 pages per Statue of <god> excluding Kormir.

BTW, Morgaine, "And what's more, each entry will have its own picture, map, and how to get there" - since each statue would have its own map, a combined Skill Challenge page is more than enough. Konig/talk 07:56, 24 October 2012 (UTC)

Personally, I think it's worth have separate sections in a page, but not separate pages. I'm full of cold and can't explain too well and so, instead, I shall create a mock up in a sandbox ^_^ [edit]: Sandbox example !! — Andrealinia 08:21, 24 October 2012 (UTC)

I am very much against merging a PoI with an Object. Though it's done with Fang of the Serpent (kinda) and Victory Cenotaph, I highly disagree with it. And in the Temple of the Ages situation, the PoI and object are in two different places. Konig/talk 08:52, 24 October 2012 (UTC)

I meant it more as a solution for the multiple statues thing, but my head is thinking of things weird and picked a crappy, crappy example. — Andrealinia 08:55, 24 October 2012 (UTC)

I still wouldn't structure it that way. I'd rather have 1 infobox and manually link the other infobox's categories - much like what was done on the GWW for when landmarks and objects shared name and location (e.g., gw1:Mourning Veil Falls (landmark)). Konig/talk 09:16, 24 October 2012 (UTC)

Ahhhh okies! I didn't really contribute to GWW so it was just a suggestion ^_^ — Andrealinia 09:29, 24 October 2012 (UTC)

Like Konig but rather more generically, I too am against merging non-identical items. Instead, partial commonality creates a natural parent class, so the way to handle such commonality properly is to factor out the shared information into a parent page, and link the specific pages which bear non-shared information (such as specific images, maps, walkthroughs etc) to the shared parent. Morgaine 11:37, 24 October 2012 (UTC)

(In answer to Konig's reply to me): Nearly, but not quite. I wasn't objecting to any particular form of naming in the zone object box. I left that open to discussion and would be happy with any form that isn't just plain silly. What I was objecting to is the linking of that field (whatever its chosen name) to a generic page, instead of to the specific item which the user has already identified by selecting that entry. She certainly isn't clicking on a link called "Class of all objects with the name Statue of Melandru", so it is completely wrong to take her to such a place. Or using the terminology of search trees that I used earlier, since she has already located the desired leaf of the zone search tree, why take her back up to the root of another tree and force her to begin another search instead of giving her the information that she has already located uniquely earlier? It would make no sense. So in summary, call the entry anything you like in the zone objects box, but the link has to go to the specific item she selected without beginning another search. Morgaine 11:18, 24 October 2012 (UTC)

But if the information for all statues is on a single page, then that page is a leaf, not a root, and your argument is invalid. There really isn't enough "unique" information for each skill-challenge-statue to be worth creating separate pages for them. —Dr Ishmael 13:04, 24 October 2012 (UTC)

If your search space contains individual entities (as ours does), then a page can be a leaf of a search tree only if it describes a single entity. If the page describes more than one entity then it is a parent to the descriptions merged within it, and the user must search again within that page for the specific entity that she had already uniquely located once before. The fact that you merged the text of N leaf descriptions into a single document containing N sections does not magically make the page a leaf, it's a container for leaves, in other words a parent node in the search tree. What's more, once the user has located object X in the zone objects box, if the link takes her to a container page {A, B, X, D, E} then she has to locate X again within this container instead of being taken to X directly, so it's crystal clear that the page is not a leaf. The leaf is X, and she is interested in X, not in {A, B, X, D, E}. Morgaine 13:57, 24 October 2012 (UTC)

Metaphores are too easily twisted to suit one's own personal purpose, and as such should be avoided. Let's put it this way: If all the information is on one single page, then there is no following pages to search through. As it would be with one page, it'd be like a flowchart where multiple beginnings (e.g., each individual zone/area article) lead to a single end (that one Statue of <god> page). Location, looks, and/or text is not enough reason to split articles - it has to be a drastic difference, such as functionality. To use GWW as an example, since you were so fond of using it, gw1:Gwen was merged from 3 different articles (Gwen in Prophecies, Gwen in Eye of the North, and Gwen in Bonus Mission Pack) because they are similar enough; alternatively gw1:Captain Langmar was kept separate from gw1:Lieutenant Langmar because there's a large difference in functionality (one being the giver of daily rotating and repeating quests). In this case, the only viable separate is between skill challenge and non-skill challenge. With the possible exception of the temple skill challenges (Balthazar and, possibly, Melandru have statues rather than altars like the others which are the skill challenges).

Similarly, a PoI and an object should be kept separate - except possibly when they're the same thing lore and location wise (e.g., Fang of the Serpent). So Temple of the Ages should remain separate - though Harbinger Torch could viably be one, despite being a PoI and a skill challenge object, since they're in the same exact location (unlike ToA). Konig/talk 22:00, 24 October 2012 (UTC)

Search space is not a metaphor. Although a few people might be using the wiki for undirected surfing of GW2 info, the vast majority will be using it to search for something specific among a huge search space of objects. As in my previous example, if they're in Malchor's Leap and are having trouble finding the Statue of Melandru skill point, then they will locate the name "Statue of Melandru" in the Locations/Drowned Brine/Map Completion field, and click it, expecting to be taken to that exact object, with a specific image of its environment, a specific map, its own walkthrough, foes to be fought, etc.. The fact that it happens to share a name with another statue is its least important attribute. They will not expect to be taken to some generic top-level page about a class of statues, and have to locate their specific Statue of Melandru within it. They've already narrowed their search down to one specific object, so why lose that information and dump them on a generic page? It's simply incorrect wiki navigation, and indeed, unhelpful. Morgaine 13:27, 25 October 2012 (UTC)

I should point out that linking to a subsection of a wiki page using a #-anchor also qualifies as linking to the unique object at the desired leaf of a search tree. I prefer the one-object-per-page approach only because it's cleaner and easier to maintain. It'll look pretty odd to find multiple instances of the standard form for a GW object's wiki entry (name, description, image, map, walkthrough, foes, allies, notes and trivia) all appearing multiple times on a single wiki page just because someone thought that the most important attribute of an object was its name. Morgaine 16:34, 25 October 2012 (UTC)

Except that the only things repeated for each entry will be map and walkthrough. Name, description, image, and trivia are all identical for all the different instances of a statue. That's why Konig and I feel that separate pages for individual statues would be pointless - there's not enough unique information for each statue to make individual pages have any value. —Dr Ishmael 16:40, 25 October 2012 (UTC)

Not sure why you claim that. The only thing likely to be the same is the name and the associated lore. Descriptions will be very different because the most helpful descriptions tell you something about where it's encountered ("an underwater statue close to Sculptor's End"). Images will be completely different except for the shared object mesh and texture, since the image will show the place where the object appears --- indeed, in the case of Statue of Melandru, one is in a city and the other is underwater, so the images are dramatically different. Trivia is different to lore, and while lore will be the same, trivia could easily encompass something related to the unique environment of a given object, we can't foretell. Everything except name and lore is different, but to avoid argument I'll grant you trivia too. PS. I'm referring to all in-game objects, not only to this pair of statues. Symmetry is very desirable. Morgaine 17:03, 25 October 2012 (UTC)

Actually, Ishy, with the exception of the temple-related statue objects (of which, I only know Balthazar, and possibly Melandru, having one) the description (that is, the text) are all the same I believe. It's only location and what "guards" it (all Object skill challenges tend to have an unrelated veteran boss in the area near it, sometimes patrolling - but it isn't part of the actual skill challenge). So, @ Morgaine, no in the context of splitting between Skill Challenge and non-Skill Challenge. Not everything but name and lore is different. Text, appearance, lore, name, and function are all the same. Difference is in location alone (and because of that, nearby NPCs, which is, again, irrelevant to the object itself).

In other words, the Statue of Melandru in Divinity's Reach and Blazeridge Steppes will be on article 1 whereas the statues in Straits of Devastation, Malchor's Leap, and Cursed Shore are on article 2. This is, imo, the preferred scenario - in which case, the latter - the skill challenge statues - would have 3 (possibly 4) maps, give or take, for the different locations. Their text and appearance (sans the Statue of Balthazar temple one) would be the same. Also, "the image will show the place where the object appears" this is false. The image will be of the statue itself. Render if possible. The maps - which can equally be part of the infobox, or in a separate <gallery> section - will show the place where they are. Konig/talk 17:36, 25 October 2012 (PDT)

(Reset indent) Edit: Since this seems to me to be going in circles because, by my understandings, Morgaine isn't getting what at least what I believe Ishy means (which I think I agree with), here are some examples of possible layouts. Mind you, it's missing maps and all images and details, but it shows the layout itself perfectly IMO.

• Option 1 - merging all like-named Objects. - what Andrealinia seems to want (note: ignore the image in the infobox).
• Option 2s and 2b - merging all like-named objects based on function - what Ishy (?) wants (note: ignore the image in the infobox).

No need for Option 3, Morgaine's want, which is "each individual object gets its own individual page." But hopefully this should be helpful. Fun thing I realized making this is that the skill challenge statues. I personally prefer Option 1. It's still clear and concise, and not confusing whatsoever. Konig/talk 18:00, 25 October 2012 (PDT)

I can't for the life of me understand why you're so overwhelmingly concerned with the name of an object as the reason for combining pages, when name is the least important attribute by far, and largely incidental. Surely you would combine pages for N objects if they were identical in every respect except their names, wouldn't you? Be that as it may, let's leave this for now, as I'd like to make a constructive suggestion for moving forward. (And by the way, my main concern is not with separation of pages but with separation of link targets to make them unique, as I explained a few times. Separating pages is simply the cleanest way of separating link targets, by far.)

Suggestion: How about moving forward by adopting one of your two merging proposals (either of them, I don't care) but also adopting my #-anchor suggestion to provide a unique link target for each name in the zone objects box? While I don't think that this is as clean as separating pages, it would fulfill both our goals so it seems a reasonable compromise. Morgaine 20:13, 25 October 2012 (PDT)

Uhm, I'm not concerned with the name. And no, I would NOT combine articles that are the same in every way except the name. Because they're separate things.

"but also adopting my #-anchor suggestion to provide a unique link target for each name" But doing such is unnecessary and - counter to your desires - creates messier linking. With my suggestions, which you do not oppose, there would be no section to link specifically to as the article on the entirety is about the subject of the links (in this situation, at least). If it were Andrealinia's format, then linking to a specific section would indeed be better, but that's not how we format pages nor will it ever be because it's counter-intuitive.

"Separating pages is simply the cleanest way of separating link targets" I disagree. It all depends on how it's done, and as I have shown, it can be fairly clean. In this case, separate pages is unnecessarily anal retentive and OCD.

You know, I really cannot figure out what it is you want, because you yourself are beginning to contradict yourself by claiming one thing, but suggesting stuff that'd go against your claim. Konig/talk 20:43, 25 October 2012 (PDT)

Oh come on Konig, no need to descend to the level of pretending you don't understand my goal of providing unique targets for what should be unique fields in the zone objects box, since the row in the box describes one specific location and not a class of objects. This isn't major league computer science, just commonsense. The row in the box denotes a unique item, so the link should lead to a unique description which describes that unique item in the world. And I didn't contradict myself, I offered a compromise which was a step back for me as I explained, but it seems that you're not interested in compromise so I withdraw it.

You're coming across like a dictionary designer, focused entirely on the words and everything else be damned. Game wikis are not dictionaries, they are contextual databases that describe objects in the world first and foremost, and context is everything. Two statues are two distinct objects each with their own environmental context, and a lot of the time people aren't even going to read the name in-game but just head for the skill icon. When looking up a skill challenge starting from the zone page and drilling down, they don't want to know about your class of items with the same name at all , but only the details of that particular skill challenge. You really have this back to front, preoccupied with the wrong thing entirely. And in the process you're making the wiki slightly less usable for its most common purpose of searching for specific items that people want to know when in-game. Morgaine 21:03, 25 October 2012 (PDT)

You know, at first I thought I knew your goal. But then you started contradicting yourself (wanting a clean link, but over-complicating the links with # linking when such isn't needed in any way shape or form) and over-complicating your comments with metaphores that make little sense objectively (trees and leaves) and putting increasingly more focus on what we supposedly care about (falsely, too).

You're trying to accommodate articles to the infobox which in of itself is faulty for the very reasons you want to accommodate it. There are many objects with the same name, same function, same everything that's in multiple locations - take Corrupted Ice Formation for example. The infobox wtf screws it up with how it's set up. So this is your issue, yes? Then the discussion shouldn't be about the articles, nor should there need to be a discussion - we just simply redesign the {{Object infobox}} to match the {{NPC infobox}} or {{Location infobox}} templates. Konig/talk 21:34, 25 October 2012 (PDT)

By your logic, we should have separate pages for every individual Carving Pumpkin in the world because they have different "environmental context". There are 34 of them just in Lion's Arch, and probably just as many in each of Queensdale, Kessex Hills, and Gendarran Fields. That's just plain ridiculous, because they all function exactly the same and only have 2 possible appearances (plump orange and skinny green).

These statues are a smaller scale, but the same principle. All of them function exactly the same and have 2 possible appearances (normal and corrupted). The surrounding environment may look different, and the surrounding enemies aren't the same, but those points are not important when documenting the statue. —Dr Ishmael 05:29, 26 October 2012 (PDT)

Just a nitpick, but statues have a minimum of 3 appearances - round uncorrupted, GW1, and round "old" - though Dwayna and Balthazar have 5 (and are the most numerous in appearance deviation) when excluding the Statue of Dwayna NPC. And Carving Pumpkins have 4 appearances - carved and uncarved of plump and skinny. Konig/talk 08:18, 26 October 2012 (PDT)

I would be most obliged if you would stop saying that I contradicted myself after I explained that I moved back a step purely to compromise with Konig in the interest of moving forward. I accept that #-anchors are messier than separate page URLs, but since Konig wants merged pages and I want each unique field in the zone object table to point to a unique target, I felt that a compromise was in order despite this being a step back for me. The fact that you wish to label compromise (everyone concedes a little) as "contradiction" is not very nice. Please don't do it. In any event, since Konig rejected the compromise, I withdraw my suggestion of #-anchors as a way forward.

A unique target for a row denoting a unique object is required, because otherwise you are breaking the meaning of the table. The 3rd field of the table has a heading of "Zone Completion", and zone completion is not related to classes of objects but to SPECIFIC objects in the zone. The fact that you propose linking not to a specific object description but to a generic class description is simply wrong. Doing so loses the fact that the user has narrowed her selection to a unique item already by clicking on the object link in a given row of the zone objects box, and requires her to search again in the generic page for this class of object. It's incorrect structuring of search, it's poor wiki navigation, and it adds one unnecessary step for the user to perform.

In addition, it doesn't respect what's often called the Principle of Least Astonishment, because after clicking on a field denoting a unique zone completion event, the user is landed instead on a generic page. It's not the end of the world, but it won't be what the user expects. And lastly, it's much more messy to manage a merged page with multiple object entries, each one having multiple sections as we've already discussed, than it is to manage separate pages. Even the Talk page of each one will have to be sub-headed each time to avoid ambiguity. What you're proposing is very messy. Konig's sandbox tests do not show the mess simply because he didn't populate them with multiple sections, one per world object in the class. If he had done so, the mess would have been obvious as soon as he'd filled in all the usual headings, paragraphs and images that we always have per important object. And every zone completion object is important enough that it will have all those sections populated, so merged pages have a mess rapidly bearing down on them. Morgaine 08:16, 26 October 2012 (PDT)

I like option 1 but also wouldn't mind option 2 (providing the page for 2b had "(Skill Challenge)" in the page name) I'm not even bothering to really read the other things because I don't want to get pulled into an argument but I don't fully understand what Morgaine wants any more. Can you maybe create a sandbox so we can see what you mean? Also if this is wrong indent feel free to change it. Not quite sure how it goes when the bit I'm responding to isn't the bit before my text. — Andrealinia 00:19, 26 October 2012 (PDT)

I have trouble following this conversation as well lol. Non-interactive objects will all be put on a single page with a gallery. Every skill challenge needs its own page really since all interactive objects will have dialogue and then an "ask" line of dialogue after completing the skill challenge. This is more so we can link to skill challenges, categorize it in the appropriate zone, and provide a "Getting there" in case it's necessary. If the skill challenge has the same name non-interactive objects (Statue of X god probably), I'd have a main article for the skill challenge and <Name> (location) for the non-interactive objects. After all, the page for Chest will be huge. The {{Object infobox}} shouldn't be used for skill challenges, because object skill challenges are only one type. We still need to categorize such skill challenges as Category:Objects (or however konig has been sorting such objects in lore), [[:Category:<Zone>]], and Category:Skill challenges right?--Relyk 05:47, 26 October 2012 (PDT)

You haven't indicated a reason why interactive and non-interactive objects should be handled differently. From the perspective of a user working on zone completion, each of the 5 types of zone completion object merits the same kind of treatment. In terms of what the user needs from the wiki, reaching a vista is no different to winning a skill challenge or completing a heart, and even quite a number of POIs are hard to reach and may require a walkthrough etc. I agree that zone completion objects need separate pages because of all the info that each one will carry, but I don't see how interaction or not alters the wiki requirements. Morgaine 08:27, 26 October 2012 (PDT)

Andrealinia and Relyk, here's a simple example which should make it clear what I'm trying to achieve. Say you're trying to complete a zone and you just can't find your way to a particular completion object such as a vista or a skill challenge. Zone completions are done by zone, so you head for the wiki and find the page for the zone. You know the area of the zone that you're in from your in-game map, so you look in the first column of the box for your area name and find the corresponding subsection of the box. You know the type of completion object that you're trying to find so you look in the 3rd field for the symbol corresponding to that type of object. This will often provide you with a single unique row of the box denoting the exact zone completion object for which you were searching, but if it doesn't then the name should help you narrow your search further to a unique row. Having found the row for your desired completion object, you click the link, and naturally expect it to take you to a description of the object plus all the information you require to complete it. And that's exactly what it does.

That's it. :-) Morgaine 09:11, 26 October 2012 (PDT)

And for completeness I'll now point out what the other two proposals achieve. I'll treat them together because from the user's perspective they both behave very similarly, since they are both merge object pages.

The user first locates a single zone completion object as per my proposal, and clicks the link in the row that denotes the desired specific object, exactly as in my example. At this point the behavior diverges. Instead of being taken to a description of the specific object which the user selected in that specific row, she is instead taken to a generic page and her specific selection is lost. In that generic page she has to locate some subsection that applies to the object which she had already selected previously in the zone box, but she has to perform this search a second time because her previous selection was not carried forward in a link. Her search will be carried out in a composite page bearing a number of entries each of which will often be large, since each zone completion object is important and is likely to carry substantial information if it is to be helpful for zone completion.

The above is clearly a lot more complex than my proposal, for users and wiki maintainers alike, and it is much less helpful. Morgaine 09:39, 26 October 2012 (PDT)

How is it more complex to maintain a single page than to maintain multiple individual pages? I completely fail to grasp your logic on that one. —Dr Ishmael 10:10, 26 October 2012 (PDT)

I'm sorry, I didn't realize that it was so extraordinarily complex, so let me assist you to understand it. We subdivide things in all walks of life to make them more manageable. The examples available number in the millions, but since you say that you completely fail to grasp the reasons for subdivision, I'll try to help by giving you just one example which is appropriate to the current context. On this wiki, why have we split zone information into top-level zone page, area pages, POI pages, and a whole lot more? Why haven't we put all that on one page? Because subdividing information assists management, assists access, and is just plain faster for all operations. Morgaine 11:15, 26 October 2012 (PDT)

That's a horrible example. Zones and areas are two different levels of location hierarchy, so of course we have articles at both the zone level and the area level. The areas themselves have nothing in common with each other, thus we document each area on its own article. Interactive objects don't have a hierarchy, and the precedent (both here and on GW1W) is to have a single article for all (nearly-)identical objects of the same name. —Dr Ishmael 11:30, 26 October 2012 (PDT)

For getting to the skill challenge, you look on the area page, this is what's done with vistas. For information on the actual skill challenge, having it on a grouped page is sufficient, like in konig's example. Combat skill challenges will also be described on those area pages. It's not really much different than if a combat skill challenge had a generic enemy, the location of the enemy would be indicated on the general page along with any other information.--Relyk 10:25, 26 October 2012 (PDT)

@Rylek: Non-interactive objects shouldn't be documented as objects. At the least they get a mention on a location page, at the most they get a landmark article.

@Morgaine: Your desires would be filled by my suggestions just as well as it already is by the zone article, and will by the area article - that is to say map images. There doesn't need to be a "getting there" unless it's complex (e.g., some vistas). Merely showing where it is on the map, with context to said map (usually an area's worth) is sufficient. If it isn't, then the person looking up the information needs more help than we are obligated to provide. We cannot - nor should try - to cater to those unable to figure out what the majority can.

"she is instead taken to a generic page and her specific selection is lostshe is instead taken to a generic page and her specific selection is lost" Except that it's not. As said, there will be a gallery of maps which will show the location of the objects. It's very simple, it's very precise, it's very bloody clear. I've stated this over and over and yet you ignore it. Are you even reading my entire posts? Please respond with "yes, I read your posts fully" so that I'm not second guessing here.

And I'm sorry, but it's easier for editors to maintain a single page over a series of pages. That's why The Founding was made by wikiers rather than 20 articles named "The Founding: Volume #" - because that one article is a hell of a lot easier to maintain - even if longer when complete - than the 20. That's why Book Cart isn't 20+ different articles. So, no, you're perception on what's easier is false. And when the article is as short as my examples showed, having to locate the appropriate map is unnecessary. Furthermore, the average wiki'er would not click the skill challenge link - instead he/she would click the zone map because that very clearly shows the location of all skill challenges, vistas, etc. The only time they'd click the link for skill challenges would be in regards to how to beat them or for dialogue - though TBH, all of them are so straightforward and simple that you don't really need a change of strategy except for a small handful.

@Rylek again: Skill challenges won't be described on area articles like vistas - vistas are described on area articles because they themselves lack articles and unlike waypoints, PoI, hearts, and (most) skill challenges, are sometimes complicated to get to (the only skill challenges hard to get to are not subject to this discussion - e.g., Remains of the Northern Wall). Konig/talk 10:39, 26 October 2012 (PDT)

Konig, be nice please. I'd be happy to confirm that I read everything you write, but I don't think you read what I write because you don't grasp some very precisely expressed points. You know full well that the selection which the user has made in the zone box (the specific row which denotes a single object) is lost when accessing a gallery page, because the gallery page is a container for a number of items, not just the single item denoted by the row. Within that container the user has to narrow down her selection to a single item again, despite having already done so previously. She wouldn't have to do this if her previous unique selection had not been lost. Her previous unique object selection was lost because it was not carried forward in the link and so her unique selection didn't pick out the single item that the row selected. It's because it was lost that she now has to search for a single object again in the gallery of multiple objects. That's a precise statement of fact, and it's not using computer science terminology. Anyone with technical or Internet background should be able to see it. Morgaine 11:53, 26 October 2012 (PDT)

I've subdivided this answer for ease of writing. :-) Regarding the complexity of walkthroughs, they will vary hugely, and we can't generalize about some types of zone completion object needing longer walkthroughs than others. Skill challenges for example vary from the trivially accessible (such as NPCs in outposts) to the almost impossible to discover because of hidden cave entrances and apparently deliberate stacking at different height for purposes of confusion. We're in the hands of what wiki contributors feel is useful information for others, and quite often what's easy for one is hard for another. Level of detail has to be flexible here, especially in level 80 zones where full information can mean the difference between success and death. Morgaine 12:12, 26 October 2012 (PDT)

Konig, you are totally and completely wrong in your statement about use of the zone map and why people click the skill challenge link, so wrong that I'm stunned, and I was seriously wondering if you even do zone completions to any great extent. On reflection I am sure that you do, but that people vary hugely and you do not quite realize it. Let me tell you how the game works for the non-clairvoyant among us. The zone map provides only 2D location, whereas the game is layered in 3D and ArenaNet has made full use of the vertical dimension when placing not only the zone completion objects, but the access paths to those objects. As a result it is completely impossible (in the absence of clairvoyance or inside knowledge or external information) to know in advance how to get to a proportion of zone completion objects, despite seeing them marked very clearly on the zone map. The only viable approach is exhaustive search aided by some spatial awareness and a sense of likelihood ... which often fails.

The up or down arrow on POI and vistas tells us about the relative height of an intended endpoint, but it does not tell us the height at which the path to that endpoint commences. Even worse, skill challenge symbols do not have an up/down marker, and finding them can be a lengthy experience. The wiki can be a godsend in this respect, even for those who have completed all zones but don't have perfect memory when playing the next character. The GW2 world is a complex place, and while some players may find everything trivial, this cannot be generalized to everyone.

PS. This is getting lengthy because of your "not being read" worry, but I'd better stop there anyway. Morgaine 12:56, 26 October 2012 (PDT)

I'll read and respond to your post in full later, as right now I'm more interested in the second act of Halloween and that insane yet fun jumping puzzle. But to clarify on one point (do note this is without reading the rest of your post yet): "you don't grasp some very precisely expressed points" The issue isn't so much with me not grasping your points - considering everyone here is having the same issues. Perhaps it's not as precisely expressed as you believe, and perhaps you're talking about a multitude of aspects (as I understand at least) or something that's not directly relevant to the division of articles (your earlier complaint about the infobox, while completely avoiding mentioning said infobox). From what I can understand, it sounds more like your problems lies primarily with said infobox, and not page layout (but not solely). Which, if so, may be the confusion: you're talking about one thing, but meaning another while believing that they're one in the same conceptually (and while somewhat true, is not from a wiki editor's perspective). Konig/talk 13:11, 26 October 2012 (PDT)

I think you may be right that we're firing past each other in a sense, not really because we have very diverging goals but because we're each looking at slightly different parts of the problem. You appear to be concerned mainly with how to wikify a particular type of statue which happens to have instances in more than one place, whereas I'm focused on getting a direct correspondance between the 3rd field of the infobox and what it points to, so that the infobox can act as a coherent index into pages which describe the objects required for map completion.

It's not really accurate to say that I have a problem with the infobox, nor indeed with the links. It's not one or the other, but how the two are combined, because the infobox and the targets to which it links are after all a system, as each half is designed with the other half in mind. I explained by way of example how the overall system really ought to behave if it is to provide the simplest, most efficient and most expected behavior under the most common usage scenario by far, and I do think that that's a worthwhile goal in itself. But going back to the 2-part system a little more theoretically rather than by example, we should really be aiming to design a consistent system, not a system in which one half has one semantic and the other half has a different one.

The infobox has a unique object selection semantic per row, because each row most definitely selects a single object (I'm sure nobody will argue with that since that's the whole point of the table). The 3rd field of the row has the terse but unambiguous header of "Map Completion" which alludes to the objects required to complete the map, and if you add together all the objects indicated in the 3rd fields then you have a complete map. Classes of objects are not required to complete the map, only the specific objects that each row selects are required to complete it, and so it's really inconsistent to link individual "Map Completion" fields to anything else, effectively a type mismatch. I know it's easy to link to anything you like and nobody needs to pass an exam to start linking things, especially on an ad hoc wiki, but that doesn't make it right nor coherent nor necessarily useful to link inconsistent and unexpected things together. Indeed, the example illustrated how it's a step away from helpful behavior for the user.

One final observation for now: Where they have been filled in, POI entries almost always link to individual pages which describe the specific locations. That's a consistent design and it's already in place. Why aren't we striving to make all map completion types work in an identical fashion for all-round consistency, symmetry, and the cleanest lookup behavior? Special-casing some types is bad design when it provides no benefit for the most common lookup case, and actually degrades it. Almost nobody who accesses the merged statues page will be doing so because they are interested in the common features between them. They will be accessing the page through zone infobox links with the sole purpose of accessing the information corresponding to a single statue at a time. This again highlights how the proposed merging matches user requirements only very poorly. Morgaine 19:57, 26 October 2012 (PDT)

(Reset Indent)
Dear folks, I have decided to withdraw my input on this particular topic, very amicably and wishing you all the very best in this work. The reason is not that I feel any less strongly about it, but because I think that we might be unintentionally wasting each others' time on this specific issue by going around in circles, and life is too short for that. On reflection, it seems clear that nobody else in the discussion is particularly interested in field consistency nor in issues of user lookup experience, and conversely I have recognized on reflection that I have little specific interest in a set of statues which to me provide no valid reason for breaking object symmetry.

I look forward to seeing what comes about, and if nothing else then this will at least give us all a few extra minutes in which to do useful things. Good luck, and keep up the good work. :-)

PS. No need to reply to my last entry Konig, although I'll happily answer if something is asked or if a reply misinterprets what I wrote. Best to just let it fade away though. I'll see you on other threads and especially in Feedback later on. :-) Morgaine 21:11, 26 October 2012 (PDT)

========

No need to withdraw your imput. Anyways, "I'm focused on getting a direct correspondance between the 3rd field of the infobox and what it points to" As I said twice before, this is something that requires the infobox to be altered, not the articles themselves - you're target is the infobox's issues, but your solution is to alter the many instead of one thing that can be, making your solution more complex than need be. As I said, we merely must alter how the {{Object infobox}} works so that the zone, region, and area fields are akin to the NPC or Area infoboxes (either or, though I'd prefer NPC set up since NPCs and objects are similar in basic essence). Konig/talk 22:44, 26 October 2012 (PDT)

Another problem here is that Morgaine is using "infobox" incorrectly - you're talking about the locations table on zone articles, and that is not an infobox. The infobox is what goes in the upper-right corner of the article and is generally a template that ends in "infobox", which is what Konig is talking about. —Dr Ishmael 06:50, 27 October 2012 (PDT)

Oh yes, thank you, I did indeed mess up last few entries by referring to the locations table as "infobox", when that's totally wrong in my context. Not sure why that happened as I wasn't using "infobox" initially. But yes, that was a mistake, sorry. :-) Morgaine 08:03, 27 October 2012 (PDT)

Great, now I'm confused, because there isn't - nor ever was - disagreement on how to treat these in the locations table. It was about the individual object pages where disagreements (seemed to?) be at. Konig/talk 11:08, 27 October 2012 (PDT)

I won't recommence but happy to clear out any uncertainties. The answer is perhaps 99% "Yes" that I was fully satisfied with the locations table. The missing 1% appeared only when I offered the compromise of accepting merged pages but linking the 3rd field for these statues to subsection #-anchors within those merged pages in order to achieve my desired 1:1 row-to-object-description target mapping. Obviously that would require a tiny change in the links used in the table, transparent to wiki users. Other than that though, the location table seemed perfect to me. And indeed, after I withdrew the offer of compromise it became 100% perfect again. :P Morgaine 12:20, 27 October 2012 (PDT)

Which leads to yet another absolute utter confusion on my part because there would be no proper section of a merged article to link to - so given my examples, where would the section linked go to? #Gallery? Then each one's the same. #Locations? Then each one's the same. There's no section dedicated to a single location, nor should there be. Konig/talk 12:22, 27 October 2012 (PDT)

Exactly, there isn't! I did point out (Morgaine 08:16, 26 October 2012 (PDT)) that your sandbox test pages were still lacking all the sections, images and text that would be needed to properly describe the object that the user selected. You're totally right that a #-link has no section to link to in your prototype, it's missing entirely. This was in the context of replying about messiness of merged pages, and pointing out that it didn't yet look messy because it was still missing pretty much everything. BTW, this explanation is only by way of clarifying what I meant to dispel the confusion you expressed about what I could possibly mean. I don't want to enter the argument about what the page should contain anymore, only to make my previous words and intent clear. I suspect that's done now, agreement not required. :-) Morgaine 14:22, 27 October 2012 (PDT)

No, it's not missing anything. All it needs is a list of the locations (check), the possible dialogue variations (check), and a map for each location (check). No need for a section header per location or anything messy like that. —Dr Ishmael 14:45, 27 October 2012 (PDT)

As Ishy said, there is no need for these things. It's not "still lacking" - it was very much complete in terms of format, otherwise I wouldn't have left it unfinished. So not, it wouldn't be messy - yet or otherwise. So the confusion began with your vision of a merged article being false. Konig/talk 14:57, 27 October 2012 (PDT)

My vision of the page is false by your metric just as your vision of the page is false by my metric, because our intents or goals are different.

My intent was consistency of the type of link target with the type of the field in which the link to the target resides. The link resides in a field called "Map Completion", meaning "Objects Required for Completion of this Map", which is exactly what the 3rd column describes, and I believe that the links should be consistent with the type of their field for adherence with the Principle of Least Astonishment. In contrast, you are placing in that field a link to a target of type "Collection of Objects Some of Which are Required for Completion of this Map". Your choice of target is inconsistent with the type of the field, and that is why your choice of what you put in your sandbox page is incorrect if one seeks consistency, which I do and you do not. So, we have two different visions, and yours is severely lacking in some very desirable consistency properties which I tried to communicate to you. This attempt failed because it has turned out that you have no interest in maintaining such type consistency in wiki fields, at least not in this one. As a result your sandbox page is fine by your metric and is in a threadbare state by mine. We differ. :P So be it. Morgaine 19:02, 27 October 2012 (PDT)

It's not "my metric" it's just how pages are formatted. We don't do what Andrealinia was doing with his/her (?) example. That's just not how it's done. Ever. So by wiki's standards, your intended format would be improper (and, to be completely honest, chaotic, messy, and just plain odd). There is no need for a direct one-to-one linking (be it article or otherwise) - it'd be like creating a new section on Bandit Scout, for instance, for each individual location and model combination. Outright lunacy and excessive unnecessary additional work. And not, as said, wiki standards. Konig/talk 19:39, 27 October 2012 (PDT)

It certainly is lunacy as you say to have multiple sections like that in a single page, but you have to remember that the merged page is your proposal and not mine, so don't blame me for its wackiness. I was merely trying to patch up the bad merge-based design by correcting its faults, but on reflection it would have been better to just throw it out wholesale. It is indeed a completely insane approach.

The simplest, most sensible, cleanest and "least astonishing" approach for the user is to use one page per map completion object being described (let's call these "object pages"), which is exactly what I first proposed. If it turns out that multiple object pages end up having some property in common then you factor out this common part into a separate page (let's call this a "class page" because it's about a number of objects that share something in common, hence a class). Finally, you add a link in each object page to its class page and give the link a name that reflects what's in that class page (there could be more than one class factored out). The infobox (using the word correctly this time) is a perfect place for such links to descriptions of common properties.

Such an approach would always link to targets of the expected type, resulting in least user astonishment. It is also conceptually very simple owing to the lack of merged pages and avoidance of inconsistency in link targets. And finally, it provides very clean search semantics, because the user is simply traversing the search tree from the zone root downwards until she hits the unique leaf describing her desired object, and only if she is interested in common properties of such objects does she bother to look in the shared parent tree which leads her to other objects which are not located in her original zone. That's extremely tidy both conceptually and from a usage perspective, and users would thank us for multiple reasons.

Your proposal in contrast is in serious trouble on multiple fronts, almost all of them stemming from your incorrectly justified desire to merge pages about very different things. How you've convinced yourself that a skill challenge and a statue in a town belong together I'll never understand. What they share (a mesh and some lore) is vastly outweighed by what they do not share, and nobody who is interested in the skill challenge is going to be looking for the town statue. Your design is really just plain bizarre.

Documenting the class of statues themselves separate from their individual employment is fine, but you need to link such an abstract page into the zone search tree in a way that makes sense, and yours doesn't. A way that would make sense would be for the 3rd field in the locations table to link to a leaf object page describing this particular skill challenge, and then this object page would link to your abstract statues page through an appropriate link name that indicates that the link target is about this class of statues, not just the one that triggers this particular skill challenge, Indeed, that's the same design pattern I described in paragraph 2 above. Your design in contrast doesn't meet the most basic tenets of logical link structure nor parent/child relationships. Morgaine 21:22, 27 October 2012 (PDT)

"your incorrectly justified desire to merge pages about very different things" They are NOT "very different"! They are the exact same statue in different locations! That's what we've been saying all along but you refuse to listen! —Dr Ishmael 21:29, 27 October 2012 (PDT)

You make it sound like it's an omnipresent statue, located in multiple zones simultaneously. :P It's not.

They are distict objects, located in completely different types of places, some have totally different purposes and behave completely differently, and really they have nothing at all in common apart from a name, mesh and some lore. Some are even different graphically because one is underwater (referring to Malchor's Leap here) and this affects the texture and lighting data used. You've convinced yourselves that the inconsequential properties they share are of such overriding importance that it's OK to mess up the map completion object tree by linking to a merged page about this trivial commonality instead of linking to map completion object descriptions, which is what any user searching for skill challenge info would expect, not your page. Your design is not only incorrect and unhelpful, it is bizarre. Morgaine 21:46, 27 October 2012 (PDT)

NB. The latter part of the above exchange has moved too far away from clarifying misunderstanding about what I wrote and into discussing your proposals again. If you can avoid replying to my post unless you want something of mine clarified, I would be grateful. Thanks folks. :P Morgaine 21:57, 27 October 2012 (PDT)

(reset) Ok, I have read the whole thing, and I am confused... As far as I am concerned this option is most desirable. It is an overall short article with all relevent information on it and you can pretty much grasp everything with one view.

Now to some of the point of criticism. In my opinion there is no lack of consitancy, when I click on a link with a column named map completion to find myself on a page that tells me how to how to complete several diffrent skill challenges, that are all extremly easy to reach and all extremly easy to complete. The dotted way on the map is everything you need to find a specific location in the game, that is required for map completion, and I know that because I have completed the map. So a screenshot of a dotted way from the nearest waypoint to the location labled "Statue of Grenth - Straits of Devastation" is enough to find that place. The real problem there will be that you are in the Straits of Devastation my number 1 most annoying zone in the game. All the trash mobs there are annoying, and will make your live so much harder to complete these things. But that is a problem of the zone and an information which should be noted on the zone article if anywhere. - Yandere 21:37, 27 October 2012 (PDT)

@Morgaine: Ugh. Allow me to break it down. They use the same name. They have the same lore. They are copies of the same thing. They might hold different text (all those in Orr, sans unique ones at temples of which there are only 1 or 2, have same text, same purpose even). They hold one of two purposes - basic objects or skill challenges, nothing else. The surrounding environment is IRRELEVANT - so that means that whether it's underwater or not is likewise irrelevant as is the "lighting data used". "You've convinced yourselves that the inconsequential properties they share are of such overriding importance" or perhaps it's you who've convinced yourself of inconsequential properties (the lighting of and surrounding textures, for instance) as ovverriding the importance. The most important thing is what it is - e.g., NPC, object, location, ambient or otherwise. In this, they are all objects. As objects, there are thus 3 kinds (in a general sense): skill challenge, event triggering, and "basic" - of these kinds, these statues are the first and the last. Always. And since they share the same name, same set of models and textures, and the same two functions of the same type of "thing" (so to say), they are very much similar. That's ignoring the lore behind them. Truth be told, the two most differenciating aspects of them is location on map and the function (skill challenge or not), and even then - as I said, they'll still only divide, at most in a reasonable matter, to two article (said Option B). But, as you yourself agree, there is not enough difference at that point to divide the articles between this one single difference since they'll both contain multiple locations and therefore maps. And truth be told, except in unique cases such as this, location is similarly irrelevant (as you would never consider splitting an NPC article based on different locations if location is the sole difference).

Again, surrounding aspects is irrelevant - be it lighting, NPCs, or ambient textures. What is relevant, in no order, is: name, lore, model, type of "thing" (I use "thing" as a catch all for NPCs, locations, objects, events, etc.), and uniqueness. Your "map completion object tree" is unhindered. Konig/talk 23:50, 27 October 2012 (PDT)

"We don't do what Andrealinia was doing with his/her (?) example." Yup, my example completely sucked. Also, 'her' is the correct pronoun ^_^ — Andrealinia 07:45, 28 October 2012 (PDT)

@Konig: You are saying that three properties of an object (name, mesh, lore) which to the user are of nearly zero consequence when doing this type of map completion are of such overriding importance that they will dictate wiki page linking and grouping. I've said it before but I'll say it again because you are repeating yourself too: when doing a skill challenge, as often as not the user is completely unaware of the name, the mesh, and the lore of the object bearing the "Skill Challenge" label, and will instead simply head in the direction of the blue skill challenge icon and press 'F'. This is especially true when there are dangerous foes around and you have only a split second to begin to commune, or at the other end of the spectrum, when you're a power player and you've done a particular spot on so many characters that you're totally nonchalant about it and the blue icon is the only thing worthy of attention. Certainly in my case I only sometimes register what passive object marks the spot unless it's an NPC, that's easy to remember. The rest of the time the only property of interest of the statue is its location. The spot is marked by the blue skill challenge icon anyway so the statue only bears half the limelight as a marker. You're focused on issues of little import.

But to really hammer home how bad all this is and how you totally misunderstand the goal here and what we're trying to achieve in the locations box specifically, I'm going to bring an issue to your attention which I haven't raised before because it's so obvious, but apparently it's not obvious to everyone so here goes.

The following is important.

The issue is this: map completion entries in the 3rd field of the location box which yield a skill point are not statues. They are Skill Challenges. The statue is just an object which marks the location and enables the Skill Challenge event to commence, but the statue is not the event, it is just a marker and a trigger for it. Let me repeat: THE STATUE IS NOT THE EVENT. Map completion doesn't collect statues, it collects successful Skill Challenges which are completions of challenge events, and the "Map Completion" field does not refer to statues but only to Skill Challenges which are events. Confusing the Skill Challenges (which are events) with the statues (which are objects) has resulted in the (rather funny) situation that the discussion and wiki organization have become focused on statues despite the fact that statues are not what the 3rd column should refer to at all. It must refer to Skill Challenges, ie. events.

Armed with this understanding, linking the 3rd field to pages about statues is a very clear and rather funny error, and it's an error whether the link is to a page about the unique statue or to a merged page about a class of statues. It's an error either way because an event is very different from an object in every respect, and for map completion skill challenges you need to complete an event. In other words, you are describing completely the wrong thing when you link that field to a page about statues. Your preoccupation with statues has blinded you to the fact that the third column is about Skill Challenge events, and instead of linking to descriptions of Skill Challenge events you are linking to the markers as if the markers had to be gathered for Map Completion. They don't. You totally miss the point of what the 3rd column and the entire locations box is about.

What you're doing is as incorrect as if you were linking the POI fields to a general page about POIs, or linking the vista fields to a general page about the fluttering banner and column of light at each vista point, "because they share a mesh, texture and label". Exactly as in the case of skill challenges, the three common properties of vistas are almost completely irrelevant to map completion, they merely mark the spot, and what you are collecting for map completion is the challenge of reaching that spot and pressing 'F'. In consequence, the Map Completion field for a vista should link to a page explaining how to reach the spot and not to a page about the common properties of fluttering banners.

I suggest that you reflect deeply on the nature of map completion and what the 3rd field of the locations box is meant to describe before telling me again how the visual properties of a marker is the most important thing ever. (Hint: read the two words in the 3rd column of the locations box header, and ponder on the relevance of the 3 shared statue properties to those words.) Morgaine 08:39, 28 October 2012 (PDT)

Well, with this argumentation we only need a handful of articles anyway. Because the skill challenge is commune. Yes it is called diffrently but names are not so important anyway as you pointed out. It works always the same you go to the challenge, you click it and you try to not get hit for a few seconds.

When you strip down the lore from these things than they are virtually identicle. So we could just make a page named "Commune" and than all information is found there. The is no need to list every single commune skill chellange in the game. [[Commune|Statue of Lyssa]] would give you all information you ever need to complete the challenge. So yeah, still no reason to list every object in a single article, because it is clear what to do. - Yandere 09:11, 28 October 2012 (PDT)

But skill challenge events are different to each other when they are hard to reach and merit a walkthrough about access and advice about fighting. The only ones that are so similar that they might not need documenting are the skill challenge NPCs in outposts, and some people will want to document some of those too because they're not all trivial to complete. In any case, thank you for agreeing that the skill completion is an event, and that the statue or NPC just marks the spot, nothing more. The properties of the marker are not what the 3rd field should be concerned with. Morgaine 09:20, 28 October 2012 (PDT)

Some vistas are hard to reach, some points of interest are hard to reach, but skill challenges are all extremly easy to reach. You most of the time don't need to search or climb, you go there an do the thing. Some commune skill challenges are hard to complete, because of the mobs in the area, but as I said, that is a problem of the area not the skill challange. Commune skill challenge all work the same, and as far as I am concerend, when you really really want to see these things seperate from the object there are attached to, there is no need for documention at all.

If you detach the challenge from the object it is bound to, it is a very abstract process, which has no variaty attached to it. If I drink ogre soup or eda's apple pie is no diffrence, because the pure skill challenge is "double click on the item in your inventory". Commune challenges are also extremly abstract if you detach them from their object.

And yeah fighting skill challenges are also that abstract. I you say you want no connection to the object than fighting skill challenges shouldn't name the enemies you are fighting. They should just state if it is a mob fight or a one to one fight. That is the level of abstraction you are suggesting.

And if that is what you want, there is also no need for seperate articles. - Yandere 09:38, 28 October 2012 (PDT)

Let me try to explain it this way: Name is important solely because that is what people will search. They will not search "bandit torch wielder" when looking for Bandit Scout, who can wield a torch. Nor will they search "statue of the god Grenth" when looking for Statue of Grenth (they may search Grenth's Statue, however, but that's extremely unlikely).

Lore is important because that's "what it is" - you wouldn't mix an NPC called "Robber" who's a bandit with an NPC called "Robber" who's a Renegade, would you? No. They're completely different things - even if the only difference is in model and lore.

Location is not important because anything - even something unique, e.g., Logan Thackeray - can appear in many locations as duplicates (or mostly duplicates, in the case of Logan who's dialogue and main-hand weapon changes). It is important to document, but it is not a factor when deciding on dividing pages.

Functionality is important because that's how people will want to see the article. If people are looking for the NPC Statue of Dwayna, they will not want to find the article on the objects for instance. Similarly, a close enough functionality - e.g., a random NPC mob named "Bandit Thief" and a specific NPC named the same thing that is at the trigger of an event should, imo, be on the same page - this, however, is a debatable factor depending on how that division is.

Model is semi-important because that's how people will recognize it. The wiki prefers render images, which in turn removes the surrounding, the lighting, and so forth (just take a look on GWW for what I mean - eventually, GW2W wikk have images much like that). This means the surrounding lighting and textures is irrelevant, as is their affect on the model. It's the model itself that's of importance, however since we can hold multiple images on a single page (much like how, e.g., gw1:Thrall does), it is not a dividing factor in of itself.

This is why these things are important. These are the things which will differenciate what people are looking for. One's attribution to a zone's map completion is part of the functionality, but that alone is the only plus to dividing these articles and is, IMO, not enough.

" map completion entries in the 3rd field of the location box which yield a skill point are not statues. They are Skill Challenges. The statue is just an object which marks the location and enables the Skill Challenge event to commence, but the statue is not the event, it is just a marker and a trigger for it." ALlow me to clarify your false understanding: Commune skill challenges - just like the skill challenges where you have to obtain and use a consumable item, DO NOT HAVE EVENTS - that's the entire purpose behind this section (read the first post). The wiki had fan-made these events. In other words they do not exist, at all. I hope that's clear enough. The skill challenge is, quite literally, "Get to object"->"click Commune"->"Wait out communing sequence" - because getting attacked interrupts the last, one has to usually clear the area of enemies, however this is not a necessity (especially if there are others who drag the aggro). They are not part of the skill challenge, just near it. The skill challenge is merely clicking the dialogue options.

"I suggest that you reflect deeply on the nature of map completion and what the 3rd field of the locations box is meant to describe before telling me again how the visual properties of a marker is the most important thing ever." I suggest you re-read the very first post in this section, as well as re-read my previous comment because I explicitly stated that the visual properties are not important - that is, in fact, something you suggested with your comment of "Some are even different graphically because one is underwater (referring to Malchor's Leap here) and this affects the texture and lighting data used." as a reason to separate the page by location.

The only skill challenge events that exist are the fighting ones, and only them. "Commune with Ancient Energy Source", Examine Temple of the Ages, Commune with Grenth's Door, etc. etc. are non-existent in the game - just as the codex skill challenge events were. The wiki literally crafted these out of thin air just in order to establish a non-existent consistency where all skill challenges have events (again: they don't). There are literally 5 kinds of skill challenges, only 2 kinds have events. And of those 2 kinds of events, only 1 are triggered by objects (the "horde" fighting skill challenges - where you fight 1 stronger enemy and 2-3 weaker ones). Konig/talk 10:59, 28 October 2012 (PDT)

@Yandere: Many skill challenges are easy to reach and to obtain (the majority), but many are really obscure to find (I can think of several such in Orr) and others are really tough to obtain, at least without aid (again, I can think of some in Orr). In both cases they will need walkthroughs about how to find them and/or advice for fighting and minimizing added foes. It's inappropriate to take an uber hardcore player position and say that all skill challenges are trivial to find and to obtain. If it were all trivial the wiki wouldn't be half as popular as it is. It's popular because it's very helpful to players of all kinds and abilities! GW1 and 2 are both for the casual player as well as for the hardcore one, and the wiki is especially important for the casual player who does not have the time to try alternatives for a week. It's also very important for the less well equiped and less able-bodied player who needs advice on the easiest ways of tackling hard skill challenge encounters, not to mention finding the ones that are cleverly hidden in the first place. The GW2 wiki has an important role in the accessibility of GW2. Morgaine 14:40, 28 October 2012 (PDT)

@Konig: You're being churlish in complaining about my use of the word "event" in describing the process that accompanies obtaining a skill point. I don't have a separate word for it and I'm fully aware that the word "event" has a specific meaning in the game, which is not exactly the one that applies here. Nevertheless, there is a "process over time" associated with obtaining a skill point at these skill challenges, even if they are of the "Commune with" type --- this process commences with a dialogue with some entity and then takes a few seconds to complete the communing. During this period you can be interrupted and you can fail it, so it's clearly a process, a tiny event of your own. Give me another word if you don't like "event", but I'm certain you know what I mean because it's obvious that there is an extended process occurring.

But the objection is churlish anyway because some of these skill challenges are most definitely "events" using the standard GW2 in-game terminology, and they even have orange event circles around them on the map. They're events in every sense. What's more, some Commune-type skill challenges not only require you to Commune with the marker but also require you to kill an NPC and its entourage, so they're very much full events. There are many shades of event among skill challenges, and not a single one of them entails simply reaching a statue as one simply reaches a POI or a waypoint. There is always a process of some kind involved. That's the "event" to which I was referring, an extended process, and this process is always different to the marker object. It's totally different in kind , not just distinct and separate. I don't see how they can even be confused. Morgaine 15:08, 28 October 2012 (PDT)

"some of these skill challenges are most definitely "events" using the standard GW2 in-game terminology, and they even have orange event circles around them on the map." Yes, some skill challenges do. The fighting ones. Never - ever - the communing ones. There is no event with them. So they are just a communing. A dialogue option that grants a skill point if you don't get hit during a time duration. This is not an event, nor is this something so spectacularly unique from non-event objects that they should be divided from them for that sole reason. Konig/talk 15:25, 28 October 2012 (PDT)

Good, at long last you're agreeing that there is a process that occurs, even though neither of us really has a good word for it, but being a process it's totally distinct in concept from an object, and therefore the Skill Challenge cannot under any circumstances ever be an object like a statue. That's just the location marker and initiator, or it could be even less than that, just an adornment, with the actual marker and initiator being the blue skill challenge icon. Indeed, the latter seems like the better interpretation, since the same object without the skill challenge icon clearly does not mark a skill challenge. The role of the blessed statue becomes less and less the deeper we analyse the real situation and relationships here.

Linking the Skill Challenge field in the Map Completion column to a page about statues is then seen to be not only incorrect, unhelpful, and misunderstanding of what actually happens during skill challenges, but downright comical. Leave the poor statue in peace, it has almost no bearing on skill challenges at all. The comparison with vistas and their fluttering banners applies exactly. Morgaine 18:31, 28 October 2012 (PDT)

The point is a process occurs, which is so basic and uninteresting that any documentation beyond one article isn't worth it. The only interesting part of the skill challenge is the blessed statue. You commune with a place of power. But what lore is attached to this place of power? It is basiclly the only thing that is worth of a documentation. So yeah there might be a distinction between the challenge and the object, but the object makes the challenge.

There are some skill challenges that are attached to jumping puzzles. One of them is in Orr the Vizier's Tower, but you don't need a walkthrough for this because the jumping puzzle has a walkthough already, including a youtube link. All other skill challenges in Orr are dead simple. - Yandere 04:50, 29 October 2012 (PDT)

Event Lists

hello, I am a rank amateur so please excuse my question if it has already been decided. I have been doing some work on Queensdale and Wayfarer Foothills. I am soon going to Caledon Forest, The first two do not have icons in front of the event list items, the third does. Which way is "right" way? Personally I prefer the no icon version but... Thanks. Bernardus 19:57, 1 November 2012 (UTC)

Need some advice

I can see you have been working on the cartography on the wiki and I have a couple of questions. One is whether I should include generic npcs such as Noble, or Citizen on pages for different areas? I am currently working on Divinity's Reach areas, and trying to complete those pages. I noted that there are many with location-stub on them, and was thinking I could finish completing the pages. I am just not sure what makes an area page complete? A good example is Plaza of Grenth. I think it may be done (with the exception of generic named npcs) but before I remove the stub I want to be sure. Should area pages have a map? Is there anything else that should be added? Any advice you can give me would be appreciated. Surriela 22:11, 5 November 2012 (UTC)

Hey, the definition of "complete" is something that only the majority of the wiki can agree upon. I'm going to move this conversation to the cartography project found at Guild Wars 2 Wiki talk:Projects/Cartography so everyone can reply and help you out! — Andrealinia 09:40, 6 November 2012 (UTC)

Now this is moved over, I'll respond to your question ^_^. I don't believe that the page you linked is classed as complete. If you look at Gunbreach Hills that page has a lot more infomation compared to Plaza of Grenth. It also has a better/more correct/the correct (not entirely sure which) layout. As for the stub template. I, personally, think that should only be removed when there's only one or two sections that are incomplete (see the page I linked as an example) — Andrealinia 09:43, 6 November 2012 (UTC)

There's a big difference there - Gunbreach Hills is in an explorable zone, while Plaza of Grenth is in a city. Gunbreach will of course have a lot more stuff to document. —Dr Ishmael 13:46, 6 November 2012 (UTC)

My bad, didn't see it was in a city. — Andrealinia 14:06, 6 November 2012 (UTC)

Does anyone have an example of a completed city type area.Surriela 01:30, 7 November 2012 (UTC)

Event List Formatting

I am told that event lists should include an icon i.e. icon event name - that's fine On looking around, there's

(55) This event

This event (55)

This event (Level55)

(icon) This event (level 55)

Which format is it the consensus to use?

Thanks Bernardus 19:56, 6 November 2012 (UTC)

In explorable zones it is: * {{event <type>}} [[<event name>]] (<Level>)

You can look this up here and Caledon_Forest which is the reference article. - Yandere 20:02, 6 November 2012 (UTC)

I'd prefer "(icon) This event (55)", as that's well-established on meta event pages, and NPC pages have levels last. Manifold 20:06, 6 November 2012 (UTC)

Thanks, I thought that was the way but since I have seen so many variations, now I know. Also, for a newb, it's not always intuitive where to find definitive advice on this or other matters. If you know where to look, then it's easy, if you don't then it's obscure. Bernardus 20:19, 6 November 2012 (UTC)

How about (55)(icon)This event ? Since zone levels usually go from north to south, left to right (or reverse), having list ordered by levels would make it way easier to locate specific event ingame--Leriel 11:55, 17 November 2012 (UTC)

Even further: http://wiki-de.guildwars2.com/wiki/Fluchk%C3%BCste#Events this list also divides events by subareas. It expands size of list a bit, but i believe this is a great change. Can i get any opinion on this?--Leriel 10:44, 28 November 2012 (UTC)

The issue I see is that some events span multiple areas, so it'd be hard to keep accurate by location. Konig/talk 16:43, 28 November 2012 (UTC)

Good point. Do you reckon it would hold value to list events this way by starting point and put event progression information in event page?--Leriel 10:11, 29 November 2012 (UTC)

I always like to push parts that are of uneven length to the back (i.e. the level). This keeps the left margin the same, rather than getting different indentations due to the level. If the icons become of different width, I'd propose moving to the back as well. The current convention on NPC levels in location sections is to put level after the NPC name. -- ab.er.rant 02:06, 1 December 2012 (UTC)

I was so up in orr areas that i forgot levels can be single digit - thanks for reminding me. From now on i will stick to "(icon) This event (55)"--Leriel 08:32, 4 December 2012 (UTC)

(Reset indent) Hmmm, I just had a random thought - would it be possible with dpl/smw listing to pull from event categories (e.g., Category:Cursed Shore events the event names and from those article names the icon and level (by pulling out the infobox's parameters for | indicator = and | level = - perhaps even the event-success/event-fail parameters too)? If so, then we could perhaps make a template or other sort of coding so that the lists are automatically updated in the proper format. Not a big necessity, but would prove helpful for when new events get added/found. Konig/talk 17:15, 4 December 2012 (UTC)

That's certainly possible, but it would be very difficult to format event chains. —Dr Ishmael 17:20, 4 December 2012 (UTC)

You have no idea how happy i am you wrote it - i have been thinking about it since i read about DPL today. Additional great thing would be that we could get rid of duplicate data (eg. events need to be put separately in Cursed Shore and then again in Azabe Qabar, the Royal Tombs), the same thing can be even done with location table - think about how much data duplication can be removed this way!--Leriel 21:53, 4 December 2012 (UTC)

Take a look at first list on this page: User:Leriel/DPL this is a plain list that i managed to pull from Category only. Chain nests and meta relation are obviously missing, but this is just me testing the water and list is already there. Probably the best solution would be to pull events from location pages like Winterknell Shore, but current agreed formatting (";Events", like seen in Azabe Qabar, the Royal Tombs) may not allow to do so, not sure yet. Opinions?--Leriel 13:29, 5 December 2012 (UTC)

Generic Named NPCs

Wondering what we are doing with "Citizen" "Noble" etc - should they be included in the NPC list for locations?Surriela 15:47, 12 November 2012 (UTC)

Of course. Konig/talk 19:59, 12 November 2012 (UTC)

Recipes

So upon looking at Diessa Plateau the recipe levels have been added in (which is a pretty good idea tbh) but I'm presuming that we're wanting to move the level to the end of the line and put it in brackets as per everything else. However, I wanted to ask opinions on how they should be categorised. I would prefer to see all the cooking ones together, all the armorsmithing ones together etc. but at the moment they're grouped by NPC that sells them. So yes, opinions? — Andrealinia 08:01, 13 November 2012 (UTC)

I prefer by vendor but there's no logic to it, just like it that way. Bernardus 08:03, 13 November 2012 (UTC)

By vendor is more logical. That way, you can do:

<vendor name>

• Recipe: <recipe name> ( 20)
• Recipe: <recipe name> ( 10)

<vendor name>

etc.

By discipline, you have to do it like this:

Artificer

• Recipe: <recipe name> - <vendor name> (10)
• Recipe: <recipe name> - <vendor name> (10)

Chef

• Recipe: <recipe name> - <vendor name> (20)

The first is a lot more compact. —Dr Ishmael 13:56, 13 November 2012 (UTC)

I don't think the recipe's level is necessary. It's a secondary attribute to the recipe itself, truth be told, and when people are looking for what recipes are available per zone, I doubt they'll care about the level of said recipe.

As for order, I would prefer grouping by discipline, but without breaking the list. E.g.,:

* {{<discipline>}} [[Recipe: <recipe name>]] - [[<vendor name>]]

If people believe the levels are really necessary, I'd just move those to the end ala event format. So:

* {{<discipline>}} [[Recipe: <recipe name>]] - [[<vendor name>]] (<level>) Konig/talk 23:41, 13 November 2012 (UTC)

That's even worse because you are repeating both disciplines and vendor names, where if you use an outline format like mine you at least save repeating one or the other. —Dr Ishmael 23:47, 13 November 2012 (UTC)

{{<discipline>}} [[<NPC name>]]

:[[<Item 1>]]

:[[<Item 2>]]

:[[<Item 3>]]

And sorting by discipline then NPC name alphabetically looks better to me. And you should sort by discipline first because players looking at a list of recipes in a zone don't care about NPC names. I view it as something like user:Relyk/craftlist. Stout Darkmind has three different disciplines, which makes it ugly sorting by name or discipline, so I want to stick him by himself. I don't like the fact that sorting by discipline ends up listing the same NPC multiple times in a row but its preferable over NPC name.--Relyk 00:54, 14 November 2012 (UTC)

"That's even worse" - that's a subjective matter, really. One I won't bother upholding since it's not preferred. Konig/talk 01:23, 14 November 2012 (UTC)

Not really - having to repeat text within a list is not good. Finding an organizational structure that removes the need for repeated text is better. —Dr Ishmael 02:11, 14 November 2012 (UTC)

Concensus please - on the way we are listing NPCs

I have noticed that there seems to be two styles for listing NPCs - one using : and one using * to list them. The Guild Wars 2 Wiki:Location formatting page MAY be out of date but states that NPCs are listed with the colon (:). Maybe there were discussions about this - but which way is correct as of now? Surriela 00:15, 14 November 2012 (UTC)

Every list I've seen on the wiki overwhelmingly uses *, let's use that. Manifold 00:25, 14 November 2012 (UTC)

(re-post) On general principle, bulleted lists are much preferred over non-bulleted for any kind of list. —Dr Ishmael 00:45, 14 November 2012 (UTC)

Then if so, the page for location formating needs to be changed to reflect that.Surriela 01:31, 14 November 2012 (UTC)

So, list the NPCs with *, list the resources and pets same way? For consistency? Surriela 23:54, 14 November 2012 (UTC)

On general principle, bulleted lists are much preferred over non-bulleted for any kind of list.--Relyk 23:57, 14 November 2012 (UTC)

There are, of course, exceptions in certain cases. In resource node lists, the icon performs the function of the bullet, so don't use * or you get a double-bullet effect. —Dr Ishmael 01:21, 15 November 2012 (UTC)

...Let me go fix that.--Relyk 01:27, 15 November 2012 (UTC)

I would say that the Services section for under NPCs would be the same as resource nodes, since it was without-discussion-agreed to use icons there (at least I don't recall any discussion, but note I'm not against it). I'd also say the pets section on zone articles (not area articles since those are formatted differently due to decreased radius of possible area to find) should stay without bullet points. Konig/talk 01:35, 15 November 2012 (UTC)

How about interactive maps?

Taken almost directly from gw1 wiki: User:Leriel/Sandbox (Sorry if this is wrong place, didn't know where else to ask for opinion about it)

This could also greatly benefit from having events laid out on a map (like in mmorpg-life website) - otherwise specific event is somewhat hard to locate.

Thoughts?

This has previously been discussed on User talk:Ee/Interactive Map trial

The gw1 maps were pretty gay to setup since the coordinates are clunky and pinpointing takes ages, I can tell you that from doing 90% of the ones on gw1 wiki (and most are ugly cept elite area maps). My guess as to other responses; "Extension:Semantic Maps". Though if we could have an identical setup to this, except with wiki links to pages instead of popup info I'd think that would be great. --Chieftain Alex 16:03, 17 November 2012 (UTC)

Thanks for your reply. Setting maps like this is pain indeed and i did this seemed like an only option possible :) But if semantic map is coming, that's great and i will just hold on for now. IGN wiki map is best one i have seen so far, but wiki itself looks like it is created for articles rather than for an in-depth knowledge which is something that bothers me. Either way i will wait for this wiki's own maps :)--Leriel 09:03, 18 November 2012 (UTC)