Talk:Items

What Constitutes a "Loose" Item?

If only 400 loose items can be spawned at once, then what makes up a loose item? Can 400 stacks of an item be spawned at once, or can only 400 of said item be spawned at once? Lil perkins (talk) 05:06, 13 June 2020 (UTC)Yo, what's up?

Stacks do count as a single items for these purposes. For example, using conveyor belts to gather drops into stacks will improve things at a farm. --MentalMouse42 (talk) 11:30, 13 June 2020 (UTC)

Max Stack

While I would consider arrows to be a consumable, don't they stack to 250? --KoreRekon 01:18, 9 June 2011 (UTC)

How do we remove X number of items from a stack? Clicking always picks up the entire stack. - Spinfx 01:35, 22 July 2011 (UTC)

Right click to remove 1 from a stack, and hold down right mouse button to remove more.--GauHelldragon 04:18, 22 July 2011 (UTC)

That sounds so intuitive I don't know what the hell I'd been smoking. Thanks! Gonna add this to the controls page as well. - Spinfx 05:57, 22 July 2011 (UTC)

Item despawning

I'm just chilling in my newly created ocean mob farm that utilises shallow lava moats to kill off unwanted mobs, and of course it reached what I assume the item cap is since some Tattered Cloth and Gel had despawned, silly me for not grabbing it when the Goblin Scouts and Slimes had died. Anyway, I'm just confirming that the article is correct unless item despawning also relies on a timer. --92.6.238.141 20:20, 10 August 2011 (UTC)

Can a source-diver confirm if loose item stacks actually can merge?

I've been using conveyor belts to try and bundle drops into stacks, but I just realized that I don't know if the code actually supports that. Can someone with access to the source code check if items stacks actually do merge on contact, or would they just be a bunch of individual items occupying the same tile? --MentalMouse42 (talk) 14:18, 8 February 2018 (UTC)

Yes, loose items do merge into stacks. I can confirm this by experience. If they didn't, the loose items limit would be reached to often and additional items would be lost. From what I gather from the source code, it applies to loose items within a 1.5 tile radius of each other. – ReedemtheD3ad! (talk) 18:58, 8 February 2018 (UTC)

Excellent, thanks! --MentalMouse42 (talk) 22:39, 8 February 2018 (UTC)

More tags in item data?

I have in mind that it would be good to add a couple of flag fields to item data, or better yet a general "tag" mechanism. Specifically, I'd like to have "biome" tags according to item affiliations, and "class" tags extended beyond the damage type to include things like "defense" ("armor" as a separate tag is already coded separately, right?), "healing", "immunity", "movement", "buffs", and so on. I'm thinking primarily accessories, but even some armor and weapons could usefully be tagged. So Frost Armor might be tagged "snow [biome], melee, ranged", while an Obsidian Rose would be "accessory, underworld, immunity". What I don't really know is whether the existing infrastructure would support that as a "simple addition", or if it would get out of hand. --MentalMouse42 (talk) 21:06, 19 December 2019 (UTC) Edited --MentalMouse42 (talk) 21:09, 19 December 2019 (UTC)

item infobox already has a tag parameter which is what you want. See its documentation for more details. And for "snow [biome]",you can use multiple tags such as "biome/snow" or "biome/biome-snow" for easier query. If you want item infobox to save any other attributes(some cate, type， etc.) into tags, please tell me, I can modify item infobox to implement it. Westgrass (talk) 01:51, 20 December 2019 (UTC)

Thanks! --MentalMouse42 (talk) 12:27, 20 December 2019 (UTC)

