Template talk:NPC infobox

Archive

---

• Archive 1

Sharks

Why not? It pointed to the NPC, the alternative is to rename Shark as Shark (NPC) and go through all the links to update them. Or am I missing something? Or is your non edit of my comment suggesting that the Shark (NPC) is the way to go? --Spionida (talk) 23:26, 25 February 2015 (UTC)

That's the code that handles categorization Spionida.--Relyk ~ talk < 23:30, 25 February 2015 (UTC)

Ok, thanks, it's sorted obviously. This is why I asked for a coder's input earlier in the debacle. Sadly none came in time. Thanks again. --Spionida (talk) 23:33, 25 February 2015 (UTC)

(Edit conflict) What relyk means is that the category defaults to #default = [[Category:{{ucfirst:{{{race|}}}s}}]] (scroll way down to the bottom of that category switch statement. This means that it takes whatever is given by the race parameter ("Shark") + sticks "s" on the end of it ("Sharks"), and makes that the category name ("Category:Sharks"). -Chieftain Alex 23:33, 25 February 2015 (UTC)

Various

"Various" is again treated as a red link, as seen on Consortium Planner and a whole bunch of other pages. —Ventriloquist 08:42, 15 April 2015 (UTC)

some overlooked simplifcation at one point I'm sure. fixed (probably) -Chieftain Alex 21:23, 15 April 2015 (UTC)

Thanks, where would I be without you. :P —Ventriloquist 21:28, 15 April 2015 (UTC)

Faction Provisioners

We might want to add support for Faction Provisioners as a service, with the appropriate icon if possible? -- Fam (talk) 04:52, 4 December 2015 (UTC)

All you should need to do is upload File:Faction Provisioner.png and the #default branch of the #switch will pick it up. Honestly, a lot of the other cases in that #switch would fit the #default and don't need to be cased explicitly. —Dr Ishmael 05:13, 4 December 2015 (UTC)

Thats what I get for not looking at the Template source I guess, thanks. I've extracted the icon and uploaded (there is no 64x64/128x128 version, so will have to live with a slightly-upscaled 32x32). -- Fam (talk) 00:55, 5 December 2015 (UTC)

Normal Rank

I was wondering if | rank = normal (or | rank = basic since that seems to be on there) could be removed since by default most npc are marked as normal, and we really only use rank if they're not normal. - Do_odleplex 20:46, 18 August 2016 (UTC)

Adding to the above, can "| status = current" be removed as well as NPCs should really only be marked if they're temporary or removed, having "current" seems a bit redundant. - Do_odleplex 18:22, 19 August 2016 (UTC)

Though I've been overall lax on it, I think it should specify normal ranked (even if it means by default/leaving the parameter blank too). Agreed on the current status though. Konig 19:29, 19 August 2016 (UTC)

You're not supposed to specify either of those lol. -Chieftain Alex 19:39, 19 August 2016 (UTC)

I haven't been adding them, but I have been seeing then while in the process of adding images of shared models to pages. Should I delete them if I see them? - Do_odleplex 19:40, 19 August 2016 (UTC)

| status = Festival

I'd like to make a request for the Status parameter for adding a parameter to either a generic festival parameter or one specifically for Wintersday, Halloween, and SAB. These would replace the need to use | status = temporary and manually put in the {{temporary}} tag on the top of festival related articles, especially since they're not really temporary but reoccurring/annual. Ideally we'd have one per repeating festival so that the tag is specialized for the event. Konig (talk) 17:03, 19 October 2016 (UTC)

I like this idea better than temporary, as really all of the NPCs I think that are currently marked with "temporary" are seasonal NPCs, or historical and never returned(for example NPCs from The Lost Shores). Not to mention it would remove there being two tags at the top for things that were marked as temporary that became historical. So yeah, I like this idea. - Do_odleplex 17:32, 19 October 2016 (UTC)

