Template talk:Object infobox

Name

Perhaps this should be named "Object infobox"? It would be less cryptic than "NCIO", an acronym I don't remember ever seeing before. —Dr Ishmael 14:13, 16 June 2012 (UTC)

I agree, most people are unlikely to know the meaning of NCIO before reading this page, myself included. ***EAGLEMUT*** TALK 14:15, 16 June 2012 (UTC)

I'm not particularly committed to it; I think I was just feeling overly specific when I made the title. (In that it shared the green color of the NPC box but designated non-npcs, and was being used for interactive objects and not items, which have their own infobox.) Redshift 14:29, 16 June 2012 (UTC)

Explanations

Would be great if someone could explain what the parameters are for... specifically "type", "usefor", and "destruct". Also, I don't think "region" is necessary. -- ab.er.rant 05:25, 18 September 2012 (UTC)

Multiple gives

Can I get something like event infobox's areaverbatim for the gives parameter? The generic plant nodes have many "primary" drops. Manifold 20:20, 13 November 2012 (UTC)

For that matter, Herb Patches have two versions, with different tool requirements, how about the same thing for requires? Manifold 20:07, 14 November 2012 (UTC)

For that case, split the article, because they are different game assets. —Dr Ishmael 21:12, 14 November 2012 (UTC)

I just stumbled upon the Varied Mushrooms article. --aRTy 18:27, 6 March 2013 (UTC)

Location parameters need to be changed

Many objects can be found in multiple locations. For instance, Corrupted Ice Formation can be found in multiple regions, let alone zones and areas. However, the infobox prevents multiple areas, let alone zones and regions. They need changed, preferably (to me) to fit how {{NPC infobox}} is. I'd change it myself but I'm no good with infobox coding. Konig/talk 01:37, 21 November 2012 (UTC)

