Forum:Bot for 'Item used in creation of other item(s)' sections
I see a lot of item pages that have uses in the creation of other items. On pages it is usually mentioned for what other items it is an ingredient (ie. Steel_ingot). However, this is not always up-to-date or you have to read the entire text instead of the nice table at i.e. Clean_ranarr There are also more and more of those "Uses" sections on item pages, but these can also be incomplete (Clean_wergali, currently not mentioned as an ingredient in the Wergali_incense_sticks.
I'd like to suggest a bot to create a lot of these usage/ingredient for/recipe sections. Perhaps I could learn how to myself, but I'm unfamiliar with wiki structures and databases and am a novice at best with coding. I could provide some iterative creative thinking for the best user experience.
So how about automated "Usage" sections? And would anyone able be interested in making it?
Interesting. We have a template called snake hide. By my count there are about 2400 items that are used as a material to make other products, but only about 500 of them currently use the template.that automatically grabs the used materials from the recipe template invocations, as seen on a page like
Of course that doesn't mean the other 1900 pages should all use that -- in some cases we have more-specific product templates, like what we use for herbs in the clean ranarr case you mentioned, or (to some extent) in the upgraded variants of smithed items. But still, probably well over 1000 pages (e.g. pengatrice egg) should probably have that template but don't.
I think the main unanswered questions are:
- What is the set of pages we want Rune bar)? on? Are there situations where we don't want it just due to volume (e.g.
- Do we want to make any modifications to the template?
- Who wants to add it? It's not a particularly difficult task if we know what set of pages we want, especially since it seems to have a well-defined position relative to the disassembly section. ʞooɔ 09:33, 30 January 2020 (UTC)
- Hmm. Thanks for the reply!
- Why would we want to exclude some pages that are ingredients in other items? I can't see a good reason. Is volume a truly good reason? It seems more of a question to ask sysadmins and perhaps limit it to 10 or 100 uses with a link to a complete list.
- With some work that template might be useful. I'm thinking xp per product for every skill it gives xp in. Perhaps the GE cost of other ingredients.
- GlicEsther (talk) 23:59, 14 February 2020 (UTC)
- I don't think we want to exclude it from any pages, but in some cases using a different template is better, especially for things like herblore where there's other information to display.
- What really needs a good solution is potions. Although the solution might be to use the Clean torstol the template, or a new template (that combines both) for herbs etc so they are all handled the same 15:56, 15 February 2020 (UTC) for the unf potion on the herb page as well. Also it would be good to decide if we use a manual table like on
- For the specific example of Rune bar (which really applies for any the smithing bars), would it be possible to exclude either a certain skill or include certain skills/levels for the template? It's not useful to have everything that can be smithed with a rune bar at level 50 at this location, especially since its already in the navbox at the bottom of the page for rune equipment, but it would be useful to have the other uses of a rune bar called out with the template, such as rune minotaur, kinetic cyclone, junk refiner, etc. 16:36, 15 February 2020 (UTC)
- Not a problem at all, if all the
method(something like standard smithing) the
excludeparameter can be used on the . 17:01, 15 February 2020 (UTC)
for smithing use the same value for
- That would work for this specific case, but it would require filling out an additional manual parameter for each of these items that's a somewhat subjective descriptor (e.g. should it be standard smithing? anvil smithing? just "smithing"? ). I was thinking more along the lines of using the skill (and level) and skill2 (and level2) parameters already present in the template and adding an argument based on these to the template to give it a bit more utility such as (excludeskill=smithing). 17:32, 15 February 2020 (UTC)
- The difficulty there is that it would exclude anything that gave smithing xp, which for example, invention items do as well. It seems much better and more flexible to use a descriptor, which would also allow leaving special smithing things, like ore boxes, or other bars on the list. Currently that's how summoning items work, and it works fine (although to be fair, in that case, the parameter isn't even exposed).
17:44, 15 February 2020 (UTC)
- The level parameter and skill parameter are independent of the XP parameter, so an inclusive clause checking for essentially if skill = smithing and level ~= null would allow you to include items that give Smithing xp but do not require a Smithing level, for the use case of invention items. From my perspective, using descriptors would not be ideal as the limiting factor specifically because it is subjective, both in the choice of the descriptor used to describe it and in functional application. For the instances you called out, I don't see anything unique about ore boxes, any more than arrowheads, armour spikes, or nails, so I would not see why they should be included in the pull while a kiteshield or hasta is excluded. Summoning items don't have this parameter exposed for an end user to populate and are automatically populated in all instances where the template is used, without exclusion, so I agree that they aren't subject to this subjectivity concern described above - that being said, I also haven't seen a case where this parameter is actually used for an "exclude" situation from a template usage perspective, nor can I think of a situation where it would be needed, although I could be wrong. 18:32, 15 February 2020 (UTC)
- I don't see it as being any more subjective than any other template parameter. I actual think that smithing items should probable have their own version of the infobox, so that progress can be included (and ticks standardized), in which case the parameter wouldn't be exposed here either. Also still not sure how you want to account for bars with your method, unless you don't think those are worth including, which I completely disagree with. I think other situations such as potions/herbloreis another example, or perhaps splitting construction items (non-flatpack) from other items. 18:42, 15 February 2020 (UTC)
- I'd support having smithing items in their own version of the infobox, where the parameter isn't exposed. As for bars - you've got a point there, I agree they are worth including. What if the method is specifically called out to be the interaction with the appropriate bit of interactive scenery (for creating bars - 'Smelt', for creating ore boxes etc, 'Smith', for creating pouches, 'Infuse Pouch'? That gets rid of my concern over subjectivity, if it's specifically linked to what's defined in game (that's the heart of my concern). For the other situations around herblore/potions described above - different problems, but worth exploring. Would it be possible to have an inclusive or for the materials? This would solve a number of the potion problems (Super attack (3) and Super attack (4) being ingredients to different potions on the same page, also having Clean guam and Guam potion (unf) on the same table for the unfinished potion example above). For the clean torstol example - the problem is that the specific effects for the potion should be defined in the Infobox Item template as what is described in the 'mouseover text' or 'tooltip', but I don't think we have it currently defined as a parameter on that page. I don't think that information should be tied to the Recipe template, as it has nothing to do with with the item creation. So I would propose that for those cases, a different template be created that pulls from Infobox Item and contains only the item and the tooltip information, with a separate section for the creation/level from Infobox Recipe (as I don't recommend having a template pulling from two separate infobox templates, as that seems prone to error. 19:18, 15 February 2020 (UTC)
- I could create a new template, or modify that one to output for multiple items, but I'd still want to display them on separate tables. Which really means that vs multiples of the template you only save the header. 00:01, 16 February 2020 (UTC)
- Not a problem at all, if all the