Template talk:NPC infobox/Archive 1

edit

Anyone knows how I can edit colours and such in this template? Nohjo 00:42, 20 December 2010 (UTC)

Sure, I changed the background to white. When you look at the differences, you will see where I changed the color. Though, I do like the white with grey borders. Makes it look sleak and new. - Lucian Shadowborn 18:51, 20 December 2010 (UTC)

Ok thanks, I'll change it to this steelblue colour. Nohjo 19:00, 20 December 2010 (UTC)

What's this infobox for? Venom20 19:04, 20 December 2010 (UTC)

I think it'll prob be used for npcs when GW2 comes out. It doesnt hurt to perfect a template while there's time. - Lucian Shadowborn 21:36, 20 December 2010 (UTC)

It doesn't hurt one bit; however, the name of the template should then reflect what it is used for. After all, there will be an NPC infobox, a skill infobox, a creature infobox, etc. I was going to recommend moving it to a more appropriate name. Venom20 22:06, 20 December 2010 (UTC)

Agreed. - Lucian Shadowborn 22:10, 20 December 2010 (UTC)

It could be used for a NPC infobox. No idea how I can change the template name though. Nohjo 13:30, 28 December 2010 (UTC)

Moved to reflect everyone's wishes. - Lucian Shadowborn 22:42, 28 December 2010 (UTC)

User:Lucian Shadowborn/sandbox/NPC|sandbox

Please feel free to use my sandbox page to tell if changes work. - Lucian Shadowborn 22:57, 28 December 2010 (UTC)

[[User:Lucian Shadowborn/sandbox/NPC/Logan 02 concept art]] is the demo npc page. - Lucian Shadowborn 04:53, 29 December 2010 (UTC)

By making the template better, I brokes yours... :( I'll find you a cookie. Aquadrizzt (talk)(contribs) 05:12, 30 December 2010 (UTC)

Link colours

I changed the link colours from black to default.There was a discussion a while back somewhere about it. With the default colours showing, people are better able to determine what words are actual links. It may not be as flashy as an all black worded document, but it is more practical. Also, good work on the format, I think it looks good. Venom20 17:45, 29 December 2010 (UTC)

Ok, I agree perfectly with all you said. I'm still having trouble determining why, on my sandbox page for NPC, it is not putting Logan into the Category:Humans, it keeps eluding me. Format is pretty much the same as the GW1 but color, size, no bad jokes about roadkill. Though, when the time comes, I think we need to put affiliation. - Lucian Shadowborn 22:35, 29 December 2010 (UTC)

Images (notably the top one)

There is no reason that the NPC and the image need to have the same file name. How to fix: just let there be an input for an entire file/image (including the extension; .jpg isn't the only extension possible for use). I'm going to try to do this myself, but be prepared to revert if I don't succeed. Aquadrizzt (talk)(contribs) 04:15, 30 December 2010 (UTC)

And success. :)

On to other things, IMO the only things that must be present (as in, "Not Specified" or value) are Name, Image, Level and Race. The logic behind it (talking about all listed in template, just to get opinions/state my own):

1. Name - Required -
2. Image - Required - Pretty much necessary, I mean, even if their invisible (LOL) we can just have a pic of their location
3. Race - Required - I'm pretty sure every thing has to have a race, so it can stay.
4. Level - Required - I would hope that ANet gave every NPC a level, even if it's just to determine how many hitpoints they have.
5. Profession - Not - I doubt ANet is going to spend the time to give every commoner we meet a profession; I think they even said that most NPCs won't have specificed professions.
6. Boss/fleshy/passive/hidden - Not - Specific to different creatures, should not be required (
7. Region/maps - Eh.... - I would need to see how many regions, however, I think (in the initial release) there are only 6... Maybe make Region-> Region(s) and not have links (going to fix that shortly).

Aquadrizzt (talk)(contribs) 04:32, 30 December 2010 (UTC)

(Conversing with myself, what fun!) Updates on what I've done: Maps now just need "Filename.jpg/jpeg/png" and are limited in size to 80 x 100px. I removed the auto link in Region(s), so now links in the "region=" are necessary, however, you can now list multiple regions using line breaks ( [[Region 1]] <br> [[Region 2]]. ) Anyone want to propose other changes? Aquadrizzt (talk)(contribs) 05:13, 30 December 2010 (UTC)

Well done! What about Faction, not a fan of the word affiliation... - Lucian Shadowborn 07:17, 30 December 2010 (UTC)

Also, for professions, some will have a set profession but not all. When they don't, we can change unspecified to something like -Unknown - Lucian Shadowborn 07:20, 30 December 2010 (UTC)

(also talking to myself), I don't know how but can ya fix the kinship so it doesnt show until one types | kinship = (whatever), also, make sure the category one non-kined pages sorts them to [[:Category:Unspecified kinship]]? - Lucian Shadowborn 11:25, 30 December 2010 (UTC)

(bleh), I removed the need for previous suggestion. When not set, no category will be added. I do want kinship to be hidden until someone actually wants to put Ash Legion into it. <recent addition:>Also, make profession optional. I do think it should very much remain but not be required. I lack the skills to hide those. Sorry for spamming, I'm done with suggestions. - Lucian Shadowborn 11:31, 30 December 2010 (UTC)

Why is Organization not logical and not already used? There's even a category for it (albeit we are currently re-organizing the entire category tree, so this statement might not be accurate in the nearby future). - Infinite - talk 14:16, 30 December 2010 (UTC)

(Reset indent) I have massive problems with Kinship. Kin implies some level of familial relationship, and thats not what any of the organizations are about. Affiliation, unless we find a better word. (And you need an "if" statement, like are done with the maps.) Aquadrizzt (talk)(contribs) 17:37, 30 December 2010 (UTC)

Ahh, well, I think organization is fine. - Lucian Shadowborn 17:59, 30 December 2010 (UTC)

Anything else people want on this template? Aquadrizzt (talk)(contribs) 18:41, 30 December 2010 (UTC)

Actually, i ws thinking it would be pretty cool to have some sort of gw2 picture where the npc name is, instead of grey... but faded and the text ontop. I guess I can only dream. ;) - Lucian Shadowborn 19:07, 30 December 2010 (UTC)

Wait...explain more. I couldn't really make sense of what you're asking for right now. Aquadrizzt (talk)(contribs) 19:09, 30 December 2010 (UTC)

The vibe his comment radiates would imply he'd like a Tango icon in the corner of the header. - Infinite - talk 19:14, 30 December 2010 (UTC)

No...give me a couple mins to find and paste a example in pre. - Lucian Shadowborn 19:15, 30 December 2010 (UTC)

<div style="background-color: #F2FDEC; width: 606px; height: 727px; margin: auto; padding: 21px;">

<div style="border: 2px solid #030303; margin: auto; position: absolute; width: 600px; height: 721px;">[[File:User Naut Backgroundwiki.jpg|600px|center|link=]] </div> <div style="border: 2px solid #030303; background-color: transparent; margin: auto; overflow-x: hidden; overflow-y: hidden; padding: 7px; position: absolute; width: 586px; height: 707px;"> , an example of being used is here. - Lucian Shadowborn 19:17, 30 December 2010 (UTC)

Ages ago, consensus was reached to not overly use visual formatting, ergo images as backgrounds are a non go in main space. - Infinite - talk 19:19, 30 December 2010 (UTC)

Ahh, I figured, my suggestion was more of a joking around. ;) - Lucian Shadowborn 19:19, 30 December 2010 (UTC)

(Reset indent) @Infinte: I was actually thinking tango, but I wanted to clarify... And yeah, in this particular case, simplicity wins over complexity. Aquadrizzt (talk)(contribs) 19:27, 30 December 2010 (UTC)

Fo sho! Then should we add support for tango icon or just wait till later on? - Lucian Shadowborn 20:40, 30 December 2010 (UTC)

So..