My last edit should enable you to use square brackets and brs around the objects with multiple names, and should also mean that existing objects without square brackets around singular location names should be linked up too without changing any pages. (you'll still have to change pages with multiple locations) --Chieftain Alex 19:36, 9 December 2012 (UTC)

Appearance when there is no image

Erm, blatant copypaste from the npc infobox? seems to default to {{race|norn}} when there is no such image.. which isn't supposed to be a parameter for this infobox :P Thoughts on which image should be displayed? -Chieftain Alex 23:13, 19 February 2013 (UTC)

I wish we had an outline of the "Under construction" image--Relyk ~ talk > 23:18, 19 February 2013 (UTC)

I say leave a bloody redlink. But no one seems to agrees with me. —Dr Ishmael 23:29, 19 February 2013 (UTC)

@Relyk: :D @ Ishmael, yeah redlink is good. -Chieftain Alex 23:56, 19 February 2013 (UTC)

Leaving a placeholder image makes it harder for new users to add images after all. I love that the npc infobox changes the placeholder based on race too.--Relyk ~ talk > 00:10, 20 February 2013 (UTC)

Area

Can someone fix area/location to work with comma delimited lists please. --Claret (talk) 18:35, 11 June 2013 (UTC)

Thanks, Relyk. --Claret (talk) 02:57, 12 June 2013 (UTC)

^_^--Relyk ~ talk < 03:09, 12 June 2013 (UTC)

Dynamically generated objects

There's several objects that may be dynamically created or appear in many places and are not linked to any particular location (e.g.: Engineer turrets, Bags of loot), but the Maps section always appears. It should appear only when a particular location is set, not when it's empty or what's set as location is something broad like maguuma, an entire game mode like PvE or WvW, even a zone. I think an object should get no maps if it may appear in more than 5-6 different places. MithTalk 14:04, 20 June 2013 (UTC)

Also, there's no meaning for many of these items to have a location entry either, so it'll be a good idea to hide also the "Unspecified" line when no location is set. MithTalk 15:59, 20 June 2013 (UTC)

Event Objects?

What about adding "Event" as a type for Objects that only spawn during certain events? If that could result in conflicts then it could be included as a separate parameter instead, similar to the one for destruct. That way you would just add in | event = y to label an object as an "Event Object". As an example of an "Event Object":

• Risen Fish Carcass
  • Only spawns in Winterknell Shore within Cursed Shore during the event Help Rakkan collect Risen fish oil glands for Merla.

I'd also like to make a page for [[Event object]] and Category:Event objects to supplement this. -Somohexual (talk) 19:30, 14 September 2013 (UTC)

Gives parameter

Is it possible to have the gives parameter return the canonical name, please. --Claret (talk) 10:28, 25 September 2013 (UTC)

Home instance objects

Should we add a parameter to distinguish unique home instance upgrades like the Sprocket Generator, including a matching category? ~ Sanna 14:19, 28 June 2014 (UTC)

That doesn't need to be an infobox parameter, but it can certainly be a category. Not all categories have to be assigned by infoboxes, y'know. —Dr Ishmael 17:15, 19 July 2014 (UTC)

interactive default 'n'?

Why default 'n'? I thought we were using "object" and "interactive object" interchangeably, since an object has to be interactive in order to document it. If we keep it at all, it makes more sense to have it default 'y' and only have to edit a few pages (if any) to set it to 'n'. —Dr Ishmael 17:17, 19 July 2014 (UTC)

Has game context=Object

Relyk, was this removal deliberate? -Chieftain Alex 18:07, 13 February 2015 (UTC)

"location" as default for other images

Other images cannot be added to the map1 parameter because they don't have 'location' put in their file name (which is set as default, from what I can observe in the code). For example, this edit did nothing, until I moved the image to ___ location.jpg. —Ventriloquist 13:56, 8 June 2017 (UTC)

Uh I think this issue was just a cache bug for the #ifexists parser function, so purging the page or waiting (or null edit) would have displayed the image eventually. I've replaced #ifexists with {{ifimage}} but I think the template code works as expected. -Chieftain Alex 15:45, 8 June 2017 (UTC)

Oh, ew. I tried that but I guess it was still angry. Thanks. —Ventriloquist 16:46, 8 June 2017 (UTC)

Objects with NPC traits

So there are various objects that have a health bar and level like NPCs. It has been suggested on Discord by at least two members, three if you count myself, that this infobox be changed to allow to record levels and or rank so that these interactive objects can continue to use this infobox instead of using the NPC box. This is because they do not actually function as NPCs, they are simply coded like NPCs in order to be able to do certain things static objects normally cannot do. - Do_odleplex 03:22, 8 December 2019 (UTC)

As I've already made known, I believe that if they've been made to use NPC UI by Anet already, it's all that's needed to continue listing them as NPCs. Isn't reflecting things the way they are in-game the point of what a wiki is about. I don't see the need to twist things around in this fashion here. It's not like listing them as NPCs would kill anybody either. 70.82.113.198 03:25, 8 December 2019 (UTC)

As much as I see anet has them as NPCs, I feel this is due to a technical limitation on their engine. In my opinion they should be objects (as they clearly are by context). This wouldn't be the first time the wiki diverges from what the in-game engine does to match the intended idea instead. Regardless of the choice NPC or Object though, I believe that an addition/teak to the chosen infobox would be needed to show that they aren't the usual NPC/Object that one might expect. -Darqam 03:29, 8 December 2019 (UTC)

I don't see how the context or what the possible engine problems have with any of this though. Like I said, if the impact of labeling them as NPCs was a massive detriment to how the wiki functions, I would agree. But there isn't any so I don't see where the fuss is about. 70.82.113.198 03:37, 8 December 2019 (UTC)

By the same logic you could say that there is no negative to making them objects. The core issue is that these "NPCs" are clearly different from what players in general consider an NPC and it is thus worth considering how they should be represented as.

Similar issues have often come up with new maps being placed engine wise in a completely unrelated section of the world, or whenever anet plays with any new toys in their engine.

Both options are viable, both have their arguments; and that's why this topic is here. -Darqam

Your logic doesn't make sense. Yes there is no negatives either way but the most accurate way again, according to what Anet went with and what appears in-game, is to list all those specific pages as NPCs. Unless listing something the accurate way wrecks everything in a horrible way, there shouldn't be much to discuss about this. Wikis exist to accurately present things whenever possible when it can be allowed to and in this case, it absolutely is. 70.82.113.198 03:51, 8 December 2019 (UTC)

My reasoning is two part: 1) is if we continue to use this box nobody has to guess what the "race" is for something that's clearly that is an object coded to function as a NPC in order to perform a function; we avoid speculation as it is confusing to players. 2) It's less confusing for editors to have to figure out what to do if we tweak this infobox to include a level and a rank. Speaking from my own experience, wiki editing can be massively daunting, and the less confusion there is, the better. - Do_odleplex 03:56, 8 December 2019 (UTC)

