Template talk:Collection table row

@Alex: Problem has arisen with an unlock sharing its name with an object: Prototype Weapon on The Predator I: The Experimental Rifle. Because the page exists, this attempts to get the icon from there. However, the page is an object page, not an item page, so it doesn't have an icon. Need an way to override that behavior. —Dr Ishmael 14:37, 3 December 2015 (UTC)

Couldn't think of a way to do this neatly, so I've added a nolink parameter - setting it to anything prevents a link being formed. Also had to move the file somewhere else to prevent it from appearing in the object infobox on Prototype Weapon. Beginning to think it would be easier to have some kind of shitty "collection item infobox" where it doesn't get any item properties. -Chieftain Alex 15:21, 3 December 2015 (UTC)

Blast, I forgot about object infobox's icon. These collections are just a huge pain in the ass. —Dr Ishmael 16:54, 3 December 2015 (UTC)

Y'know what? They are actually items. They just don't get whitelisted for the items endpoint.

• https://api.guildwars2.com/v2/achievements/2534 Predator I
• https://api.guildwars2.com/v2/items/71143 Should be Prototype Weapon

Oh fucking joy. —Dr Ishmael 16:59, 3 December 2015 (UTC)

I'm curious about your method, Ishmael. How did you match the ID from the achievement api to that particular item? Did you convert the ID into a chat-code and ping it in-game? G R E E N E R 17:26, 3 December 2015 (UTC)

I'm at work, so I can't exactly check things in-game right now :P , otherwise yes, that's exactly what I would have done.

However, the first few items listed on the achievement's API data do exist in the items API, and they matched exactly to the list given on the wiki page. So I inferred that the order on the API would match the order shown in-game, which is what the editor probably followed when writing the wiki page. —Dr Ishmael 20:17, 3 December 2015 (UTC)

Possibility of redlinks?

I'm wondering if it's desirable to have the template generate redlinks for items which haven't been added yet. Currently it just gives a blank link to the icon but not the item. Seylan (talk) 15:08, 30 December 2015 (UTC)

According to Ishmael's section above, they are items too, only documented properly via item IDs found in the API. I'll remove the code. -Chieftain Alex 15:37, 30 December 2015 (UTC)

Pull the hint parameter if it's used in the template?

Is it possible to have this use the hint parameter rather than description to pull the hints from the collection item page so it can just go there instead instead of being hard coded onto the page? A lot of them have just the hint for the collection and no description and some have both. Seylan (talk) 09:37, 6 January 2016 (UTC)

Updating and standardization

Really hesitant about making big changes to a template used across multiple pages, so I'll start here. I've drafted a newer version of this template on {{collection table row2}}. It has some flexibility to accommodate the two main collection item table formats I've seen throughout the Wiki thus far, and more importantly, facilitates a standardized format (and file naming convention). Would love to get some feedback, and a green light to implement.

Of course, doing so will involve digging up and fixing tables already using this template, as well as those that we'll be using this template on. However, I think it'll be worth the trouble. - Ojimaru (talk) 14:48, 30 August 2019 (UTC)

The overall concept seems okay to me, however there are several issues with the parameters and format which needs to be addressed.

• Parameters:

1. item — The basic idea of this template is to use it as {{Collection table row|<item>}} and let semantic mediawiki do the rest. Therefore I suggest to use unnamed parameter 1 instead of the parameter item, rather than complicatedly calling the parameter item as prefix every time.
2. hint — Again, if the semantic mediawiki doesn't work for whatever reason and doesn't find the property: Has collection hint (using this property at this template is exactly what it was invented for) or alternatively Has game description, then one should set it by hand. But do not complicate things by calling it via a named parameter, hence I suggest to use unnamed parameter 2.
3. map — Setting map parameter in each row is just unnecessary work to be done. Set the parameter showMap to "true" in the header, which defines the variable #var:showMap and check if it is set to true in the row template.
4. walkthrough — This is an optional parameter, it's okay to have a parameter name there. However, the tag <br> will line break whether there is a hint or not, introducing an emtpy line if there is no hint.
5. map — Again map, but now in a differnt context. If the [[File:{{{1|}}} location.jpg|150px]] doesn't work for whatever reason one should be able to specify it manually with this parameter.
6. visual — Same as new map parameter, [[File:{{{1|}}} visual.jpg|150px]] doesn't work for whatever reason one should be able to specify it manually with this parameter.