So, are we done for now? There will most likely be room for improvment once GW2 comes out and I can predict alot more users will want a say in this template (for the oddest of reasons or because they're edit frenzies). I do suggest we try to find pictures of NPCs with white backgrounds. - Lucian Shadowborn 19:25, 30 December 2010 (UTC)

I think that this is functional as an NPC infobox. We would really have to wait until when the game comes out (we're probably missing something important). And the "try to find pictures of NPCs with white backgrounds." You mean renders? Aquadrizzt (talk)(contribs) 19:28, 30 December 2010 (UTC)

Yeh, renders. That word seemed to escape me there. Is there a NPC guideline or would you like to create it? I'm a fan of this nice grey over that weird orangeish pink anyday. - Lucian Shadowborn 19:33, 30 December 2010 (UTC)

I don't really have much of a say here, since I'm not good with code, but I think the color should be replaced. If not to a more solid color, then at least to a darker shade of gray. I don't think it looks very good, in my opinion. ---~=Ѧrtѧxϵrxϵs 20:05, 30 December 2010 (UTC)

In case anyone had missed it, I tested it out last night on Petra. Yes I know I jumped the gun prior to consensus. Venom20 20:13, 30 December 2010 (UTC)

Its' a decent test page :). We can say grey is a temp color for any template until a color (other than gw1w color) is reached. It's a new wiki and a new wiki should have some changes. - Lucian Shadowborn 20:30, 30 December 2010 (UTC)

IMO the Light grey (headers) + white (background) + black (plain text) + blue/purple (links) + the NPC render colors and the map colors makes this look sophisticated yet simple. My two cents have just been provided. Aquadrizzt (talk)(contribs) 00:37, 31 December 2010 (UTC)

Really? To me it seems like a generic infobox from one of those random wikis for one of those Asian grind MMOs. I have to disagree, i don't think it looks sophisticated at all. However, I'd have to say either leave it as it is or maybe darken the gray a little bit until we have more official colors that match the game itself. Beta, maybe?---~=Ѧrtѧxϵrxϵs 01:07, 31 December 2010 (UTC)

Simplicity is also easy to understand, if you make it so complicated it would make changes difficult. I vote for this to be a beta. I suggest, that for every template in beta phase should have this grey color coat until an official color is reached. - Lucian Shadowborn 01:29, 31 December 2010 (UTC)

(Reset indent) This is relatively complete...what should we move onto? Skill infoboxes round 42? Aquadrizzt (talk)(contribs) 04:03, 31 December 2010 (UTC)

There is a way to compare old and new proposals for skill pages here. - Infinite - talk 04:22, 31 December 2010 (UTC)

As it turns out, we are not done. Lucian, as [[Template:NPC infobox map1|these]] [[Template:Infobox images first row|were]] [[Template:NPC infobox map2|your]] doing, would you be able to place (add the coding of) the templates into the actual infobox. There should only be one template, and also, that's not really (IMO) how you should use templates in the main space. Aquadrizzt (talk)(contribs) 04:41, 31 December 2010 (UTC)

I am, quite slowly and with much RC flood, removing all other templates from this template. Templates like the ones I linked in the above comment are not particularly useful, and should not be the only thing holding a template together. Aquadrizzt (talk)(contribs) 06:05, 31 December 2010 (UTC)

Well...that was an adventure. But... success, this template is now completely self reliant. Aquadrizzt (talk)(contribs) 06:12, 31 December 2010 (UTC)

Those are copied directly from GW1W when first creating npc infobox. I suggest you make sure you don't need those templates before they get deleted. - Lucian Shadowborn 11:09, 31 December 2010 (UTC)

Thanks for making it self reliant though. As I said, copied exactly from old wiki to progress npc box. - Lucian Shadowborn 11:10, 31 December 2010 (UTC)

If the lines were added directly into the main template, leaving them blank should be fine. Albeit an if-structure might be required, but we shall see. - Infinite - talk 14:34, 31 December 2010 (UTC)

Added (for additions only)

Added more races. Let's keep adding more, shall we? - Lucian Shadowborn 11:30, 31 December 2010 (UTC)

Added some more from the Achievement page. (yeah, that last IP is me, why wasn't I logged in?) There are a few more though like Vases, Sons of Svanir or Indescribable... Wasn't entirely sure yet to add those. ge4ce 11:52, 31 December 2010 (UTC)

Race

At the moment, the hyperlink on race links to Race, which is a redirect to Playable races. Obviously, there can be NPCs of races other than the 5 playable races. I don't know if any are known at the moment. Someone (not me, too tired) needs to change the link target. I guess they could either make a race page and go through all the links to race that should point to playable races, or they can point it to the bestiary or some other suitable page. Thering 02:31, 4 July 2011 (UTC)

More affiliations

Conveniently Caithe is being used as an example here, so: for those NPCs with both racial and organizational affiliations, is there a greater feeling as to how these should be included? Should there be a separation of organization and affiliation, or should both be listed under the organization field, or do we prioritize and list only one and rely on the page content to address the other? The recent spate of sylvari information has been demonstrative of this, with things like Cycle of Night/Destiny's Edge (Caithe), Cycle of Noon/Warden (Niamh), Cycle of Noon/Nightmare Court (Cadeyrn), and such. Redshift 10:39, 13 August 2011 (UTC)

Icon

Does that icon in the current template have a use? It seems like a carry over from the item infoboxes. In one of the old sections above tango icons were thrown around and I thought we could set it up like this. Looking at Karra Ghosthammer, there is plenty of room to the right of the npc image that these could fit into and would be a visual representation of the info in the infobox. In that example I have race, profession, and then a third tango. I don't know if merchants ever fight, but that 2nd tango could be an identifier of what they do (fighting npcs show their profession, merchants could have a merchant tango, w/e). Then the third tango I thought could be based off of the NPC's organization, like once we get to the vigil/durmond/whispers the respective npc's have the tango representative of their organization. Would need more tangos for this though (minor races, merchant tango, w/e other npc jobs tangos, vigil/durmond/whispers tangos, Destiny's Edge tango. If we use this for enemies as well then enemy race tangos, a tango of the boss icon, and could make tangos for enemy groups (like an ascalon ghost might have ghost/boss/ascalonian-ghosts tangos). 05:39, 23 March 2012 (UTC)

I built a few ideas in my sandbox. Churl Ghostshield has not head-icon so I put the the icon of Armorsmith NPC Vendor. Seraph Outfitter is a NPC vendor Weaponsmith-karma with head. It's more easier for npc no monster ... I suppose. Lasha 08:32, 23 March 2012 (UTC)

Region

The "region" parameter in the example includes no places that are regions, at least according to location. Few NPCs using this template are using it to mean region, either. "Zone" is what distinct explorable areas are called, but does that word encompass cities, too? It should be renamed to "Locations" or "Zones", plural even if there's only one place listed, since it's a heading. Organization should probably be plural too. Manifold 16:39, 23 March 2012 (UTC)

Now that there's been more discussion and something approaching consensus as to location terminology, I'd agree that 'region' has moved further from being the appropriate parameter. Location, as a broad cover for the various distinctions, might be a more accurate field in its stead. Redshift 02:05, 20 May 2012 (UTC)

Issue with current parameter naming

I am specifically referring to "Race" and "Region" in this:

1. Race is not accurate, as shown here, some people take it as a lore viewpoint however it should be taken from a mechanical viewpoint - the ArenaNet term for this is "Family" (GWW calls it gw1:creature type). I suggest changing it to Family (and {{{family}}} in coding).
   • An example for an issue with this: Destroyer, Branded, Undead, and Ghosts were all previously marked as something else (e.g., Orrian Grub was marked as Grub and not Undead; or the various Ascalonian ghosts are/were marked as Human and not Ghost). This also is repeatedly happening with new pages.
2. Region is, as the section above, not accurate either. Regions are things like Kryta, Ascalon, etc. However, the infoboxes currently use smaller location terms which don't really have a term on the wiki (explorable zones is a wiki-made one for some, but things like Village of Smokestead don't have such a name).
   • Addendum: How we work with this parameter is also a bit odd. Most pages are going as specific as possible (e.g., marking Smokestead instead of Plains of Ashford). But considering that generic NPCs can be widespread, if we keep that then we'll be getting huge lists (same can potentially occur with levels, depending on how Anet does things).
   • Addendum 2: I suggest changing this parameter to Location for the time being.
3. A third thing which has not been added yet is the situation of gw1:army (which is also carried over). Some examples of known armies are things like Inquest, Sons of Svanir, Flame Legion, etc. (These are per Slayer). I'd suggest adding an {{{army}}} parameter in this template somewhere.

Side note: I think it'd be best if put the upper right icon image into an {{#if:}} set up - and also expand the image over (with or without the icon) since there's a lot of white space. Konig/talk 19:35, 1 April 2012 (UTC)

I've been filling out the region section with the most specific information possible, since you can always go less specific if needed, but not the other way. However, ultimately, I don't think locations should be in the infobox. I can already tell that NPC spawns are going to be very messy, multiple levels and ability sets, depending on events. Locations should have its own section so we can detail which levels appear where, when and why, and which ability sets those spawns have. And if it has its own section, then the infobox is just a less detailed version.

I'm also not sure of the use of profession parameter. Few NPCs are specifically said to be a certain profession, such as Queen Jennah and Destiny's Edge. Some generic enemies have profession names as part of their names, but most don't. Many NPCs seem to be one profession or another, but there doesn't seem to be really any way of knowing. Many abilities are contradictory or interpretable many ways. What profession is an Ascalonian Monk? Even though it's optional it seems like it could lead to a lot of unanswerable and unnecessary debates when instead it could be mentioned in the description text for the few NPCs that it applies to. Manifold 20:18, 1 April 2012 (UTC)

Monsters don't have a profession, but some npc's do have one and since that is an optional I don't see that as a problem. Aqua brought up that maybe we should split NPC and Monster infobox's since they are different in quite a few ways (and gave an example for a mob infobox here).

-> I agree with Race being a little odd. I like carrying over creature type from gww more than Family. Family sounds like it could still get into that same problem of Orrian Grub is listed as Grub and not Undead. Creature type sounds more game mechanical to me.

-> Region should have always been top level (since top level IS Region), which made me wtf when I saw all these pages with specific maps on them. I agree changing it to Location, just so we keep it at region level but also add dungeons to that (like Veteran Ascalonian Mesmer). More specific location information (like maps and areas within the maps) can be given elsewhere on the page imo (like with your Smokestead/Plains of Ashford ex could be Plains of Ashford (Village of Smokestead) ).

-> Your army and race ideas seem to be very close together as they both seem to be based off of the slayer achievements. I think add an Affiliation, but slayer achievements would go under a creature type (game mechanical grouping) and this affiliation would separate different groupings under that. (So an ascalonian ghost would have Creature type: Ghost and Affiliation: Ascalonian Ghost).

-> As for your side note, I agree with setting up the {{#if: }}. There are some ideas floating around for what to actually use that for, but for now a lot of pages don't use it and it looks weird (and some ideas have that icon only used for merchant/karma-merchant icons that float above the npcs head which would still leave a lot of pages not using it). I think why there is so much white space is because it looks like the picture is centered over that bar that splits the rest of the infobox. Getting rid of some of that whitespace isn't a bad idea but I think it either needs to be a slight increase (keeping some white space to the right and the picture sitting on the left side of the box) or the picture just needs to span the entire width of the box. 20:57, 1 April 2012 (UTC)

@Manifold: I can see where you are going about levels and locations (I don't think that ability is in the infobox anyways). Though I do think listing the explorable zone (e.g., Plains of Ashford) is beneficial in the infobox - I personally think that specific NPCs should go as specific as possible for location. Furthermore, I'd also like to limit the infobox to only listing persistent area and dungeon locations (otherwise it'll get wtf messy for, say, Logan Thackeray) - or at the very least to not list personal story missions.

That is to say, Ascalonian Archer should list Plains of Ashford, Diessa Plateau(?), Blazeridge Steppes, and Ascalonian Catacombs(?) in the infobox, but the article will have a section for locations where it will say Fury of the Dead (lvl 1), and whatever other personal story and/or specific location they're found in. However, Issormir will list The Great Hunt in the infobox and article section.

On profession - I say remove for simplicity (90% of monsters would be "special" anyhow), however it may be that allies get professions while enemies can but most likely don't (that's what it seems to me at least).

@Mattsta: I would be fully for splitting ally and hostile NPC infoboxes. I only want family and army because they're the official terms, but using creature type and affiliation (respectively) will probably be easiest overall.

Thing is about the slayver achievements... if you're killing one of the five major races, then the slayer is counting the affiliation - Inquest, Sons of Svanir, Bandit, Nightmare Court, Flame Legion, and Pirate (all 5) are there instead of "asura slayer" "human slayer" etc. etc. It's only those 6 that the slayer achievement can be used for affiliations. And those six are very much not creature types. Konig/talk 23:55, 1 April 2012 (UTC)

Something like this? Aqua (T|C) 02:28, 2 April 2012 (UTC)

I like it :D 193.127.207.152 07:18, 3 April 2012 (UTC)

I think it'd be best to use explorable zones and dungeons (except for NPCs which appear in only one specific location) - a "go as specific as you can without listing too many locations" kind of deal. But other than that, I like. Though I am unsure (as pointed out below) about the veteran/champion bit. Konig/talk 16:05, 4 April 2012 (UTC)

Design

The design of the info box is very plan my suggestion is to change the header to match that of the headers on the main page. (change the color maybe) just so its a bit more in line with gw2's style.- Zesbeer 00:51, 4 April 2012 (UTC)

There is a significant problem that arises because we use images to generate the paint-stroke appearance on the main page. Many skills/npcs/whatever that has an infobox have names longer than one line can hold... While this isn't really a problem for div styles, as they can wrap, it would be a problem for images, because it would mean that somehow we would need to make the image stretch iff the name was too long and stretch even more iff the name was even longer than two lines... Aqua (T|C) 02:40, 4 April 2012 (UTC)

Would it be very costly make it functional first? I see more interesting work with the new template as soon as possible that to see the colors ... if not too much trouble then change it. The game is still in Beta and can change many things. Lasha 10:23, 4 April 2012 (UTC)

@Aqua that's not a problem at with infoboxes. Look at my sandbox. Alfa-R 16:54, 4 April 2012 (UTC)

Then lets go... :) Aqua (T|C) 20:05, 4 April 2012 (UTC)

It's a little jarring to have the header background... just end. I dunno. Something about it seems off. --JonTheMon 20:22, 4 April 2012 (UTC)

I like the header background but I think the problem is that the paintery-organic look clashes with the infobox's inherent boxiness... I dunno if that makes sense. Maybe removing the infobox border and using a different font on the header might help. --Lania 20:34, 04 April 2012 (UTC)

anything to make it look less plan would be welcome, even just making it more "painterly" would be better imho.- Zesbeer 21:18, 4 April 2012 (UTC)

I'd rather focus on functionality (see above section) rather than apparel for the time being. Also, I have no issue with current design - in fact, I prefer that over Alfa-R's current design alteration. But this is just me and my view that not everything on the wiki should be artsy - primarily referring to infoboxes and navbars not needing said appearance (also, they're already better looking to most other wiki infoboxes I've seen). Konig/talk 22:02, 4 April 2012 (UTC)

I agree that this kind of header clashes with the rest of the info box, and the purpose of this demonstration was to show that in case of info boxes variable height and paint strokes can coexist, rather than to actually propose a design change. Alfa-R 04:58, 5 April 2012 (UTC)

Documenting levels

Is COMPLETELY pointless. The levels scales based on the number of players - I went through an area while empty and they were around the kickdown level (13-14), then later I am with a little mob and the enemies are all level 17. So you can, quite literally, fight Enemy A in Place A and return sometime later and see Enemy A several levels higher. On top of this, enemy names are shared over large level differences - for instance Brackish Skales are in starter level (3-4), slightly higher (7-8), teens (16-17), and early twenties (22-23) at least. There might be some in Gendarran Fields which would put them somewhere between 25 and 35 as well (this doesn't count when they scale to match more players). Konig/talk 06:41, 30 April 2012 (UTC)

That's a good point. Maybe we could sort of figure out the formula with which an NPC's level is scaled. Maybe some NPCs are scaled less than others? But for now, perhaps we should just remove "level" as being required. -- ab.er.rant 10:23, 13 May 2012 (UTC)

Another thing I noticed over the BWE is that uniquely named NPCs who appear at completely different level'd missions (e.g., Logan Thackeray, or Lord Faren) do not have levels mentioned. So you can pretty much bet that any Personal Story re-occuring named NPC will not have a level attached, but obviously scales. Konig/talk 10:46, 13 May 2012 (UTC)

Hmm... now that you mentioned it, I did recall named NPCs in the first human noble personal story being without a level. I suppose they're similar to NPCs in GW1 that are found in outposts - no combat ability whatsoever I suppose. -- ab.er.rant 11:04, 13 May 2012 (UTC)

Some of them do have combat ability. Or are you saying that Destiny's Edge don't fight? :P Konig/talk 11:25, 13 May 2012 (UTC)

I'd not require recording a level, but, I would argue that it is not always without point. The Renown Heart NPCs have levels appropriate for their content, giving an easy spot to check for 'Is this region too difficult for my character to reach?' Require the level? No. Obviously, scaling makes level somewhat irrelevant for some NPCs, jsut as role makes it irrelevant for others. Torrenal 01:23, 6 June 2012 (UTC)

That makes sense. Unnamed cookie-cutter NPCs (the majority of PvE enemies) are going to show up in lots of different places at many different levels, but named unique NPCs (like Renown Hearts, Scouts, Skill Challenges, etc.) who only appear in one location will always have the same level. —Dr Ishmael 01:33, 6 June 2012 (UTC)

Display issue

I've noticed this before but never really bothered to confirm it, but; the icon takes up the whole right side of the infobox (and forces everything else out of its way, up until the maps are inserted) which I'm pretty sure should not be the case. I am not sure how to fix this issue at short notice, but I wanted to point it out to anyone who does know offhand. - Infinite - talk 12:40, 1 May 2012 (UTC)

NPC Picture Consensus

Not really about the infobox itself. But, for the image used in this infobox I have been seeing 2 types of pictures crop up. Either the full body shot like in the example, or some are doing just a head shot. I am leaning towards full body shot. Only so many faces in the game and seeing outfit can add to individuality, plus a little bit of the background can help people if they are looking for said NPC. Other opinions on a standard? Kenrid 22:49, 19 May 2012 (UTC)

I personally would prefer full body shot since there seems to be a lot of recycled faces in the game so far. --Lania 22:50, 19 May 2012 (UTC)

Headshot doesn't make sense at all. Full body should be the standard. —Dr Ishmael 23:30, 19 May 2012 (UTC)

As far as I'm aware and concerned, head shots are placeholders. Nothing more. And can we remove that outline? IMO, it's very poor and distracting. Konig/talk 02:13, 20 May 2012 (UTC)

Yep, I've been using headshots only when I didn't manage to get a full body shot. I figure a nicely-cropped head (that shows up when having a dialogue) is better than nothing at all. -- ab.er.rant 05:58, 21 May 2012 (UTC)

I can roll with that. —Dr Ishmael 12:03, 21 May 2012 (UTC)

When I've been doing NPC screenshots, it's full body, high res, 50 px margins, and I'll crop out the weapon if it extends the image boundaries by a significant amount (thus far something I think I've only cropped out the weapon for Carman Fawntracker, who has a bow that extends another two head-heights above her.) I'd suggest setting a formal policy on screenshots, so that we can have something to point to, and to give a place for discussing such formatting concerns. tbh, I've been pondering using the dialogue headshot for NPCs where I didn't get a proper screenshot, but the only real candidate I have for that lacks even a proper name.  :/ Torrenal 00:39, 5 June 2012 (UTC)

I have a question, on the heart NPCs, is it better to put the picture with the heart on top of his head showing his name and level or just put the NPC by himself? CranSnap 12:02, 14 September 2012 (UTC)

It's generally preferred to not have any interface showing in screenshots on the wiki (unless the interface is the subject of the image, obviously), so no, no name/level/service. —Dr Ishmael 12:59, 14 September 2012 (UTC)

Compiling of outright needed changes

This is mainly imo, but from the above discussions and other discoveries I believe that:

• "Region" should be renamed to Zone.
• Profession parameter should be removed completely as NPCs may borrow profession animations (e.g., Vilnia Shadowsong has abilities either straight from mesmer (staff skill 1) or skills which mimic mesmer abilities (the phantom system)), however this is not true for all nor does it really even matter outside what we see or may encounter - it was said that NPCs are not limited to professions, after all.
• The boss parameter and category should be removed and replaced with a veteran, champion, and legendary system (perhaps with one category each?).
• The maps parameter should be given an #if as very few NPCs will be viable with maps.
• This is completely my opinion 100% and is of personal preference, but can we also remove those outlines? They look bad, especially on pages where the NPC isn't of the playable races.

I'd do the first few changes but I am not that good with infobox editing on large scales (particularly for that boss situation). Konig/talk 07:54, 22 May 2012 (UTC)

Where was the consensus, if any, reached on using outlines anyways? I agree on that they're somewhat unnecessary. Mediggo 08:05, 22 May 2012 (UTC)

There wasn't even a discussion on it (looked through the history of the person who added the outline - and removed the icon which all NPCs have (though it's just their face in a circle and a border for vets/champs/legendaries), it was just simply added. Konig/talk 08:36, 22 May 2012 (UTC)

I think the icon should remain in place because it helps players to recognize targeted (faces are more easily memorized than names) mobs even if they can't see it's world model or the model is in part incorporeal (such as aatxes and shades in Godslost). Mediggo 08:41, 22 May 2012 (UTC)

I agree with all of these points, and also "Zone" should change to "Zones" when there's more than one, and "Level" should change to "Levels" when there's more than one. Manifold 16:10, 22 May 2012 (UTC)

I took the liberty of changing region to location. Then realized that this essentially de-located every single NPC page. Thus, I have restored region until if a more far-reaching desire for its specific terminology to be changed, and simply changed the display text for a hopefully less break-y solution. Redshift 14:16, 12 June 2012 (UTC)

I've added the "location" parameter to replace "region". All articles that are using "region" will be placed into [[:Category:Uses deprecated NPC infobox region attribute]], so that we have a place to go to find NPC infobox usage that needs cleaning up. -- ab.er.rant 11:29, 31 August 2012 (UTC)

Remapping Service to Category

Any objection if I have this template map the service of 'Renown Heart' to the category of 'Renown Heart NPC'? Torrenal 00:44, 5 June 2012 (UTC)

Style guide

Do we want to start a style guide for NPCs and capture design decisions on that page? Torrenal 02:13, 6 June 2012 (UTC)

I've gone ahead and started a style guide: Guild_Wars_2_Wiki:NPC formatting. Currently it contains my few additions to how I might expect NPC infoboxes to be filled out, please expand, update, or otherwise document what you expect would be proper content for NPC info pages there, so that others can more readily find and follow it. Torrenal 02:56, 12 June 2012 (UTC)

"Goal"

I've added in a 'goal' parameter so that an entry can be added to any specific events or karma tasks that an NPC is particularly tied to. This is less useful for some of the more ubiquitous NPCs, but I think it's a nice option for how a lot of the NPCs and objectives seem to function. Redshift 14:16, 12 June 2012 (UTC)

Linking

I know I've seen mention of this somewhere else, but is there a general approach as to linking or no from the infoboxes? Personally, I'd rather have links condensed in the infobox so that it can act as a dense hub to head from rather than having a straight-text infobox and having lots of links peppering the brief text that's going to happen on these pages (i.e. [[McSmiley]] is a [[burger]] [[flipper]] who is a [[heart]] for [[Butterfrost Peaks]]). Redshift 14:16, 12 June 2012 (UTC)

Well, I prefer having links on both. I tend to ignore the 1-link-per-page guideline when it comes to infoboxes. -- ab.er.rant 14:49, 12 June 2012 (UTC)

I feel the same way. It's not really overlinking if the infobox can be viewed stand-alone. You shouldn't have to look on the other end of the screen to find a link that should also be right in front of you. - Infinite - talk 14:57, 12 June 2012 (UTC)

Duly noted, then; as long as it's not considered overlinking. Redshift 15:00, 12 June 2012 (UTC)

The general wiki guideline (for any wiki) is one-link-per-section, not per page. The infobox counts as a separate section. —Dr Ishmael 16:57, 12 June 2012 (UTC)

I understand the linking discussion above. When working on the NPC infoboxes I am linking the locations in the infobox, in the descriptions, and then in the Location section as well. It seems like a lot of linking. I think it makes sense in the locations part, particularly if the NPC is in various locations. I just want to be sure that is what we are supposed to do. It seems like a lot of linking on one page in a short space. Surriela 23:22, 22 October 2012 (UTC)

That's fine. There's no harm in linking too much. The guideline is to make sure that no one tries to link every single word every single time it appears. Most of the NPC descriptions mention location because there's little else to mention of the NPC. If there's a backstory in their dialogue, I sometimes try to write it into their description so I can give the page a bit more content instead "he can be found in blah". -- ab.er.rant 09:38, 25 October 2012 (UTC)

Content-less headlines in NPC articles

← moved to Guild Wars 2 Wiki talk:NPC formatting

Species > Race

We're using race to classify different species, any objection to change it to the more correct term? --Xu Davella 02:56, 10 July 2012 (UTC)

Hrrr, I do realize that all articles that uses this infobox will have to be changed. --Xu Davella 02:58, 10 July 2012 (UTC)

Profession Tables

The professions appear to have common tables throughout the world. Rather than hand-coding these tables, it may be best to put them all in one place and just include them in the template.

For example, for NPCs with profession / service Artificer, it could include the {{merchant tables|artificer}} template, which would include those common tables (material, kits and tools, insignias, and the unique tab based on profession).

Thoughts? BlooMune 19:00, 2 September 2012 (UTC)

Thinking the idea over more, it's based on services, not professions. Also, priority would be getting these into templates; having them get autowired through this template may be more trouble than it's worth. BlooMune 19:50, 2 September 2012 (UTC)

You mean crafting disciplines. Professions are things like and .

Yep, I've already drafted something like that as Template:Inventory. Still refining it when I have the time. -- ab.er.rant 02:38, 3 September 2012 (UTC)

I see, that is exactly what I was looking for. I had created [[Template:Kits and Tools]], so I will follow your example and just add that to the templates

It will probably be under a similar namespace like "Crafting/Kits and Tools" or "Crafting/Materials/Artificer". That sounds reasonable. —The preceding unsigned comment was added by BlooMune (talk • contribs) at 11:14, 3 September 2012 (UTC).

Boss parameter

I'm not really sure how the infobox works coding wise, so I'll just put this here... I suggest removing the | boss = parameter and replacing with a | rank = parameter. I don't think there needs to be categories for each rank, but not against such, but there are 5 ranks (in order of weakest to strongest): Normal, Dungeon (these guys have silver circles, only seem to appear in dungeons, and never seem to have unique prefixes), Veteran (bronze circle), Champion (gold circle with two swords), and Legendary (purple starburst with two swords). It's misleading to call such bosses since they really aren't per say, and I've already gone and removed the previously used boss parameter since it was a remnant from GWW. Konig/talk 07:29, 4 September 2012 (UTC)

Yea, that's the next attribute I plan on deprecating after I finish cleaning up the "region" -> "location" change. But is this attribute even necessary? For example, Champion Vassar already clearly identifies it as a "Champion". I haven't played enough to have seen "dungeon" and "legendary". Are they prefixes to the creature name? Is there going to be a chance where we might merge the creature pages? Say... merging Destroyer Harpy with Champion Destroyer Harpy. If we go with merging, then perhaps this "rank" parameter is more like a list of ranks that this particular creature appears in. -- ab.er.rant 09:58, 4 September 2012 (UTC)

In my opinion, it is. Logan Thackeray and every member of Destiny's Edge is legendary, as is King Adelbern. They do not have prefixes. In the Blood Legion storyline there is a "Champion Bane Gladiator" but he is merely a veteran rank. In Caudecus' Manor, there's quite a few "Separatist Lieutenant"s who are veterans and champions, no prefixes. Along with this, I recall a discussion (don't recall where) where I suggested to not document the rank on NPCs who do not have such during the cinematics/in text (as not all do - for instance, Vassar, Ralena, Kasha, and Nente do not have the prefix in any dialogue, nor in the objectives, but not sure if they do or don't as NPCs still). IMO, uniquely named NPCs on a whole could easily lose the prefix on the wiki, as tbh Vassar is more likely to be searched than Champion Vassar, just as Svanir Marauder is imo more likely (if not equally likely) to be searched as Champion Svanir Marauder. With non-unique NPCs, that's an up-in-the-air thing from my viewpoint, as technically they're far more unique and merging would mean denoting where the ranked NPCs are (in a way, they are akin to the GW1's nameless bosses, like the gw1:Mursaat Necromancer (boss)) which can prove troublesome in formatting. Konig/talk 15:26, 4 September 2012 (UTC)

I was planning on helping you in the deprecation, I just haven't had time. I'm also working on the previous section, the problem is I need to think carefully about it to keep the pages from being too ambiguous... BlooMune 03:42, 5 September 2012 (UTC)

@Konig, perhaps Monster rank needs to be updated. When the rank parameter is introduced, we'll need proper sub-headings to link to. -- ab.er.rant 12:28, 5 September 2012 (UTC)

Passive, Hidden, No Flesh

Do we even need these parameters? They are obviously carried over from GW1, where these terms have an understood meaning (the parameter explanation doesn't even bother explaining them). I don't think they apply at all for GW2 creatures. -- ab.er.rant 13:47, 5 September 2012 (UTC)

"Hidden" isn't even used on GW1W, the category for it is empty.

"Fleshiness" has no equivalent in GW2, since minion and well skills do not require a corpse.

"Passive" might have a use, I know in Defending Shaemoor there are some human NPCs that simply cower as the centaurs attack them. —Dr Ishmael 15:07, 5 September 2012 (UTC)

Haven't a clue what Hidden means, personally. I figured Passive refers to NPCs with yellow names (attackable but not outright hostile) whereas in GW1 it meant they didn't attack on aggro (e.g.,lvl 0-1). "Fleshiness" isn't really around in GW2 - ignoring the whole "require a corpse" bit, the whole "immune to certain conditions" bit appears to be racial rather than a flesh=y/n situation like in GW1. Konig/talk 15:41, 5 September 2012 (UTC)

Ok, so only "passive" might have a potential. I'd rather use it for NPCs that don't attack than NPCs that are not outright hostile though... are there NPCs that are not outright hostile at lower levels but are hostile at higher levels? Would make for a complex parameter if there were. -- ab.er.rant 01:05, 6 September 2012 (UTC)

Levels has nothing to do with it. In Snowden Drifts there are yellow-text Sons of Svanir, some of which will turn red if you're too close for too long. I've also seen deer being red in lvl 15-20-ish areas, but yellow higher. "NPCs that don't attack" are neutral (yellow-text), critters (white-text), or greens. No ifs ands or buts about it. And among yellows and reds, reds will always attack on sight, whereas yellow will mostly attack in retaliation (though not always). Konig/talk 04:07, 6 September 2012 (UTC)

That's what I'm saying. Some Deers are red-text, some are yellow-text. So using "passive" to indicate "hostile-only-if-attacked" won't work because both kinds of deer will be sharing the same page. Or rather ... it won't work as a yes/no parameter. Should we change it to "hostile" or something instead? Where the possible values are "yes", "no", and "if attacked". -- ab.er.rant 05:30, 6 September 2012 (UTC)

Ah, fair point... I would have to say that denoting yellow-text enemies is pointless. Instead, what would be pointful are "critters" (I'm using this term from the first BWE's finale - they're the indiscriminate slayer title), but that's more of a mechanical special, according to the slayer title. Konig/talk 05:47, 6 September 2012 (UTC)

Removing service2

The service2 parameter appears to be a remnant for GW1. I've removed it from the usage template and I'm planning on removing it from the infobox entirely. The only use of this parameter is where NPCs are marked as both Renown Heart NPCs and karma vendors. I've edited to clarify their differences so that we shouldn't even need this parameter anymore. From what we've seen so far, NPC service is more clearly defined now and there shouldn't be an NPC that performs multiple services. -- ab.er.rant 15:35, 6 September 2012 (UTC)

I should've checked in-game before posting that. -- ab.er.rant 02:11, 8 September 2012 (UTC)

Location

Do we need it in the infobox? It makes more sense to me to have a tiered location section (as on Brackish Skale) so that levels and spawning requirements can be listed. It's just redundant listing the zones in the infobox, and doesn't seem to add anything to me. Manifold 17:50, 13 September 2012 (UTC)

I support that. My preference has always been to avoid overloading infoboxes with lists of stuff that can be presented better in the article itself. —Dr Ishmael 18:05, 13 September 2012 (UTC)

Well, if that's the case, then "location" should be removed entirely for every NPC. Otherwise it's difficult to get people to follow guidelines on what should or should not be in a location.

But about categories? Would it be possible to do a set of location parameters that does auto-categorisation? -- ab.er.rant 06:01, 14 September 2012 (UTC)

I think the problem here is still what is the definition of location? As I was going through and changing it, I saw some listing just the world location it was in (i.e. Queensdale) while some where more specific (i.e. Godslost Swamp). I like the idea of attaching it to categories because then it all just falls into a taxonomical tree. The problem there is, if we do it at the level of the finest granularity (Godslost Swamp automatically hooks it to that location plus Queensdale plus Kryta, etc.), that may require a lot of work to get the structure set up. So the real question is, is that kind of work worth it to just cut lines of code and confusion on the back end? Maybe. I'm not fluent in templates but if I was I'd give it a crack. BlooMune 16:42, 15 September 2012 (UTC)

Addendum: If we do it this way, it would make it a lot better to have a specific, separate template to do this work for us, maybe. Modularization is usually the best way to go in automation.

The reason for some infoboxes having things like Godslost Swamp in them isn't confusion over what a zone is, it's because we didn't have the locations section that we do now back during the BWE when those entries were made. I was just trying to record as much information as possible, and there was no other apparent place for it.

As for categories, I've been advocating the return of {{NPC location|<area name>}} making a return from GW1W. Manifold 18:21, 15 September 2012 (UTC)

Pretty much what I was thinking when it came to the addendum. Maybe I'll take a crack at it to kind of learn templates. BlooMune 22:49, 15 September 2012 (UTC)

If we're doing that template again, I'd suggest using a more appropriate name, maybe {{NPC area|<area name>}} or {{NPC in area|<area name>}}} or just {{in area|<area name>}}. The "location" label made it ambiguous enough that some people think "area" and some think "zone", so we'd better include the word "area" in the template. -- ab.er.rant 06:14, 16 September 2012 (UTC)

The only thing I'm wondering is how should the categorization go? We could make a category page for each area labeled something like [[Category:<Area>/NPCs]]. Do we distinguish between NPCs and Mobs? Mobs would be found in multiple areas (i.e. Earth Elemental) so how feasible is it to split a parameter into an arg-list; does the wiki even do that? Was looking over template code, I almost prefer Perl over it... BlooMune 18:55, 16 September 2012 (UTC)

Well, for one, don't use "mob", Ish doesn't quite like it :D But no, we shouldn't need to separate them. Some NPCs, most notably Destiny's edge, appear in multiple areas as well. There's no splitting needed. You use this area template just like the way you'd use a skill icon or item icon template - one template use per location - {{in area|Shaemoor Fields}} {{in area|Beetletun}} etc. The current way of categorisation appears to just drop the "NPCs" suffix. Would it be a good idea to just merge everything that can be found in an area within the same category? So we'd have NPCs, POIs, skill challenges, events, all appearining in the same category (as opposed to having subcategories). -- ab.er.rant 02:29, 17 September 2012 (UTC)

We didn't distinguish in GWW, however, my question is this: do we really need to have such categorizing? Always seemed relatively contrived on GWW and some of us still remember the annoyances the huge block of categories articles like gw1:Mhenlo got, which did little to help that list on the page. Konig/talk 03:32, 17 September 2012 (UTC)

That's why I was wondering if we should distinguish between NPCs and insert preferred term for enemies here. I would think people would tend to think about enemy locations very specifically (what areas Earth Elementals can be found in) and NPCs on more of a macro-scale (where all the Renown Heart NPCs are for Queensdale, where all the Crafting NPCs are). Tying it into categories makes the most sense that way to me, but I'm thinking more in terms of an engineer than a wikier (locations have many NPCs and NPCs belong to locations). BlooMune 23:28, 17 September 2012 (UTC)

Addendum: Maybe inserting the areas rather than locations into the infoboxes and creating sortable-table pages would make more sense. Just a thought. BlooMune 23:32, 17 September 2012 (UTC)

You're a little confused on the terminology here: NPC covers everything, whether it's hostile or not. You're thinking of ally and foe (or enemy, but Anet uses the former in skill descriptions). Also, making that distinction can be very difficult - there are allies that can become foes (e.g. skill challenges like Defeat Centurion Micka Thickblood) and foes that can become allies (in the story mission Pets and Walls Make Stronger Kraals, the Rock Dogs are initially hostile but become allies once defeated). Just calling them all NPCs is all we need. —Dr Ishmael 00:01, 18 September 2012 (UTC)

Terminology aside, a sortable table per location may be what we actually want. It would display at-a-glance information formally. NPC Type (graphic), their name, area, maybe the image, and if they're a foe a small list of only the most notable / sought after drops (crafting mats). The NPC pages themselves can link to these pages. BlooMune 00:53, 18 September 2012 (UTC)

Addendum: I threw together a mock of what I mean. This is really crude, and it doesn't necessarily sort very well for most of the fields... and I took some liberties, but it's basically what I was getting at. BlooMune 01:58, 18 September 2012 (UTC)

You're getting sidetracked here. This is really about the infobox. Your table is more suited on a location page, not an NPC page. The "Type" and the "Name" will always be the same.

If we're going with a "Location" section, then yes, the "location" parameter becomes redundant and somewhat useless. But I think we should just leave it there for now, since most NPC articles don't have "Location" sections. Best to wait until we get several passes through the NPC pages before actually removing this parameter.

For the actual content of the "Location" section, join in here. -- ab.er.rant 03:47, 18 September 2012 (UTC)

The problem I was trying to solve was Konig's, regarding massive category pages. NPC Infobox doesn't necessarily have to hook into Location categories that way. BlooMune 22:30, 18 September 2012 (UTC)

(Reset indent) Now that more information is available, I think the Location variable should start to be standardized. It doesn't necessarily need to appear in the infobox (though I like it there) but having tiered variables to make it easier to more adequately auto categorize would be helpful. I've been working primarily on Karma Merchants, and I think if we could add a Map variable, in addition to the Location one, we could then have the infobox autocategorize by map at least. It's ridiculous now trying to find a karma merchant on any given map with just Category:Karma merchants. I think the same can be said for every other type of NPC as well. Currently, the Location variable is too loosely defined, and there aren't enough specific location names to make it a real helpful option. I think if you added a Map variable, pretty much everyone would know what to put into it. -- Wyn talk 12:07, 7 October 2012 (UTC)

I think you mean "zone" instead of "map". The problem is that this infobox is used for both uniquely-named NPCs that only ever appear in once place, like vendors, and generic NPCs that appear in multiple places. Including a specific location/zone in the infobox makes sense for one, but not the other. I don't really have a solution, just explaining the underlying issue. —Dr Ishmael 14:36, 7 October 2012 (UTC)

No Ish, I said exactly what I meant. Each "Zone" as you call it represents a single MAP (if you are talking about map completion) I don't think anyone but you would have problems understanding what a Map variable would mean, but I'd be willing to compromise and call it "mapzone" or some other such idiocy. And does it really matter that the infobox is used for NPCs that appear in more than one place? Then we double up (or triple or whatever is needed) the variables. Stop playing word games, and let's make this template really usable for everyone. Currently, the variable "Location" is too vague to be used for any sort of categorization. Either we need to concisely define "Location" or we need multiple variables. Whether or not they all actually appear in the infobox is moot imo, we just need something to hook for Categories, as well as dpl, (or if you really are serious about switching from dpl to smw... big mistake imo, but meh). And you don't need to "explain" the underlying issue... I'm perfectly capable of understanding it all on my own. It's also perfectly acceptable to leave the location variables blank where they appear in multiple plasces, but then manual categorization will need to be added to those pages. I would really like to be able to find Vendors by MAP, or Trainers by MAP, or Repair NPC by MAP. As it is now, people are putting in various "locations" sometimes, the Map zone, sometimes the nearest waypoint, sometimes a more specific location name (if there is one). I personally can't tell you what MAP most areas are on without searching the entire world, so having anything besides the MAP name, gives me very little point of reference. If however, the page were in Category:Cursed Shore Karma merchants I would at least know what map to start with to look for them on. This would at least make the information more usable than it is currently. And yes... I LOVE micromanaging categories to the lowest common denominator. -- Wyn talk 16:33, 7 October 2012 (UTC)

There could be multiple parameters for both areas and zones (zone1, zone2..) and a condition to show the zone&area in the infobox only when there is just one possible location for the NPC and otherwise display something like "varies". And yes, we should certainly go with 'zone' as the parameter name since it is already called such in all other infoboxes and the article about them is called Explorable zone. On top of that, if you would look at the infobox you would see that it already has variables 'map1-5' used for map images - like in most infoboxes. ***EAGLEMUT*** TALK 22:06, 7 October 2012 (UTC)

Well, if you don't want to show multiple locations in the infobox, then what's the point of putting it into the infobox in the first place? Putting a "Varies" word in the infobox feels even less useful than having multiple zones shown in the infobox split by <br/> tags. -- ab.er.rant 02:34, 8 October 2012 (UTC)

From what Stephane has said recently, it sounds like SMW will finally be getting installed within the next month or so. That means we'll have access to the #arraymap function that can parse comma-separated lists in a single parameter, so there won't be any reason to use multiple input parameters (zone1, zone2, etc.) for the same thing. Regardless of whether we go that way or not with listing multiple locations in the infobox (I agree with aberrant that it's pointless to do that if we don't display anything), let's not go adding these parameters now just to have to remove them in a few weeks. —Dr Ishmael 02:41, 8 October 2012 (UTC)

So we leave it non functional in the hopes that something might happen in a few weeks? -- Wyn talk 03:37, 8 October 2012 (UTC)

It's just not functional from a convenient-automatic-categorisation-perspective. Your hostile tone is baffling. The "location" parameter needs to be standardised, yes, but not as MAP. A map brings to mind actual images (and incidentally, it's already in use as such). Other infoboxes are already using "area" and "zone", so it makes more sense to keep it standardised.

Are you looking for auto-categorisation of just NPC services like karma merchants and scouts? Or are you also looking to auto-categorise everything else, like Ridgeback Skale? Any thoughts about storyline missions NPC appearances? What about event completion-only vendors? I did give auto-categorisation some brief consideration before, but didn't really took it up. -- ab.er.rant 16:00, 9 October 2012 (UTC)

It's going to be difficult to reuse "location" for the auto-categorisation, since this parameter is used in a lot of different ways. I think the best way to approach this is to add "zone" and "area" parameters. I'm thinking "zone" categorisation might be enough for all NPCs, then additional service-specific zone categories for NPCs with services. -- ab.er.rant 07:56, 15 October 2012 (UTC)

Understanding the difficulty with characters that appear in multiple locations, the other infoboxes (eg {{object infobox}}, {{heart infobox}}) use area, zone, and region. I didn't have any suggestions on how to do this here to replace location until I read through the comments, and ishy proposed multiple zone parameters. If we were to go through and figure out the NPC with the most unique locations, and then build the parameters up to this amount, we would be able to effectively implement this. I'm in favor of this as well, because it really is difficult to effectively format across all pages how location should be formatted. —Jyavoc 04:30, 23 November 2012 (UTC)

Let's avoid the multiple parameters, please? Semantic Forms is coming really soon, like, before the end of the year, and then we'll have #arraymap and everything will be happy. —Dr Ishmael 04:37, 23 November 2012 (UTC)

Well heck, I'm sorry. I saw that as I was looking through, and managed to not read the rest of the post. Namely the parts where you were saying you didn't want to be doing that. Apologies. —Jyavoc 04:41, 23 November 2012 (UTC)

Perhaps we can reboot this? More and more NPC locations are being noted, and it's becoming an increasing hassle to list all of the zones twice, especially for things in many zones. We're keeping the Locations section, right? So the zones in the infobox is completely redundant. We can categorize them from there, rather than waiting who-knows-how-many-more months for SMW stuff, which would still make the infobox's locations parameter redundant. We could make an effort to copy anything that's not in the infobox to the loctations section before the change is made. It's mostly friendly NPCs that don't have a locations section, and that information would still be there after the parameter no longer does anything. Manifold 17:42, 4 January 2013 (UTC)

I support this. When so many NPCs have multiple locations, it's simply better design to present that as a list in the article instead of cramming them into the infobox. —Dr Ishmael 18:16, 4 January 2013 (UTC)

The problem of listing locations in the infobox continues to grow, especially with enemies found practically everywhere, like certain spiders. For allies like karma merchants, or very unique enemies, we can leave the location as specific as we can, like a poi or an area or a dungeon, but for monsters we should only include the regions they can be found in, with more specific information found in the article. I like the idea of using a template for the location entries for easy categorization, and the level can be included as part of the template as well. This wouldn't really require much of a change to the infobox, as far as I can figure, just in implementation. Psycho Robot (talk) 03:27, 7 November 2013 (UTC)

(re-indent)Yet another reboot of this discussion. It is getting really annoying updating a NPC in multiple locations specificly related to Story NPCs. I think standardization is needed but the location box is still useful for a NPC type. We need to have the NPC infobox specify if a NPCs is generic or named. We can then force the location to say Tyria when a NPC is flagged as generic(This will fix people not paying attention to formatting).

• For generic friendly NPCs like Worker,Citizen as well as order/race specific NPCs like Krewe Apprentice that are mainly put in for aesthetics and making the world feel alive we could add phrase stating just that in the locations page. Then list the events/dungeons that they are involved in separately. I have formatted Krewe Apprentice in such a fashion. This keeps the page clean and I don't have to go in and update the Krewe Apprentice page and the location page if a Living World update kills them all off in a area like happened Escape from Lion's Arch. We only have to update the location page.
• For killable generic NPCs like Earth Elemental it is useful to note their location in the location section. This is because people want to go kill them specificity to get their specific drops. People are also much more likely to notice if they have moved/killed off and update the wiki. Sadly we have to rely on them updating the NPC's section. If the Sytamatic wiki can pull from other things like categories or if a template is used and it's varaibles. We might then be able to make a NPC location template so specify location variables then use those variables(Level,disposition(Ally,Foe,Both(in cases where it switches depending on event or is both), Natural(Changes to enemy if attacked),and Ambient) to display the information in it's current format NPC's location page. As the variables would be stored in the template and (Maybe) pullable from the Sytamatic wiki. We can then have a dynamic update the Location pages with it.
• For story named NPCs like Evon Gnashblade,Braham and even less recognised characters like Bouncer Kinna or Commodore Lawson Marriner we would flag them as named in the NPC infobox allowing us to specify each location they are in. This would allow us to do dynamically update the location pages regarding these characters. They however would not be listed as a ally or foe but a story character. The NPC page however will list their status Maybe using the method above for killable generic NPCs.
• For other named NPCs that are not related to the story like Toskra but are in only one location perhaps we can do the same as the story named NPCs however it is important that they be allowed to be marked as a location unknown.

The benefit behind this is we only have to update the NPC in one location(given that we can do what is described in killable generic NPC.)

The above comment was made by me. Anzenketh (talk) 18:50, 2 June 2014 (UTC)

Retrainer

We need a icon for the Retrainer. See Marcus.Surriela 00:29, 18 October 2012 (UTC)

I uploaded a rip of the retrainer overhead icon. File:Retrainer.png —Jyavoc 20:33, 5 December 2012 (UTC)

A golem isnt a asura

I was looking the the Category:Asura and noticed that people are listing golems as asruas when they are the race of golems they might have been created by asuras but they are golems its like saying robots have the race of human. but robots are not humans they are asruas. anyone else have any thoughts on this before i go thew and make changes to golem pages listed in that category?- Zesbeer 00:28, 28 November 2012 (UTC)

Did we ever decide whether to go with mechanical/achievement race, lore race, or what actually makes sense race? Manifold 00:58, 28 November 2012 (UTC)

In terms of the Slayer achievements, hostile golems and asura are both Inquest; dunno how we'd apply that to non-hostiles. In any non-mechanical sense, however, they are obviously not the same race. —Dr Ishmael 01:00, 28 November 2012 (UTC)

Not really, I'm still in support of race and family terms (since anet uses the term "family or group" in the game). Slayer counts in terms of affiliation, which is separate from race/family/etc.--Relyk 01:02, 28 November 2012 (UTC)

(Edit conflict) @Ishy: The slayer achievement doesn't follow race, but affiliation as I've said before elsewhere (some affiliations and creature types are just named the same), so which slayer achievement golems count as should be irrelevant in this regard.

Anyways, this looks like an typography error, seeing how only 3 golems are typed as asura in the infobox that I see, and there's Category:Golems. Furthermore, golems and asura are, even mechanically, different creature types as per the Daily Kill Variety achievement. Konig/talk 01:06, 28 November 2012 (UTC)

Do golems fall under their own type for daily?--Relyk 01:07, 28 November 2012 (UTC)

As far as I can tell, yes. At the very least, they're not asura. Konig/talk 01:09, 28 November 2012 (UTC)

and I see someone already changed it.- Zesbeer 22:59, 28 November 2012 (UTC)

Halloween creatures category

Currently there is no category for Halloween Creatures. Could one be added? I propose the race parameter to simply be "halloween". ~ Sanna 02:09, 4 January 2013 (UTC)

If you wanna get technical, Halloween creatures don't have a race - or mechanically, creature type/family - just as karka and certain, most likely accidentally, other creatures. (They don't progress the daily kill variety) Konig/talk 14:08, 4 January 2013 (UTC)

Deceased/ghost

Would it be an idea to add a "deceased" parameter to denote ghosts and NPCs found lying dead? ~ Sanna 11:20, 22 January 2013 (UTC)

I guess, but what purpose would it serve? Dead bodies are are still considered to be whatever race they belong to, while ghosts of the deceased are very likely ghosts. Mediggo 11:59, 22 January 2013 (UTC)

Edit to make organization2 and 3?

Some NPCs belong to more than one organization, such as some members of Destiny's Edge (Logan is a member of Destiny's Edge as well as the Seraph, and Rytlock is a member of the former as well as the Blood Legion), and characters like Apatia, who was Lionguard as well as joining the Vigil. Is it possible to add on second and third organization sections into the template? --IceBlink (forgot to sign in)

just separate it with a comma that won't work right now--Relyk ~ talk > 06:33, 27 January 2013 (UTC)

Picture links to unknown

Some NPCs seem to be looking for a picture when none exists. On my Browser (chrome) and also on Safari, as an example Tamini Chieftain shows 240x300px in the infobox which links to http://wiki.guildwars2.com/index.php?title=Special:Upload&wpDestFile=Unknown_Centaur.jpg, a non existent picture. I have tried cache clearing and forcing a page update. There are quite a few other places I have seen this. Am I missing something? Claret 16:20, 14 March 2013 (UTC)

It's probably due to the infobox creating a default image link since none is given. For most pages it works fine (like Peacemaker Klodi) where it gives the outline based on the race. Off the top of my head, it's just concatenating "Unknown_" & race together. --JonTheMon 16:29, 14 March 2013 (UTC)

may well be, it's seen on all the Tamini centaurs where there's no picture, so it seems to be going for race and, as far as I can see, any race = centaur infobox without a real image seems to be going for this. I would suggest that maybe a template change would be nice, if those who have the skill can consider it. Claret 16:48, 14 March 2013 (UTC)

There's only outline images for the playable races, but non-playable races should default to the unknown human image. Or at least they did. Konig 17:47, 14 March 2013 (UTC)

Default image is for "Unknown Norn" unless the race is specified. You could possibly upload a "Unknown Centaur", but I'm not sure of that. If that's the route, check with Chieftain Alex since he's the last person to work with those. --JonTheMon 18:05, 14 March 2013 (UTC)

The template uses File:Unknown {{{race|Norn}}}.jpg if an image doesn't exist. The template should be leaving red links if an image doesn't exist rather than leave placeholder images; you can see User:Relyk/SMW/NPC infobox for example. That way, people can upload an image easily.--Relyk ~ talk > 18:19, 14 March 2013 (UTC)

The pages in question use the red text linking in some instances, in others it uses the Norn silhouette image. If this is the desired behaviour then fine. It seems weird that race = centaur behaves one way and other races behave another way. It's also that the text looks "untidy". But that's just my opinion.Claret 18:31, 14 March 2013 (UTC)

I'm guessing it uses the silhouette if the NPC has no race specified. If it's showing up when a non-norn race is specified, I'd have to look into that. --JonTheMon 18:45, 14 March 2013 (UTC)

It uses a silhouette in most places but I am unsure if it's Norn or whatever, then there's the exception for centaurs and possibly others. Claret 22:29, 14 March 2013 (UTC)

As of "now" centaurs are showing a centaur silhouette if there is not a picture, seems fixed. Thanks. Claret 22:45, 14 March 2013 (UTC)

Yeah I uploaded a crude cutout! -Chieftain Alex 22:51, 14 March 2013 (UTC)

Thanks. Claret 22:58, 14 March 2013 (UTC)

"Event-starter" NPCs

The star (as everyone knows) is used as a map marker for events, to show for example the destination of a caravan you have to protect, but also defines very special NPCs who wait for you to trigger their event via conversation (shows up on their head). Such NPCs are special because of that (they're "quest givers" in a sense, like the heart npcs). I think the star should somehow be assignable to such an NPC on their article page. Either on the header of the page, or on the title of their infobox or both. I don't see a way to do that now (except using the "icon" parameter). If the same NPC turns into a temporary merchant, for example, and you indicate that in the infobox, they'll get a merchant icon on their title, which is often not the most important thing about them as I said. Is there a category for such NPCs? ("Event starters?") And can this be somehow integrated into the infobox? --Alad 04:48, 17 April 2013 (UTC)

Hide parentheses in "Location" if the string is empty, and assign category to Story NPCs

There are characters which can only be seen in the story quests, and in the Home Instance. I think entering Home Instance as a location for them in the infobox makes sense. In that case, the infobox now displays some empty brackets after Home Instance.

Also such NPCs having the characteristic of appearing in the story, should probably be assigned to a "Personal Story NPC" category automatically if "goal = Personal Story" is entered. (In fact it doesn't matter if a wiki category is created for them or not, but that a list of such characters can be auto-generated if need be.) --Alad (talk) 01:59, 12 May 2013 (UTC)

I have changed it to only show the second line if something is actually displayed there. So for a red link, empty parentheses will not show. Regarding the home instance as the location I’m not sure if that isn’t too general (which home instance for example? The human one? Or another race?). In any case, it should be cased “Home instance” (lower-case i). Regarding the goal, I’ll leave that to someone else for now. poke | talk 02:26, 12 May 2013 (UTC)

Thanks, Poke. And which home instance, doesn't matter really. It's the player's. (In fact, no matter what your race is, I'm discovering that any of the home instances you enter will show you your story-related npcs; works in The Grove, Rata Sum, Hoelbrak upto now. Black Citadel doesn't work for some reason, or I'm not finding them.) Thanks again. --Alad (talk) 02:45, 12 May 2013 (UTC)

Abilites in quotes, with signature, as description

It's perhaps useful or a good idea to put the abilites on top of the page (although there's a chance they won't attract much attention there). However, I don't think they should be "quoted", nor followed by an "--Abilites" signature (see Veteran Ettin Leader). Perhaps starting off with Special Abilites: is more suitable. --Alad (talk) 02:19, 23 May 2013 (UTC)

Abilities isn't a correct term anyways, the description can include random stuff unrelated to any skills or effects on the monster.--Relyk ~ talk < 03:37, 23 May 2013 (UTC)

Just make it a plain list in the article. There's little consistency to the abilities listed in-game, so there's no benefit to parameterizing them in the wiki. —Dr Ishmael 04:01, 23 May 2013 (UTC)

I don't like the plain list as you end up being redundant describing the actual skills and effects that may or may not match the abilities.--Relyk ~ talk < 00:38, 25 May 2013 (UTC)

If we're going to describe the actual abilities in detail anyway, then what's the point of documenting the listed "abilities"? "Here's what the game says this creature does, but that doesn't matter - here's what they really do!" —Dr Ishmael 00:58, 25 May 2013 (UTC)

Unique yet generic NPCs with shared names

Not sure if best place, but is somewhat related. How does everyone think we should handle the various NPCs that have generic and shared names? For example, Consortium Representatives are located in Lion's Arch and Southsun, and while they may all be called "Consortium Representative", they have their own specific dialogue and model. It's easy to create a specific page when that NPC has a very specific role (see Lionguard (Refugee Coordinator) vs Lionguard), but sometimes they're just in the same area and say/do different things. I found something similar with Tourist (which isn't created right now, but they had multiple different dialogues). One idea I had was to create a single page and just put all the variations in there, with screenshots next to each dialogue if for some reason that particular NPC is notable. Might get big, but would avoid creating multiple pages with (specific location) appended to the name, which can get confusing. Vahkris (talk) 14:34, 24 May 2013 (UTC)

If there's nothing really distinguishing about them, then yeah, a single page is best even if it gets large. —Dr Ishmael 14:48, 24 May 2013 (UTC)

We can separate the services from generic NPCs, such as making Refugee Coordinator its own page and listing the NPCs that provide the service. Then we can list dialogue for a particular service on the NPC page. We should probably move any dialogue no longer present to a subpage. It would be the same as tagging Lionguard (Refugee Coordinator) for historical content when it's removed.--Relyk ~ talk < 18:03, 24 May 2013 (UTC)

Levels in infobox

The template shows an error if there is more than one level ie with 70,71 70—71 70-71. Thanks --Claret (talk) 19:27, 11 June 2013 (UTC)

I've formed a solution for this in my sandbox (version5). Its uses quite a few functions, but it can cope with basically any format currently used. -Chieftain Alex 09:55, 23 June 2013 (UTC)

The implicit assumption is that these ranges are continuous. A lot of pages that use the range format, however, have extremely large ranges - Alpine Minotaur states 2-74, and I'm pretty sure that they don't appear at every single level between 2 and 74. —Dr Ishmael 13:57, 23 June 2013 (UTC)

Would it not we easier to accept "Multiple" as a valid value? so often the actual occurences are detailed in the rest of the page. --Claret (talk) 14:42, 23 June 2013 (UTC)

Well if the infobox isn't being used for precise data, then why set a SMW property on the level parameter at all? -Chieftain Alex 16:07, 24 June 2013 (UTC)

I don't know, and I can't really think of why we would want to annotate NPC levels anyway - other than the obvious ANNOTATE ALL THE THINGS. —Dr Ishmael 17:31, 24 June 2013 (UTC)

This has been changed, yet again. and, Once again, its broken for values with dashes in. If I remove the parameter entirely, then it defaults to zero (wrong in this case), and if I leave it as 80-84, then it throws up the error. I'd vote for removing the annotation on this parameter entirely. -Chieftain Alex 20:01, 4 June 2014 (UTC)

Perhaps this is a remnant practice from GW1 Wiki or a assumption based upon previous MMO experance. Personally I think a level that a NPC currently is in the context of the area/event/dungon/story/location/whatever. Is more important that what level he is as a whole. After all I am not a level 80 all the time. When I go to the 1-15 zone my effect(therefore my level) is 15. Therefore I agree it should not even be noted in the infobox but instead should be listed on the area page. Anzenketh (talk) 20:08, 4 June 2014 (UTC)

you misread my comment. Keep the parameter, lose the semantic annotation. -86.154.221.33 23:41, 4 June 2014 (UTC)

Historical

NPCs get added and removed from the game. Perhaps we can add a "date introduced" and "date removed" parameter to the template. If removed, the article gets classified as historical and the info box includes a trivia tooltip with the date. Similarly, a tool tip for the introduction date could be added to the infobox.

The same idea could be applied to other infoboxes, including skills, traits, items, etc. That way, we could more easily track this type of trivia and avoid the ubiquitous note. This might be a better compromise to satisfy something that is of great interest to a small number of players and no of interest to a larger number. 75.37.16.64 16:25, 27 June 2013 (UTC)

Off topic: In reality, this wiki can use some harmless sense of humor from time to time. ;D --Alad (talk) 17:36, 27 June 2013 (UTC)

Services parameter

It seems unhappy with "Thief trainer" etc --Claret (talk) 20:33, 8 July 2013 (UTC)

Add support for master craftsmen services

At the moment services like "Master chef" and "Master Huntsmen" are not supported, although the matching categories have been created already. I think these services are important enough to be added to the template, considering these NPCs grant access to crafting, which plays a considerable part in the game. ~ Sanna 18:41, 29 July 2013 (UTC)

Fixed. —Dr Ishmael 20:29, 29 July 2013 (UTC)

Automatically add NPCs to location pages

It should be possible with Systematic Wiki to automatically add NPC's to Foe or ally to the NPC infobox. I think this would save time in the end and make it more complete. Anzenketh (talk) 21:20, 18 August 2013 (UTC)

Some NPCs, generic ones especially, can be friend or foe depending on the circumstances/context. --Claret (talk) 21:36, 18 August 2013 (UTC)

It's not nearly as simple as you think. As Claret said, some NPCs can have different statuses depending on location or context. Many can even switch status based on what's happening - skill challenge duel/spar opponents, the Poachers in Archen Foreland, etc. It's not something we can statically declare in an infobox. —Dr Ishmael 21:41, 18 August 2013 (UTC)

(edit conflict) With the Lions arch future update it becomes more apparent that something like this needed. Even if it is only the main and alternate story NPC characters like Braham or Evon Gnashblade. I show that the | SMW NPC page shows a property for Has disposition with a multi-string value. I was thinking maybe we could use that. Then I came to the conclusion that will not work as they are not always a enemy in all areas that they would be listed in. So I decided that probably the best way to go about this is flag all the story NPC's or even all the non-generic NPCs systematically add those. Then manually add all the non-generic. Most of the generic NPC's have a location of Tyria anyways so they would not appear on a location query. Anzenketh (talk) 18:34, 26 May 2014 (UTC)

NPC location proposal

As User:Louise continues to make us all look bad, its started me thinking about how the way we handle documenting the location of NPCs isn't working out well. For an example of this, see Grub (NPC). The infobox essentially duplicates the info of the article, and that's not especially useful. As such, I propose the following changes to how we handle NPC locations:

• For allied NPCs like renown hearts and shopkeepers which are found in one and only one location, the infobox should state the area and zone which they are located in.
• I don't think the POI where NPCs can be located should be put in the infobox, because some NPCs are not found "in" a POI, and many POIs have no discernible boundary. Therefore in the interest of consistency, the infobox should only get as specific as the area where it can be found.
• For allied NPCs which have multiple locations, the infobox should state the most specific location it can. If the NPC can be found in multiple zones, it should state the region its found in. If it can be found in multiple regions, it should just say that it varies and to see the article for details
• For most foes, the infobox should state all the regions where they can be found. For instance the infobox for Alpine Skelk would simply state that they are found in the shiverpeak mountains, and the infobox for Veteran Oakheart would state that they were found in Kryta, Ascalon, and The Mists.
• If a foe is only found in one zone, the infobox should state the zone and the region where it is found. If its only found in one area, it should state the area and zone where it is found.
• The infobox for dungeon specific NPCs should state the area and dungeon where they can be found, or just the dungeon where they can be found if they are found in multiple areas within a dungeon.
• The infobox for personal story NPCs should state which step they are involved in. If they are involved in multiple steps, the infobox should state that the location varies and to refer to the article.
• When an NPC is found in a combination of the open world, dungeons, and personal story quests, the infobox should state that their location varies and to refer to the article.
• All NPCs should have a list of their locations in a standard format, even if they are only found in one location. The output would look the same as it does now (Golden Moa for an example), except...
• NPC location entries should be in a template, something like {{npclocation|area|level}}. The purpose of this template would be to make it easier to add location entries to the articles, but maybe it can also be used to make automatically populating lists of NPCs for the area articles. I think its a neat idea but I also have no idea if its possible.

That's all I can think of for now. WHAT SAY YOU? Psycho Robot (talk) 02:24, 14 November 2013 (UTC)

Sounds good to me. --Claret (talk) 02:29, 14 November 2013 (UTC)

personally I would like to see a hierarchical menu in the infobox but that may be too difficult to code. --Claret (talk) 02:57, 14 November 2013 (UTC)

"hierarchical menu in the infobox" *KZRRKX* DIVIDE BY ZERO ERROR. PLEASE INSERT KUMQUAT AND REBOOT. —Dr Ishmael 03:53, 14 November 2013 (UTC)

"*KZRRKX* DIVIDE BY ZERO ERROR. PLEASE INSERT KUMQUAT AND REBOOT." Not sure what that means. Humor, if that is what it is, is often lost in purely textual communication. --Claret (talk) 04:29, 14 November 2013 (UTC)

Possible translation: So difficult to code a "heirarchical menu" that it broke dr ishmael. I'm not 100% sure what you mean, but if semantic tree format was working it might just be possible.

• although the amount of work it would create would be horrendous, personally I'd remove area/zone locations from the infobox entirely + use some kind of **{{npclocation|area|level}} template as you suggest instead. Just like {{Contains|<item name>}} + {{Contained in|<area name>}}. Formatting the it shouldn't be difficult - but we'd would have to distinguish between foes and allies in the infobox though to be able to split up the list on articles like Grawlenfjord#Foes.
• Storing the region in the infobox instead seems sensible since most articles will get tiny infoboxes as a result. -Chieftain Alex 07:52, 14 November 2013 (UTC)

Now I am worried that dr ishmael is broken. I feel responsible. How can I make amends? Yes, it's outgrown the infobox. --Claret (talk) 08:00, 14 November 2013 (UTC)

Not the difficulty so much as putting it in the infobox. That would take the current situation and expound upon it - unless I'm misunderstanding what you mean by "hierarchical menu." —Dr Ishmael 13:28, 14 November 2013 (UTC)

Just ignore ishmael, he's always trying to get people to shove kumquats inside him. I told you no and I meant it. In any case, as the kumquat fetishist said, putting hierarchical menus in the infobox would just make it more cluttered. The list of NPCs in the articles would be essentially a heirarchical list, starting with the region, then breaking it up into zones, and finally into areas, it just wouldn't have the expanding effect that I think you were getting at, and I don't think that's a good idea, because it would needlessly obfuscate the information. Psycho Robot (talk) 18:18, 14 November 2013 (UTC)

pretty much--Relyk ~ talk < 10:55, 14 November 2013 (UTC)

It's amusing how stuff keeps recurring. --Claret (talk) 11:06, 14 November 2013 (UTC)

Nah, I'm just ahead of everyone else.--Relyk ~ talk < 11:23, 14 November 2013 (UTC)

So in your opinion using SMW stuff to generate automatically populating lists would work out? If that's the case then a thought occurred to me: what about POI articles like Hanto Trading Post? Is that evidence that, contrary to my previous notion, we really should be listing NPCs under POIs if its applicable? Psycho Robot (talk) 18:18, 14 November 2013 (UTC)

service = Living World

[[:Category:Living Worlds|a few npcs]] have "Living World" set as their service. I don't think this is a service + I would propose that they be manually placed into a "Living World NPCs" category instead + remove the parameter. -Chieftain Alex 13:29, 24 November 2013 (UTC)

I thought that service was determined by the floater icon above the NPC - although usually corroborated by being appended to the name in square brackets, the icon is also important on its own. —Dr Ishmael 15:57, 24 November 2013 (UTC)

oh hang on. should these npcs be using Living world or Living story... -Chieftain Alex 18:35, 24 November 2013 (UTC)

Living World is the correct term.--Relyk ~ talk < 19:41, 24 November 2013 (UTC)

Multiple goals

A few NPCs - Sonjaw Redclaw as an example - have more than one goal. Some goals have commas in thir names. Solution? --Claret (talk) 12:31, 27 November 2013 (UTC)

use a newline "\n" as the separator, and put new goals on a new line? -Chieftain Alex 14:56, 27 November 2013 (UTC)

That sounds good. However, my coding, such as it is, does not extend to the wiki. --Claret (talk) 15:28, 27 November 2013 (UTC)

I see you have done this Alex, thanks. --Claret (talk) 15:36, 27 November 2013 (UTC)

Service: Guild Bank or Guild Banker?

All the Bankers are labelled as providing the Service, "Bank", yet all the Guild Bankers are currently labelled as providing service, "Guild Banker". The Service parameter shows an error for "Guild Banker" (apparently it should instead be "Guild Bank"). Shall I correct all the Guild Bankers' Service parameter to "Guild Bank"? -Lord Mondegreen (talk) 23:53, 3 January 2014 (UTC)

yes :)--Relyk ~ talk < 00:25, 4 January 2014 (UTC)

