Guild Wars 2 Wiki talk:NPC formatting/Archive 1

Stubbed out (sorta)

Ok peeps, we've got us a spot to use for documenting how we decide to format pages involving NPCs. Don't take any of the content I added as law: If it makes sense, feel free to keep it. If not, change it to something that does. And by all means, flesh it out. Torrenal 02:49, 12 June 2012 (UTC)

Thanks for getting this up. I've been looking around at various NPCs, and I think we might want to direct some attention as to the handling of merchant item tables in general before we start winding up with more huge item lists...As it is now, they're currently an odd assortment of styles that are a bit unwieldy and unappealing. I agree with including some sort of higher rarity designation, but i wonder if it might be given its own slot or color background or whatnot. Thoughts? Redshift 03:52, 12 June 2012 (UTC)

For "region" Konig and I have been putting the "zone(s)" (Snowden Drifts-level) the NPC appears in, and then include a Locations header, such as on Grawl_Berserker. Many enemies need an Abilities and Drops section, too. Manifold 04:03, 12 June 2012 (UTC)

I would suggest a header for the items table, "Items offered". -- ab.er.rant 16:12, 12 June 2012 (UTC)

Location

List this as the zone? The sub- region inside the zone? Or both? What about NPCs with multiple locations, or appearing only in instances? Torrenal 15:10, 12 June 2012 (UTC)

Zone is fine. Both is too much detail I think, especially when you start considering NPCs with multiple locations. Having it show only zones allows us to more specifically state the actual area in the description itself. I always prefer writing a short paragraph to try and describe the NPC a little. A page with an infobox and a table consisting of items just doesn't seem like a proper wiki article. -- ab.er.rant 16:12, 12 June 2012 (UTC)

That brings up a good point. We have several categories of 'being' we can document. We have the poly-case: Generic monsters and townsfolk both fit in this category. Then you have the singleton case, the NPC appears in a single spot and never moves. You then have the Duplicate Singleton case, where a specific named NPC appears in multiple locations (The named NPCs appearing in personal stories might fit here). When designing this page, we will either need to have rules for each case, or design a separate formatting guide for each. Saving *that* discussion for another day, I propose:

• Poly case: Describe the location only in general terms. For the Grawl Berserker mentioned above, I might get as generic as 'Ascalon', and describe location more specifically in the body, but even there not document every single spwn location.
• Singleton case: I've actually seen two types of this.

• NPC appears in a single location / does not move. - Document in infobox with Zone + sub-region.
• NPC appears in a single zone, but moves around -- If the NPC has a home location and leaves it only for events, document the home location zone+sub-region in the infobox, and describe movements from it when describing the events the NPC partakes in. If it's homeless (I've not seen any) then document only the zone in the infobox.

• Duplicate Singleton - Example: Eir Stegalkin -- She appears in multiple locations for multiple personal story segments. Do not document location in the infobox.

Part of my reason for wanting more detail in the infobox is that's w here I first look if I want to find the NPC. Not buried three paragraphs down in the description. I'd be happy with just sub-region, except there will be more sub-regions than even experienced players can remember each one, and I don't expect every sub-region to get its own page (they may, but I'm not going to rely on that).

-- Thoughts? Torrenal 23:26, 12 June 2012 (UTC)

• I agree for the singletons; when looking I think it'd be preferable to see the area and map (sub-region and zone :P) listed for the stationary NPCs because we can have that degree of specificity. It also aligns with how specific we are with the event/heart infobox. The only issue is that this infobox just currently has one location parameter, and that's just going to make things slightly messy--adding another is simple enough, but we'll just have to untangle which one is which.
• For the roaming NPCs, I might just go with the map it's in--it's hard to tell which one is the 'home' area, and a number of the escort quests link two areas. The NPC escort quest in Beetletun winds up as a service NPC in Beetletun but starts elsewhere, iirc--things like that make it a little less useful.
• For the generic monsters, listing the maps where there are significant concentrations of them might be the best bet; this is probably going to be in flux as we see what distributions are like. For example, things like Barracuda and other aquatic creatures are pretty ubiquitous...just have to see. Redshift 00:21, 13 June 2012 (UTC)

Blimey, I forgot about the wandering merchants. I was thinking more of the 'Lets make a forray and clear out that enemy structure' type thing. Yes, wandering merchants, I've no issue listing just the zone, and then in the body of the document give specifics on where to find them. I'll put up a 'location' section on the main page. Torrenal 04:22, 13 June 2012 (UTC)

Was there a previous discussion on why we don't want a "Location" section? With so many different "cases", trying to come up with rules on how to insert them into the infobox is just going to be difficult to follow or standardise. I would suggest that we put known home locations (fixed and never moves, poly case) in the infobox. And then have a location section that explains exactly where in the home location, as well as any other special locations where so-and-so NPC will be encountered. -- ab.er.rant 16:09, 13 June 2012 (UTC)

I'm not aware of one, and I don't have any real strong opinion of it (yet :D). I'm perhaps on the same line of thought as you; I'd like for it, for at least the stationary interactive NPCs, to be somehow more meaningful if we're going to devote a section to it. Otherwise, having a section just for a short [[Zone]] <br> [[Area]] is probably indeed better kept in the infoboxes. Talk:Bestiary might be the place to bring up / revisit this topic with mobs. Redshift 12:03, 14 June 2012 (UTC)

I'm in favor of multiple levels of location in the infobox. I'd like to see us emphasize information at-a-glance, so that people can look at the info box and instantly see where to find NPCs.