While we're at it I think we need a "| status-description" added so that the status can be "festival" and description can be "blood and madness". It could also be used to describe why a status has been used since {{infobox status}} with accept it now. J.Tesla (talk) 17:50, 19 October 2016 (UTC)

That might not be needed if the status could be specify exactly which festival, ie | status = Wintersday 2014 or | status = Halloween 2013, that way NPCs that were in previous festivals that didn't return can be notated as being from that festival but are historical. Though calling it status feels weird to me, what about a new line like "| festival = Halloween 2013"? - Do_odleplex 18:06, 19 October 2016 (UTC)

Putting the year may start to get troublesome next year. If the event repeats again everything will be marked as halloween 2016 and have to be updated. It may be better to assume if the event is repeated like this year it will have all the same npcs unless stated otherwise. Thinking about it some more, what about items that were in last year but have since been discontinued? I think "| festival = blood and madness" with "| status = discontinued" and "|status-description = This item was only available during blood and madness for the year of 2015" would be a good solution. J.Tesla (talk) 18:27, 19 October 2016 (UTC)

True, so perhaps the idea of having it on something like | festival = Halloween would leave the status part open to be used to mark NPCs historical if needed. Also, you might want to put the item stuff on the Item infobox template talk page, not the NPC infobox template talkpage. ;) - Do_odleplex 18:37, 19 October 2016 (UTC)

I don't think specifying the year is necessary or worthwhile. Most Halloween and Wintersday - and SAB - still are now fully annual, only being taken out due to bugs (presumably). If something was part of a festival and didn't return, it'd simply be historical - no need for two tags. And any note for why it was taken out belongs in the Notes section, not infobox - if a note is needed for editors, then there's using the <!--(note here)--> method. And I would suggest this change be done to all infoboxes in general (object, area, item, etc.) since they're all doing the same thing. Konig (talk) 18:43, 19 October 2016 (UTC)

When you enter "historical" or "future" into "| status" in this template it goes first to the "infobox status" and then to the correct notice template. Infobox status has been updated to include descriptions but this template doesn't support that yet. I was planning to add "| status-description" anyway but it may have been useful for festival stuff too. And I agree that a page doesn't need the Halloween temporary banner and historical banner, just the historical would do. A description in the historical banner can always link back to the event. J.Tesla (talk) 18:54, 19 October 2016 (UTC)

(Reset indent) I noticed somebody used | goal = Halloween on a halloween NPC. Perhaps the answer is as simple as that, ie going | goal = festival would put a tag went up on top for what festival it was linked too, and would leave |status = open to notate if that NPC didn't return for future festivals. (Also don't forget Lunar New Year is a festival too.) Just a thought anyway. - Do_odleplex 19:43, 20 October 2016 (UTC)

Personally, I really hate the goal parameter. On one hand, what people would see is "part of" which is far too generic - almost every NPC, object, or item that's part of something is part of at least ten things (hearts, events, story instances, storylines, releases, zones, areas, dungeons, raids). On the other hand, "goal" sounds so specific as to referring to when the subject of the article is the specific primary/secondary objective of something else (e.g., an event). Personally I want to see that parameter removed entirely.

It is also a bad idea to have multiple parameters slap a tag on top of the article, and using the status parameter to slap a {{temporary|Halloween}} tag on top of articles is what I'm proposing (though ideally it'd be its own {{Halloween}} template so that if there ever is a desire to use it outside of the infobox we can do that, just as we do for {{Heart of Thorns content}}. If we had two or more parameters place tags, then it'd just get unsightly fast (and would have to make players scroll down).

And a thought: we should mimic the HoT content tag with the festival tags rather than having these big boxes. This way we can feasibly use both historical and festival tag without it becoming unsightly (one would have to be a manual transclusion like with historical HoT content when this occurs). Konig (talk) 21:45, 20 October 2016 (UTC)