There's not much in this particular case that is confusing. Both objects and NPCs use different UI layouts that are easy to get and discern between the two, the simplest being that objects can't have levels. I don't get how blending the two together is any less or more confusing, just a pointless exception. 70.82.113.198 04:02, 8 December 2019 (UTC)

Perhaps not to you, but there are definitely a few objects where the editors have gotten confused as to what was what. For example, this is one such case. - Do_odleplex 04:23, 8 December 2019 (UTC)

I've already listed several traits that differentiate objects from NPCs (levels, ranks, icon/art) that could be made public knowledge if it isn't already. Once or if that's done, if people get confused, there would be a source that could be referenced for explanation. 70.82.113.198 04:47, 8 December 2019 (UTC)

(Reset indent) Regarding 'just a pointless exception'. You only have a rule if you need to make exceptions. As such, if we considder a rule like 'Everything with an NPC UI/level is to be considdered an NPC.' then the thing with objects with NPC UI/level could be seen as an exception to this rule 'except it is intended to be an object.'. (Where 'it is intended to be an object.' could be understood as e.g. 'Does not move on it's own (neither has idle animations (because it doesn't have a general npc model) nor generaly changes position over time on it's own (or simply; is inanimate))' and hence an object.) Nightsky (talk) 04:51, 8 December 2019 (UTC)

The fact that it doesn't move or what it's intended to be doesn't matter here. I feel like I'm repeating myself. If Anet decided to apply the NPC UI for them, the wiki's interpretation of them or its guesswork of why it was done doesn't change anything in the long run. They should be labeled to what they appear in the game, even more so considering that doing so has zero negative impact in terms of functionality on how the wiki continues to operate. The case that some cannons use the Object UI and others such as in the Sabetha fight use NPC UI is a clear example of the difference between the two layouts. 70.82.113.198 05:19, 8 December 2019 (UTC)

While i can see your point i have to say that i would find it sort of confusing if the cannons in the Sabetha fight were documented as NPCs since they look like objects. Though i guess they also act on there own which is somewhat unusual for an object to be doing. I wonder if maybe a different template for these kind of 'object npcs' would be an option? Nightsky (talk) 05:47, 8 December 2019 (UTC)

(Reset indent) The main differences between NPC and Object are 1) Name colors, 2) Mobility, 3) Portraits. Object names are yellow, while NPC namess are green, red, yellow (turns red on attack) or white. Objects cannot move. And objects do not have portraits. (While Objects cannot have levels, NPCs can be lacking levels too, thus is not a reliable means of distinguishing the two.)

I am against just labeling something as an object because "they are meant to be game wise" (to quote Darqam on Discord) since that's a potentially false and highly subjective sentiment. Usually, unless they need to move, ArenaNet will make them objects if they're to be objects. Objects can be destroyed and interacted with after all. And this isn't a limitation of the game engine (except for mobile objects) - Access Panel has no need to be an NPC, yet it is. It's a design choice, even if it's strange and weird design choices. And we should reflect those design choices.

Simply put, if it lacks a portrait and has a yellow name (even after being attacked if it can be attacked), it is 100% an object. If it has a portrait and a non-yellow colored name, or turns from yellow to red upon being attacked, it is 100% an NPC. To me, there is no question of "is it an NPC or object", but rather "what do we categorize the "Species" of NPCs that are, lorewise, merely objects." And in the case of "what do we label these NPCs", the best solution comes from Talk:Phantasm (race)#Definition of Phantasm, which is suggested to be Unknown. Alternatively, we could make Objects a viable entry for that parameter, which categorizes them into [[:Category: Objects (NPCs)]] or something. Konig (talk) 06:53, 8 December 2019 (UTC)

Would work for me. Nightsky (talk) 08:38, 8 December 2019 (UTC)