• For fixed NPCs (always reachable in the same spot), I think we should be as specific as possible and show the nearest WP or PoI (I prefer WP, because that's how most everyone I know gives directions, but PoI works, too).
  • Example: Alf the Banker (Divinity's Reach, Minister's WP)
• For roaming NPCs, let's identify up to three specific locations in which they are notable NPCs, e.g. if Fred is involved in a farm Event which leads to him taking command of a nearby fort, the site of another event, let's list both.
  • Example: Fred (Fred's Farm, Freddennia & Fred's Fort, Fredennia)

I'd also like to see maps indicating locations (in Fred's case, it could be one map, showing his "migration"). – Tennessee Ernie Ford (TEF) 09:14, 16 June 2012 (UTC)

This is really enough content to justify having a Location section, I'd think. For roaming NPCs, especially. WPs for service NPC are useful, especially for bankers and crafters, but they're not going to be useful for the NPCs and mobs (mostly the mobs, which this box also currently services) out in less accessible areas. Regarding putting it in the infobox, I wonder if that level of specificity in the infobox would be manageable or useful, given the amount of information that we're starting to try to fit in the infobox. Lastly, there are already fields for maps! (If you look at the example at the template page, you just have to toggle it to show.) Redshift 11:00, 16 June 2012 (UTC)

While I agree that the infobox should be info-at-a-glance, attempting to put zone + area + waypoint is too much. While it's fine for NPCs with a single location, NPCs that appear in multiple locations (excluding personal story) would turn into clutter. Also, if a user wants to pinpoint exactly where an NPC is, specifying a waypoint is not enough. No matter how much location specifics you put in an infobox, the user will need to look at a map, or a description on where exactly to find the NPC (direction, which level, how far, nearby landmarks, etc.). So why not keep the infobox a little cleaner and use the proper medium for giving someone directions - either a picture, or an explanation on how to find the NPC. -- ab.er.rant 15:51, 17 June 2012 (UTC)

Quotes

Should we bother with NPC quotes at this point? You know, the little text balloon that comes up randomly when you hit 'F'. I checked a few NPCs and found that a similar type of NPCs appear to share the same set of popup quotes. -- ab.er.rant 16:12, 12 June 2012 (UTC)

Not all quotes are repeated. You have event dialog (ie: Personal story, Task completion, etc), which should be recorded under the respective event, and I could see some of it possibly being duplicated here. If we don't record quote information, we may not find where it gets repeated. Yes, if they are repeated among a category of NPCs (say, 'All Charr Merchants'), then we don't need to document it under each Charr merchant, we could document it on the general merchant page. No harm letting people gather data. We can always cull excess/repeated content after we determine it to be such. Torrenal 23:02, 12 June 2012 (UTC)

Content-less headlines in NPC articles

→ moved from Template talk:NPC infobox

I've noticed more and more people add placeholder headlines to NPC articles, and in some cases even placeholder tables. Personally I find that completely pointless. The headline can be added when there is content to support it. What is the consensus though?

Also, could we get a couple of reference NPC pages going? Pages that we can use as reference as to what should be on each respective NPC type's pages. — Rhoot 04:01, 13 June 2012 (UTC)

People who aren't as used to editing wikis are more likely to add to an existing table than to find out how to add a table and then fill it in. Manifold 04:05, 13 June 2012 (UTC)

its also quicker to just use something already existing and fill in where you need to then it is to write a new table ect. also if you are referring to a npc that i added today that was because i had to go and didnt have time to fill in the rest of the dialog and knew i would come back to it with in the hour. or upload the screenshots of dialog- Zesbeer 04:10, 13 June 2012 (UTC)

Not sure what you mean by 'content-less headline'. Is it a '== ==' page section? Part of why I want to see these formatting poages (NPC, weapon, armor, crafting, etc) put together is we can put page templates on them that users can pull from, making it both easier for them to add content, and less likely that we'll have to go back and fix things. And lets be honest, I'm being partly selfish here: I create the odd page now and then. I like using templates too ;) Torrenal 04:18, 13 June 2012 (UTC)

For what I've been doing today is that the two — Items offered and Dialogue — are specific and certain to the type of NPC that I wound up focusing on. It's not speculative and the data is out there, and I agree that having a consistent framework ready to accept the data that other users may have gathered (or remind other users of data still left to be gathered) is more beneficial at this point in time. This is also the reasoning behind the placeholder tables. It is a bit messy, but I think that in general everything is messy right now and that seeing the framework and scaffolding is more useful at this point in time. Redshift 05:12, 13 June 2012 (UTC)

Torrenal: Yes, that's exactly what I mean.

Zesbeer: People who aren't used to editing wikis are more likely to add the text outside the table rather than figuring out how tables work. The fact that they can do that and someone else will fix it is what makes wikis go around. And wiki tables aren't exactly intuitive.

As an example, the table on this page just looks broken. It might just be me, but we're getting an increasing amount of users on this wiki. The last thing I want to do is scare them away due to half the wiki containing broken tables and placeholders. I could live with something like {{stub section}} below those empty headers though. — Rhoot 08:19, 13 June 2012 (UTC)

My point with all is, we should try to avoid things looking broken and strive towards people realizing that it is intended to look that way. Empty headers look broken. A small text that says content is lacking and encouraging the visitor to add some does not. Normally I'm against stubs, but it's a lot better than having nothing there at all. — Rhoot 10:42, 13 June 2012 (UTC)

I understand your concern, and normally I would be right there with you. However, I think in general both the contributors and the audience need to understand that this is a still a work in progress, and while ideally we'd be able to continuously document the game and pick up all the pieces left behind to deliver everything whole and intact, the actual practice is that we've got different pieces with different and potential contributors. A user looking for information is likely aware of that, and a user looking to contribute will want to add to what we've got. If we wanted to be formal and mark where more information is still needed, that would pretty much encompass every single section of every single service NPC page (missing dialogue, missing rarities, missing levels, locations, purposes...). If we are ok with delivery of unformatted and raw information, then I think there should be similarly some leeway, again, at this point in time, for the framework of the pages. That said, I'll also keep an eye out for this and try to do some clean-up and covering up of the naked bits where I find them. Redshift 11:59, 13 June 2012 (UTC)