So, looking at the template docs, they seem to get their info ultimately from the source code, while I more or less want to annotate that. (I presume the source code doesn't actually provide biome info etc, or it would be there.) How would I then add an tag to a given item? By putting its page in a category, or setting up my own data file?? In my comment, the bracketed [biome] was meant to be a comment rather than syntax; how would something like "biome/snow" be useful? --MentalMouse42 (talk) 03:02, 22 December 2019 (UTC)

item infobox will auto retrieve some tags from source code, and you can manually add others if needed. Just use |tags = biome_snow,for example, in the item infobox of that item. We can use cargo query to retrieve them later, for example: {{#cargo_query:tables=Items_new|fields=name|where= tags HOLDS 'yoyos'}} will retrieve all items with "yoyos" tag. Multiple tags may make some query easier, for example, if you use |tags = biome/snow, that item will hold both "biome" and "snow" tags, so we can use {{#cargo_query:tables=Items_new|fields=name|where= tags HOLDS 'biome'}} to retrieve all items with biome info, and use {{#cargo_query:tables=Items_new|fields=name|where= (tags HOLDS 'biome') AND (tags HOLDS 'snow')}} to retrieve only snow biome items. This is not the only option, you can also use |tags = biome-snow to tag them, by doing so we can use {{#cargo_query:tables=Items_new|fields=name|where= tags HOLDS LIKE 'biome-%'}} and {{#cargo_query:tables=Items_new|fields=name|where= tags HOLDS LIKE 'biome-snow'}} to do the same queries. snow[biome] or biome[snow] are feasible options too. You can decide which one to use, and the point is to be consistent. --Westgrass (talk) 06:30, 22 December 2019 (UTC)

So basically the "biome" tag would just mean "this has a biome", but that would easily be worked around with a biome- prefix. But... I'd need to edit the tags separately into each item page, which is :-( . If I came up with lists (e.g., "these names get the biome-snow tag"), do you think someone could sic a bot on the task? Or better -- if you have to change the info* templates anyway, perhaps designate a central file/dir on the Wiki for such "supplemental information"? --MentalMouse42 (talk) 13:16, 22 December 2019 (UTC)

I'm not sure about creating such a central file with this information, since we already have these kinds of tags (or "listcats", simply category names), like westgrass mentioned, – yoyos, hardmode, drop, etc. – which are all stored on the individual pages. Of course, these could be extracted, removed from there, and put in the central database with a bot, but although I'm generally an advocate of centralization and standardization, that might not be the best decision in this case. That is because, as with all undertakings of this kind, it makes editing the wiki harder. While that is not as dramatic for data that is taken from the source code anyway (i.e., doesn't need to be edited until an update comes out and we do a single automated update to the databases), it is more of a problem with this "soft" information. New editors might notice that a page should be in Category:Hardmode-only items (especially with the new entities bound to be introduced in 1.4), but might have no idea how to add it and end up adding the category manually to the page. Again though, I'm not sure, and I definitely see the clear advantages of a central file.

Whatever the case may be, rest assured that the tasks bots are able to accomplish are mostly only limited by the programming capabilities of the person behind them (if you're interested, take a look at the MWParserFromHell package for Pywikibot, it opens up an incredible number of possibilities), so don't think of what bots can do as a limiting factor (at least at first; of course there are boundaries). Also, what steps to take depends a bit on what you are trying to achieve in particular – this is not totally clear for me yet. Do you want to be able to print a list of all items with tag x, do you want the items to be categorized in additional tag categories, ...? Maybe the solution is already built-in.

--Rye Greenwood (talk) 20:30, 22 December 2019 (UTC)

Hmm. I had gotten the impression that most of the info was mechanically taken from the source. If some of the existing categories are already "homed" in the infoboxes, then yes, the new ones probably should be likewise -- as you note, it's much more natural to edit a value in an infobox template, than to hunt down a central database. But yes, definitely gonna need a bot for the initial setup, not planning to edit 1000+ pages by hand! --MentalMouse42 (talk) 23:19, 22 December 2019 (UTC)

As for plans -- those are somewhat inchoate, mostly realizing that there are a couple of natural classifications that aren't yet represented in the wiki. I'd at least want to be able to do lists or tables of, e.g., "jungle-based items" including not just things harvested in the Jungle, but the crafting-chains based on them, and stuff like the Leaf Wings which are an NPC buy but still linked to the Jungle. Or "summoner items", and automatically pull up not just weapons, but armor, accessories, the Bewitching Table, and the Summoning Potion. --MentalMouse42 (talk) 05:03, 23 December 2019 (UTC)

Alright, to me it seems the tag/listcat solution westgrass suggested would be the best option then – it's very flexible and doesn't require modification of {{item infobox}}. I guess the next step is to list the new tags you have in mind? We could get an overview and decide on a consistent system then. --Rye Greenwood (talk) 04:02, 27 December 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Two groups; in both cases I'm open to suggestions, including pointing out where my tags would duplicate existing ones:

The class-support tags will need a prefix "class-" just to dodge the "deals X damage" tags, but that also lets them dodge other tags too: Without prefix, the tags would be:

melee, ranged, magic, summon, thrown, defense, offense, life health, mana, immunity, movement, water, lava, mech, building, fishing, money.

In all cases these would apply to support items including accessories and armor -- e.g., the Frost Armor would get tags for class-melee, class-ranged, class-offense (for its set bonus), but wouldn't get class-defense because that's covered by its "armor" tag. Building would include mining.

The biome-affinity tags (with prefix biome-) would be: forest, snow, desert, jungle, corruption, crimson, hallow, ocean, sky, underworld, mushroom, dungeon, meteorite.

I'm omitting most of the mini-biomes because their items would consist almost entirely of furniture and a very few drops. I figure "meteorite" gets in because of its ore and associated crafting, but "hive" doesn't because it's covered by "jungle". I could be persuaded on "spider", but I'm inclined to leave it out because it's a total of 7 items, 8 if you count cobwebs.

--MentalMouse42 (talk) 13:52, 28 December 2019 (UTC)

Am I right in thinking the class- prefix would only apply to the first seven tags you listed? I don't really understand what a class-life or class-lava tag would mean.

Looks good otherwise! If there are no objections, then we would be onto creating an initial list of all items with their new tags. --Rye Greenwood (talk) 11:55, 2 January 2020 (UTC)

No, the "class-" prefix represents an extension of the theme, and would help avoid conflicts with existing tags based on the common terms. Note that there are relatively few accessories that cover more than one of these items, and those tend to be combinations of accessories that each handled one. (And the two dual-class armor sets, of course.) "Life" is the in-game name for what most of us refer to as "health", here I meant it to cover healing, regeneration, plus stuff like Heartreach and Lifeforce. In fact, changing it to "health" is probably better, I have edited the list. "Lava" is parallel to "water", it would cover the accessories (and potion) that specifically protect from lava damage. --MentalMouse42 (talk) 13:17, 3 January 2020 (UTC)

And, now looking at the prospect of a list of all the items. I see the cargo query in Item IDs, but is there a way to make the cargo system output a CSV list, or even a saveable HTML table? ETA: I set up a sandbox page here for initial bashing-on, you guys can feel free to edit there.

--MentalMouse42 (talk) 20:54, 5 January 2020 (UTC)

Thanks for clarifying. Cargo is very powerful when it comes to output formats. If you would like to learn about it in detail, check out the MediaWiki documentation, specifically the Querying data and Display formats parts. The gist of the basic functionality is, you tell the query, for every row, to pass its result columns (or cells, rather) to a template as parameters. In the template, you handle the cells as regular template parameters. The template then returns its processed results to the querying page and outputs the respective row there.

I set up a CSV display template here, and an HTML table code template here (although I'm not sure if you wanted raw code).

--Rye Greenwood (talk) 21:41, 5 January 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ So, coming back to this project after a bit of a break, I find myself with more thoughts and questions about how it should be handled.

• A technical point: Does the keyword list need to be quoted? If so, or if absent fields are a problem, I can probably beat the field into shape with UNIX commands.
• Should yoyo accessories get their own keyword? (All those strings) Currently they're just class-melee.
• I'm currently marking mech tools (as well as accessories) as class-mech -- anything that's not actually a (placeable) mechanism
• Currently I'm not giving classes to placeable items. Should I make exceptions for movement-affecting blocks & furniture?
  • Portal Gun Station
  • asphalt
  • slime block (regular, pink, frozen)
  • ice (and honey blocks?)
  • tracks (regular, pressure, booster)
• Similarly, I'm currently excluding wings, hooks and minecarts/pieces, especially as they'd all be class-movement anyway.
• For biome tags, it's occurring to me that if Hellstone and Meteorite items get tagged for their biomes, that leaves an issue with the Chlorophyte subtree where it massively inflates the biome-jungle list. And Shroomite and Spectre stuff would conceptually be dual-biome, which I think is more confusing than useful. Some possible solutions -- which do you think seems more reasonable?
  • Just declare Shroomite and Spectre as biome-mushroom and biome-dungeon respectively, excluding them from biome-jungle. Keep Chorophyte stuff, Beetle items, and Turtle armor as biome-jungle.
  • Exclude the bar-crafted items altogether. Is there currently a natural way to identify the bar-crafted items? If not, a new bar-* tagspace might be in order. This would reduce, e.g., biome-meteorite to those items which are not solely made of Meteorite bars.

--MentalMouse42 (talk) 11:50, 28 January 2020 (UTC)

• The keyword list does not need to be quoted. The quotes are just there to prevent the CSV format from breaking due to commas in item names.
• A class-yoyo tag probably doesn't hurt, yes. (Are there other weapon subtypes which could need one? Maybe bows (Magic Quiver) or guns (Rifle/Sniper Scope)? They don't have nearly as many accessories as yoyos, though.)
• Why are you excluding placeable items in general? I'm thinking they might be useful, e.g. Ammo Box and its equivalents.
• Items crafted from bars are indeed already identifiable: The {{recipes}} template with the ingredient parameter prints all items crafted with that ingredient. This is used on all bars' pages.

--Rye Greenwood (talk) 19:05, 2 February 2020 (UTC)

I did indeed put classes for Ammo Box and kin. I'm running off for an errand just now, I'll need to look later to remember what problem cases I was thinking of when I wrote that. Re; bars, the recipes template lets you enumerate all items with a given ingredient, I was instead thinking of being able to select or (given an item name/ID) test for, items which are made entirely from one bar type. But I'm starting to think that in this case I'm getting hobgoblin'd, that is the proper response might just be to be slightly inconsistent about how I treat the bar items. --MentalMouse42 (talk) 15:11, 4 February 2020 (UTC)

About the bars: I made a quick template draft which should do what you intended (unless I misunderstood): It can check whether any given item's recipe only has a single bar type as ingredient and nothing else, and it can list all items which can be crafted with just a single bar type as ingredient and nothing else for any given bar type. The output is very raw, but of course it can be refined and adjusted, depending on how you actually intend to utilize it. --Rye Greenwood (talk) 22:33, 4 February 2020 (UTC)

While I appreciate the effort, I wasn't clear enough about my intentions. I was basically wondering whether those items were "naturally" categorized, on a level equivalent to the tags (and therefore biome-tagging them would be redundant). My basic idea here is not to serve a specific task, but to supply a general information layer that can be used in future for whatever somebody comes up with. I was wondering a bit about ideas like having mechanisms automatically put in class-mech, but I haven't suggested that because my instinct is to avoid duplication of info -- and something like that could easily be done later if it turns out to be useful. (Note that my thinking here is limited by my shaky understanding of the wiki's intermediate-level mechanics.)

Based on your response, I am reconsidering tagging the relevant blocks and the tracks with class-movement. I was thinking about the Cannon(s) too, but I note that the Cannonball page does not list a damage type. Class-arrow and such seem plausible -- they won't have many non-ammo items, but they could at least group the shroomite helmet options and relevant accessories, and class-arrow in particular would include a potion as well. Hmm....

I'm hoping I'll be able to start in on the biome tags tomorrow, it would have been sooner but I had some IRL annoyances extending from the weekend. Naturally, biome tags will include furniture and such, since many of those have natural biome affiliations. (I'm thinking that palm wood should go in biome-ocean, since Ocean naturally has trees but desert mostly doesn't.) --MentalMouse42 (talk) 03:16, 6 February 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ So, I've been tagging away, and one thing I note is that a few items aren't showing up in the auto-generated list. I'm keeping notes in User_talk:MentalMouse42/Sandbox/Tags_Workspace#Missing_items.3F. Mostly this is enemy banners, but the Gothic Chair also seems to be missing. So is the Rusted Company Standard, but I added that one manually. --MentalMouse42 (talk) 22:03, 22 February 2020 (UTC)

So, even with scope creep, I can't think of anything else that really ought to be tagged. Before firing up scripts, you might want to look at my work in User_talk:MentalMouse42/Sandbox/Tags_Workspace, and see if you can spot any gaps or other issues.

1. I've added a few lines to the original data file for items that for some reason hadn't come up from the original cargo pull. You may want to investigate to see why they didn't get pulled.
2. On the discussion page, I have a section of things that reasonably could be auto-tagged, the question is whether they should be. You're the one with the scripts, so I figure those are your call.
3. Also on the discussion page, I pulled out a list of the tags I used.

-- MentalMouse42 (talk) 15:43, 26 February 2020 (UTC)