I think you guys are making up your own definitions for what "temporary" means. Any recurring events fall under the "temporarily unavailable", like the template explicitly says. I disagreed with tagging special events when we first started doing it and still disagree now. We don't need a tag at the top of the page stating how the content is temporary, just that it is. Because that's going to be the very first sentence of the article summary. The fact that the article is related to a specific festival or event is identified with a category tag. If we want to handle it more specifically, then sure, figure something out. And I'll continue to repeat myself that the HoT option in the infobox status template was temporary and needs to be removed.--Relyk ~ talk < 22:11, 20 October 2016 (UTC)

I agree with the HoT thing, I've been removing it when I find it and sticking {{Heart of Thorns content}} on the bottom, but I think it'd be easier if a bot just ran through and switched it all. - Do_odleplex 22:22, 20 October 2016 (UTC)

Personally, I find using the status parameter simpler than using a temporary tag or HoT content tag. And simpler is often better for getting newer editors in. Konig (talk) 23:06, 20 October 2016 (UTC)

NPCs in Multiple Groups

So after playing with it for a bit, I came up with :

{{#if: {{{organization|}}} |
;[[:Category:Organizations|Organization]]
:{{#arraymap:{{{organization|}}}|,|@@@|[[@@@]]|<br>}}{{#switch: {{lc:@@@}}
| druids = [[Druid (group)|Druids]]
| sentinels = [[Sentinel|Sentinels]]
| bandits = [[Bandit|Bandits]]

That seems to make infoboxes accept multiple groups. Question is, I had to remove the default line or it showed up twice and the second time was borked, is that a bad thing to remove/can I put this in so we don't have to put a category on the bottom of the page now for NPCs in multiple groups or no? - Do_odleplex 21:07, 1 December 2016 (UTC)

The #switch was after the #arraymap so the array action [[@@@]] was preformed for every iteration of @@@ and then the last @@@ was used in the #switch. By moving the #switch into the arraymap it will preform the switch for each iteration of @@@. Theres also a line further down that adds the organisation catagorys themselves.

<!-- Line 102 -->
{{#if: {{{organization|}}} |
;[[:Category:Organizations|Organization]]
:{{#arraymap:{{{organization|}}}|,|@@@|{{#switch: {{lc:@@@}}
| druids = [[Druid (group)|Druids]]
| sentinels = [[Sentinel|Sentinels]]
| bandits = [[Bandit|Bandits]]
| #default = [[@@@]]
}}|<br>}}}}
<!-- Line 232 -->
{{#if: {{{organization|}}} | {{#arraymap:{{{organization|}}}|,|@@@|[[Category:@@@]]}}}}

This should work but I've not worked with categories before so someone may want to double check it first. J.Tesla (talk) 21:54, 1 December 2016 (UTC)

Finished testing and added. I'll keep an eye on it in case it blows something up. J.Tesla (talk) 23:41, 2 December 2016 (UTC)

Lovely, thank you! Though I'm not too sure about the new category, feels a tad redundant as Category:Pages with broken file links exists and most of what's in there is NPCs, a handful of user pages thrown and an object or two in there yes, but mostly NPCs. =o - Do_odleplex 00:01, 3 December 2016 (UTC)

For some reason, if I add a second organization, a comma shows up in the first line such as what what happened here. - Do_odleplex 00:34, 8 December 2016 (UTC)

Took me a minute just to find the comma. All sorted now. J.Tesla (talk) 18:53, 8 December 2016 (UTC)

(Reset indent) Thanks! - Do_odleplex 18:55, 8 December 2016 (UTC)

NPC Descriptions

According to this conversation, it appears "descriptions" is really the ability of an NPC, and shouldn't be in the descriptions anyway. That being said, would anyone object to it being removed? - Do_odleplex 04:39, 18 February 2017 (UTC)

Map to Gallery

I was wondering if we could change it from "Map1...5" to "Gallery1...5" as we have coordinates now which works for most NPCs that need a map, and the rest of the images usually found in the NPC infobox are pretty much either other models or concept art, so "Gallery" is a little more accurate. - Do_odleplex 23:59, 7 March 2017 (UTC)

Sure thing, I did the same for objects anyway. —Ventriloquist 21:40, 8 March 2017 (UTC)

You changed the text that showed up on the page, I meant changing the actual code from "| map1 = X" to "| gallery1 = X". - Do_odleplex 21:44, 8 March 2017 (UTC)

Location name containing comma

So, how to properly parse location strings with 'comma' inside?
Typing comma (,) makes it list as two separate entries; using HTML (code &#44;) does not parse it properly at all. This results in either wrong pages linked or red link.
Having issues with Mirror, Mirror's NPCs Kispik and Part-Carrying Skritt for example.
Workarounds I could think about would be either omit the info or use a non-comma-in-string redirect - both options seems bad, though, so I'm not touching those pages. :P --NIN37 15:26, 17 September 2017 (UTC)

I was thinking about this recently (not these specific examples), but we can convert all infobox invocations with multiple locations to use semi-colons ; instead. The template we need to look at is Template:Infobox location btw. -Chieftain Alex 16:06, 17 September 2017 (UTC)

I'm now changing all 2090 pages via a robot to use semi-colons as the delimiter. -Chieftain Alex 17:32, 17 September 2017 (UTC)

Is there any risk this problem will repeat itself, in case some some new place/story gets this new "control character"? Or is semicolon already a "control character" not allowed on page titles?

I don't want to sound too pessimist... :P

By the way, thanks for taking your time to check this issue and quickly applying a fix. --NIN37 03:36, 18 September 2017 (UTC)

Well we're five years into GW2 by now, and have >17000 NPC/object/story articles with locations assigned (not even including events), none of which so far use semi-colons in their names. Going by that, we'll be ok. (besides ; is often the next line terminator in programming and I bet they won't use it in case they've not escaped something.) -Chieftain Alex 06:44, 18 September 2017 (UTC)

Automatic category removed from historical

It doesn't make a lot of sense for historical NPCs to be removed from the categories of their own organizations. For example, imagine the whole Twisted Watchwork category empty because they are no longer ingame. It also makes navigation unbearable, since it puts all historical content under the same category with hundreds of articles unrelated to each other, be it lore, items, events, or whatever. Removal of NPCs shouldn't imply those NPCs were nuked away from history, they didn't stop being members of their groups, and they are worth storing, for they might return later (as has been the case multiple times), and readers have an easier time finding historical content.--Lon-ami (talk) 13:58, 16 October 2017 (UTC)

After mentioning it on the discord in relation to a historical skin that still appears in wardrobe, I am bumping this topic as I absolutely agree with Lon-ami here (and I know from discussions with others that there are more people thinking the same). I understand that with services there might be some issues related to current x noncurrent stuff for vendor templates and such (though because of the nuke of service categories too, there are some basically empty historical service categories as well), this is absolutely a non-issue for many other types of pages, especially NPC and lore stuff. ~Sime 17:46, 27 September 2022 (UTC)

I've long advocated for removing this removal because of how it makes all historical pages extremely hidden to players, basically hiding any page not manually linked to, which in turn prevents ease of navigation, etc. I've heard arguments of "it makes sense" or "there are many ways to find the pages" but honestly it only feels like that after bothering to learn the system - to casual readers it definitely won't be anything but obscure. Konig (talk) 17:54, 27 September 2022 (UTC)

I agree, it feels almost arbitrary in nature as to the navigation of historical content from a non-historical page. I am in favour of making he classification(s) of non-historic NPC's more robust. Venom20 18:01, 27 September 2022 (UTC)

The infobox will now continue to categorize historical npcs. --BuffsEverywhere (talk) 08:13, 7 October 2022 (UTC)

Status as Alive or Deceased

Hey, I thought about raising the idea to place an option to set on the NPC infobox if the character is alive or dead. opinions?

Set everything to dead by default.. story characters all die eventually, and anything remotely targetable gets massacred. -Chieftain Alex 21:36, 7 January 2019 (UTC)

Undead category

Hey, since my edit to allow categorization of NPCs to the already existing (but addmittedly rather empty) [[:Category:Undead]] got reverted (and especially because someone else already reverted the revert): IMO we could debate about the need for that undead category. Preferably on the corresponding talk page. But as long as it exists it should be possible to add fitting NPCs via the infobox. --Alcahata (talk) 22:26, 15 January 2019 (UTC)

Vendor location parameter

I think a new parameter needs to be added for NPCs who are in multiple locations but only offer items in one. For example, Branded Mass erroneously lists 3 NPCs as selling it in the wrong area. -BuffsEverywhere (talk) 14:42, 22 January 2019 (UTC)

Subrace of Race property

There's a few NPCs we should categorize under a subrace instead of their race, but their race should still be indicated somewhere clearly, for mechanical purposes (sigils, potions, slayer achievements, etc).

I suggest creating a new property, something like Property:Located in and Template:Infobox location, but for the parent race. Something like [[Property:Subrace of]] or [[Property:Parent race]]. Few examples:

---

| race = Bloodstone ghost

Bloodstone ghost
(Ghost)

---

| race = Choya

Choya
(Plant)

---

| race = Human

Human

---

The same could be done for organizations, using another property like [[Property:Parent organization]] or whatever. Few examples:

---

| organization = Covington Pirates

Covington Pirates
(Pirates)

---

| organization = Stone Warband

Stone Warband
(Blood Legion)

---

You get the idea. It could be done with a switch too, but properties would be far more elegant.--Lon-ami (talk) 17:20, 2 July 2019 (UTC)

Category for NPCs with missing coordinates

The NPC infobox has an optional coordinates option. It would be nice if it was easier to see which NPCs are missing their coordinates. This could either be done by SMW magic or by added a "NPCs without coordinates" category when the info is missing. There may be issues with NPCs in multiple locations (especially when they are not stationary). What do you think? ~ Sanna 18:01, 16 September 2020 (UTC)

Good idea. But there should probably be an exception for NPCs only found in instances (story instances, dungeons, strikes, fractals, etc). --BuffsEverywhere (talk) 18:12, 16 September 2020 (UTC)

While maintanence categories tracking for missing tasks are always helpful, e.g. Category:Locations missing a screenshot, Category:Pages with empty semantic mediawiki query results, here there already exists a project page, see Guild Wars 2 Wiki:Projects/NPC Coordinates#Progress, that lists all NPCs and their coordinates (and their non-existing coordinates) on subpages. Simply putting the missing pages into a category gets very confusing to due the amount of missing coordinates, so listing them by zone as the project page does is in my opinion the best way to do it.

However, if you still want an extra category (since you can't query for a missing property explicitly, you have to set it in the infobox directly), then of course we can add one. --Tolkyria (talk) 18:21, 16 September 2020 (UTC)

Yes, I'm aware of these pages and they generally frustrate me in a sense that you cannot easily get a list of only NPCs with missing coordinates. However, with some SMW there may be a way. Definitely agree with BuffsEverywhere that we need some more exceptions, that may be a bit too much to program into the infobox. Good points, thank you. ~ Sanna 18:49, 16 September 2020 (UTC)

Okay.

As I already said, you can't use smw directly to search for pages that do not have a property set.

Two solutions:

1. Set a property/category here in the infobox immediately when coordinates are not set.
2. Create a custom table result format that simply doesn't display the rows where coordinates are set. Quick and dirty, doesn't require any infobox modification nor requires any infobox exceptions.

--Tolkyria (talk) 20:26, 16 September 2020 (UTC)

I have adjusted the template that is used on the project subpages, namely the additional parameter mode=missing only

{{Guild Wars 2 Wiki:Projects/NPC Coordinates/region template|<region>|mode=missing only}}

--Tolkyria (talk) 20:54, 16 September 2020 (UTC)

Edit: My edit caused a template timeout and since there was no respond nor use of this template anyways, I reverted this edit. Hence, this template with the parameter "mode=missing only" is not available anymore. However, the NPC Coordinates project tables can now be filtered, allowing to select "NPC with coordinates" or "NPC without coordinates". --Tolkyria (talk) 09:45, 22 September 2020 (UTC)

Thank you! Nice idea to add these filters. ~ Sanna 17:20, 26 September 2020 (UTC)

Property:Has race

Currently, the property Has race isn't set to all NPCs, for example missing are NPCs with race set to "Various", "Object" or empty. Hence in general we can't use this property as smw sort property which however would be nice and somehow required, e.g. the upcoming template stolen from (intending to group NPCs by race) based on the template {{stolen skill}}. Therefore, I want to request to either make this property sortable by either

1. setting it to all NPCs: because this property is of type page, we would need the pages Various (or NPCs with various races) and NPCs without race.
2. creating a more general sort property of type text. This property might create problems which for a page property would be resolved with redirects. Furthermore, since the current page property could be easily extended adding a new sort property feels redundant.

--Tolkyria (talk) 17:43, 9 October 2020 (UTC)

• Added NPCs with various races and NPCs with unknown race to the property Has race.
• Added the new property Has organization, see also next point.
• Fixed the property Has family for organizations, previously due to plural/singluar mix ups it would have been set to red links. However, I do not understand the purpose of this property, set to race and organization at the same time.

--Tolkyria (talk) 14:24, 10 October 2020 (UTC)

On gw1w it used to be called "affiliation" and internally in the gw1 client it was called "army" (I bet it's still called that on gw2...) When the first infoboxes were ported from gw1w to gw2w there was a bit of discussion - see Template talk:NPC infobox/Archive 1#Images (notably the top one). A couple of alternative descriptors like "kinship" and "faction" were considered but rejected.

I've no particularly strong personal thoughts on "has family" but it seems your "has organization" is the same thing with a different name.

Can I suggest we remove "has family" and replace all occurrences with "has organization"? -Chieftain Alex 18:07, 10 October 2020 (UTC)

Okay, maybe I should have thought a little bit more before questioning the property Has family. A quick search doesn't yield me any mainspace results that justifies the property's existence, however I think I understood the idea behind the Has familiy property due to this page: User:Relyk/sandbox/championloot. While races different from the five main races can be used as unique categorization term, e.g. Quaggan, Skelk, Spider, they cannot be used for the five main races. Here, the organizations are more important, e.g. Bandits, Pirates, etc..., all having NPCs without any clear race. Hence, having such a search property, that allows to ask for either the race or the organization without actually specifying which of the two exactly is meant, sounds indeed as a good idea.

The two properties Has race and Has organization can be used to search and show when the exact context is known. So taking this into account, we might want to keep all three properties, although I cannot see a mainspace application for Has family right now. --Tolkyria (talk) 19:05, 10 October 2020 (UTC)

Interactive map

Can we always show the interactive map if coordinates are set? Added a gallery2 on Zzzig which removed the interactive map. —Kvothe (talk) 15:38, 15 December 2020 (UTC)

Fixed. --BuffsEverywhere (talk) 12:48, 29 January 2021 (UTC)

Rank category

I think we should have categories for ranks (Category:Champion NPCs, Legendary NPCs, etc.). Currently, there is no way to view npcs of a specific rank without using special code, and it just seem as a basic category to have imho.The German and French wiki both have it, too. ~Sime 15:47, 19 January 2023 (UTC)

Added. --BuffsEverywhere (talk) 16:39, 19 January 2023 (UTC)