I would support this only on a case-by-case basis. For NPCs, "Items offered" is fine, but not for blank "Dialogue" sections. I would think that the number of NPCs with actual dialogue would be in the minority, causing the majority of these sections needing removal at a later date. -- ab.er.rant 16:15, 13 June 2012 (UTC)

I think I agree with 'case-by-case' in a 'service-by-service' manner. Basically, if it's a definite section that needs content for that subset of service NPCs, then I think it's fine to have it ready and waiting. Meanwhile, sections like 'Notes' or 'Trivia' are definitely sporadic, and I would agree that they should not be inherently included (and I've gone ahead and cleaned that up for the renown NPCs). Redshift 16:31, 13 June 2012 (UTC)

Dialogue formatting

Thoughts on dialogue formatting? We are starting to have multiple systems in use here as well. Redshift 17:18, 13 June 2012 (UTC)

I was just about to bring this up. I'll add 3 subsections. Add more as needed. -- ab.er.rant 17:52, 13 June 2012 (UTC)

Indentation

Compare Farmer Diah vs Farmer George. The former has greater indentation than the latter. The latter tries to line up the NPC response and all available options in the same line while the former indents conversation options. -- ab.er.rant 17:52, 13 June 2012 (UTC)

I have been trying to line conversation options in the same section if you move to another option I add a indentation I know some spots when I was first adding dialog used the other way before I realized that it makes no since (the indents conversation options style). I would also like to suggest maybe using a hide tag for more content so just like in game you have to click to see more of the dialog options.

tl dr:

• we should always use line up like on Farmer Diah
• add a hide tag to more dialog options.- Zesbeer 18:03, 13 June 2012 (UTC)

No incredibly strong preference here, but I think I tilt towards Farmer Diah. It looks a little odd, but when you then take into account dialogues like Kiryn Brant, having those layers of indentation instead of indenting on the NPC response makes a notable difference, I feel. Redshift 19:01, 13 June 2012 (UTC)

I really like that hide suggestion. *looks at Dougal Keane* -- ab.er.rant 03:42, 14 June 2012 (UTC)

Double quotes and italic/bold

It's just a matter of which is preferred:

"Hi there, generic NPC!" vs Hi there, generic NPC! vs Hi there, generic NPC!

Currently, I bold my character's dialogue options, and italicise the NPC's response. -- ab.er.rant 17:52, 13 June 2012 (UTC)

I think bold and italic should be standard, were as double quotes I don't care. If someone has a compelling reason for one or the other then state it as for now I would say drop them.- Zesbeer 18:07, 13 June 2012 (UTC)

I think it's obvious that these are quotes from the game, there's no need to wrap them with quote characters. —Dr Ishmael 18:31, 13 June 2012 (UTC)

I agree with dispensing with the quote marks, and they make for one less thing to worry about. I'm not keen on the bolding of the player response (or really, the bolding of any of the dialogue, actually)—it makes the dialogue too visually heavy on either side and is fussy to actually enter. I'd rather suggest having normal NPC text and italicized character responses. The italics also make sense to me because they suggest the choice of the dialogue being taken, rather than the bold that seems like it's just dialogue set in stone (if that makes sense). Moreover, these choices align with how it's presented in game—NPC text normal, character text in itals—and I don't feel that there's a compelling reason to change from that presentation. Forgot to sign; whups. Redshift 00:25, 14 June 2012 (UTC)

That's a good point, being the same as in-game. I'll undo my changes later. -- ab.er.rant 03:44, 14 June 2012 (UTC)

Without the quotes, how should we differentiate non-dialogue text? See Seraph Soldier Diedra. Bold the "Before acquiring renown heart" label? -- ab.er.rant 06:42, 14 June 2012 (UTC)

There's now {{dialogue icon|heartyes}} and {{dialogue icon|heartno}} in the dialogue icon template, but if there is a need for more delineation or we can decide on another alternative, then we should approach it. See Farmhand Abhean for an example. Similarly, we can (and, I think, should) do this for skill challenges, too (which abide by the same before-and-after dialogue settings)-- see Chhk the Windmill King. How is that? Redshift 11:46, 14 June 2012 (UTC)

Bold makes sense for those notation - take a look at Diedra again. I think that looks good. —Dr Ishmael 13:52, 14 June 2012 (UTC)

I do like the bold there, if we need to rely on more than the heart icon to differentiate it. That said, if we want to do that, should we streamline it and simply do Before acquiring the renown heart: instead of having the marker per line? I a) would like to keep that visual marker in there at least in some form and b) like the way the marker per line helps to keep things distinct but c) do worry that having it per line will be unnecessarily busy. Redshift 14:17, 14 June 2012 (UTC)

Bold is nice but you're right, the icon seems sufficient enough to differentiate it. Considering we're going to be stating the same "Before", "After" on so many pages, might be a tad redundant. What do you guys think of making a bigger gap? See Chhk the Windmill King. -- ab.er.rant 06:31, 15 June 2012 (UTC)

I think I do like the slightly bigger spacing; it does help. Redshift 10:07, 15 June 2012 (UTC)

On a similar note, does that mean it's more consistent _not_ to use italics and double-quotes in the "Quotes" section? -- ab.er.rant 03:24, 19 June 2012 (UTC)

Hi, new to editing and I'm a bit confused on the consensus of dialogue formatting. I used existing articles to base my writing on (my work e.g. Lieutenant Pickins) however I see now in the template that only the player dialogue is italicized, and which no extra quotes. Which is correct? I don't want to make extra work for myself going back and correcting lots of lines in the future. --Film11 01:34, 3 September 2012 (UTC)