• Format:

1. A collection is mostly about items, so I think we should keep the table class "item".
2. You specified style="width:80%; min-width:800px;" on the table class which uses display:inline-block resulting in an unwanted table footer line with the width of 80%. I would skip that.

• Flexibility: If you want a flexible template, then you should take the following options into account:

1. Item with page and with displayed icon
2. Item with page and without displayed icon
3. Item without page and with displayed icon
4. Item without page and without displayed icon
5. Item with page and with manually set icon

So far you have only implemented flexibility options 1) and 4) while the original template addresses option 1) and 5).

So in my opinion, if you intend to use this concept all over the wiki, these points should be clarified before changing everything. Of course, I can give you the required code for my suggestions. --Tolkyria (talk) 15:35, 30 August 2019 (UTC)

So here's my shot in the dark.

The {{Collection table header}} would look like

{{#vardefine:showIcon|{{icon|}} }} 
{{#vardefine:showMap|{{{showMap|}}} }}
{{#vardefine:mapFile|{{{map|}}} }}
{{#vardefine:visualFile|{{{visual|}}} }}
{| {{STDT|item}}
! style="width:10em"| Item
{{#varexists:showMap|! Map !! Visual| }}
! Hint and  Walkthrough

Then the {{Collection table row2}} would look like...

|- class="{{{class|}}}" {{#set:Has collection item={{{1|}}} }}
| {{#if: {{{indent|}}} | style="padding-left:{{#expr:(30*{{{indent|1}}})-20}}px" }} | {{#if: {{{indent|}}} | {{chain|parent}} }}
{{#varexists:showIcon 
 | {{#ifeq:{{{icon}}}                                      
   |no                                                     <!--If "icon" parameter set to "no", display only the name-->
   |{{#if:{{{page|}}}                                      <!--If "page" parameter is set...-->
     | [[{{{page}}} {{!}} {{{1}}}]]                        <!--Link to page-->
     | '''{{{1}}}'''}}                                     <!--...else,  display collection item in bold, without links-->
   |{{plain icon|{{{icon}}} }}{{#if:{{{page|}}}            <!--If "icon" parameter is defined, display "icon" as a {{tl|plain icon}}, followed by page name-->
     | [[{{{page}}} {{!}} {{{1}}}]] 
     | '''{{{1}}}'''}} }} 
 | {{item icon|{{{1}}} }} }}                               <!--If "icon" parameter is not defined, default to displaying {{tl|item icon}} of collection item.-->
{{#varexists:showMap                                       <!--If "showMap" parameter is defined, display 150px versions of the map and visual files-->
 | {{!}} [[File:{{{#varexists:mapFile|{{{map}}}|{{{1}}} map.jpg}}|150px]] {{!!}} [[File:{{{#varexists:visualFile|{{{visual}}}|{{{1}}} visual.jpg}}|150px]]
 | }}                                                      <!--If "map" and "visual" parameter is defined, use those file names, else use a preset file name-->
| {{#if: {{{2|}}} | ''{{gray|{{{2}}} }}'' | ''{{gray| {{#show:{{{1}}}|?Has collection hint|default=}} }} }}'' {{#if: {{{walkthrough|}}} | <br>{{{walkthrough}}}| }}

-Ojimaru (talk) 21:08, 30 August 2019 (UTC)

Okay, basically there are different approaches on the wiki for collection pages, that's what I have found so far:

1. Collection items section and Walkthrough section (e.g. Skyscale Eggs)
2. Collection items section which have the walkthrough included. (e.g. Skyscale Flight)
3. Walkthrough section (e.g. Making Cents of Jahai)

I'm not exactly sure if you proposed to combine collection items section and walkthrough section, but in my opinion they should not be merged.

My reasons are:

• A walkthrough contains spoilers, so maybe a user is just interested in the collection item list, but not in the overall solution.
• Walkthrough images extremely increases the size of a table row, but a collection item list should be compact... however the walkthrough section below may be as large as needed.

I.e. your proposed changes are transfered to the new template Walkthrough table row while there are minor modifications to this template here, but Collection table row will not get a map or visual column. This means that option 2) pages are formated to either 1) or 3).

Expanding the idea of Walkthrough table row, there is a need of a Location column as well as a Waypoint (or Nearest waypoint) column, they can also be merged into one column. Furthermore, an optional index column is also needed.

Regarding your code: I would skip the complicated item code, requiring to specify three parameters in worst case. I rather suggest this:

{{#if: {{{item|}}} | {{{item}}} | {{item icon|{{{1|''No item specified''}}}}} }}

i.e. unnamed parameter 1 calls item icon, optional parameter item overwrites unnamed parameter 1 and allows any format, e.g. {{plain icon|<file name>|<displayed text>}}. That gives flexibility without unnecessary complicated parameter constructions.

There are some other little details, but first I think it's better to focus on what we want rather than how we do it exactly. --Tolkyria (talk) 09:27, 31 August 2019 (UTC)

This is how the walkthrough table template could look like (note: first try!), based on the pages I found:

Header

{| {{STDT|pve sortable}}
{{#vardefine: showIndex|{{{showIndex|false}}} }}{{#ifeq: {{#var:showIndex}}|true|! # {{#vardefine:index|0}}}}
! Item <!--
-->{{#vardefine: showLocation|{{{showLocation|false}}} }}{{#ifeq: {{#var:showLocation}}|true|!! Location}}<!--
-->{{#vardefine: showMap     |{{{showMap     |false}}} }}{{#ifeq: {{#var:showMap     }}|true|!! Map}}<!--
-->{{#vardefine: showVisual  |{{{showVisual  |false}}} }}{{#ifeq: {{#var:showVisual  }}|true|!! Visual}}
! Hint and  Walkthrough

• Parameters: showIndex, showLocation, showMap, showVisual.

Row

<includeonly>|- class="{{{class|}}}" <!--{{#set:Has collection item={{{1|}}}}}-->
{{#ifeq: {{#var:showIndex|}}|true|{{!}} {{increment|index}}{{#var:index}} }}
| {{#if: {{{indent|}}} | style="padding-left:{{#expr:(30*{{{indent|1}}})-20}}px" }} | {{#if: {{{indent|}}} | {{chain|parent}} }}{{#if: {{{item|}}} | {{{item}}} | {{item icon|{{{1|''No item specified''}}}}} }}<!--
-->{{#ifeq: {{#var:showLocation}}|true|{{!!}} {{#if: {{{location|}}} | {{cname|{{{location}}}}} {{#if: {{{waypoint|}}} |<br>|<br>{{#ask: [[Located in::{{{location}}}]][[Has location type::Waypoint]]|?Has game id# | format=template | template=waypoint | mainlabel=-|sep=<br>}}}}}}{{#if: {{{waypoint|}}}|{{waypoint|{{{waypoint|}}}}}}} }}<!--
-->{{#ifeq: {{#var:showMap}}|true|{{!!}} {{#if: {{{map|}}}|[[File:{{{map|}}}|150px]]|[[File:{{{1|}}} location.jpg|150px]]}} }}<!--
-->{{#ifeq: {{#var:showVisual}}|true|{{!!}} {{#if: {{{visual|}}}|[[File:{{{visual|}}}|150px]]|[[File:{{{1|}}} visual.jpg|150px]]}} }}
| {{#if: {{{hint|}}} | ''{{{hint}}}''{{#if: {{{walkthrough|}}}|<br>}} <!--
               -->| '' {{#show:{{{1}}}|?Has collection hint|outro={{#if: {{{walkthrough|}}}|<br>}}|default=<!--
                   -->{{#show:{{{1}}}|?Has game description|default=}}}} '' }}<!--
               --> {{{walkthrough|}}}
</includeonly><noinclude>

• Parameters: 1, hint, walkthrough, location, waypoint, map, visual.

Please note this code is not intended for implementation, I haven't tested it enough yet, there might be mistakes or incorrect behaviour. However, it's intended as a alpaha version that you can copy it to your userspace and improve it, e.g. User:Ojimaru/Sandbox2 for the header and User:Ojimaru/Sandbox3 and for the row and call it with {{User:Ojimaru/Sandbox2|header parameters}} and {{User:Ojimaru/Sandbox2|<row parameters>}}. —The preceding unsigned comment was added by Tolkyria (talk • contribs) at 19:47, 1 September 2019‎ (UTC).

Thanks a lot! I haven't had the time to look at them yet, but will do so when I get the chance. - Ojimaru (talk) 23:29, 1 September 2019 (UTC)

Right, had some time to think about it. First of all, I disagree with the need to split the Collection and Walkthrough tables. I would argue that players who bother to come to the Wiki to look up collections, especially while in-game, are looking for spoilers. Information such as collection item names, hints, and such are already available in-game, and having to repeat said information twice (once in the Collection table, and another in the Walkthrough table) seems redundant.

As such, I also don't understand the need to keep a compact collection table, nor how my proposed solution isn't already compact. If this is in regards to the size of the thumbnails of the maps and visual locations, that—I would argue—can be tweaked by modifying the thumbnail size. Worse comes to worst, we can simply use text links, seeing as how the current 150px-size is barely usable without having to click through to the full-sized maps and screenshots anyway.

Further, I fail to see the absolute need to have specialized columns for Location and Waypoint. The former, in the example case of Skyscale Eggs, serves little purpose as the Location column sorts alphabetically, rather than in a manner that can help minimize travel time and cost (e.g. eggs the The Skein appear far below the other eggs in Melandru's island). In my opinion, these two work just as well as part of the main Hint and Walkthrough column.

On the topic of Walkthroughs, there is also a case of Skyscale Flight, and Gourmet Training, where we can offer optimized routes in a non-table format. Maybe something akin to Dulfy's guides?

Lastly, the item code you suggested doesn't look like it would play well it collections like Making Cents of Jahai, as the aren't any individual items, and would lead to lots of missing links. Maybe an overarching showIcon variable perhaps?

Loving the discussion, and eager to standardize all these different formats. - Ojimaru (talk) 14:47, 3 September 2019 (UTC)

I can't really argue against not having a location column... if you think it's unnecessary, just skip it. If someone else insists on it, well at some point they will let you know.

Indeed, for coin collects, which displays the collection item as plain text ingame, there is no need for the Item column. Therefore a parameter #var:showItem, set to true on default, is required.

As the next step I suggest to decide:

1. the table class, e.g. color scheme pve or item, or maybe more special ones, like: sortable (would require a permanent index column) or collapsible,
2. the possible columns, e.g. Index, Item, Map, Visual, Hint and Walkthrough,
3. and which of them are shown by default and which need to be activated in the header.

Basically with the discussion above this should be more or less clear. Hence I suggest to try the format on some examples in your sandbox. --Tolkyria (talk) 19:22, 4 September 2019 (UTC)

achievement bit not always set

Visions of Kourna's collection table was miss‑behaving for the Banner of the Commander row (data-id="achievement4760-bit"), using Banner of the Commander (skin) corrected it (data-id="achievement4760-bit5"). Is that an issue to address or “work as intended, wont fix”? --Rustre.5980 (talk) 14:13, 13 March 2021 (UTC)

For me it's "work as intended, won't fix", as the collection requires the skin and not the item. Sure, practically in almost all cases this is basically the same but theoretically it isn't. Note that there are collections that requires the item but not the skin, thus I think this is a notable difference that should be emphasised by using the correct collection task.

Technically, the achievement bit order is stored on the according achievement category page, here Legendary Trinkets#achievement4760 (see also the property Has achievement collection from the smw subobject), by matching the in-game order and hence the API order (not aware of any case where it doesn't match). Therefore, the bit id will only show up in this template if the unnamed parameter 1 (item or skin) is exactly contained in the smw subobject collection list. Not sure if it's possible to somehow to obtain the bit id whether the item or the skin is required in a reasonable way, but nevertheless, I think it's not wrong to correctly specify the required task (at one point shortcuts will cost more than they are saving initially) --Tolkyria (talk) 15:08, 13 March 2021 (UTC)

I was not aware of the Is part of collection property and should have seen it on the parent template. Although all the missing bits are now present, I wonder if a more permanent fix could be done to prevent future bit from ending up missing. Other than keeping the category you temporarily created, I have no idea that would not also make the editing process clunkier. --Rustre.5980 (talk) 15:45, 19 March 2021 (UTC)

The property Is part of collection is equally set in item and skin infoboxes without any differentiation (~7200 values, so pretty much impossible to adjust this), whether the achievement requires the item or the skin, nor does it provide the in-game order, which is needed to extract the bit id order, we can only sort it alphabetically. Hence, the property used for this case is Has achievement collection which is set via the template achievement table row, preserving the order and ultimately allowing the bit-API unlock check.

While given the skin it's somehow possible to select the related item (see Template:Collection table - an automatized version of this row template - doing it) as we are starting with the collection list, it's kinda tricky to select the actual related collection skin for an item.

Overall, It would be more guessing than actually selecting the correct one:

1) check if the unnamed parameter 1 is part of the collection

2) if not, check if the first skin of the item is part of the collection

3) if not, add a small hover warning s.t. the user will see it

That might work and should handle most of the cases. Although, in my opinion we should emphasising what exactly is needed for the needed collection task, i.e. skip option 2 and only add a visible hover warning that that the item is not part of the collection (but most likely it skin is) and those the unlock check isn't working.

Example: The Cutting Edge (achievement) requires the skin Holosmith's Sword (skin) but the weapon Libeh's Truthteller, and not the related skin Sunspear Cutlass (skin).

--Tolkyria (talk) 17:07, 19 March 2021 (UTC)

I have permanently added the category Pages with collection table rows where achievement bit ids are missing and a warning in the index column. --Tolkyria (talk) 16:27, 24 August 2021 (UTC)

Property:Has collection item

Summing up the facts regarding the property Has collection item which is set in this template:

• Usage: It has never been actively used on the wiki (as far as I know).
• Order: It cannot store the in-game collection order.
• Consistency: It is only set via this template, so all collection pages using for example the automatically generated table via the template collection table or even a fully manual table won't have this property set.
• Alternatives: We have the properties Is part of collection that is widely used on item and skin pages (without caring what exactly is needed, thus it can be used for loose queries; it's compareable with Has collection item) and Has achievement collection storing the exact in-game order and the exact required collectible.

Considering these four points, do we really need the property Has collection item? --Tolkyria (talk) 21:40, 10 October 2022 (UTC)

Agree, it is unused and unlikely to ever be used; so I vote for removing it too. DJemba (talk) 21:46, 10 October 2022 (UTC)

I agree. I don't see it being useful if it's not set consistently. --BuffsEverywhere (talk) 00:57, 11 October 2022 (UTC)