Template talk:Guild upgrade infobox
I am thinking we might need to increase the size of this infobox so that the prereq's fit nicely in the box. Anzenketh (talk) 05:55, 29 October 2015 (UTC)
Query base ingredients.[edit]
I have not had time to look at this yet but I think a query base ingredients might be useful for the item section. Anzenketh (talk) 13:52, 30 October 2015 (UTC)
- Ya I took a look at this and I don't think I can do it. I tried to pull apart how {{recipe}} does it but I can't seem to wrap my head around it. Anzenketh (talk) 15:46, 30 October 2015 (UTC)
- The base ingredients template examines the recipe subobject (e.g. for Banana Cream Pie the subobject is called Banana Cream Pie#recipe1) and fetches the ingredients for all of the ingredients a few times over. I am not keen on implementing base ingredients support for pages generated by this template (which would mean adding recipe subobjects to pages using this template) since I don't know how templates such as {{recipe list}} would react to non-recipes using the same properties... it might be ok but it might break stuff too. I'll do some tests. -Chieftain Alex 15:57, 30 October 2015 (UTC)
- Could we create a guild upgrade subobject and just preform the same actions. Anzenketh (talk) 16:04, 30 October 2015 (UTC)
- I'm hoping it won't break anything elsewhere (because I've neglected putting any particularly special properties), but it seems to work ok on these guild upgrade pages. -Chieftain Alex 17:47, 30 October 2015 (UTC)
- Does not look like it broke anything elsewhere. If it would break something I would expect it to break on Bolt of Silk Anzenketh (talk) 17:53, 30 October 2015 (UTC)
- I'm hoping it won't break anything elsewhere (because I've neglected putting any particularly special properties), but it seems to work ok on these guild upgrade pages. -Chieftain Alex 17:47, 30 October 2015 (UTC)
- Could we create a guild upgrade subobject and just preform the same actions. Anzenketh (talk) 16:04, 30 October 2015 (UTC)
- The base ingredients template examines the recipe subobject (e.g. for Banana Cream Pie the subobject is called Banana Cream Pie#recipe1) and fetches the ingredients for all of the ingredients a few times over. I am not keen on implementing base ingredients support for pages generated by this template (which would mean adding recipe subobjects to pages using this template) since I don't know how templates such as {{recipe list}} would react to non-recipes using the same properties... it might be ok but it might break stuff too. I'll do some tests. -Chieftain Alex 15:57, 30 October 2015 (UTC)
- Well, I had hoped to keep this separate from crafting, otherwise I would've reused Property:Has ingredient in the first place. —Dr Ishmael 20:11, 30 October 2015 (UTC)
- Yeah I figured you wouldn't like it using crafting properties. How about an alternative version of base ingredients which, for the first query, uses "Has input material", and for the other queries resorts to regular crafting properties then? -Chieftain Alex 20:35, 30 October 2015 (UTC)
- Well, I had hoped to keep this separate from crafting, otherwise I would've reused Property:Has ingredient in the first place. —Dr Ishmael 20:11, 30 October 2015 (UTC)
- That looks exactly like what I would've done if I'd the time when I made my last comment. Thanks. :) —Dr Ishmael 21:44, 30 October 2015 (UTC)
(Reset indent) The input materials list needs to be separated from the infobox. Especially if it has its own section.--Relyk ~ talk < 04:15, 31 October 2015 (UTC)
- The section header seems superfluous. The box itself already says almost the exact same thing. —Dr Ishmael 04:24, 31 October 2015 (UTC)
- Just curious, why things seemed to be going so well on this thread then nothing for over a week? We still have all those nasty yellow exclamation points in the "Input materials" tables resulting from this template because there is no "Guild upgrade" sub-object. Also, unclear why "favor" and Aetherium were placed in the "cost" parameter (with the same nasty yellow exclamation point problem) rather then including them among "inputs"? If they were "inputs" rather then "cost" then Template:guild upgrade list might work for them too. ~ 1Maven (talk) 00:39, 9 November 2015 (UTC)
Aetherium Capacity: another prerequisite[edit]
Guild upgrades specify the guild level and previous upgrades required to be able to complete. However, a less obvious restriction is the total aetherium available, as many of these are above the default capacity of the mine. Once the levels are fully known for Aetherium Capacity 1/2/3/4/5, perhaps we should include this information somewhere in the infobox. -- Dashface 15:41, 30 October 2015 (UTC)
- I would just add the capacity level to the prerequisites. Even though it is not explicitly stated. Anzenketh (talk) 15:48, 30 October 2015 (UTC)
- Perhaps this could be automatically included depending on the aetherium threshold? -- Dashface 16:16, 30 October 2015 (UTC)
- I think it's plain enough that if it requires 3000 aetherium, then you have to have upgraded your capacity above 3000. I wouldn't add anything extra that isn't explicit in the game. —Dr Ishmael 16:19, 30 October 2015 (UTC)
Schematics sub-Type and Header[edit]
It would be quite useful to assign a sub-object type to the different types of schematics upgrades. Each of these might have a standard header that appears immediately before the Acquisition section. Both the schematic-type (%%1) and the link to the actual schematic (%%2) might be passed as parameters. Examples for 4 possible schematic-types:
- Improvement: Unlocking this Improvement allows a scribe to manufacture a [[%%2]]. The %%2 may be queued for assembly in the Assembly Device. Upon completion it is placed into the guild's War chest and must then be manually slotted (configured) after claiming objectives to become active when the associated tier is unlocked.
- Tactic: Unlocking this Tactic allows a scribe to manufacture a [[%%2]]. The %%2 may be queued for assembly in the Assembly Device. Upon completion it is placed into the guild's War chest and must then be manually slotted (configured) after claiming objectives to become available. After becoming available, a tactivator may b used to activate the tactic.
- Banner: Unlocking this Guild Banner allows a scribe to manufacture a [[%%2]]. The %%2 may be queued for assembly in the Assembly Device. Upon completion it is placed into the guild's storage and must then be manually deployed by a member with privilege.
- Siege: Unlocking this Guild Siege Weapon allows a scribe to manufacture a [[%%2]]. The %%2 may be queued for assembly in the Assembly Device. Upon completion it is placed into the guild's storage and must then be manually deployed by a member with privilege.
What do you think? ~ 1Maven (talk) 08:14, 19 December 2015 (UTC)
- This sounds like a solid plan, it also creates uniformity. All schematics basically have the unlocking guild upgrade in the recipe. Datawise this might be useful information to have. I'm not completely sold on the fact that this adds a lot of text, imo the explanation of the mechanics of schematics, scribe only, the assembly device, etc. shouldn't be in every description. Shouldn't it just be another row in the infobox, like other info in there? For example:
- Property:Unlocks schematic - Schematic: Minor Supply Drop
- Property:Has schematic type - Tactic
- The infobox row would be something like (inside the infobox table): Tactic | Schematic: Minor Supply Drop
The schematics could also benefit from this Schematic type property, there currently is no data-driven distinction between a tactic and a banner
What do you think? —MatHack (talk) 12:07, 22 December 2015 (UTC)
- I hate making up stuff that doesn't exist in the game data, but in this case, I can see the utility of adding this. However, the schematic type should be a property of the schematic, not the guild upgrade. I fixed the property names for you, too. —Dr Ishmael 23:28, 22 December 2015 (UTC)
- Another idea: Keep the schematic type, it's useful even outside this scenario, but instead of making the unlock property schematic specific, make it something like Property:Unlocks service. This way we have an optional data entry in the guild upgrade infobox to link to whatever service that guild upgrade unlocks. This way the property can also be useful for stuff like Guild Enhancement: Karma and Guild Trader 1. The infobox visual entry would be something like: Unlocks | Schematic: Minor Supply Drop. —MatHack (talk) 06:35, 23 December 2015 (UTC)
Support all upgrades in API:2/guild/upgrades?[edit]
Can this template be used for everything in v2/guild/upgrades, which includes everything in guild storage? Or would it be better to make a "Guild Storage Item Infobox" for those? --BryghtShadow (talk) 07:55, 11 September 2016 (UTC)
Planning to add to this infobox.[edit]
If no one minds then I’ll add in support for unlocks service (merchant, schematic, etc), upgrade type (unlock, boost, claimable, …), activation (tactics take 3min to activate), recharge (banners 10min, wvw stuff 20min). I know that there is a “build time” in the API but that is better suited on the scribe item page. I may add “guild upgrade ID” but I can’t think of a use for it. Any other requests? J.Tesla (talk) 00:07, 21 November 2016 (UTC)