Only player dialogue is italicized. Any other variations of doing it were before we sort of finalised it as per what's presented in this formatting guideline. -- ab.er.rant 02:43, 3 September 2012 (UTC)

I see, thank you. Looks like I have some work to do then :-) --Film11 10:44, 3 September 2012 (UTC)

Now, I'm not so sure of it again. If I put in a condition label, for example: "After completion of so-and-so event:", then that label becomes difficult to distinguish from normal NPC dialogue. I think we need to apply formatting on these conditional labels. For now, I've been applying <small></small> on a few of them. Would like some suggestions on how to deal with such labels. For example: Fjotli. -- ab.er.rant 06:18, 4 September 2012 (UTC)

I don't see bold used anywhere in dialogue formatting and I think it would suit this purpose quite well. Personally, I think small text should be used for "wiki-specific technicalities" (e.g. sic?). --Film11 17:57, 5 September 2012 (UTC)

NPC name

Due my use of bold and italics, I didn't see the need to add the NPC name's as prefix to the dialogue. I think the speaker label is only applicable for conversations that involves more than 2 characters. -- ab.er.rant 17:52, 13 June 2012 (UTC)

Have we ran into dialogs that take place between more then one person? Because I haven't only in the weird to people staring at each other cutseens have I ran into that.- Zesbeer 18:10, 13 June 2012 (UTC)

I think it's also obvious who is speaking what, as long as you use italics for your options, so there's no need for the NPC name, either. The only instance of different NPCs talking together is in cutscenes or the random audio-only environmental dialogues. —Dr Ishmael 18:31, 13 June 2012 (UTC)

Agreed; I'm not too keen on it but wasn't sure as to how far to deviate from the long dialogue blocks presented in the personal storyline pages. Redshift 19:01, 13 June 2012 (UTC)

Dialogue variants by player race / disposition

Beginning to realise that many dialogues are radically different depending on the player's race and disposition (barbaric, charming, etc), in ways that aren't always helpfully marked by the relevant icons. For instance many Charr NPCs in Plains of Ashford are much more aggressive to human PCs, and vice versa. Do we have any ideas on how to standardise formatting to reflect what races produce what dialogues? (Check out Archivist for an example of a conversation that only occurs for Charr.) - DustFormsWords 07:19, 13 September 2012 (UTC)

No particular consensus yet. I've seen (for so-and-so only) being added behind a particular line, but I'm more partial to adding a <small>(for so-and-so only)</small> at the beginning of a particular line. Can't seem to find the NPC where I did that though... -- ab.er.rant 09:09, 13 September 2012 (UTC)

Items offered table

I have something of a quandry. I need a table format that meets several fairly divergent requirements.

1. Needs to handle multiple object types (consumables, armor, weapons, etc), as a single merchant may sell 3 or more object types.

• Looks like weapons and armors get modifiers built in, so that would need reported, or at least captured.

1. Needs to handle identical objects with different rarities.
2. Needs to make the content available to SMW.
3. Needs to be easily editable by users.

Something tells me that a single table will not accomplish this. I think however, that much of the rest can be managed with intelligent use of templates. Torrenal 00:30, 14 June 2012 (UTC)

where are you applying this?- Zesbeer 00:32, 14 June 2012 (UTC)

Clerk Ulva would be an example. She has: Armor, rifle, torch, and accessory (each with blue & green versions). What she lacks is the crude salvage kit I'd seen with most karma merchants. If you want the terror example, add the kit, a harvesting tool, a crafting recipe, and some crafting mats. Such an example may not exist, but there are NPCs out there that sell crafting mats, recipies, or harvest gear with armor and weapons. Torrenal 00:50, 14 June 2012 (UTC)

Still any problems? I did Tiga Fierceblade this morning and she was a pain just because of all the stuff, but... the table entry itself is not overly complex, I feel. Of course, the more parameters you wish to have sorted by, the more complex it'll be, but you could probably add in a column for item type...but at that point you'd probably want to look to dpl (though not really easily transparent to users), which is out of my territory and more up in Dr's league. Redshift 00:58, 14 June 2012 (UTC)

Perhaps we are talking at cross purpose. Lets back up a step... that was just an example of an NPC.

Details to gather on the items offered section:

• All items are level 26.
• The armor all has an innate vitality + crit damage mod.
• The green armor includes a minor rune.
• The blue rifle has a power mod.
• The green rifle has a power+precision mod.
• The torch boosts vitality and condition damage.
• The blue spoon gives +power.
• The green spoon gives +power and +crit.

-Is there a single table format we can use for capturing all that detail, or will be be forced into using multiple tables? Oh, and all the detail really should be available to SMW so that we can index where all the karma merchant gear is at, by innate modifiers Torrenal 01:07, 14 June 2012 (UTC)

SMW is still a ways out, but again, an Ish and other more technically-minded contrib question :). What I do want to note is that I don't think there's a need for capturing all that detail in the merchant table. To be more specific, I believe the focus of the merchant table should be to list the items for sale, not to act as a listing for the item itself. Thus, save those details for their respective itemboxes. (In an ideal world, we'd be able to mousehover over the icon and have the stats/details show that way.) There's definitely utility in that information and being able to aggregate it and pull, but I'm not sure of the benefit of including it in the table (for the same reason that we're not hammering everything into a zone page). Redshift 01:18, 14 June 2012 (UTC)

I'd want it for the same reason Claw has it. I'd use it to tell if the merchant had anything of intereste to me. As it happens, claw has that 20x20 offhand I've been looking for... Torrenal 01:32, 14 June 2012 (UTC)

You can theoretically toss as much info as you want in the table; you just have to put it in. There are probably neat technical tricks, but for the tables that you're referring to, a raw code is basically going to look something like this:

