Template talk:Base ingredients

Seems to fail for multiple items with the same canonical name (>.>) if I query Mystery Tonic (furniture) for example, you get the three versions of the tonic (Mystery Tonic (beast)#recipe1, Mystery Tonic (forest)#recipe1, Mystery Tonic (furniture)#recipe1) from the first ask in base ingredients lookup. sticking "|limit=1|searchlabel=" makes it not return blank space, but isn't guaranteed to be the right match. thoughts?-Chieftain Alex 18:26, 30 December 2013 (UTC)

Wrap the whole thing in another arraymap on the results of a query for all recipe subobjects with the given canonical name, index the variables to keep them distinct for each recipe, then display the results in side-by-side divs. Possible, but I'd have to rewrite the lookup to work by passing the subobject itself, rather than the canonical name. I don't think anyone really cares to know the base ingredients of those tonics, though. —Dr Ishmael 18:53, 30 December 2013 (UTC)

Shouldn't we be using Property:Has item data object to avoid collisions in canonical name? The canonical name of the recipe doesn't always match the name of the item it creates either, but that only matters if you're trying to use Special:RunQuery/Base ingredients query directly.--Relyk ~ talk < 19:30, 30 December 2013 (UTC)

Problem there would be runes/sigils with different recipes for each discipline, e.g. Superior Rune of Altruism. All 3 recipes share the same item data object, so you've still got a collision. —Dr Ishmael 19:41, 30 December 2013 (UTC)

Forgot about those. Your solution works for either case.--Relyk ~ talk < 20:30, 30 December 2013 (UTC)

Bug

Currently, any items with the "name" parameter set differently to the page title can cause the lookup to fail. (Examples: the 3 recipes on Dynamic Tempered Spinal Blades (Infused), Satchel of Apothecary's Prowler Armor (masterwork)‎)

This is because its looking up the canonical name and producing 1 or more items - whereupon the next #ask, which expects one item, fails.

example 1: {{#ask:[[Has canonical name::Color Infused]][[Can be queried for base ingredients::true]]|link=none}}

Dynamic Tempered Spinal Blades (Infused)#recipe2, Static Tempered Spinal Blades (Infused)#recipe2, Synergetic Tempered Spinal Blades (Infused)#recipe2

example 2: {{#ask:[[Has canonical name::Satchel of Apothecary's Prowler Armor‎]][[Can be queried for base ingredients::true]]|link=none|default=(blank)}}

Satchel of Apothecary's Prowler Armor (fine)#recipe1, Satchel of Apothecary's Prowler Armor (masterwork)#recipe1

A way of fixing this would be to make the base ingredients just go for

{{#ask:[[Dynamic Tempered Spinal Blades (Infused)#recipe2]][[Can be queried for base ingredients::true]]|link=none|default=(blank)}}

i.e. the Recipe template could just type in the subobject's name directly. This isn't any good for the form though, where we would like it to take something comprehensible to a wiki reader. Ideas please? -Chieftain Alex 16:21, 27 May 2014 (UTC)

I guess we could improve the precision of the existing query..

{{#ask: [[Has item data object::Dynamic Tempered Spinal Blades (Infused)]]
[[Has canonical name::Infuse Colored]]
[[Can be queried for base ingredients::true]]
|link=none}}

where the canonical name value defaults to the item data object name. -Chieftain Alex 16:22, 27 May 2014 (UTC)

This template was why the canonical name was using the {{{name}}} identifier.

The page we're looking at for the problem is: Dynamic Tempered Spinal Blades (Infused).

There are three subobjects generated by the recipe. (recipe#1, recipe#2, recipe#3)

This template is linked from {{recipe}}, and this needs to target the subobject + "can be queried for base ingredients" -Chieftain Alex 21:53, 12 October 2014 (UTC)

Fixed with new recipe number selection parameter. (Luckily the multiple recipes issue seems to be exclusive to top level recipe tree items) -Chieftain Alex 11:39, 18 October 2014 (UTC)

(Reset indent) Based on this redirect I've gone a bit further this time + replaced the #explodes with length + subs. The brackets in Fractal Capacitor (Infused) were causing it to split "1 (Fractal Capacitor (Infused))" in the wrong place.

Also I've set it to only look for one valid item data object ingredient since two or more results just blanked out the multi-recipe items (hence removing needed ingredients from the list). -Chieftain Alex 17:41, 2 August 2015 (UTC)

Can be queried for base ingredients

The way it's set in {{recipe}} makes it redundant with [[Has recipe type::!Promotion]][[Has recipe type::!Demotion]].--Relyk ~ talk < 23:51, 5 October 2014 (UTC)

If we ever want a third category to be excluded, then it wouldn't work, because we'd have to use the OR thing. -Chieftain Alex 21:54, 12 October 2014 (UTC)

We aren't expecting to filter any values beyond promotion and demotion. That's an AND statement we'd need, not an OR.--Relyk ~ talk < 23:21, 12 October 2014 (UTC)

Easiest to leave it how it is, in a working state, with the capability for more excluded categories later.

Additionally, we currently exclude some other items which aren't included in those two recipe types, notably Obsidian Shard, Mystic Clover + Agony Infusion.

Besides, that query wouldn't work if the item didn't have the recipe type set. -Chieftain Alex 11:39, 18 October 2014 (UTC)

tp price

Dear Relyk, (n/a) is ugly. -Chieftain Alex 00:06, 15 November 2014 (UTC)

Output value

Shouldn't the output value be the TP Sell Price instead of the Buy Price? Isn't this overview to roughly calculate the cost if you buy the ingredients to craft the item? Or do i miss sth?--62.224.74.214 13:24, 28 November 2015 (UTC)

The buy price is the "buy now" price - what you would pay to buy the item immediately, rather than placing a lower bid and waiting for it to be filled (that's the sell price, what a seller gets when they sell immediately to the highest bid). —Dr Ishmael 17:43, 28 November 2015 (UTC)

Output formatting

I've been toying with the [[Widget:TP prices total]] that I've cobbled together, and come up with a tabular output that we could potentially use for this template instead of the current list. The working example can be found at User:Chieftain Alex/sandbox2. Things of note:

• The table can be sorted by item cost or name - I've always felt this was missing from the current format
• The subtotal price of each ingredient (i.e. quantity * individual ingredient price) is visible
• The grandtotal is the sum of the subtotal values.
• The individual price/subtotal/grandtotal values are all optional (i.e. by changing the html class the widget won't insert the values, so if you liked the individual price + subtotal you could remove the grandtotal)

Things that the widget doesn't account for:

• The price of items sold cheaper by vendors than the trading post - getting TP values is way easier than querying for the vendor sell price in coin of an item.

Any opinions either way (old vs new)? -Chieftain Alex 23:35, 5 January 2016 (UTC)

That pricing issue may soon be a moot point. Yay! So I confused the item's value (hard coded to the item) with its cost from a vendor (not hard coded, and therefore not easily referenced). G R E E N E R 01:10, 8 March 2016 (UTC)

Another "bug"

Currently this template doesn't account for recipes which output multiple of the same item.

Example: if I craft the recipe listed on Potent Master Maintenance Oil, I get 5x Potent Master Maintenance Oil as the output. When I pass it into base ingredients, it thinks it needs 40 Jugs of Water when I only need 20. This is because it doesn't take into account Property:Has output quantity on the Master Maintenance Oil that is an ingredient (which also outputs 5 not 1 when crafted). —See here to understand the problem.

Ultimately this doesn't affect most queries, since they've come directly via the link at the bottom of the recipe template and for most ingredients (96% of them) the output quantity is 1.

I've got a solution that addresses this issue (it divides the required ingredients by the output qty) but it might strike people as odd when they see "3.6" Piles of Crystalline Dust for example. (I would add a note if any of the results returned a not-equal-to-one output) -Chieftain Alex 16:24, 28 January 2016 (UTC)

I don't think they would see that because you'd have to round up.--Relyk ~ talk < 05:51, 30 January 2016 (UTC)

It should simply be a simple change of

{{#if: {{#ask:[[Has item data object::@@@]][[Can be queried for base ingredients::true]]}}
      | {{Base ingredients lookup|@@@|{{#var:@@@ qty}}}}
      ...
     }}...

{{#if: {{#vardefineecho:output_quantity|{{#ask:[[Has item data object::@@@]][[Can be queried for base ingredients::true]]|?Has output quantity}} }}
      | {{Base ingredients lookup|@@@| {{#expr: {{#var:@@@ qty}} / {{#var:output_quantity}} ceil }} }}
      ...
     }}...

--Relyk ~ talk < 06:06, 30 January 2016 (UTC)

Actually, we're going to need to do a little more paperwork recursing down. We need to track quantity needed and quantity made in {{base ingredients lookup}}. In the call, we do

difference = (old quantity needed + current quantity needed) - current quantity made
if difference > 0
    current quantity made = current quantity made + ceil(difference / output quantity) * output quantity
endif
old quantity needed = old quantity needed + current quantity needed

and present both the amount needed and the amount made in the resulting list. otherwise, we would overshoot the amount to craft because we don't track leftover item crafting in a different part of the recipe.--Relyk ~ talk < 06:41, 30 January 2016 (UTC)

I think you've interpreted the problem correctly, but I'm not entirely sure if you realised that I modified User:Chieftain Alex/Templates/Base ingredients lookup already (?). It takes the "required output quantity" as an input to the template, looks up the "actual output qty for one recipe usage" and effectively does

qty = previous_depth_qty + ((current_depth_required_recipe_output_qty * current_depth_ingredient_quantity_required) / actual_output_qty_from_one_recipe )

Which is the same as your 3rd line apart from ceil? It seems a bit confusing (for the wikicode at least) if we're tracking leftover outputs too.. -Chieftain Alex 12:02, 30 January 2016 (UTC)

You'll have to explain what you're doing because the code definitely isn't going to. I'm still not sure what the fractional quantities would indicate because you can't craft fractional quantities of items. Crafting 5 Potent Master Maintenance Oil obviously still requires 40 Jugs of Water and 6 Crystalline Dust. Both templates will be wrong if you want to craft 10 Potent Master Maintenance Oil as you would need 60 Jugs of Water and 9 Crystalline Dust. What we really don't want is the template telling us you need 400 Jugs and 60 Crystalline Dust.--Relyk ~ talk < 14:09, 30 January 2016 (UTC)

Ok I'll start the problem from scratch. Using {{Base ingredients|Potent Master Maintenance Oil|quantity=25}} (so that I end up with 25 PMMOs in my inventory).

• (A) I'd suggest that the correct output of this (for query depth = 1) should be "100 Jug of Water, 15 Pile of Crystalline Dust and 5 Master Maintenance Oil", because we asked for 25 output items, not 25 recipe repeats.
  
• (B) If I was to do query depth = 2, I'd want the result to be "120 Jug of Water, 18 Pile of Crystalline Dust" (i.e. there were 5 MMOs output from one recipe usage, so I only need to do the previous materials PLUS whatever it takes for 5x MMO)

I think we're agreed on (A) and (B) at least?

What should the output to the template read if I ask what ingredients I need to produce 5 PMMOs? Should the template report additional by-products? (i.e. 4x MMO spare), or display non-integers? -Chieftain Alex 14:51, 30 January 2016 (UTC)

The query depth is a technical limitation and won't necessarily provide a valid result, so we wouldn't be concerned with the results when doing so. The output of the template needs to display a set of the minimum quantity of every item required to craft the all the subcomponents for the item. By-products wouldn't be displayed on the list and we have no reason to right now.--Relyk ~ talk < 15:15, 30 January 2016 (UTC)

Only related to current edits: If you're going to mess about with the query depth parameter, at least leave in "querydepth" alternative parameter name which is needed for linking with semantic forms - you can't pass semantic form parameters with spaces in using URLs (such as from template:recipe).
It should be possible, using this template alone, to only ask for one query depth, i.e. an exact copy of what is listed in the ingredients section of template:recipe. In order for this to work, it has to be possible to pass an empty string as the input for arraymap (because {{Template:Base ingredients first lookup}} handles the first depth) - {{numbers}} doesn't do this. -Chieftain Alex 17:25, 30 January 2016 (UTC)

The template shouldn't be doing the work for semantic forms. It seems like we want to parse the ingredients first and have another template that generates the table. Then we can pull the form code into {{base ingredients query}} and leave the base ingredients template agnostic about the parameter names. That will leave us free to format the form page without changing the template itself. You'll have to remind me why we have query depth in the first place, because I don't know what we need it for besides stuff not breaking.--Relyk ~ talk < 18:52, 30 January 2016 (UTC)

I finished refactoring the code. I created {{base ingredients query}} and you can check the results on Form:Test. The next step is change the ingredient processing to a stack instead of storing in the ingredient list string so we don't have to iterate over the entire ingredient list to process any new items. We also need to maintain a list of items that can't be queried to reduce the number of #ask calls we make. Then we can add the quantity tracking. --Relyk ~ talk < 22:29, 31 January 2016 (UTC)

Code itself looks pretty, but the first test case I tried, Hedge, broke.

• It seems you're replacing the item name with a single tilde only - you must use two, or it will match on partial word boundaries (i.e. it must match the whole item name - this is why we previously used a separator before and after each name.) (Can we not use tildes btw? When you preview all_ingrs it interprets it as a signature string)
• If we want to link to forms using a URL (e.g. from {{recipe}}), then we should probably trim the inputs again to remove the newlines that dumb-as-hell-smw adds to parameters fed via URL.
• If we encounter quantities > 1000 in recipes (common code from guild materials) then they'll have the comma separator + break: {{#vardefineecho:curr_ingr|{{#sub:$$$|{{#expr:{{#pos:$$$|,|2}}+1}}|-1}}}}
• The reason for dplreplace cleanup after each value of {{numbers}} is so it works on >1000 character strings
• The reason for the arraymap redefine is to cleanup empty patterns of tildes caused by the dplreplace.

-Chieftain Alex 01:22, 1 February 2016 (UTC)

Not matching partial words would be a matter of #dplreplace and checking ahead that string doesn't end with a whitespace. For example:

{{#dplreplace:~Iron Ingot~Heartbleed~Iron Ingot~Iron Ingot Ore~Bleedheart~Iron Ingot|(~Iron Ingot)(~{{!}}\z)|$2}}

~Heartbleed~Iron Ingot Ore~Bleedheart

I don't know what you mean by signature string for all_ingrs, previewing seems normal? I'm not sure what SMW has to do with the URL link in {{recipe}} since there's no SMW there. These are recipe ingredient, not guild upgrades, so the items will only stack up to 250. We don't need to worry about the character limit once we switch to using a stack for processing the ingredients.--Relyk ~ talk < 04:48, 1 February 2016 (UTC)

Have a look at the bottom of Template:Recipe. The bit that links to the form. its the only way of preloading the form with the right recipe index + basepagename. And for that to work, the newlines have to go. -Chieftain Alex 08:58, 1 February 2016 (UTC)

I asked where the newlines are coming from, not where the URL link is located.--Relyk ~ talk < 02:40, 12 February 2016 (UTC)

afaik any parameters passed to the Special:RunQuery via the URL get a newline added to the front/end (I don't remember which) of them. -Chieftain Alex 04:21, 12 February 2016 (UTC)

Relyk's rewrite - bug reports

Since you rewrote it I'm going to let you fix the bugs that I found when having a poke around on the pages that usually break whenever I change something with this template:

• Pages with brackets in titles break. Try {{base ingredients|Beta Fractal Capacitor (Infused)}} - the Beta Fractal Capacitor component is omitted from the results.
• When you're previewing a long page, it displays "@@@" in the row before parsing the widget. I think this might be something to do with using #arraymaptemplate - because I've not observed this previously. Are there any advantages to using #arraymaptemplate over #arraymap?
• {{Base ingredients table row}} needs to remove the commas from any reported vendor values. This is the issue with format=product?
• {{Base ingredients table row}} should also default to a vendor value of zero (easy to fix, stick 0 as default variable value)
• {{Base ingredients table row}} predicts the wrong value for Gift of Ascension (should return zero value instead of 1260000... = 500 (fractal tokens)*2620 (coin)!) - this probably happens for all items which are sold for both coin+currency (example):

:{{#vardefine:min_unit_price:{{#ask:[[Sells item::Gift of Ascension]][[Has unit cost::?;Coin]]|?Has unit cost#|+index=1|format=min}}|default=-1}}<!--
-->{{#ask:[[Sells item::Gift of Ascension]][[Has unit cost::{{#var:min_unit_price}};Coin]]|?Has item quantity|?Has unit cost#|+index=1|format=product|limit=1}}

0

• Links from pages with multiple {{recipe}} link to broken query forms. e.g. Superior Rune of Antitoxin. This problem probably stems from not using searchlabel= to mute the mutiple objects.
• Links from pages with multiple {{recipe}} have no way to link to the specific recipe, e.g. if there is an armorsmith, leatherworker and tailor recipe for the same item, each uses different ingredients. This template doesn't provide any accomodation for such recipes - and would likely return the same recipe ingredients independent of which base ingredients link was clicked. It is fine to assume that the first (#recipe1) recipe is used on subsequent calls, however we should be able to specify the first level!
• Check out the link from the recipe template on Solaria, Circle of the Sun (Infused), looks like #arraymaptemplate jams before it reaches the final row? ("...@@@" still displayed, widget doesn't fire, no javascript log errors)

Stuff that works:

• Attuned Solaria, Circle of the Sun - looks like commas are ok!

-Chieftain Alex 12:01, 28 February 2016 (UTC)

• Brackets will be easy enough.
• I guess the wiki parsing handles #arraymaptemplate in a different order and the wiki never evaluates the @@@ argument? Have to switch back to #arraymap I guess.
• SMW can remove the commas for us.
• It should default to -1 because some vendors have 0 cost. I haven't looked out how you coded that in to the widget, but the widget would understand -1 indicates there are no vendors I think.
• Records aren't flexible enough to do any queries involving the currency it seems. The min value simply picks the first value for the record property. Considering that we can't decide a "minimum cost" for any vendor entries requiring coin+currencies in the first place, the naive solution works fine. We would need to switch to subobjects to do more complex queries. The whole thing is only there as a small optimization and won't impact 95% of the items that can only be purchased at the Trading Post.
• We don't actually need to make any accomodation as the difference in cost between the difference recipes is trivial. We should just pick the first recipe. Allowing the user to choose which subobject doesn't make sense: They don't know the difference between the recipes. It's not fine to assume the first recipe in subsequent calls either because those matter as much as the initial recipe. If we wanted a solution, we would supply the template with the preferred discipline. The template would then use the specific discipline if possible and default to the first if not.

--Relyk ~ talk < 22:50, 28 February 2016 (UTC)

@bullet 6: the main point of the template is to look at the actual ingredients, not the cost, so I don't see why the items are not important. For what its worth, I don't think any subsequent calls, at all, have multiple possible recipes, only the first level. -Chieftain Alex 23:32, 28 February 2016 (UTC)

I didn't say anything about items being important or not? Either you are reading a completely different discussion or didn't understand what I said. You might be getting distracted by the initial iteration as far as ingredients. We don't distinguish between the first recursive call and any subsequent recursive calls, that's how recursion works. That's also why it will be easy to implement generating the base ingredients from a set of items when we get around to it.--Relyk ~ talk < 01:04, 29 February 2016 (UTC)

"We don't actually need to make any accomodation as the difference in cost between the difference recipes is trivial". I read that as "who cares which recipe we use to get the output item, the cost is similar". And actually we could easily accomodate it, by checking which of the "numbers" sequence you're at you could accept a parameter to the line starting {{#vardefineecho:recipe|{{#ask: with an offset parameter (ask returns them in the order #recipe1, #recipe2, #recipe3 so the offset would be adequate).

You've probably guessed: I'm not at all happy with losing any features the previous revisions of the template had. -Chieftain Alex 01:20, 29 February 2016 (UTC)

We don't care what recipe we use. That's the whole point. Once we say that choosing which recipe matters, then we have to address that in the template. Picking the recipe subobject associated with the initial item or items (and not guaranteed to exist) is in no way a solution to choosing a recipe. An offset doesn't make any sense at all. In the query result, the order of the recipe subobjects is arbitrary, you aren't guaranteed to have more than one subobject, and the subobject numbering isn't guaranteed to be sequential.--Relyk ~ talk < 02:25, 29 February 2016 (UTC)

I do care which recipe I use. If I ask a template for the ingredients to make the middle recipe on Dynamic Tempered Spinal Blades (Infused), I don't expect the results to bring up the left recipe. -Chieftain Alex 09:00, 29 February 2016 (UTC)

Oh, I see what your entire issue is. Mystic forge recipes don't have a recipe id or unique identifier to address this edge case. The problem is you're screwed if someone switches the order of the templates. We can add the mystic forge recipe ids to the subobjects, then have base ingredients handle picking out the specific recipe id to use. If they pass the item name, it will default to the first recipe subobject, generate the base ingredients, and the form will generate the list of recipes for the item. We also needs to use Property:Has canonical name so we can create a list of recipe names rather than referring to the subobjects.--Relyk ~ talk < 00:16, 3 March 2016 (UTC)

I don't really want to know anymore what you're doing, but I saw this and hence removed the link to base ingredients from the recipe template entirely. -Chieftain Alex 19:01, 6 March 2016 (UTC)

That was an easy fix. It's fine if you don't want to contribute, but that doesn't mean you get to sabotage the template. Just don't touch it all then.--Relyk ~ talk < 21:43, 6 March 2016 (UTC)

Pages using "Craft table"

Not sure where in the process the rewrite is, nor if this has been brought up above, but I noticed that the "Show base ingredients" link doesn't work too well on pages such as Emblazoned Coat. You can place the Item IDs into the query page and have them work properly, but the query won't load if you directly from the {{Craft table}}. G R E E N E R 22:04, 6 March 2016 (UTC)

Fixed. Those are recipe ids, not item ids. {{craft table row}} just needed to pass the recipe id as well.--Relyk ~ talk < 22:13, 6 March 2016 (UTC)

Yes, I did mean the recipe ID, and thanks for fixing it! G R E E N E R 22:15, 6 March 2016 (UTC)

It is using the subobject number for the default quantity, so not fixed yet. —Mora 22:18, 6 March 2016 (UTC)

Was already fixing.--Relyk ~ talk < 22:23, 6 March 2016 (UTC)

Sell price

Personally I never found this query to be particularly useful to me (and probably a lot of others) because this only lists buy order prices, even though most are likely to just insta-buy the materials that they need. Imo this should default to showing only the sell price and then add an option to show buy price instead (as opposed to showing buy and sell at same time, with the material cost column it would look messy). --ItVictor (talk) 00:08, 11 February 2024 (UTC)

Modified the form to default to using the "sells" price, and labelled it something that makes sense to me ("Instant buy (best sell price)") -Chieftain Alex 22:54, 7 March 2024 (UTC)