Done! -Lord Mondegreen (talk) 01:34, 4 January 2014 (UTC)

Sorry, that's ridiculous. (1) The person who runs a bank is called a banker, not a bank. (2) All the members of the category were called guild bankers not banks. Surely if would have been easier to leave it at the accurate, properly named wording. --Claret (talk) 01:44, 4 January 2014 (UTC)

Further, Chieftain Alex recently changed "Bank" to "Banker" so there's some extra support for my pov. --Claret (talk) 01:53, 4 January 2014 (UTC)

The npc is labeled "<Name> [Guild Bank]" and "<Name> [Bank]". The NPCs are labelled as "Banker" and "Guild Banker" on the map. Our convention is to use the NPC name notation, that's valid as far as template parameters. Either way is perfectly fine, so I shouldn't say it needed to be changed; just keep in mind not all NPCs get labelled on the map. The actual link will be to guild banker and banker for the service page in any case. On another note, Alex doesn't own the game.--Relyk ~ talk < 03:22, 4 January 2014 (UTC)

It works in two ways: 1. he's not the boss of the whole game, and 2. he literally doesn't own it! Ha! Psycho Robot (talk) 03:27, 4 January 2014 (UTC)

I did not say that Alex did, nor tried to imply that he did. But whatever… --Claret (talk) 10:15, 4 January 2014 (UTC)