{|{{STDT|sortable white}} ! Item !! lvl !! Rarity !! Type !! Item !! Price |- | {{item icon | First Haven Cloth Gloves }} || 26 || {{rarity|blue}} || [[Armor]] || +20 {{Vitality}} <br> +1 [[Critical]] || align="right" | 182 {{karma}} |- | {{item icon | First Haven Leather Gloves }} || 26 || {{rarity|blue}} || [[Armor]] || +20 {{Vitality}} <br> +1 [[Critical]] || align="right" | 182 {{karma}} |- | {{item icon | First Haven Gauntlets }} || 26 || {{rarity|blue}} || [[Armor]] || +20 {{Vitality}} <br> +1 [[Critical]] || align="right" | 182 {{karma}} |- | {{item icon | Lionguard Rifle }} || 26 || {{rarity|green}} ||[[Weapon]] || +10 {{Power}} <br> +20 {{Precision}} || align="right" | 588 {{karma}} |- | {{item icon | Lionguard Torch }} || 26 || {{rarity|green}} || [[Off-hand]] || +6 {{Vitality}} <br> +11 [[Condition]] damage || align="right" | 392 {{karma}} |- | {{item icon | Kidney Bean }} || 1 || Common || [[Ingredient]] ||   || align="right" | 3 {{karma}} |- | {{item icon | Crude Salvage Kit}} || 1 || Common || [[Consumable]] ||   || align="right" | 28 {{karma}} |- | {{item icon | Recipe: Jeggings}} || 99 || {{rarity|red}} || [[Recipe]] ||   || align="right" | 99999 {{karma}} |- |}

Does that help make it a little clearer? Redshift 02:08, 14 June 2012 (UTC)

Rather much. So the physical layout can work. That was my biggest concern. I'd omit the object type, in most cases that'll be obvious. Where it's not, the user can click the object for details on its page. I'd omit level for crafting materials. It's by no means unusual for one iem to have multiple different levels assigned (Tailor 150, chef 75, Artificer 125), and I'd rather not confuse people by trying to list a level for them here. Further, I'd make the level column optional, for instances such as the merchant which sells only crafting materials, or non-level restricted objects. Cons and such can get lengthy text, so I'd be inclined to omit it here as a general rule. That, or we'd need the multi-use column last, which makes a problem of placing the price column... I've somewhat updated the table under Clerk Ulva to match. I think it can work... Time for me to draw up some templates. Is now a good time to ask about colors to use? Torrenal 04:48, 14 June 2012 (UTC)

Colours for which part of the table? -- ab.er.rant 07:05, 14 June 2012 (UTC)

Colors how? And yes, that was sort of a demo table (if the Jeggings didn't make it apparent ;))—the current version at Ulva looks reasonable and we can continue to adjust as necessary as the discussion goes. Redshift 11:55, 14 June 2012 (UTC)

Merchant table, work in progress. The hiccup I see is if I move the item level to its own line, the template breaks. I believe its interacting poorly with the table in that case. Any thoughts on fixing that, besides always stringing everything in onto one line when using the template? Torrenal 05:10, 15 June 2012 (UTC)

As for colors, I was thinking of using a different title-row color for each currency coin merchants use, say, yellow. Karma merchants, magenta or so... Torrenal 05:10, 15 June 2012 (UTC)

got the template problem sorted. Templates parse named and unnamed variables differently -- specifically, unnamed variables do not have little things like newlines trimmed. Should have a complete set of templates by this time tomorrow Torrenal 00:10, 16 June 2012 (UTC)

Merchant tables,a demo version -- Can I get a vote on this? Good, Bad, Ugly? And will it let us easily embed things in SMW (which is 80% of my drive for the templates)? Be sure to mouse over the links and compare them to the stated name of the objects -- I'm trying to parse out the name from the components, and use common links for items with common base objects and different traits. That's going to mean some items in the list do not show with the same name the merchant sells them with, but those items get the name I list when bought. I'm also confident that accessories will require some additional work for back items & doubloons. Torrenal 17:00, 16 June 2012 (UTC)

Absent comment on it (do try to at least look at the doc I put in the templates) I'll start entering data with them tomorrow -- I got a slew of screenshots from merchants, allowing me to populate a number of tables in the detail this table will take. Torrenal 02:11, 17 June 2012 (UTC)

You need a possibility to add stacks. I have seen stuff that's sold per stacks of 5, 10 and the like. --Ee 07:24, 17 June 2012 (UTC)

I've seen those too, come to think. Thanks for the reminder. Time to see if I can spot the screenshot... Fortunately, that should be just the generic item template. With luck, they won't require extra columns. Torrenal 07:43, 17 June 2012 (UTC)

Found in screenshot 118, glad I didn't have to go through many. Fixed, although the fix, tbh, is crude. It works just fine tho:

{{Inventory/Table Header|hideLevel=y|hideRarity=y|hideModifiers=y}}
{{Inventory/Item
 | name= Lump of Tin
 | plural= Lumps of Tin
 | quantity = 10
 | level = -
 | rarity = white
 | type = crafting material
 | price = 30{{karma}}
}}
|}

This adds a quantity and a plural parameter. If the plural parameter is set, it uses that in place of the displayed name, but the link and icon still come from the actual name. It does make the quantity part of the link... but it looks very close to the merchant inventory in-game. -- Torrenal 07:58, 17 June 2012 (UTC)

It might be a deviation from the item title, but if you're including it in the item name and if the number interferes with alphabetical sort, might it work to pop it at the end? As in, Lumps of Tin (10). Redshift 10:26, 17 June 2012 (UTC)

that is quite very possible. Before I make the change, is it possible to have the table sort on one value, but show another? Torrenal 14:02, 17 June 2012 (UTC)