I'm glad someone finally sees this thing similar to how I do, I really don't think it needed to be as complicated as this all was blown out to be. As I did for Phantasms in the past with memory and clone NPCs, I was simply listing them with what I considered to be the best race available at the time. But if a separate page for them could be made such as was written above, similar to what was discussed with Phantasms, that would make sense to me. I agree upon further thought that Construct should be kept to somewhat "living" entities. 70.82.113.198 09:43, 8 December 2019 (UTC)

I think I'd like to ask our liason Stephane first if nobody minds exactly how these are coded, since I am very much not a fan of adding "object" as a parameter to the NPC infobox. Additionally it wouldn't be the first time we've deviated from putting things in exactly as the are, seeing as how Sloths are coded as plants, but we don't identify them as such. - Do_odleplex 13:02, 8 December 2019 (UTC)

I am all for asking Stephane if he has additional insight; however following Konig's statement I am leaning a bit more towards a 'modified NPC' idea over a modified Object. Could always have an either new template for inanimate NPCs (which I think is a good qualifier for these), or another parameter which might slightly change how they are represented. -Darqam 15:21, 8 December 2019 (UTC)

I don't think presentation needs to change at all. NPCs are NPCs, simple as that. Excluding the super rare outliers, only issue is how to categorize them. Not how to present them. Arguing over how to present them is, technically speaking, trying to fix something that isn't broken. Konig (talk) 15:33, 8 December 2019 (UTC)

After thinking about it for a while the Access Panel might be an NPC because of engine limitations as well, since it has voice lines; which i would imagine objects might not be able to have. So it could be something that is probably intended to be an object but isn't an object in engine due to the possibly existing limitation of objects not supporting voice lines. Nightsky (talk) 16:51, 8 December 2019 (UTC)

It's probable that early on, Objects couldn't have voiced lines. But at least as far as this update goes they can - see Buried Vigil. Konig (talk) 19:50, 8 December 2019 (UTC)

Examples

Could you guys give some example pages that you find confusing? This is usually pretty clear-cut in my head. -Chieftain Alex 17:23, 8 December 2019 (UTC)

Zinn's Print-o-Matic comes to mind. It's an object but it's a merchant. (Edit) Hey Konig isn't this thing the same as that scrap cannon? It has to move so it's treated like an object while moving? - Do_odleplex 17:40, 8 December 2019 (UTC)

I wondered if you were talking about things like Corrupted Ice Formation - they have red names, skills and attack players. -Chieftain Alex 17:43, 8 December 2019 (UTC)

I believe these are usually objects like that but are allied instead of foe. Bubble (NPC), Spatial Rift, and Population Control Device for a few more that if nothing else confuse me as to why these are NPCs. - Do_odleplex 17:46, 8 December 2019 (UTC)

@Doodleplex, re-Supply Cart question: It is indeed an NPC because it moves, but it isn't like the Scrap Cannon because the Scrap Cannon is both an object and an NPC at different points in time. As far as I know, that is the one and only such case. The Supply Cart in the PS is 100% an NPC. Similar to the Bubble NPC: those move, so they must be made NPCs instead of objects mechanically. Zinn's Print-o-Matic isn't an object, but an NPC; likely objects cannot be vendors and that's why they made it an NPC.

@Alex re-Corrupted Ice Formations: I believe they're technically NPCs in Bjora Marches, but in older maps they're objects (need to reaffirm this). The various Corrupted Ice Shards in Bjora Marches are also NPCs, despite their older-map counterparts being objects. The odd thing about them is that other than the name color (yellow->red) they're 100% identical. Objects can attack NPCs, btw, as we see with engineer Turrets. Konig (talk) 19:48, 8 December 2019 (UTC)

I just ran around a bit the older Shiverpeak maps and I believe I can confirm that only the Bjora Marches version are shown as NPCs. Nevertheless, I agree with Konig's comment above, there's no point in trying to fix or interpret something differently when it's not broken. 70.82.113.198 19:57, 8 December 2019 (UTC)

Revisited

So it's been suggested, and seems to be the favorable idea, that on the discord that we continue to use the NPC infobox for these objects coded as NPCs, but have the race for these things be "object" and as a result, the race not appear in the infobox at all. This way there's not back and forth on anything. They'll be categorized as "Object NPCs". - Do_odleplex 21:03, 1 March 2020 (UTC)