(Reset indent) hurr. I just changed it because it was screwing the categories up and producing "guild banks" for the npcs, which didn't make sense as an NPC category name. The service should be whatever it is ingame, and the category logic should figure out to call the category name something that isn't retarded. i.e. "service = Guild Bank" and it should categorize into "Category:Guild Bankers". Just fill out the service parameter with how it is ingame, and we'll fix it up later on the infobox template. -Chieftain Alex 11:56, 4 January 2014 (UTC)

Like so. -Chieftain Alex 12:02, 4 January 2014 (UTC)

Historical paramter removing categories

So if someone fills the | historical = parameter, all other categories made by the infobox will no longer exist. I really hate this personally as it prevents, for example Doc Howler being listed in Category:Humans. This is bad, as the NPCs should still be in their racial categories, as well as their affiliation categories. I looked at the code and couldn't see what would be needed to be done to remove this, but these categories should not be removed (the service ones makes sense to remove, however). Can someone who knows wiki coding better than I fix this? Konig 22:13, 23 March 2014 (UTC)

Do we need to categorize NPC articles for NPCs that no longer exist in the game? I thought the infobox templates are intentionally coded like that to keep historical articles separate from content still in the game.--Relyk ~ talk < 22:53, 23 March 2014 (UTC)

Maybe we should differentiate "historical" (meaning unimplemented or removed-from-game) from "deceased" (meaning they are dead in lore/canon) and have them disable different branches of the auto-cats. —Dr Ishmael 00:39, 24 March 2014 (UTC)