(Reset indent) That template for recipe sheet entries just seems broken to me. We should stick with the official name ArenaNet uses for the item. It is not ok to rename items en mass like that when there is no reason not to use the official name. A quick look at the recipe sheets category shows that other editors follow the same convention. --Valshia 23:06, 28 July 2012 (UTC)

Recipe: in the front of a name is for items in the Recipe namespace. I beleive the decision has already been to not create a unique namespace for recipes. Further, we do need to disambiguate between Recipes and the objects that unlock them, giving them all the same name would be silly. —Torrenal 05:19, 29 July 2012 (UTC)

I'm not saying we shouldn't disambiguate. I'm saying the game already has a naming convention that does just that and we should follow its lead instead of creating a different one on our own. It takes more than simply putting a colon in the page name to create a namespace. All the current "Recipe: Foo" articles are in the Main namespace and the wiki appears to handle their existence just fine. --Valshia 21:09, 29 July 2012 (UTC)

And I'm saying that the game naming system is in direct conflict with the wiki naming system. —Torrenal 01:45, 30 July 2012 (UTC)

Gah, let add 'Because you can do something, doesn't mean you should', and back this up a step.

What names do you propose for each of these pages on the wiki: The page for the object: Shadow Leggings. The page for the recipe: Shadow Leggings. The page for the Recipe unlock: Shadow Leggings. It's clear you have energy on this, so please explain for us how each of these objects gets documented on the Wiki —Torrenal 01:58, 30 July 2012 (UTC)

Character Name vs Player Name

I've always been opposed to using [Player Name] as part of the dialogue. I mean, the NPCs in the game don't refer to my real name; they use my character's name. [Character Name] is the correct placeholder phrase to use. Can we establish this as part of the guidelines? -- ab.er.rant 02:38, 19 June 2012 (UTC)

no this is trivial and a non issue. if you want to change the edits to character name then do it but lets not have nazi editing.- Zesbeer 02:55, 19 June 2012 (UTC)

No, it makes sense - "player name" is the name of the player, i.e. Dr Ishmael or Aberrant or Wesb-- er, sorry, Zesbeer. :P (using wiki names instead of real names) "Character name" is the name of the in-game character that Dr Ishmael or Zesbeer is playing, and that is what is used in the dialogues. It's not me speaking the lines, it's my character. So I agree with Aberrant that we should be using "character name" instead. —Dr Ishmael 02:59, 19 June 2012 (UTC)

honestly i am going to put what ever i think of at the time.- Zesbeer 03:02, 19 June 2012 (UTC)

That's fine. That's how wikis work; people type in what they want, and other people fix it. I just don't want people to undo my "nazi editing" when I replace "Player" with "Character". -- ab.er.rant 03:16, 19 June 2012 (UTC)

cool story bro.- Zesbeer 03:25, 19 June 2012 (UTC)

no objection, as long as the proper attitude is put forward with the edits. Torrenal 03:55, 19 June 2012 (UTC)

thinking on this some... Could the nazi edits instead be referred to ad 'ninja edits'? MIT help with the whole 'proper attitude' thing. Torrenal 05:54, 20 June 2012 (UTC)

Well, I think of it as just an edit - like changing British English to American English. You're not really "correcting" and there's no attitude involved - it's just making it a little more appropriate; I wasn't proposing that we go on an editing spree just for this. -- ab.er.rant 02:43, 21 June 2012 (UTC)

Services

We need a list of services for reference. As it is now, I've seen people referring to karma vendors both as 'Karma' and as 'Karma Vendor'. And I've seen both weaponsmiths and master weaponsmiths referred to as simply 'weaponsmith'. Anyone willing to start one? — Rhoot 14:18, 19 June 2012 (UTC)

stub added, flesh it out to your heart's content. I've added the three I've got any opinion over. Torrenal 05:53, 20 June 2012 (UTC)

Are portal masters a service? Worth a seperate category? Questgivers sure are - oh pardon me - heart starters/event starters. --Ee 05:39, 21 June 2012 (UTC)

I've no recollection of such a critter, can you describe them? Do they have the words 'portal master' over their head? Do the get a special icon over their head? Do they perform a special service? Torrenal 07:00, 21 June 2012 (UTC)

Do you mean the NPCs manning the asura gates? Redshift 10:57, 21 June 2012 (UTC)

Capitalization. I'd prefer the in-game capitalization (Master Armorsmith) over lowercase (Master armorsmith). Any objections? — Rhoot 11:32, 21 June 2012 (UTC)

Yes, i mean the NPCs at the portals. It's just a question on how far you'd want to go with categorizing NPCs. Scouts for instance as well. --Ee 05:12, 22 June 2012 (UTC)

Personally I think that, if the NPC has a tag after the name, it should probably be listed as a service. Ninja-addition: Excluding obvious ones, such as the [Necromancer] in the swamp. — Rhoot 13:33, 22 June 2012 (UTC)

I require formatting halp.

so when interacting with Councilor Zudo and Councilor Lundo they both talk at the same time to you. how should that be documented on there pages? heres a link to what I am talking about. http://imgur.com/a/Tk24D#0 - Zesbeer 00:48, 13 August 2012 (UTC)

Do it like a storyline mission dialogue, with the "Councilor Zido:", "Councilor Lundo:" prefix? And have that same dialogue block on both pages? -- ab.er.rant 05:26, 29 August 2012 (UTC)

can you link me to a example of that?- Zesbeer 18:42, 5 September 2012 (UTC)

Defending Shaemoor#Dialogues? Basically, any storyline dialogue. The one where people usually do a prefix like '''Councilor Lundo:''' per line? -- ab.er.rant 10:55, 6 September 2012 (UTC)

Abilities

NPCs have abilities that come up in the combat log and they also have a description beneath their name. For example, level 6 Inquest Technicians have "Stuns, Bouncing Projectile, Buffs Allies" while their abilities used on you are "Stab" and "Shocking Stab". How should this distinction be handled? For now, I'm putting abilities as a sublist of their description. BryghtShadow 09:00, 2 September 2012 (UTC)