{{NPC infobox|race=object}} creates an empty "race" entry:

Object infobox

Location

Unspecified

--Tolkyria (talk) 21:26, 2 March 2020 (UTC)

Yeah, that was on purpose, unless there's some way to have the race section not show up at all if object is entered. - Do_odleplex 22:32, 2 March 2020 (UTC)

{{#switch: {{lc:{{{race|}}}}}
| object = <!-- do not show if object -->
| <!-- empty --> =
;[[Bestiary|Race]]
:Unknown
| #default =
;[[Bestiary|Race]]
:{{#arraymap:{{{race|}}}|,|@@@|{{#switch:{{lc:@@@}}|object=<!-- suppress object for multiple race parameters -->|various=Various|phantasm=[[Has race::Phantasm (race)|Phantasm]]|#default=[[Has race::{{ucfirst:@@@}}]]}}}}
}}

--Tolkyria (talk) 22:46, 2 March 2020 (UTC)

Ah, awesome, yeah, I'll add that in, thanks! - Do_odleplex 23:22, 2 March 2020 (UTC)

Mastery point ids

Today I found a couple of these were still set and I've renamed them to "mastery id" on 39 pages. I was going to add them to this infobox but found at some point in the past I removed the "id" parameter from this infobox for mastery insights. I can't remember discussing this anywhere.

Q1: Do we want to document the mastery id solely on the achievement pages with Property:Has mastery id, as nearly every mastery (verdant brink champion is the only one afaik) has an achievement too? Or do we want to include the id in the object infobox? Currently the parameter is set on 39/151 mastery insight object pages. Q2: Perhaps an alternative question would be: should the object infobox link to associated achievements for insights? Example with the parameter set: Grothmar Valley Insight: Shimmering Spire -Chieftain Alex 23:31, 1 February 2021 (UTC)

Personally I'm thinking remove the remaining parameters with a further bot request. And for the second question probably not worth it as the achievement name is long and identical to the page title, plus we've got "related achievements" -Chieftain Alex 23:33, 1 February 2021 (UTC)

There's no need to store the same id twice, they are already completely covered by the achievement subobjects.

Also, one can obtain the mastery id related to a mastery insight object with: {{#show: <object> | ?-Has achievement page.Has mastery id}}. E.g. for Grothmar Valley Insight: Shimmering Spire the query gives: 484.

Note that currently the number of mastery insight objects matches the number of achievement subobjects which have a mastery insight object as related page, namely 223 = 223. --Tolkyria (talk) 23:59, 1 February 2021 (UTC)

What you're said is sensible, I've removed the remaining mastery id parameters. -Chieftain Alex 07:08, 2 February 2021 (UTC)

Home instance upgrades

This is based on some other feedback elsewere, but what about adding a parameter for home instance upgrades for resource nodes to the infobox? Something like "| home instance = Basic Ore Node Pack", which would be listed on the copper, silver, and gold node pages to show you can unlock the nodes for your instances from this item (in addition, what about "| unlocks = Silver Ore (node)" for the Item infobox for these upgrades?). Infobox should have important information to be available at glance, and this, in my opinion, is quite important for it to just be hidden under Notes. ~Sime 20:10, 1 September 2022 (UTC)

Adding a parameter to show how home instance nodes are acquired would probably be a good idea, I agree. The suggested "unlocks" name for the parameter would be good, I think. Sunlion (talk) 22:50, 1 September 2022 (UTC)

I don't agree that home instance unlock info is relevant enough to add to the object infobox. Acquiring a node for your home instance is secondary information that is not a property of the object itself. The nodes are also a very niche item due to their high cost. The Home instance page already has a comprehensive list of unlockable nodes for those who want to invest into unlocking them. --BuffsEverywhere (talk) 00:02, 2 September 2022 (UTC)

So what about at least the unlocks = parameter for the Item infobox? That for sure cannot be argued to be a secondary info, since that's literally why these consumables exist (if needed I will move this conversation to the relevant template talk). ~Sime 00:07, 2 September 2022 (UTC)

True, but the node that the item unlocks is already linked in the item description at the top of the article. I think the item articles are very clear about what they do already. --BuffsEverywhere (talk) 00:30, 2 September 2022 (UTC)