@Rylek the Hylek: We have lore figures not in game in those very categories I mentioned. E.g., Cobiah Marriner. I see no reason why NPCs who were but no longer are in-game shouldn't be. It isn't like we remove and re-add Mad King Thorn from his categories so why remove not-in-game NPCs?

@Ishy: I agree. They may have been removed, but some like Captain Theo Ashford or the Twisted Marionette,remain relevant. Then there are those like Captain Mai Trin who are (well, mostly in this case) removed but still relevant. For such reasons, I avoided historical tags on NPCs thus far. Locations and especially events makes sense (maybe not locations but eh). Konig 00:53, 24 March 2014 (UTC)

Edit: I don't mind the historical tab, but the removal of the race/organization categories. It messes up categorization of the articles. Konig 00:56, 24 March 2014 (UTC)

Characters that don't exist in the game have nothing to do with NPCs that are removed from the game, which is what historical refers to. Mad King Thorn is a recurring NPC, so he's not the best example from an NPC removed from the game. The historical content tag doesn't mean that the lore related to the NPC has been redacted, just that the content for the NPC no longer exists in the game. The racial and affiliation categories are mechanical, I can see leaving the affiliation category since that's lore-related.--Relyk ~ talk < 01:10, 24 March 2014 (UTC)

You missed my point. Thorn and characters that don't exist in the game remain in the categories regardless while historical NPCs are being removed from the categories because they're tagged historical. It isn't so much a case of them being tagged historical, but the fact that tagging them as historical removes the categories. I have absolutely no issue with tagging them historical. I DO have issue with removing them from the categories, even if they don't end up in the DPL lists they should be in the categories so that those looking for all, e.g., Lionguard can go just to Category:Lionguard and don't have to bother sorting through Category:Historical content too. In other words: Why would Cobiah Marriner be in Category:Humans when Doc Howler is not? And on an side: if you remove such category/ies from non-in-game NPCs they'll be more or less category-less