Where are you getting that they use Stab and Shocking Stab? I see there's a bunch of player skills named Stab, but nothing called Shocking Stab, what are these skills? The abilities are meant to be descriptive, not exactly precise descriptions of what monster skills are used, if that's even the right way to describe what enemies do. Manifold 16:09, 2 September 2012 (UTC)

It's the "Combat" chat channel - messages like "You were hit for <x> damage by <foe> using <ability>." I don't know how we'd tell whether any of them are identical to profession skills or not, and there's no way to find additional data about them, so maybe we shouldn't be linking these abilities. —Dr Ishmael 16:47, 2 September 2012 (UTC)

How about a "Skills" section separate from the abilities section? Skills won't necessarily match up with abilities neatly. It's probably a bit early for this, but we could record damage data for monster skills, although it would be a slow process of recording hundreds of hits, and putting it through the damage formula. Perhaps we could start listing monster skills on monster skill, since I'm sure some enemies share skills. And I don't know a lot about this, but is it possible to get skill info from the .dat? Things like condition duration are easier to find. Manifold 18:13, 2 September 2012 (UTC)

It's possibly in there, but I don't know how to get it. I know that there is an encrypted block of skill data that at least covers profession/racial skills, and it might include these (ugh) "monster" skills as well. That's how GW2DB is able to have all the skill data they do - Curse employs people specifically to reverse-engineer games like this. I learned this much from someone who somehow knows the guy at Curse that's working on GW2DB, but he refused to tell me any more than that. —Dr Ishmael 21:27, 2 September 2012 (UTC)

NPC project

I am creating a project called [[Guild_Wars_2_Wiki:Projects/Project_NPC| Project NPC]] that will work on the polish for the NPC pages. Anzenketh 19:18, 10 September 2012 (UTC)

It will be placed there after I complete it in my sandbox. Anzenketh 07:56, 11 September 2012 (UTC)

Location specifics

"If the page is for a common monster, town, or other NPC that appears multiply without regard to zone but rather with a terrain type, it can be perfectly acceptable to use that terrain type (eg: underwater). Exceptions and examples can then be documented in the body of the article." I don't agree with this. No enemy just appears in a specific terrain type. Underwater areas share many enemies, but that doesn't mean anything spawns in any underwater area. People are going to want to farm specific creatures for specific drops, no one is going to want to be told "these spawn in grassy areas".

"If the NPC is a unique character that appears in multiple places, like Eir Stegalkin, do not list a location - listing a location in this instance would confuse people. " I also don't agree with this. It seems like an attempt to avoid huge location lists like Mhenlo had. No NPCs appear in as many places as Mhenlo and some other characters did. Eir for example appears in Hoelbrak, a few personal story instances, and a few dungeons, and no other place that I'm aware of. Not a big deal to document them.

The template example should be changed to have "location" instead of "region" in the infobox, and its description updated accordingly. This parameter is currently used for zone names that the NPC appears in. Multiple zones are separated by a br tag. What needs to be decided upon is how these will be ordered:

• Alphabetically?
• By increasing level of zone, alphabetically within equal leveled zones?
• By alphabetical geographical region (maguuma jungle, etc), alphabetically within same region?

Regions don't seem as important as they did in GW1, so I don't really favor splitting them up that way. By level would probably be a bit of a headache, and some zones have different level ranges. Alphabetical would be the simplest and hopefully easiest for a casual editor to pick up on.

The template example should also include a "Locations" section, as has become common practice. I'm not sure if the zones listed should be linked or not, since they are already linked in the infobox. It may be convenient or redundant. Again, the same question of how the zones are ordered comes up. It should be the same order as infobox.

Personal story NPCs and dungeon NPCs are very inconsistent currently. For dungeons, I think, using Ascalonian Catacombs as an example, should be formatted like so:

• Plains of Ashford
  • Ascalonian Catacombs
    • Specific Location

For personal stories, perhaps like this:

• Plains of Ashford
  • Personal story name

It would also be useful to have a template for locations, like on GW1W, it would help tremendously in keeping location pages and NPC location sections consistent, by providing a list, and possibly other nice lists down the line.

For NPCs with multiple possible levels (almost all non-specifically named ones), each location listed should include all possible levels. Pages are currently inconsistent as to how they are done: "(level 8)" or "- level 8". I don't have much preference, I'd just like it consistent.

There's also the question of NPCs that only appear in a location as part of an event. I haven't seen this come up yet, but I think they should be included, after level if it's included:

• • Decimus Stones - level 8, only during Kill the Risen before they ruin the quaggan's birthday party

Manifold 22:11, 10 September 2012 (UTC)

Fixed the template code. I updated the infobox page but forgot that a copy of the template was placed here.

Terrain-based location: We're not saying "All grassy locations in Tyria". We're saying "grassy locations" in so-and-so area/zone. Works best for neutral creatures and 1-hit critters. -- ab.er.rant 02:28, 11 September 2012 (UTC)

Location for unique NPCs: Sure, go ahead. I'd go for alphabetical order as well. It's just easier. Sorting by level, which is placed after the name, just makes for a clumsy sort.

The whole guideline doesn't really follow what's been done though. So perhaps you should just edit in your recommendations based on what you've observed so far and then we can discuss each point separately, if anyone wants to offer alternatives. -- ab.er.rant 02:28, 11 September 2012 (UTC)

Must we list locations in the infobox? A lot of area names are long enough that they'll wrap, which looks horrible. And listing the level with the location just makes it worse. —Dr Ishmael 02:52, 11 September 2012 (UTC)

Aberrant - It sounded to me like it meant "environment type in replace of specific area", but if it means something like "Decimus Stones - rocky areas", sure, that's fine with me.

