Template talk:NPC infobox

From Guild Wars 2 Wiki
Jump to: navigation, search



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 AlexUser Chieftain Alex sig.png 23:33, 25 February 2015 (UTC)


"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 AlexUser Chieftain Alex sig.png 21:23, 15 April 2015 (UTC)
Thanks, where would I be without you. :P —Ventriloquist 21:28, 15 April 2015 (UTC)

Faction Provisioners[edit]

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 User Dr ishmael Diablo the chicken.png 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[edit]

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. - Doodleplex 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. - Doodleplex 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 AlexUser Chieftain Alex sig.png 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? - Doodleplex 19:40, 19 August 2016 (UTC)

| status = Festival[edit]

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. - Doodleplex 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"? - Doodleplex 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. ;) - Doodleplex 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. - Doodleplex 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. - Doodleplex 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[edit]

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

{{#if: {{{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? - Doodleplex 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|}}} |
:{{#arraymap:{{{organization|}}}|,|@@@|{{#switch: {{lc:@@@}}
| druids = [[Druid (group)|Druids]]
| sentinels = [[Sentinel|Sentinels]]
| bandits = [[Bandit|Bandits]]
| #default = [[@@@]]
<!-- 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 - Doodleplex 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. - Doodleplex 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! - Doodleplex 18:55, 8 December 2016 (UTC)

NPC Descriptions[edit]

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? - Doodleplex 04:39, 18 February 2017 (UTC)

Map to Gallery[edit]

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. - Doodleplex 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". - Doodleplex 21:44, 8 March 2017 (UTC)

Location name containing comma[edit]

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 AlexUser Chieftain Alex sig.png 16:06, 17 September 2017 (UTC)
I'm now changing all 2090 pages via a robot to use semi-colons as the delimiter. -Chieftain AlexUser Chieftain Alex sig.png 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 AlexUser Chieftain Alex sig.png 06:44, 18 September 2017 (UTC)

Automatic category removed from historical[edit]

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)

Status as Alive or Deceased[edit]

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 AlexUser Chieftain Alex sig.png 21:36, 7 January 2019 (UTC)

Undead category[edit]

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[edit]

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[edit]

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

| race = Choya


| race = Human


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

| organization = Covington Pirates

Covington 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)