"The racial and affiliation categories are mechanical, I can see leaving the affiliation category since that's lore-related." Wrong. Both of them are both lore and mechanical. But this is more of a quality of life thing than anything else. And if there's an issue with the dpl lists on articles, we can easily add a parameter to disclude members of the historical content category rather than removing them from all other categories. Konig 02:09, 24 March 2014 (UTC)

Not sure you are reading the words I am writing. As far as the template for the infobox is concerned, it categorizes the NPC based on the mechanical race and affiliation. This has nothing to do with lore. When you tag the infobox as historical, you do not want the NPCs in that are in the same category mechanical. Mad King Thorn is an NPC that existed in the game and is not the same as a character that only exists in lore. He is therefore categorized mechanically because the page uses the infobox. He is not tagged as historical because he is a recurring NPC.

Cobiah Marriner is assigned to the category manually, not by the template. You're confusing pages related to the category mechanically or by lore. You can easily tell people to add the categories manually if you want the page associated by lore. That should be fine because the historical content category only applies to NPCs mechanically, although relating the page to lore by the infobox is a weak connection. I am not fine with your argument that the template should categorize the pages as the category is not for lore as far as the template is concerned.--Relyk ~ talk < 02:52, 24 March 2014 (UTC)

"You're confusing pages related to the category mechanically or by lore. You can easily tell people to add the categories manually if you want the page associated by lore." Your argument makes no sense to me. You are basically, if I understand right, saying "if it's mechanical, it gets categorized by the infobox; if it's lore, it gets categorized manually" - but the end result is the same and its categorized in the same exact category. Cobiah Marriner is categorized manually because it lacks an infobox (it lacks an infobox because it isn't an in-game NPC), so if articles in question have an infobox, why bother categorizing manually? That's just extra work - redundant work, even. These historical NPCs have the infobox, they have the proper parameters filled out, so why should we categorize each individual page manually with what would be automatically categorized anyways if not for the historical parameter when all we have to do fix the shared template's parameter? How it is done shouldn't be determined by if it is lore or mechanic information if the end result is the same. Konig 03:16, 24 March 2014 (UTC)

The point is that the race and affiliation have applications mechanically, as far as Slayer and other achievements are concerned. I don't like that the categories are sticking NPCs related mechanically or by lore because makes them impossible to use for reference on achievements. However, I do think it's fine at this point to have the infobox use the categorization for the NPCs lorewise because we can use Semantic Mediawiki to identify the NPCs that are mechanically related.--Relyk ~ talk < 04:59, 6 April 2014 (UTC)

Services

I don't think we need the parameter multi-valued; an NPC only ever has one service. It seemed to only be used for renown heart NPCs, which was incorrect in the first place.--Relyk ~ talk < 05:01, 6 April 2014 (UTC)

Ya sure sounds good to me. I always thought it was weird that heart vendors were also marked as karma vendors, since to me it seems like they should be different, or at the very least one or the other. Psycho Robot (talk) 19:34, 6 April 2014 (UTC)

Renown NPCs are a subcategory of karma vendors with an additional condition (have to complete their task to enable vendoring). —Dr Ishmael 20:42, 6 April 2014 (UTC)

Commander trainer

Could we have a "Commander trainer" as an option. At present, the commander trainers seem to be listed as just "trainer" which may be suboptimal. Thanks. --Rhynchelma (talk) 01:21, 21 May 2014 (UTC)

It is a option "Commander trainer" is a redlink however. I would create it but I have not determined what should go there. Anzenketh (talk) 18:57, 2 June 2014 (UTC)

Guild weaponsmith

Infobox does not seem to like this. Should be an option, ?broken --Rhynchelma (talk) 12:28, 23 May 2014 (UTC)

works fine for me. Perhaps a recent change fixed this.

New parameter: status

I'd like to propose we add a new parameter to the infobox (and thus a new NPC property): status. Possible values could include "Alive", "Dead", "Unknown", "Undead" (ghost?), or any others. The original reason for this was that setting | race = Ghost conceals what race the character originally was, but now I think about it, it would have even more utility since PS and LW NPC's often "die" in lore. This means that the infobox location parameter is conspicuously empty, or they are tagged with {{Historical}} which messes up categorisation and DPL, or some other complication. –Santax (talk · contribs) 22:54, 3 June 2014 (UTC)

Yes yes yes. I thought about this back when Lion's Arch was under attack, because I knew at least one character will die but I kinda just forgot about all that. That'd be a great idea and would help a lot with the future releases. --Ventriloquist (talk) 22:59, 3 June 2014 (UTC)

Setting the historical parameter doesn't mess up categorization or DPL. We can have templates be categorized even if they are tagged as historical. The historical parameter has no impact on DPL since we don't use DPL. I don't know what you mean by the location parameter being empty. I assume "conceals what race the character originally was" is related to the risen. The race parameter only details the group the NPC belongs to, not what we want to consider their race in lore is.

In addition, a status parameter has no meaningful usage. People don't care whether they are alive or dead, only whether they exist in the game. A status property doesn't have meaningful usage. If we want a list of Living World NPCs we consider alive or dead, make a list.--Relyk ~ talk < 23:38, 3 June 2014 (UTC)

Redundant maps

Is there anyway to get a map location for an NPC not to show, in the occasion that that map is no longer accurate? For example, for the npc Black Davi the map location for him is no longer correct but I don't particularly want to update the file with his new position as he's no longer an NPC of any real value. No longer a service NPC, one line of dialogue etc. I'm not exactly versed in wiki code and the likes so i'm not aware of the proper solution to this. --Wingsy (talk) 22:33, 4 July 2014 (UTC)

Most NPCs don't use maps except for the ones that had their files uploaded on release or even pre-release (as you can see, your example shows it was uploaded on May 2nd, 2012). Click on the file, tag it as {{delete|<reason here (in this case, redundant map)>}} and one of the admins will annihilate it soon enough. With that being said, NPCs don't need maps most of the time, unless they're on a hard-to-find location or something. --Ventriloquist 22:49, 4 July 2014 (UTC)

New parameter: disposition

I think it would be nice if there was also a parameter for disposition (Friendly, Hostile, and Neutral). For NPCs who change dispositions, you could just list them in the same way multiple locations are listed, but with the "primary" or "default" one first.

Ex: Roj the Rowdy Butcher, a skill challenge NPC.

{{NPC infobox
| race = Charr
| level = 17
| disposition = friendly, hostile
| profession = Warrior
| service = Skill challenge
| location = The Blasted Moors
| goal = Defeat Roj the Rowdy Butcher
}}

It would also be really cool if the top strip of the infobox, where the NPC's name is, could match the color of their disposition (or their "primary"/"default" one).

1. Friendly = green (like all NPCs/objects use currently)
2. Hostile = red
3. Neutral = yellow

I don't know how difficult it would be to add this color functionality though, or if it's even possible at all. I just thought it would be a nice touch as it's the same color system used in-game to differentiate dispositions from one another.

-Somohexual (talk) 16:56, 19 October 2014 (UTC)

This has been brought up before. The consensus was that it really isn't all that useful in the first place, so there's not much point in spending time adding it to every NPC page. —Dr Ishmael 17:05, 19 October 2014 (UTC)

I thought the Wiki was meant to be a detailed source of information though, how an NPC interacts with players seems significant enough to warrant being included. Just look at how confusing or vague some NPCs pages could be:

1. Veteran Mosshearts are neutral but probably look like a big, hostile tree monsters to someone new to Guild Wars.
2. Veteran Golden Moa (neutral) and Veteran Eagle Griffon (hostile) don't behave in the same way, but appear to belong in the same category as if they do.
3. All guild bounty NPC pages just look like another Champion event boss, but they also roam the map as friendly NPCs and let players talk to them. Many new players accidentally run into them in-game and think they're just friendly NPCs that are part of something like an event.
4. The page for Skritt Sentry makes them look identical to Skritt Pistoliers or any other Skritt enemy, but instead they're friendly and guard allied Skritt territory.

-Somohexual (talk) 20:15, 21 October 2014 (UTC)

I would worry that the labelling would be too subjective. Would someone like Reidarr Rockcrusher be labelled as friendly (as that's how he first appears), or hostile (as that is the general reason for him to be in game); the same can be said for the guild bounty NPC's. There are also NPC's which sometimes change from friendly to hostile after talking with them (I can't recall the heart where you have to interrogate the servants).

It is an interesting idea, and would add more flair onto the pages, but I see a number of edit wars happening over it. G R E E N E R 21:08, 21 October 2014 (UTC)

There are simply too many different cases to deal with in the infobox. A significant portion of NPCs can be both friendly and hostile, like the examples Greener pointed out. All of these would require an out-of-infobox explanation of how/where/when they are encountered in each disposition or what causes them to change. The info shown in the infobox would be useless on its own, so there's really no point having it in the first place. —Dr Ishmael 21:15, 21 October 2014 (UTC)

I already mentioned they could be listed in a similar way to how multiple locations are in the infobox but with primary, default (AKA: without player interaction), or most commonly seen disposition listed first.

1. Guild bounty/Skill Challenge NPC/any NPC you can challenge to a fight = friendly, hostile
2. Boss NPCs that are briefly considered friendly just so they can deliver their lines without getting killed (Faolain, Kudu, etc) = hostile
3. NPCs that only attack when provoked = neutral (keep in mind, you can provoke some creatures without attacking them)
4. NPCs that attack when provoked but become friendly when a certain condition is met = neutral, friendly
5. NPCs that attack when provoked but become hostile when a certain condition is met = neutral, hostile
6. NPCs that attack on sight but become neutral when a certain condition is met = hostile, neutral
7. NPCs that attack on sight but become friendly when a certain condition is met = hostile, friendly
8. NPCs that wont attack and cannot be attacked but become neutral when a certain condition is met = friendly, neutral
9. NPCs that wont attack and cannot be attacked but become hostile when a certain condition is met = friendly, hostile

If the first disposition listed in the infobox determined the color used for the NPC's name tag (Friendly = Green, Hostile = Red, Neutral = Yellow) then it wouldn't be useless. It would give people a quick way to identify how this NPC behaves in-game, primarily or completely.

-Somohexual (talk)

This is something that is extremely variable and too dependent on the content. The very same creature can be found as both enemy and ally. The best example of this are the 5 racial allies. There's no "primary" for them, which one would you set first one for a "skritt thief" or a "skritt forager" that appear as both allies and foes? Would just instead make pages for each appearance of each NPC like the Queensdale skritt and then the Harathi Skritt? You can't do that, it's actually two instances of the very same creature, just being spawned in different map factions.

This is also the result of a combinations of flags and settings we can't see. An enemy isn't really just set "Ally", "Hostile" "neutral". Yellow-named enemies aren't really "neutral", but "non-aggresive enemies" with such a low aggression towards all other factions they can attack, that they won't attack anything. The actual neutral creatures are the green-named ones that will be ignored by enemies and not take boons or other allied effects from players. And if you remember, several enemies are hostile to each other.

This happens, as far as I can tell from what I've seen and heard from devs, because enemies aren't really set as "hostile", but they are instead set as part of a 'map faction' or 'map team'. Then those teams are the ones that get the actual settings that determine their relations. All creatures in a map would then be dynamically switched between teams when their behavior towards other creatures needs to change, and the aggressiveness value that determines aggro (what makes a yellow-named creature start yellow and then go red) comes after that as a separate value.

But we can't know to which team anything is assigned. For example, when we can't give boons to an NPC that's because they joined the team that makes them immune to that or because some flag was changed on them? When two enemies do not attack each other that's because they are set as part of the same faction or because they are part of factions that are allies or factions that ignore each other?

These and other reasons caused previous editors to decide that it's better to leave this out of the NPC infobox back in GW1, and things have not only not become easier now in GW2. They got even fuzzier as content makers have taken a liking to dynamic changes in creatures. As it's something that comes with the location or event that spawns them, its better to put it in the Allies and Foes sections of event and location pages rather than in the NPC pages. MithTalk 22:55, 21 October 2014 (UTC)

If it's too fuzzy for NPCs with multiple dispositions why not just reorder the categories a bit.

1. Hostile = attacks the player when unprovoked (Red)
2. Neutral = attacks the player if unprovoked (Yellow)
3. Friendly = cannot attack players or be attacked by players (Green)
4. Variable = disposition varies (Blue or Grey)

Ex 1: Roj the Rowdy Butcher (blue or grey nameplate)

{{NPC infobox
| race = Charr
| level = 17
| rank = normal
| disposition = variable
| profession = Warrior
| service = Skill challenge
| location = The Blasted Moors
| goal = Defeat Roj the Rowdy Butcher
}}

Ex 2: Skritt Forager (blue or grey nameplate)

{{NPC infobox
| race = Skritt
| level = 3-45
| rank = normal
| disposition = variable
| location = Ascalon, Kryta, Maguuma Jungle, Shiverpeak Mountains
}}

Ex 3: Arid Devourer (red nameplate)

{{NPC infobox
| race = Devourer
| level = 80
| rank = normal
| disposition = hostile
| location = Prospect Valley
}}

Ex 4: Oakheart (yellow nameplate)

{{NPC infobox
| race = Plant
| level = 9-42
| rank = normal
| disposition = neutral
| image = Veteran Oakheart.jpg
| location = Eternal Battlegrounds, Gendarran Fields, Queensdale,Harathi Hinterlands
}}

Ex 5: Caithe (green nameplate)

{{NPC infobox
| race = Sylvari
| rank = Legendary
| disposition = friendly
| profession = Thief
| organization = Destiny's Edge
| location = The House of Caithe, Twilight Arbor
}}

-Somohexual (talk) 15:12, 22 October 2014 (UTC)

Well, that is a much cleaner approach than the first one, and I would say more feasible to implement. My next question to you - playing the Devil's Advocate - is whether or not it will be used.

An analogy may be the lovely spreadsheet I once made for Borderlands 2 so as to not only compare weapons, but have an at-a-glance overview of my build. The issue was that I never used the latter part of the spreadsheet, ever. The time it would have taken gather the new information while travelling around made it a near pointless endeavour, especially as I could almost always figure out in-game what my spreadsheet would have simply confirmed.

So, would the typical player, new or otherwise, stop upon seeing an NPC (which this game is full of) and look up who they are on the wiki? They would only do so upon seeing a green-text NPC in-game, and the vast majority of those would be confirmed by the wiki as "friendly". After a while, they'll stop bothering to confirm what they already assume to be correct.

I may be missing a pathway in which this labelling would be accessed, though. G R E E N E R 22:18, 22 October 2014 (UTC)

I still can't see it as a property inherent of the creature, but of the the location or event that spawns it. We already have the allies and foes sections on those. MithTalk 00:50, 23 October 2014 (UTC)

Changing the template to accommodate for this disposition system would be the only thing that really requires significant work or time, I don't see how it would take an intensive amount of information gathering though. Plus, it would make NPC pages much more appealing to the eye.

-Somohexual (talk) 15:10, 26 October 2014 (UTC)

There are over 8,000 pages that use this infobox. Every one of them would have to have their disposition verified, then someone would have to edit the page to add the parameter to the infobox. Even if we pick a default, say "friendly," that would only cover, on average, half of them - there would still be around 4,000 pages to edit. THAT is what requires the most significant amount of work, and the benefit gained from this is negligible compared to that. —Dr Ishmael 17:05, 26 October 2014 (UTC)

Why not making things automatic? The info is already int the allies and foes sections in location and event pages. They could be made into something similar to the vendor and container templates. A "{{npc|disposition = ally/foe/varies|neutral = y/n|xxxx}}" template could be added. Then the NPC's page would check the locations and events to see whether it's ally or foe and where it's ally or foe. Then part of the process could be automated. We'll only need to manually put the info that's missing: neutrality (neutral enemies arenot agressive and have yellow names, neutral allies are ignored by enemies and can't be affected by player's bfriendly effects). Since most NPCs are either neutral allies or hostile foes, then the only thing left to set manually are the exceptions: friendly allies and non-aggressive/neutral foes. MithTalk 17:05, 27 October 2014 (UTC)

Those lists are often incomplete and inconsistently maintained. And someone would still have to potentially edit almost 5,000 location/event/personal story/renown heart pages to add that new template (botting something that huge when we have no way of guaranteeing the consistency of page layouts would be rather risky). —Dr Ishmael 18:58, 27 October 2014 (UTC)

Random models

Several NPCs – often with generic names, such as the human "Bartender" found at Plaza of Balthazar, Salma District, and Evonhawke – have random appearances that change each time the map is created. Wouldn't it be cool if for those NPCs with random models we had a gallery with all known possible images, and when their wiki page loads, one random image is picked from the gallery and used in the infobox, with a "See full gallery" line under the image? Would that be possible with the current version of the wiki? MithTalk 21:02, 19 October 2014 (UTC)

 | image = {{#switch: {{#expr: {{#time:U}} mod 4 }}
            | 0 = Image zero.jpg
            | 1 = Image one.jpg
            | 2 = Image two.jpg
            | 3 = Image three.jpg
           }}

Possible - yes. Whether we want it or not, meh. -Chieftain Alex 22:10, 19 October 2014 (UTC)

No, no. I mean having a gallery, and the infobox picking one random image from the gallery, so we just add images to the gallery without adding them to the infobox. MithTalk 00:04, 21 October 2014 (UTC)

We'd have to work it through SMW. Each image in the gallery would be tagged with [[Propery:Has appearance]] (as [[Has appearance::File:blah.jpg]]), then the infobox would query that property and select one of the results at random, in a similar fashion to Alex's snippet. —Dr Ishmael 01:03, 21 October 2014 (UTC)

Might be best to set up a parameter so that the infobox can just have a "see gallery", and the gallery have all possible models. This would work not just for those which have randomly chosen models, but also those generic names that have multiple hard-coded models (e.g., Son of Svanir). It's annoying to have the infobox with just one specific model out of many, or red-linked. Konig 23:36, 20 October 2014 (UTC)

We can already create galleries on the page, using the <gallery> tag. What's wrong with that? —Dr Ishmael 23:48, 20 October 2014 (UTC)

Pick an image to go at the top, and stick a gallery section on the page. If people care, they will find it. -Chieftain Alex 07:10, 21 October 2014 (UTC)

That's what's already done. It's not something I care too much about, but imo, gw1:Thrall is better formatted than Son of Svanir in regards to images. And what about pages which only have two variants (e.g., Icebrood Norn). Having a gallery with one image seems silly. Having a gallery with two images and one being a duplicate of what's in the infobox seems equally silly. But as said, it's not something I care too much about; just thought since the topic's come up, I'd offer my 2 cents. Konig 23:14, 23 October 2014 (UTC)

Ah, I didn't quite catch your gist before - you are saying to use the built-in gallery format, as I did, but you want an option to suppress an image in the infobox. I suppose that could work. —Dr Ishmael 00:05, 24 October 2014 (UTC)

Well, if you pick one random image from the gallery each time the page is loaded like I say looks better and matches the game behavior (picking a model each time a copy of the map is generated). But suppressing the image makes the gallery much ore noticeable as some people will ignore a "See full gallery" text under or over an image. So I guess going with functionality takes precedence over presentation. In any case, the main point is that some creatures have multiple appearances, sometimes random, at the wiki could document that. MithTalk 00:11, 24 October 2014 (UTC)

Konig's Son of Svanir example isn't a good example for that, though - each appearance is actually a different NPC - they use different weapon sets, but they all have the same name. They really should be split into separate pages so that we can track their occurences better (e.g. only the axe and greatsword versions appear in one area, while every version except longbow appears in a second area).

On the other hand, if the NPC always appears in the same location with the same functionality, but can have different appearances, then it should remain a single page with a gallery. We could modify the infobox either way, I would just like a consensus on which way is preferred before doing so. —Dr Ishmael 00:39, 24 October 2014 (UTC)

Let's se... my ideal way is:

1. Images are added to a gallery in a subpage (eg.: Thing You Wanna Kill/Gallery ).
2. Instead an image (| image=Thing You Wanna Kill.jpg ), the image property get a gallery page: (| image=Thing You Wanna Kill/Gallery).
3. The infobox will detect it's is getting a gallery instead an single image, and pick a random one among all images of the gallery to show each time the page is loaded, and add a link under the image show that directs to the gallery subpage ("See full gallery").

My second preferred way is having just a link to the gallery without images, so the user goes to the gallery that may be at the bottom of the same page or a in a subpage.

My least preferred way for creatures with random appearances is having one fixed image in the infobox. MithTalk 02:12, 24 October 2014 (UTC)