Ishmael - Now that you mention it, having the zones in the infobox seems redundant. It looks like it was put there years ago, probably before we had seen any real game footage. I'm for removing it, but that's probably to be addressed over on the infobox page. I do think the levels should stay in the infobox, though, since there won't be anywhere else that they'd be all together. Manifold 22:41, 11 September 2012 (UTC)

I agree that this is better for the infobox talk, but listing levels will probably be okay. If there are only a few levels, you could list them explicitly, but if there are a lot of levels for a creature, just condense it to a range. —Dr Ishmael 23:59, 11 September 2012 (UTC)

Yea, I agree the parameter is quite redundant if we're going to have a "Location" section anyway. But I proposed to retain it for now since a lot of NPC pages don't have location pages. We'll have to wait until we established a norm where the "Location" section is expected.

Id' like to bring attention to sorting though. How should we sorting locations? Do storylines come before areas? Separate storylines from area? Do lower level areas come first? How should we decide which area comes first if an NPC appears in multiple regions? I'd suggest putting these implicitly into the copy-paste template. -- ab.er.rant 03:56, 18 September 2012 (UTC)

For hostile NPCs, I'd say location sections are very much expected already. Allies seem more mixed. I'd prefer just alphabetizing zones, and alphabetizing areas within. Storyline instances can cover multiple areas, so I think this would be messy:

• Zone
  • Area1
  • Personal story
    • Area1
    • Area2

Like this makes more sense to me and would avoid redundant links and categorization via templates:

• Zone
  • Area1
  • Personal story
  • Area2

Regions as in Maguuma Jungle, Kryta, etc? I don't want to list them at all. I don't really they say anything important anymore. In GW1, you progressed linearly from one region to another (with some exceptions), and some drops depended on area. Neither is really the case in GW2.

One other thing we need to address is HoM, sPvP, WvW, and Heart of the Mists NPCs. For sPvP I'm not even sure if there's areas within each map in sPvP, but WvW has four "zones" with areas. I suppose HotM could be considered a zone, I don't remember if it has areas either. As for HoM, a zone with a single area of the same name? Manifold 05:00, 18 September 2012 (UTC)

I agree with pretty much everything there. Personal story instances should be treated at the same level as areas, without sub-listing areas, and regions are unimportant.

The loading screen for HoM says "Eye of the North," but the map only shows the area name "Hall of Monuments." For simplicity, I'd say we just call it "Hall of Monuments" and let it be a zone with no areas. —Dr Ishmael 12:43, 18 September 2012 (UTC)

I personally find regions helpful, because it helps me zone in on exactly where the location is. I'm not familiar enough with where specific zones are to know where to look for them, so having the region listed helps me know which portion of the map to look at. Think of it like trying to find a State in the United States. If you weren't familiar with the U.S. at all, and someone says "Find Utah", you'd be looking all over the map at all the states, trying to figure out where that one is. Whereas if you are told Utah is in Mountain Standard time, and your map shows the time zones, suddenly you've narrowed it down to looking at one strip of the country instead of the whole thing. I don't know, that's how I see it.

What do people think? I'd really like to get a solid consensus for this. I've been spending time on enemy NPC pages, which have much more location information than other NPCs (such as service NPCs). I like my contributions to make sense and follow a standard so that they don't need to be "cleaned up" later. :) Jauranna 18:34, 18 September 2012 (UTC)

How to show NPC levels for a location

It's been mentioned once or twice in the discussion but I'd like to pick it up and get a consensus on this: how do we show the level of the NPC in the location listing outside of the infobox? There are several versions out there right now:

* (1) Location

* Location (1)

* Location - level 1

* Location level (1)

* probably some other variants

Personally, I prefer the second version because a) the location comes first, as it is the most important thing in the location listing and b) because the 'level' prefix is not necessary for clarity (the infobox makes it clear that the number refers to the level) - Zerebruin 22:44, 13 September 2012 (UTC)

Either "Location (level 1)" or "Location (1)" is fine for me. Given the multi-level bullet list, and some being level-ranges, having the level come first would just mess up the indentation. -- ab.er.rant 06:24, 14 September 2012 (UTC)

I much prefer a dash. Parenthesis I see as denoting alternatives, as it was used for hard mode levels on GW1W, whereas a dash denotes "here comes some extra information". I think it should definitely say "level", it's not always going to be clear at a glance that they correspond to what's in the infobox. They should definitely be after the location name, though, since it's alphabetized, not in order of level, and the location is more important than the level. Manifold 18:23, 14 September 2012 (UTC)

Well, the level is "some extra information". It's optional because we won't specify it for NPCs that only have a single level or appears only in a single location. Just like how area pages put NPC services in parentheses, like "(merchant)" or "(trainer)". -- ab.er.rant 03:56, 18 September 2012 (UTC)

I like the Location - level 1 option. That's what I've been using. Jauranna 20:01, 20 September 2012 (UTC)

Examples:

• Queensdale - level 1-10
• Kessex Hils - level 15-20
• Gendarran Fields - level 25-30
• Lornar's Pass - level 30-35

Versus

• Queensdale (level 1-10)
• Kessex Hils (level 15-20)
• Gendarran Fields (level 25-30)
• Lornar's Pass (level 30-35)

Versus

• Queensdale (1-10)
• Kessex Hils (15-20)
• Gendarran Fields (25-30)
• Lornar's Pass (30-35)

I suppose not having the parentheses looks less cluttered. -- ab.er.rant 03:33, 21 September 2012 (UTC)

Not having the parentheses (i.e. dashed plus levels) looks totally cluttered to me, but that's a matter of taste. As long as we agree on one style it doesn't really matter to me. --Zerebruin 08:47, 23 September 2012 (UTC)