User talk:Quietust/archive4

From TheKolWiki
Jump to: navigation, search

Old Comments

More Q's for the wiki expert

I'm using the variables extension on the KoLmafia wiki to cut down on what would otherwise require a lot of repetition. The problem is, the variables have to be set before the main page template is called, and they function as templates themselves. To be readable, and therefore easy for others to edit, each is on a separate line. Which, as you probably know, means I end up with extra line-breaks at the top of each page. Do you know of any way to avoid this, other than the messy solution of having no line breaks before the start of the main page template call?

Also, how coldfront-specific is your bot? It seems like I might want to look into being able to run something similar at the KoLmafia wiki. Any suggestions? Prerequisites?

Thanks again! --StDoodle 09:42, 6 March 2010 (UTC)

{{
#vardefine:name|item_drops}}{{
#vardefine:return_type|int [item]}}{{
#vardefine:aggregate|yes}}
  • A quick test shows that the above type of formatting does appear to eliminate all but one or two of the unwanted line breaks - we use the same sort of trick in the {{item}} template so we don't get blank lines when various fields aren't present (like power, stat requirement, level requirement, autosell value, etc.). As for my bot, it isn't at all specific to coldfront - I've used the exact same code on a standard Mediawiki installation on another site. The only trick is that you also need to patch Snoopy.class.php as described here. --Quietust (t|c) 17:13, 7 March 2010 (UTC)

Thank you so much! As annoying as the extra breaks were, the worst part was that some pages use more vardefine's than others, so they ended up with extra line breaks. This seems to give me one phantom line-break everywhere, regardless of how many vardefine statements I use, which is excellent.

I take it from the fact that you post the bot's code that anyone who desires is free to make use of it, but I'd like to explicitly ask, just in case. Also, I have no idea what to do with that info; if you know of a good tutorial you could point me towards, it would be greatly appreciated (my google-fu is failing, and producing only pages on Wikipedia's bot policy). If not, I'm happy to figure it out on my own eventually; you've helped more than could be hoped for already. Thanks again! --StDoodle 14:54, 8 March 2010 (UTC)

  • You are indeed free to use my bot code as you wish. I'll add a sample script in a moment which demonstrates how I use it myself. --Quietust (t|c) 17:19, 8 March 2010 (UTC)

Some help with wiki templates

Hi, I'm trying to help clean up & standardize the KolMafia Wiki.

I was hoping to be able to create a master template for function pages, but this would require a sub-template that surrounds a parameter with <syntaxhighlight> tags (which for all intents and purposes act like <pre> tags). I'm not having any luck, and thinking it may just be beyond the capabilities of a wiki. But any help on this topic would be greatly appreciated.

Thanks, --StDoodle 23:40, 24 February 2010 (UTC)

  • If their syntaxhighlight tag works the way our wiki's custom tags work, then it won't be possible to use them within templates because they get evaluated before the template substitution is performed. --Quietust (t|c) 05:08, 25 February 2010 (UTC)

A little buggaboo about {{item}}

I'm noticing something a little annoying with how {{item}} is currently working for potions with no effect to list. In particular, if you go to edit such an item's page (vial of blue slime, say), and look at the list of templates the page uses at the bottom, you'll see something like Data:N down there (possibly Data:!, depending on the exact effect= value). Playing around with the effect= value passed in reveals that this results from the item template apparently trying to access data for a page name equal to what you passed in. Which is exactly what it should do so when you give it a generic input so it can generate the correct display name. But it shouldn't be trying to do this for inputs of 'n' or '!'. Well, I don't think it should. Obviously the wiki thinks it should be. This doesn't cause any real problems that I know of, but I was wondering if you could figure out what's happening and if it can be remedied. --Flargen 07:20, 19 February 2010 (UTC)

  • Don't know if there's anything that can be done to avoid that, since conditional code gets evaluated even if it's not going to be included in the page output, for some reason. In any case, this should only be a problem for Data:!, since I've gone and removed the "n" and "0" options from the list of valid values for the "effect" parameter and cleaned up the templates that still used it. --Quietust (t|c) 14:10, 19 February 2010 (UTC)
    • Ah, I see, that's what was causing it. Thanks for removing the grandfathering of the other two options. --Flargen 01:32, 21 February 2010 (UTC)
    • A question I don't think that addresses comes to mind: inputting a '?' (or a blank) as the value does not cause Data:? to appear on the list of templates used by the page. If it was evaluating the default case all the time and generating data links from that, shouldn't one appear when you use effect=?? Seems a little weird. --Flargen 03:23, 21 February 2010 (UTC)
      • Actually, specifying "effect=?|" does result in a link to "Data:?" when I test it on a random item page using Preview, but using "effect=|" or simply omitting it entirely does not result in a "Data:" link (presumably because the wiki no longer treats it as a valid template call). --Quietust (t|c) 05:22, 21 February 2010 (UTC)

Template useitem and BRICKO chick

The template is locked (for good reason) but the BRICKO chick, when hatched, does not follow the normal naming scheme. I found that it hatched with the name 9699. Not sure of the significance, but it is what it is. --Almightysapling 20:47, 5 February 2010 (UTC)

  • Done. --Flargen 21:39, 5 February 2010 (UTC)

Marketplace Price Data

So I'm trying to generate a reliable data source for the old greasemonkey script Pricegun.

The coldfront marketplace data looks, at this time, to be the best source of data. Does the wiki have any hooks or ability to get at that historical data? (I guess that question has to get answered before any of the rest of these questions are worth asking, but I'll put em here while I'm thinking about them)

Would the wiki be willing to host collected mall prices for a pricegun application? If that data is accessible, would the wiki be able/willing to (once per day, every other day, whatever) collect that data and dump it into a text file? Would there be a way to take the average price over the last 7-14 days and put up that data? If the wiki can't hook into that database, would the wiki be willing to host an externally generated data file?

It looks like, at one point, some sort of price project was going to happen. And based on this discussion, it looks like some sort of wiki/marketplace interface was possible: http://kol.coldfront.net/thekolwiki/index.php?title=Talk:Proposed_Standards&oldid=85946

(I did use the contact form on the kol.coldfront site to contact a coldfront admin, but I never heard anything back)

--Kain 18:08, 12 July 2009 (UTC)

  • A bit of a late reply, but the wiki absolutely cannot be used to perform these tasks - the wiki only serves to host (mostly) static documents and is incapable of performing the sort of calculations or data aggregation you propose, and it is not intended to host frequently updating data on its own (the only notable exception is display case data, which is simply imported from another site using a special addon module). Perhaps you are confusing the wiki with the Coldfront website itself. --Quietust (t|c) 18:05, 22 December 2009 (UTC)

Template Requests

Hey, Quietust. I'm working on reformatting the Clover Adventures page to include a table, similar to the Semi-Rare Adventures page. As I've been going through, I've come up with a couple template requests that I'm, unfortunately, too inept to do myself.

First, could StackItem be given a default value of "something" (with the question mark image), similar to the default for an empty Acquire?

Secondly, I'd like to put in a request for a "StackMeat" template similar to StackItem-- something very simple, with the meat image, and in small font below, "X Meat". It would be very helpful for tables such as the one I'm working on.

Thanks! --Southwest 01:32, 11 July 2009 (UTC)

  • Both changes have been made, assuming they are still relevant. --Quietust (t|c) 18:00, 22 December 2009 (UTC)

Curious

cough--Toffile 20:50, 25 June 2009 (UTC)

  • Yeah, I noticed that. If that's who I think it is, then he's got some serious issues. --Quietust (t|c) 23:48, 25 June 2009 (UTC)

Templatey Weirdness

I don't suppose you can figure out why the first of these works and second one doesn't, can you?

  1. {{acquire|item=blue pixel|num=1-3}}
    Pixel5.gifYou acquire 1-3 blue pixels
  2. {{acquire|item=blue pixel|num=2-3}}
    Pixel5.gifYou acquire 2-3 blue pixels

I assume it has something to do with the switch that determines if it needs to use the plural or not, but I'm not sure if there's a way to fix that. --Flargen 20:27, 24 June 2009 (UTC)

  • Apparently, the {{plural:N|singular form|plural form}} construct changed behavior in some recent MediaWiki release; before, it would compare the number directly to "1", while now it seems to cast it to an integer first (which discards everything after the minus sign). If necessary, we could replace it with an #ifeq instead. --Quietust (t|c) 23:48, 25 June 2009 (UTC)

Recent Changes

You deleted my redirect from Recent changes to Special:RecentChanges. I created that page so that when I use the Firefox search bar for "recent changes" it takes me to the appropriate page. Is there a reason you deleted it? Because I don't find it to be "unnecessary". I will refrain from recreating it until you respond. Thanks! --Azeltir 18:26, 24 June 2009 (UTC)

  • There's a easily accessible link to it on the left-hand side of the wiki at all times. --Flargen 20:27, 24 June 2009 (UTC)
  • Once again, I'm talking about getting to it from outside the site. Also, what's the cost in having that page? I think some people, such as myself, would find it useful. --Azeltir 03:51, 25 June 2009 (UTC)
    • There's absolutely no need for the internal page. Perhaps you should add it your bookmarks.--Toffile 05:26, 25 June 2009 (UTC)
    • i absolutely concur. if you're typing it into the search bar you're doing it wrong. you can add the page as a button on the toolbar, or for about an extra nanoJoule you can add the RSS feed as a dropdown, whose items link to the diff of the change. if you're visually impaired or otherwise find pointing devices useless then you can replace "button" with "menu item" above at no extra cost to yourself. --Evilkolbot 11:22, 25 June 2009 (UTC)

IP Lookup

do you know how to get at the ip address used by a user? the first one used by mar, say? --Evilkolbot 20:30, 22 May 2009 (UTC)

  • Nope, and I personally wish I had that information available. --Quietust (t|c) 21:10, 22 May 2009 (UTC)
    • it must be in the logs somewhere. i'll have an eke about. --Evilkolbot 21:13, 22 May 2009 (UTC)
      • the ip is held in the ipblocks table; we'd need to ask coldfront to gain access to the database. perhaps this Extension might be of use, too. --Evilkolbot 21:48, 22 May 2009 (UTC)

Monster data page

Could you add the option to add and use base meat drop values in monster data pages instead of ranges? This is relatively easy to find, and is more powerful than the textual range which cannot be processed automatically. Examples include giants with a base value of 150 (producing a range of 120-180), and bandits with a base value of 1000 (giving 800-1200). The {{meat}} template was already updated with a Mval value for this purpose, though I'd prefer calling it basemeat, meatvalue or something like that. --Eleron 04:17, 6 February 2009 (UTC)

  • I went with Mval so the "M" could stand for a variety of things. "Meatiness", "Meat", "Monkeytasticness", etc. But I'm certainly not married to the idea. And if Quietust is wondering, the ease of finding this meatiness value is due to the Mer-kin hookspear. It gives you 15-20% (integer percents only) of that value, making it an amazingly quick process to get base meat drop ranges for a monster. The meat drop range then follows what is indicated in {{meat}}: roughly between 80% and 120% of the value, with a roughly triangular distribution. This is how I got the Mine's meat ranges the same day it was released, for example. So integrating this value into the monster data pages would also make it possible to more clearly explain things like the Hookspear. Well, along with a wiki page explaining how this "meatiness" mechanic works. You still working on that, Eleron? --Flargen 04:38, 6 February 2009 (UTC)
    • I'm still procrastinating instead of doing any work on that, yes :P This distribution is inherently part of how monsters meat drops work, but not how meat gains work in general. As such I think a "weird" name for the parameter to the {{meat}} template is just fine and appropriate, but it could be something much prettier for the monster data pages. Also, finding the base value was already quite easy and easily found for anything I cared to look at, the hookspear just makes it even easier ;) --Eleron 05:16, 6 February 2009 (UTC)
      • I assume this is a general change request rather than a bot request, considering it was added using the "+" link at the top (just like the big purple box tells you not to). --Quietust (t|c) 06:04, 6 February 2009 (UTC)
        • Actually it was placed incorrectly manually. But yeah, sorry about that, my mistake. It seems like I have an urge to place anything new at the bottom. I almost did it again for the bot request. --Eleron 06:53, 6 February 2009 (UTC)

Old Bot Requests

Candy

I've got a list of 63 items known to be candy. Could you add category tags to them? How do you want the list delivered? --Club (#66669) (Talk) 18:43, 4 December 2009 (UTC)

  • Given that this request appears to have already been fulfilled by Foggy, I am considering this request closed. --Quietust (t|c) 17:36, 22 December 2009 (UTC)

Removing some manual categorizations

I've recently modified {{item}} and {{effect}} to auto-cat pages. Item doesn't auto-cat weapons (it could, but as I believe you know it'd involve a large number of very specific cases in a switch), but it gets most everything else it didn't used to I think, based on the type= parameter (and the gift= one):

It also has a special case for the type of "combat / usable item", to put it in both such categories. And of course Category:Effects for the effects template. Could we have QuietBot go through and remove the unnecessary manual categorizations for the cases that are currently handled by the item/effect templates? In related news, I'm intending on eventually throwing in an autocat parameter (defaulting to "yes") for these templates, so it'd be possible to seamlessly use them on example pages and user pages without them being categorized in undesired ways. It's not hard, just slightly lengthy since there are auto-cat codes spread throughout the templates depending on the value or absence of certain inputs. --Flargen 01:30, 9 May 2009 (UTC)

  • Effects should be done, except for the ones new users are adding. Items may be a bit trickier, since removing them has to be done by context. --Quietust (t|c) 15:24, 3 June 2009 (UTC)
    • Category:Food (358, now 357)
    • Category:Booze (249, now 248)
    • Category:Off-Hand Items (174, now 173)
    • Category:Shields (54)
    • Category:Gift Items (154)
    • Category:Accessories (453)
    • Category:Shirts (62)
    • Category:Combat Items (262)
    • Category:Potions (281)
    • Category:Usable Items (592, now 583)
    • Starting the job now... hopefully it doesn't take too long. --Quietust (t|c) 19:20, 4 June 2009 (UTC)
      • ...and they're done. For some reason, though, I lost a food, booze, offhand, and 9 usable items from the categories, even though my script only removed category tags if the corresponding parameters were present in the item template. It might be useful to temporarily modify {{item}} to disable all auto-categorization so that the remaining manual category tags can be stripped out. --Quietust (t|c) 00:10, 5 June 2009 (UTC)
        • All of the following categories should be mostly empty once the job queue is empty - once they've been checked, then this can be considered done. (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) --Quietust (t|c) 17:25, 9 June 2009 (UTC)
          • Turns out I had missed a few categories. Now that everything's done, it's time to re-enable autocat. Hopefully, it'll be done within a few days... --Quietust (t|c) 17:05, 10 June 2009 (UTC)
            • Cool, thanks. Also: damn, I spelt "manual" wrong and didn't notice until way too late. --Flargen 17:01, 11 June 2009 (UTC)
              • ...and it is done. --Quietust (t|c) 18:37, 12 June 2009 (UTC)

HCO Domain Name

The HCO spading clan apparently let their jick-nerfed.us domain expire, breaking some links. Is there any way you can search each page of the Wiki and replace "jick-nerfed.us" with "hardcoreoxygenation.com"? --BagatelleT/C 16:59, 1 March 2009 (UTC)

  • Unfortunately, the wiki doesn't seem to know how to find URLs in searches, so the only way to do it would be to export the entire wiki and work from there. Not surprisingly, that's not something I'm particularly keen on doing. --Quietust (t|c) 17:18, 10 June 2009 (UTC)

Category deprecation

  • Can you empty out and delete Category:Combines? All of them information is now redundant to the Meatpasting discoveries page.--Toffile 05:22, 17 February 2009 (UTC)
    • It is done. --Quietust (t|c) 18:10, 17 February 2009 (UTC)

Filling in item data pages

Actually, I do have a bot request as well, or perhaps more of a question. Can you add data from {{item}} to the item data pages? And is it feasible to add consumption data as well for "normal" consumables that only have one {{useitem}} use on the page, in a when consumed section with nothing else in it? It's not ready for automatically changing all {{useitem}} consumption to {{consumeitem}}, but just getting the data pages populated would be very nice. (And I guess the 80%+ simplest items that only gives adventures and positive stat gains could be changed to use {{consumeitem}} automatically, but that would definitely require manual inspection.) --Eleron 09:15, 6 February 2009 (UTC)

  • Exactly what item data do you intend to populate into the data pages? Remember that it really only makes sense to populate data that can appear in more than one place, since the act of fetching information from a data page places extra load on the wiki every time a related page is edited. --Quietust (t|c) 14:00, 6 February 2009 (UTC)
    • Preferably all of it. The data page is really the right place to have the item stats, just like the monster stats were placed in the monster data page. So basically everything from item and useitem, nothing else, not notes or references or anything like that, just what's actually part of the item in the game. (I'm not sure why it's referred to as monster/item metadata instead of data in some places. I suppose it makes sense since the pages are technically templates, but I would consider the embedded item data as the meaningful primary content of the page. Not important though, but it's puzzled me at times.) For some properties such as quality I don't think they'll even be used anywhere at all right away, but they're part of the game and should be stored somewhere on the wiki, and the data page is the right place to do it. Everyone might not agree with that sentiment, but at least a significant fraction of the "spades" agree that storing all known information is the right thing to do. And if it doesn't hurt anyone and is mostly invisible to end users except where it can actually improve the pages, I don't see the problem. If it's a massive and unavoidable performance problem, that would be something different.
    • I don't know much about what kind of overhead it actually imposes for the wiki, but I really like the way it works for monster data, and that seems to be OK(?). However, from looking around at the underlying templates I can tell that the monster data is done more intelligently, where the data is passed to a template en masse instead of being extracted individually. Is that your concern? I would really like the item data pages to be done the same way as the monster data pages :) (And they can just be called with #switch:foo as the format if you really want individual fields the way it's done today. I think they could be changed automatically if it's a significant performance difference, and just using Data2 instead of Data1 where it's really needed.) --Eleron 04:49, 7 February 2009 (UTC)
      • I am rather strongly opposed to using item data pages to hold all data about a particular item, specifically because although it is convenient, it is inefficient. The entire reason the data pages were created in the first place was so that they could hold information that was stored on multiple pages, so that they could be updated in all places at once by making a single edit - for items, this was the singular form, the plural form, and the item image, all used by {{acquire}} (and the same fields for effects, minus the obviously nonexistent plural form). There is absolutely no advantage toward storing information such as the item's ID, description ID, description text, or use messages in data pages, because it is only ever used on the page for the item itself. Some properties such as a more detailed item type (food, booze, spleen, combat, weapon melee/ranged, weapon category, weapon handedness, offhand versus shield) and fullness/drunkenness/spleen-ness might possibly be useful to aid in automatic categorization of item pages (and those could potentially just be placed directly inside {{item}} and just not be displayed directly), but anything which is otherwise used in only one place does not need to be placed in a data page since all it will do is make the page more difficult and confusing to edit (especially to newer editors) and increase load on the wiki whenever any property of the item is changed (the item page would be instantiating numerous instances of the data page template, and any page using {{acquire}} would be needlessly refreshed). Data pages are not meant to be a substitute for an actual database - if we want to keep information like that, we'd be much better off putting it on a separate site (or just elsewhere on kol.coldfront.net) and updating the item/useitem templates to simply include links to said data, much as we do for Market Statistics. --Quietust (t|c) 20:04, 7 February 2009 (UTC)
        • Fine, I don't think that it's the right thing to do, but that's a deeper semantic issue and I'll back down. However, many of the properties are already used in multiple places. Name, plural, type, image, autosell, power, stat, statreq, size, consumable adv/stat gains. Enchantment and useitem effect for other items are also used in several places, but they would probably require further changes to be converted to using templates. My main concern is consumable gains, since today they're often replicated incorrectly. For the other properties I think it's causing unnecessary manual cross-referencing, but I don't think it's as common for those to contain errors. --Eleron 03:45, 8 February 2009 (UTC)
          • But even if we move, say, stats and statreqs into the data page, how do you plan to make use of that to cut down on "manual cross-referencing"? If you wanted to cut down on, say, the Hats page, you'd need to do something like create an all new template that parses a given item name's data and generates a table row. Probably possible (the main hiccup being how the | character gets interpreted). And it could lead to some very compact tables on the equipment pages themselves. But what seems like the problem here to me is that you'd have to create a new template for every niche use, or expand an existing one to parse in various ways. Sounds nice; like what you'd probably do when writing a computer program to display things. I'm not sure if it is worth it, though. And I can understand Quietust's concerns that this would, in certain cases, make page creation an arcane mechanism that only the initiated can understand. Unlike a computer program, the code itself has to be accessible and comprehensible to a wide audience, not just the final presentation. --Flargen 04:00, 8 February 2009 (UTC)
            • I think it was wrong of me to keep up the discussion about this here on the talk page, especially since it's now a Current Point of Discussion. Could we move it back to Discussion? The objections concerning efficiency and user-friendliness should be represented over there as well. I withdraw my request to automate it until it's resolved what should actually be on the data pages. --Eleron 09:21, 8 February 2009 (UTC)

Could you comment on the efficiency of moving the data to the item data pages, on the discussion page? If I understood correctly, the performance impact was your main objection? Is there any reason not to change item data pages to behave like monster and location data pages, which can be used efficiently instead of extracting just one data field at a time? --Eleron 18:07, 13 February 2009 (UTC)

Eradicating a boneheaded mistake

Can you replace {{editlink|Template:{{PAGENAME}}}} with {{editlink|Template:{{subst:PAGENAME}}}} in any case where it shows up in the Template namespace? I'm not too sure if there's any cases left, but I just want to make sure. That particular line creates an edit link to non-existent templates.--Toffile 16:31, 4 February 2009 (UTC)

  • I can find no such pages, so either you got them all on the first run or somebody else already cleaned them up. --Quietust (t|c) 17:40, 17 February 2009 (UTC)

Potion Update

User:Antoids has pointed out that the current sauceror potions and effects pages are inconsistent as to the presentation of the number of turns gained and why. would it be possible to change the template to accomodate the 5/10/15 turns and a note explaining how this is worked out? the reason why i've put this here is that whether you can change the tempate or not the pags concerned will need to be updated, and perhaps quietbot is the one to do it. --Evilkolbot 06:47, 22 May 2008 (CDT)

  • Eheheh.. Yeah, sorry about just doing it like that. I didn't realize it would a big deal. But, yeah, the pages currently say "5-15 turns" on the items, and "5/10" on the effects, with no explanation. Neither of these is right, as there are only three turns in the 5-15 range that occur, and the other is leaving out a value. It's both slightly confusing and inconsistent. So yeah. (And next time, I'll find a Discussion page instead of immediately applying an edit with no confirmation. ^_^;;)--Antoids 20:19, 22 May 2008 (CDT)
    • Antoids: I feel I should tell you that editing other people's comments, even if only for capitalization or grammar, is forbidden on this wiki, so please don't ever do it again. Evilkolbot: as for resolving the issue of reagent potions, I could either add a special parameter to {{acquireEffect}} or, probably simpler, just make a separate template solely for acquiring effects where the effect duration varies - this would include not only reagent potions, but also Turtle Tamer, Sauceror, and Accordion Thief buffs (most likely using a parameter to indicate which explanation to link to). Further opinions are welcome. --Quietust (t|c) 21:45, 22 May 2008 (CDT)
      • I don't know how complete you want to make this, but the opera mask and jewel-eyed wizard hat affect durations of certain buffs as well, and this behaviour isn't noted in such a way that a newbie browsing the Wiki would be likely to come across it. There's also the Platinum Yendorian Express Card, which is more of a "global" sort of thing that might not be worth implementing in a template. --Bagatelle 22:21, 22 May 2008 (CDT)

Item Drop Tracking

Per what is being discussed, would it be possible to have a bot find every monster/noncombat which drops a particular item? I was thinking it might be done by tracking the acquire template, as well as checking the category of the page it was used on. But I'm not very well versed on the limits/capabilities of wiki botting. --Starwed 14:51, 6 February 2008 (CST)

  • So, any thoughts? --Starwed 03:49, 26 February 2008 (CST)
    • If it'd be restricted only to combat and noncombat adventures, I could probably manage something (though it might get confused by the fruit golems, which drop items as part of certain attack messages). I'll see what I can do. --Quietust (t|c) 09:00, 26 February 2008 (CST)
    • Script has been written and is currently running across all 1227 pages which use the acquire template. Output will be plain text, listing each item along with every page which drops it and indicating whether the page is another item (usually from an item consume message), a noncombat adventure, a combat adventure, or some other kind of page (mostly Quest pages). --Quietust (t|c) 10:57, 26 February 2008 (CST)
      • It's done running, and the results look fairly good. I've posted them here. Once the data is sufficiently cleaned up, we can decide what to do with it (possibly some mass edits by QuietBot). --Quietust (t|c) 11:45, 26 February 2008 (CST)
        • A couple of quick observations from just looking at the first few entries. One, I think we can ignore "from items" entries for this particular purpose (those are listed in the notes). Second, it's picking up on obsolete adventures without identifying them as such. Namely, spices coming from Zest!; and presumably others. And do we care if it's picking up, say, dough drops from a zombie yeast beast? --Flargen 11:58, 26 February 2008 (CST)
          • I didn't filter based on category tags (because those can be inconsistent, just on the templates present at the top of each page. If all obsolete adventures are categorized as such, it should be simple enough to manually filter them out of the data. --Quietust (t|c) 12:22, 26 February 2008 (CST)
            • Any chance on getting this moving again? --TechSmurf 20:47, 8 May 2008 (CDT)