Discussion/Infoboxes

From TheKolWiki
Jump to: navigation, search


Call for comments: As mentioned below in the Format discussion, if no one has any further comments about what should be included in the location infoboxes and how they should be integrated into the page, I'll start rolling them out. (I think there is discussion left to be had on several issues, so please comment!) --Starwed 20:35, 11 November 2006 (CST)

Since no one has commented, I'm going to start the process of including location infoboxes on all pages which warrant them. --Starwed 15:46, 18 November 2006 (CST)

Back to Discussion.

Location Infobox Rollout

I put infoboxes on most of the location pages. Notes on adding infoboxen:

  • I used the Safe Adventuring list as a guide to finding locations, so anything not listed there I might have missed.
  • The hedge maze looked really weird w/ one, so I left it alone
  • I didn't add them for dual areas, which include:
    • pirates cove, hippy camp, orcish frathouse
    • dungeons of doom
    • Misspelled Cemetary
    • The Bugbear Pens
    • The Battlefield
    • Crimbotown
  • Didn't add any for Boss areas (quite possibly we could use a special boss infobox)
  • Should the Daily Dungeon have one? It's got monsters and noncombat, but it's obviously a very special case.

My current thought is that, where two completely seperate sets of adventures are listed on the same page, that a special dual infobox template be used. --Starwed 18:09, 18 November 2006 (CST)

I've implemented the dual infobox, and added it to a few of the pages. --Starwed 12:42, 30 November 2006 (CST)

Tasklist

  • Hammer out what infoboxes should look like. This should probably be uniform across different types.
  • Where should infoboxes be used?
    • Monsters, locations seem a natural fit. --Starwed 01:38, 16 October 2006 (CDT)
  • Get a list of what information should be included in each type of box.
    • Need an indicator for physical immune monsters. --Quietust 08:31, 16 October 2006 (CDT)
    • Now that the infobox templates have official pages (Locations and monsters), I guess it would make sense to dicuss what's needed on a per template basis. --Starwed 04:04, 17 October 2006 (CDT)
  • Decide where (if at all) database like methods should be employed.
    • Probably not for locations. --Starwed 01:38, 16 October 2006 (CDT)
  • Actually start implementing the concept.
    • Locations will be simpler, and there are less of them anyway. --Starwed 01:38, 16 October 2006 (CDT)

Format

What format should the infoboxes have?

Sample of what one could look like can be found here.

Wikipedia uses some CSS classes to style their infoboxes, it would probably be good to simply copy those onto this wiki. (They're located in main.css, and are all clearly labeled as for infoboxes.) Obviously this is an admin's call. ^_^ --Starwed 08:05, 16 October 2006 (CDT)
Is this what you are looking for?
(snip CSS which is now found in monobook.css)
--SomeStranger (t|c) 17:36, 16 October 2006 (CDT)
Yup, that's it. Is there any objection to just copying all that into the wiki's CSS? (Of course it takes an admin to actually do so.) --Starwed 04:30, 17 October 2006 (CDT)
I added it to the monobook.css page which works just as well.....--SomeStranger (t|c) 20:03, 18 October 2006 (CDT)
Thanks, that streamlines the templates nicely, and properly formats the individual cells and rows. Any comments on how monster infobox at my userpage looks? You seemed bothered before about how it messes up the centering of the page; is there any way around this issue? --Starwed 12:19, 19 October 2006 (CDT)

I proposed a slightly difference format at Template talk:TestInfobox removing the redundant name listing and listing physical resistance.--Dehstil (t|c) 12:36, 19 October 2006 (CDT)

Ah, I'd missed that somehow. For some reason I thought that position:relative didn't work in IE, but since I see that it does we should indeed use that instead of float for infoboxes. I'm not sure if we want to remove the name entry or not; the standard on wikipedia seems to include the name in an infobox even if it's a bit redundant. Take a look at Wikipedia:Lime to see how it's used with fruits, for instance.
There are all sorts of tweaks to the basic infobox that we could make, especially changing the color scheme. I'll leave that up to the admins, since it looks like you need that sort of access to update the CSS pages. Right now I'd like to go ahead with implementing basic infoboxes for adventuring locations; it's much smaller in scope than doing it for monsters. I started a list of what I thought should be included on the talk page. --Starwed 16:24, 19 October 2006 (CDT)
Looks like using CSS positioning to place the infoboxes can run into problems; it will overlap onto the text of the article. There might be something I'm missing, though. Because it would be the most elegant way to add these infoboxes. ^_^ --Starwed 00:22, 20 October 2006 (CDT)

I've slightly revised how the infoboxes look; you can see that for locations and monsters. (Color!) The big issue, I think, is: how should infoboxes fit into the flow of the page? If they're stuck in as on wikipedia, then the image of the monster/location at the top is no longer centered. Using CSS instead of float solves that problem, but then the infobox can overlap the text of the article. Another option is having the infoboxes appear underneat the image, to the right of the text, but that looks a little funny. Anyone else have any thoughts on this, or about how to make them look better in general? --Starwed 10:01, 24 October 2006 (CDT)

  • I think that the infoboxes should definitely be at the top. I'm pedestrian at best in dealing with these issues, but perhaps we could incorporate a mini table into {{battle}} that holds the image and the "You're fighting a ..." text. Then the two tables would sit side-by-side and avoid overlap problems. --Gymnosophist 01:58, 25 October 2006 (CDT)
    • The problem becomes one of long infoboxes. (Not so much a problem for locations, but there's a lot of info to included for monsters.) Ideally, we want the image to be centered, the infobox to be at the top right, and the text to start directly under the image, flowing around the infobox. To get the text to flow around the iBox, I'm pretty sure its necessary to add float to it, rather than using CSS positioning. This causes the image to become uncentered, but you can use CSS positioning on the image to force it into the center again. If you're not careful this will mess up where the text starts, but by placing a dummy div of the right height, this problem can be avoided. It's a little convoluted, but it's the only way I could think of to get the correct effect. I might be wrong, but I think a table wouldn't allow the text to wrap around the infobox.--Starwed 02:13, 25 October 2006 (CDT)
    • Damn, can't get the method I mention above to work in IE. If it was up to only me, I'd just live with uncentered images. It doesn't really look bad if the infobox is long enough; then the image is centered relative to the first block of text. (Honestly, I'd probably put the image directly into the infobox, as is commonly done on wikipedia, but it seems there's a preference for having pages appear like they do from within KOL.) It would be nice to get other peoples comments on this, as it's probably the last "blocker" that I see for rolling out infoboxes on location pages. --Starwed 07:58, 26 October 2006 (CDT)
  • I really like seeing the singleton image included as part of the location (and had almost suggested doing just that). However, it can be a problem for locations with multiple images like The Haunted Bedroom, Right Side of the Tracks, etc. Maybe we could set up the template so that including the image is optional? If so, are people OK with having two slightly different approachs to locations? I think I would be. We might also consider doing the same thing for monsters, although this would mean a more radical departure from our "Wiki adventures should look like ingame adventures" standard. --Gymnosophist 05:24, 27 October 2006 (CDT)
    • The template is already set up to show the image cell only if an image parameter is set. Full zones like the Right Side of the Tracks aren't a problem, as they'd need a different sort of infobox anyway. But I hadn't noticed that there were adventuring locations like the haunted bedroom... Presumably there are only a handful, so I guess we could just make little mini images for them that are the right size. (Assuming that the consensus is for images in infoboxes. I'm still now undecided on which looks better.) --Starwed 05:58, 27 October 2006 (CDT)
    • It would be good to get a few more comments on this one; there's really no reason not to go ahead with the location data, at least. I think the least intrusive change would just be to add floating infoboxes, without the image in them. So if no one else comments in the next few days, I'll take that as tacit approval and start adding them to pages. ^_^ (As SomeStranger says about the item data pages, otherwise the project will just stagnate.) --Starwed 15:51, 6 November 2006 (CST)

Dual locations

Sometimes there are effectively two locations on one page. This happens when the adventures change depending on your outfit or quest completion. My gut feeling is that we should have two, separate infoboxes on the page; what do others think? --Starwed 10:44, 10 November 2006 (CST)

  • Technically, we should move these to a separate page called "Area name (in disguise)", since the game itself does distinguish them as separate areas. --Quietust (t|c) 12:15, 10 November 2006 (CST)
    • That sounds better to me; I had assumed that having them on the same page was policy. But I don't think the Mispelled Cemetary distinguishes in the name itself; is that the only odd case? (edit: Bugbear Pens has the same problem.) --Starwed 13:06, 10 November 2006 (CST)
    • Having them on the same page is policy. But that doesn't mean that the policy can't be changed. The best place to discuss such a change might be over at Discussion#Adventure Sort Order, which has been awaiting feedback for some weeks now. For myself, I'm against having two separate locations or having two separate infoboxes. The single infobox could just say something like "Disguise Adventures: Yes". --Gymnosophist 14:47, 10 November 2006 (CST)

I came up with a "dual infobox" which should work for these pages. You can see it here... any commments? --Starwed 15:47, 27 November 2006 (CST)

Change

I've come around to the idea the the location pages will look better with the image included in the infobox, in most cases. I also think that all location info might as well be kept in Data: pages. Without any objections to these ideas, I'll go through and make the changes soon, adding in location # when I do so. --Starwed 22:35, 27 January 2007 (CST)

  • Hmm, as long as it looks good. Is there a test template or whatever somewhere showing what it'd look like? I assume it'd seem just fine.--Dehstil (t|c) 22:48, 27 January 2007 (CST)
    • You can kind of see what it looks like at User:Starwed/LocationTest. It looks a little funny if the infobox overlaps with the adventure listings, but that can be fixed by adding clear: right onto the CSS of the adventures. (Scroll down the page to see a mockup.)

Metadata issue

Should we use /Data pages to create an effective database of monster stats?

Pros:

  • Allows standardization and easy update of data which is used in multiple places.

Cons:

  • Could add lag to the wiki.
    • Why would this cause any more lag than a normal template? Updating metadata for one monster/location would only force a few pages to update. --Quietust 08:39, 16 October 2006 (CDT)
      • As someone who knows nothing about how the wiki actually works, I only know that this claim was made. If no one believes this to be the case anymore, strike it from the list! ^_^ --Starwed 12:08, 16 October 2006 (CDT)
  • Harder for new users to update.

Initial Discussion

I thought it might be a good idea for infoboxes to be introduced for some categories of article. (Like how wikipedia does for albums, for instance.) Monsters especially: it would be nice to see the level, statgain, elemental, and so on right at the top of the page. Locations could use this too, having safe moxie, avg monster level, clover adventure, and so on in an infobox. I don't know how to set any of it up, but I'd certainly be willing to help with adding these once the ball was rolling. Thoughts? --Starwed 10:18, 10 October 2006 (CDT)

  • I would like to see this information somewhere for the monster pages...hopefully in the near future.--Dehstil (t|c) 20:32, 10 October 2006 (CDT)
  • I want to see this information on the individual adventure pages as well (I think monster combat messages could be pushed way down the page), so I'd like to see examples of possible templating. --Jonrock 21:19, 10 October 2006 (CDT)

It seems the standard way of doing this requires that a certain stylesheet be in use, with all the "infobox" declarations. I've copied the declarations by hand into a sample infobox: Template:TestInfobox. It would obviously be more elegant to include them in a common style sheet. --Starwed 16:27, 12 October 2006 (CDT)

I've mocked up what this could look like at my user page. It seems to me that it would be nice if all the data associated with a monster could be stored on one page and then called via templates everywhere it's referenced; I don't know if that's possible or even desirable, but since all the information we'd want in infoboxes is already mentioned elsewhere it would be nice to have uniformity. --Starwed 16:43, 12 October 2006 (CDT)


I've experimented a bit, and it is entirely possible to keep seperate subpages for each monster with the data in it. That data could then be reused on any page it might be useful (right now, probably individual monster pages and the monster summaries on adventure pages.) It's quite possible that this would slow down the wiki, but it's at least technically feasible. ^_^ (You can check out my userpage to see how this works.) --Starwed 16:14, 13 October 2006 (CDT)

  • Yes, it's feasible to have autoupdating metadata for different stuff, but it'd be a huge drag on the wiki. See Talk:Best Drinks, {{plural}}, and Discussion/archive3#A Companion for .7B.7Bplural.7D.7D.--Dehstil (t|c) 16:27, 13 October 2006 (CDT)
    • Actually, this particular technique probably would have resulted in less lag than {{plural}} currently does, and it would allow storing not only plural forms, but also singular forms (for stuff like Item #13) and image names (to be automatically included by {{item}} and {{useitem}}). Updating the 'infobox' template would still cause just as much lag as before, but updating stats for a single monster/item would not cause any significant extra load on the wiki. I've created an example at {{test/acquire}}. --Quietust 16:32, 13 October 2006 (CDT)
  • The database administrator in me likes this idea but the usability consultant in me hates it. Typical. I'd want to make sure that the "data page" for a monster is clearly linked to its main page (or talk page), so that it doesn't require "wizard skillz" to make modifications. We're already having troubles in that templates themselves don't have "preview", so they take much more care to make work correctly. --Jonrock 19:28, 13 October 2006 (CDT)
    • Is it be possible to have an "edit" link in the infobox itself? Also, we're mostly talking about data that has to be pretty carefully gathered in the first place; the sort of people who could alter it reliably are probably the same who wouldn't find editing a template too tricky. --Starwed 20:05, 13 October 2006 (CDT)
      • If you show me what the heck you want it to edit and where you want it to go I can whip up an edit link in a few minutes.--SomeStranger (t|c) 23:31, 13 October 2006 (CDT)
        • I messed around a bit and seem to have come up with a workable solution for infoboxes. (Simply a link to edit CURRENTPAGE/Data) Unfortunately I can't grok how to get the pagename of a template from within that template, which would be the nicest solution here. (Using the CURRENTPAGE functions renders the page the template is called from; which makes sense but is unhelpful. ^_^) Still just using my userpage as a sandbox. If there's real interest in adding infoboxes (with or without the metadata templates) maybe we should start a proper discussion page? --Starwed 02:33, 14 October 2006 (CDT)

I quite like the general concept of using Infoboxes for combat adventures, locations, etc. The example Infobox looks pretty good, and, with some formatting tweaks, will look even better. I also like the implementation, despite having something of a reservation over it's complexity. I share Jonrock's concern that ordinary users are increasingly finding that making even basic edits is becoming prohibitively difficult. That said, I definitely see the value of having the data in a /Data page, at least for data that will be used in multiple places, (like the monster data). But all in all, I think the benefits outweigh the additional complexity. We'll just have to do a good job on documenting the usage. On locations, or any other type of data that will probably be used only once, I think it may be better that we not use the /Data page approach and instead use a simpler, more straightforward template wherein we simply drop the data values directly into the instance of the location Infobox template on the location page. Starwed, great idea, and thanks for your work so far in illustrating it. --Gymnosophist 04:31, 14 October 2006 (CDT)

  • In the past when a user has been unsure about how to use a template/format a page they have either posted on the talk page with the information they wish to be added, or attempted to add it and an admin/someone who knew what they were doing fixed it. I believe that first and foremost this wiki needs to be useful to those who don't edit at all, the vast majority. If you want to edit you can find your way. (Besides most large updates are usually made by the admin, while the references/notes are edited by everyone else.)--SomeStranger (t|c) 09:09, 14 October 2006 (CDT)
    • I agree wholeheartedly that first and foremost the Wiki needs to be useful to those who don't edit at all. However I couldn't disagree more with the implied contention that the admins should be the users doing all the heavy lifting of non-reference edits. That's certainly not how Wikipedia runs things, nor should it be the way things are run here. I also strongly disagree with the viewpoint that documentation is a lesser priority. My own view of the role of being an admin is that we should be activly participate in developing policies and standards. Additionally, part of my concern with things becoming more complex is that it also has the unwelcome side-effect of making the Wiki more insular and less open to newer and less experienced editors. This is ranging a bit far from the original topic of Infoboxes, but here we are.  :) --Gymnosophist 20:00, 14 October 2006 (CDT)
      • I don't necessarily believe that admin should be doing all the work, but that in order to acheive a global standard they end up doing most of the work along with a few select editors. Why do we use templates? So that formatting is easier. The problem is that learning how to use templates is not always very easy. I think that documentation is pretty good at this point (I know that all the templates have it anyways) and that most people learn from example (they copy previously made pages). Removing templates in order to create "simplicity" just makes it harder for admin and those select users who have to go back and format pages constantly. I think the way we do it now is pretty straightfoward, the only exception being the plural template, I find it pretty damn intutive that variables named "name" and "itemid" correspond with an item's name and id respectively.
Oh, and back on topic, HOORAY FOR INFOBOXES! Yeah....--SomeStranger (t|c) 20:21, 14 October 2006 (CDT)
        • I almost feel like we're talking in circles here - I generally support the use of templates, and am not suggesting that templates be removed in favor of "simplicity". And yes, templates are generally well documented and intuitive to use. What I was trying to make clear (and was apparently failing to do) was to note the fact that the /Data pages are a new wrinkle and would need to be clearly documented. Hopefully, my positions on these matters are now pellucid.  :) P.S. - Not all the templates are documented - that would make a good project sometime. --Gymnosophist 03:24, 15 October 2006 (CDT)

Metadata Storage

The infobox method being discussed involves using metadata pages to store relevant information. This same method could be used for pages like items and effects, where certain metadata is repeated in numerous places throughout the wiki (such as images, and especially plurals). A bot could probably manage creating and populating metadata pages for all item and effect pages on the wiki, eliminating the need for the horribly laggy {{plural}} as well as centralizing the specification of item/effect images. As noted above, I've already adapted {{acquire}} (into {{test/acquire}}), and updating {{AcquireEffect}}, {{item}}, and {{useitem}} would be trivial. Tracking pages lacking metadata (whether lacking individual fields such as plurals, or missing the page itself) could be accomplished with conditional categories using #ifexist for page detection and a generic 'getMeta' template (currently implemented as {{test/field}}) to try and fetch metadata from an object. If anything, using this for plurals would be only slightly slower when updating pages that use {{acquire}} (since it would have a few more templates to parse), but it would be immensely faster when updating plurals (since it would only have to update the pages that refer to acquiring that particular item). --Quietust 17:49, 16 October 2006 (CDT)

  • My only concern relates to those who parse the plural list for use in scripts, etc... Instead of being able to parse one list they would have to hit the wiki multiple times to find all their data. I'm not particularly worried, but well...it certainly must be considered. Furthermore, we need to decide how to display data on the data pages. I am not thrilled about using <includeonly> tags, simply because they make the page look empty, something very confusing to new editors. Is there anyway we can format it nicely and still make it usable for database purposes?--SomeStranger (t|c) 18:09, 16 October 2006 (CDT)
    • It looks like making the data pages look nice wouldn't be too much of a problem; we just call the template on its own page with a template for that format. I made another quick mockup of this at User:Starwed/Data, using the template User:Starwed/NiceDataDisplay. We could include instructions for editing the data on the /Data page itself.--Starwed 02:42, 17 October 2006 (CDT)
      • I think I would have to say that I'm not convinced as to the value of extending the /Data page approach to items, etc. As with any contemplated change, the advantages and disadvantages should be weighed. For the item example, the advantages seem to be easier and mistake-free editing with {{test/acquire}} as well as less lag, while the disadvantages seem to be more difficult setup of items pages and a significent conversion to go through. Let's look at each of these more closely. With regard to the first advantage, it certainly makes life easier to simply plug in just the item name into an acquire template and not have to dig up the image name associated with the item. As to mistake-free editing, let's put this in context: with monster data, it's not unusual to find different data values (errors) for meat drop, etc. on the location page and the adventure page. However, with item data, it almost never happens that an incorrect item image is used; even if it happens, that sort of mistake is always caught and quickly corrected. Not so with monster data. The same arguement holds with regard to missing item metadata: these lacunae are not suffered. With regard to the second "advantage", less lag, I'm not sure that any real advantage conveys here. When Quietust implemented the "View Market Statistics", that change propagated in a matter of seconds, which would lead me to believe that language such as "horribly laggy" and "immensely faster" overstates the case. As to the first disadvantage, the setup of the item /Data page, I think this has already been pretty well covered above - many users will have difficulty with the approach. Additionally, as new items are rolled out much more frequently than new adventures are, this makes adopting the /Data page approach for items that much more problematic. Finally, to the second disadvantage, the conversion process for existing item pages. Bots were mentioned as a possibility, but I think that several people have complained recently that some sort of incompatibility broke their bots. That aside, the conversion and verification of some 2,000 pages is not something to be undertaken lightly - there are a variety of risks to consider, including the risk that errors will creep in undetected in the conversion process. Viewed as a whole, it seems like a pretty close call, but I'm currently leaning against implementing /Data pages for items. Are there other factors I'm missing? --Gymnosophist 04:02, 17 October 2006 (CDT)


First a trivial thought, i like /Info better than /Data, data to me sounds sound data collection, like samples fo results, while info includes data/info/stats. but that could just be my concieved use of those terms and doesn't really matter. On to the main stuff now. If the data is store like it is in User:Starwed/Data, it is useless except for the infobox (only only for the infobox). Isn't the point of a data page having a place to store stuff which can be referenced from anywhere. For example, shouldn't if the monster data is changes, shouldn;t it not only update the monster page, but all combat templates (on location pages usually, or as a reult of a choice adventure) which show the monster too. For example all items, monsters, etc. could have a data.info subpage which would be a case/switch statement, for example:

 {{ #switch: {{{1}}}
 | name = monstername
 | hp = HP
 | ...
 | image = image
 | unknown, may need to be added [[{{{PAGENAME}}}/Info|here]]
 }}
   or
 {{ #switch: {{{1}}}
 | name = itemname
 | image = image
 | ...
 | plural = plural
 | nknown, may need to be added [[{{{PAGENAME}}}/Info|here]]
 }}

Then this could be used in all templates, you could get info about anything using {{PAGENAME/info|STAT}}, like {{knott yeti/info|level}} or {{yo-yo/info|plural}} or {{big stick/info|plural}} or {{{{helmet turtle/Info|image}}. Then the combat template would end up like {{combat|knott yeti}} and it could get all the info based off the knott yeti info/data/stat page. This would cause all references of the knott yeti's info to be updates everywhere with one edit. Same with tiem info and plurals. One edit changes everywhere. This would remove all plural lag too, updating a plural would no longer force over 200 pages to be updates, only the pages which references that one items /info page, which would prob be about 20 or so including templates which use it, that's way less that 2000+!. Thoughts anyone? The item, when used, and other templates would also automagically get info from that page, only the things which aren't needed elsewhere would be tempalte parameters (items desc, use messages, etc.). And imaginee if the values on "Items by autosell value" or "Some Equip By Stat" or "Muscle Modifers", etc. updated themselves as /info pages where changed as items changed in game! (of course they may need to be reordered manually from time to time). Those infoboxes would also ref the info pages, updating according. The info there could be used anywhere as needed. Thoughts? --JRSiebz (|§|) 19:36, 19 October 2006 (CDT)

  • That's actually a slightly more convenient way of storing the data - the method Starwed came up with effectively makes it so the data page simply instantiates the template of your choice, where said template simply takes all of the data and formats it accordingly (doing {{knott yeti/info|combat_row}} to render a "combat" adventure entry in a Location, and {{knott yeti/info|battle_infobox}} to render an infobox on the monster page itself). This method you suggested would be a bit slower, since it would include the data page once for each field, though it would work a lot better for item pages, where individual values are read out more often than everything at once. --Quietust 19:52, 19 October 2006 (CDT)
      • To my surprise, the way that User:Starwed/Data is currently set up, you can emulate the switch page. Obviously it was written to take a template as an argument. But oddly enough, if you call it like this: {{User:Starwed/Data|format=#switch:meat}}, it actually produces the value of the meat parameter: 15-16. (I was kind of surprised that this actually works, but I'm not complaining. ^_^) There's obviously some extra line break being introduced by the template, but I hope there is some way around this. In any case, I thought it was interesting that this worked.--Starwed 21:03, 19 October 2006 (CDT)
        • A line break between the includeonly and noinclude sections was causing that. --Quietust 21:12, 19 October 2006 (CDT)
          • If you are looking for efficiency I believe that Starwed's way of doing this is better. I believe that the switch method calls upon the page each time, while his just grabs it all and does with it what it needs and just forgets the rest. --SomeStranger (t|c) 23:21, 19 October 2006 (CDT)
            • A slightly different (and somewhat improved) way of fetching a single field from an Info page involves using a special template - for my {{acquire}} conversion example, I created {{test/field}}, used as {{Pagename/Data|test/field{{!}}fieldname{{!}}default value}}, which has the advantage of allowing a default value to be specified. I can't make any speculations on efficiency, though, but this method might actually work properly with subst: while the #switch method certainly does not. --Quietust 10:03, 20 October 2006 (CDT)
              • For whatever reason, what worked fine in {{test/acquire}} did not appear to work properly in here. --Quietust 10:23, 20 October 2006 (CDT)
                • With the "builtin switch" data page format, it's significantly simpler. In addition, put a "default argument" of {{{2|}}} at the end so you can return a specific value if something wasn't defined otherwise. Again, this would work better for attributes on items and effects that it would be for adventures and locations (where a lot of information is used, and all of it is used at once). --Quietust 15:58, 20 October 2006 (CDT)
                • It is possible to get substitution to work for switch after all, just use: {{subst:User:Starwed/Data|format=subst:#switch:meat}}. (I found this info here, where it is explained that all internal templates must also be explicitly substituted.) Sorry if I've misunderstood the issue you were dealing with. --Starwed 10:46, 20 October 2006 (CDT)
  • Using the contents of {{plural}}, Special:Export, and a simple PHP script, I've generated a file containing data page definitions for every item currently defined in the wiki using the 'switch' method outlined above to include item name (singular, for stuff like barrrnacle (hatchling), zmobie (drink), and Item 13), plural form, and image filename, and have uploaded it here; presumably, SomeStranger's bot could be made to accept this data format (that, or I could convert it to some other output format it will like) if it's decided that this is a worthwhile effort. --Quietust (t|c) 23:17, 1 November 2006 (CST)
  • Will consumption info and such be there too?--Dehstil (t|c) 23:29, 1 November 2006 (CST)
    • I think it should be....but that might be too complicated. In regards to my bot: I barely know how to code Python so anything I do will really be a hacked up job.....I really doubt my ability to have it parse data to create wiki pages let along create wiki pages at all...I would feel much more comfortable creating a huge, overdone Greasemonkey script which created all the pages....(that would be far easier for me; GM has a post method so it is possible). If any of you understand python to the degree that we need, I will happily send you what I have modified, etc....(not much really, just a few hacked up bits to get the script to add things to the bottom of pages indiscriminately.)--SomeStranger (t|c) 23:47, 1 November 2006 (CST)
      • A quick search turned up this script, which takes data in a format remarkably similar to what my script generated - I could easily edit that script to accept my own data format (as well as fix a few other bugs). If I can get a bot account, I could easily import all of these pages myself.
        Also, regarding consumption information, what would be appropriate to include? Consumption information generally only ever appears on the item page itself, while singular/plural/image appear everywhere {{acquire}} gets used. --Quietust (t|c) 14:22, 2 November 2006 (CST)
        • I now have a working bot (complete with 'blessing' from Jinya), configured to create all the item metadata pages as soon as it's agreed that 1. it's a good idea to make them, and 2. what stuff should go on the page (any other fields, a 'noinclude' block to show a preview, any sorts of categories, etc.). --Quietust (t|c) 23:09, 3 November 2006 (CST)
          • At this point just put the three things that we already have. If we need to add more we can run the bot through again (it is not that bad on the servers). If someone does not do something eventually then this project will continue to stagnate. Sometimes just doing what you think is best is the only way to get things done. (Forget consumption data)--SomeStranger (t|c) 15:43, 6 November 2006 (CST)
            • That's funny, I got the exact opposite comment from somebody in response to {{useitem}} (that I was just doing stuff on my own whim without getting input from anybody else).
              I'll drop a comment in each metadata page to say "This page contains metadata, edit it to view its contents" and run the bulk import tonight, then we can decide what to do next. --Quietust (t|c) 15:50, 6 November 2006 (CST)

Well, generally speaking, it's best to try to get a concensus, especially on major stuff. Fortunately, we all seem to be agreed on the big issues, we just need to iron out some details. Let's see what we can do to get these decided before proceeding precipitously. It's usually a lot easier to get things right the first time than it is to go back and fix things.

  1. For starters, there are currently three different names either suggested or in use for data storage subpages: "/Data", "/Info" and "/data". I don't think it much matters which name we use, except that it should be uniform. I suppose that I support "/Data", but am fine with anything that gets decided.
  2. Do we want images in Location InfoBoxes? Personally, I really like the example with the image in the InfoBox.
  3. Do we want images in Monster InfoBoxes? I'm ambivilent about this.
  4. How much data do we want in the data pages? As much as possible? Or just what we can immediately use? Do we want to set up placeholder parameters that will be populated later?
  5. Monster subpages: I think we currently have "level", "drops", "meat" (meat range), "stat", "element", "image" and "hp". We should probably add "physical resistance", and "element" should probably be split up into "elemental resistance" and "elemental weakness". "adventure rate" would be nice to have as well. Should we also have "moxie for no hit" in the subpage? We probably should, if there's any possibility of reusing this data. It would also be nice to have "average meat drop". This would be useful for calculating expected meat gains, as discussed elsewhere. Similarly, it would also be nice to have "average stat gain" as some stat gains are ranges. Can we autocalculate "moxie for no hit", etc. directly in the subpage? It might also be nice to have item drop rates as well. Instead of "drops", we should perhaps have "drop 1", "drop 1 chance", "drop 2", "drop 2 chance", etc. This would let us do some fancy farming calculations. Should we identify Bosses as such? Also, Kittiwake's monster guide lists several parameters that we don't even have - Monster Attack and Defense values as well as a separate To Hit value. Clearly, there is a whole realm of monster data out there that we haven't even attempted to track - do we want to start now? (Monster inititive is another stat to be researched). Finally, I've got a lot of stuff here, perhaps too much. But it's better to think about these sorts of things in advance, even if we don't decide to immediately implement them.
  6. Location subpages: I had previously argued against having a data subpage, but would now like to reverse myself. Calculated expected meat and experience gains could go here and be used elsewhere. Also, we could possibly have the moxie required for Safe Adventuring posted here.
  7. Item subpages: There are obviously lots of possible parameters, but here we could perhaps be guided by the course of the discussion on locations and monsters.
  8. Item pages, KWE Wrestler pages: I feel strongly that every "parent" page should have some sort of edit link that takes you to the "child" data page. Where should we put this link?
  9. Template implementation: We seem to have two different implementation approaches - the original approach developed by Starwed's original implementation and the variant developed by Quietust. Which approach should we use? Starwed's implementation is beautifully elegent, but Quietust's implementation seems to be more generally usefully, especially as it seems to have a more graceful syntax for the user typing in a "request" for a piece of data. Am I understanding this properly? Is Quietust's implementation to be preferred?
  10. Rollout: I suggest doing a limited scope initial rollout, probably a single location and it's monsters (perhaps The Hippy Camp ?). This way we can work out any issues before going on and doing the entire Wiki. --Gymnosophist 18:55, 6 November 2006 (CST)
  • I've already begun the item metadata import, and it's about 20% completed. Page names are currently "/data" and include the singular form (for display when it differs from the page name), plural form, and image filename, and use the "switch" method of retrieving data due to the increased usefulness of that method for item pages. --Quietust (t|c) 18:59, 6 November 2006 (CST)
    • Given that the rollout has already begun, I say just let it finish. There were no huge disagreements on any of the issues for the past few days, it was reasonable to just go ahead and implement some version of the system. If we need to go back and change it again, we can compile a list of changes and do it over, but I don't think we could have grasped usage unless we saw it on a wide scale approach. Now that it is implemented, we are free to play around with templates that use the data and can get a better feel for what should be added (if anything) to the data pages. Personally, I hope that at some point all pages are run completely through their data pages so that users can simply substitute a template onto the main page and fill in the data template. At least for now, less is better, let's see how this turns out.--SomeStranger (t|c) 19:14, 6 November 2006 (CST)
    • Well Ok then, item data pages are being initialized. That doesn't prevent us from also discussing the above issues, nor does it prevent us from doing a test location (preferably in that order). I agree with you in that I'd also like to offload as much as possible to the data pages. I disagree that we need to do a 100% rollout in order to grasp usage - that's why I'm pushing for a test location. I also disagree that playing around with templates is the best way to determine what should be added to data pages - that's what discussion is for. So let's discuss!  :) --Gymnosophist 20:10, 6 November 2006 (CST)
      • Item metadata pages are in place, and {{item}}/{{acquire}} are all using them now. {{plural}} has been reduced to the equivalent of the old {{plural/autolink}} (which has been deleted along with {{plural/link}}), making it slightly cleaner to list item plurals. The next step is to update all instances of {{useitem}} to include the item name (where it isn't already defined) and then drop all image/name tags from existing {{item}} blocks. One minor side-effect of this change is that "custom user-page items" won't work without metadata, "custom sandbox items" are completely nonfunctional, and any Example pages will need to be retrofitted with metadata and updated accordingly.
        Also, the lag which previously resulted from editing {{item}} has gone away! --Quietust (t|c) 22:08, 6 November 2006 (CST)
      • One rather annoying behavior of MediaWiki is that the "preload" URL tag will remove any "includeonly" tags it finds in the page to be preloaded. This causes the "create metadata page" autolink to create a page which does not follow the same pattern as the other metadata pages. We may need to lobby to have this wiki patched to either remove this behaviour (assuming it isn't used elsewhere) or possibly add an additional URL tag to do the same thing but don't strip out includeonly. --Quietust (t|c) 22:56, 6 November 2006 (CST)
      • Sweet, what I'd really like is that monster data, but isn't some what was listed kinda redundant. For instance, elemental resistance and weaknesses need only be one field and such.--Dehstil (t|c) 22:59, 6 November 2006 (CST)
        • Salien brought up a rather interesting issue - these new metadata pages show up whenever you perform a Search, and they result in a lot of clutter. The only easy way to exclude pages from Search is to put them in a separate namespace, though I'm not sure if that can be easily done at this point (not to mention the potential difficulty of creating a new namespace). --Quietust (t|c) 16:37, 8 November 2006 (CST)
        • The data pages should produce a view of the data included in them. You can call a template even from the page it occurs on, and this will make it look a lot nicer. (See the sample monster data page for an example) --Starwed 12:32, 9 November 2006 (CST)
          • Now that I've substituted {{item/meta}} into every item's /data page, this should be fairly straightforward. --Quietust (t|c) 12:49, 9 November 2006 (CST)
          • In addition to making the above change to {{item/meta}}, we desperately need a link from the item page to the child /data page (see above). Once we've got that taken care of, let's stop messing around with items and actually get to work on infoboxes, which was the original reason for establishing the /data pages in the first place. A first step here is to begin discussing the unadressed issues listed above. --Gymnosophist 13:12, 9 November 2006 (CST)
            • For now, I've embedded a link to the /data page within the item image itself - since that's not a very good place to put it, could you suggest a more convenient location? To me, the itemid/descid/market infobox would seem to be a convenient place to insert that link. --Quietust (t|c) 13:21, 9 November 2006 (CST)
            • I agree, that makes the most sense. Let's put it at either the very top or at the very bottom. When the time comes, we can also add it to the similar templates for effects, familiars and skills ({{effect}}, {{Familiar}} and {{Skill}}). Wrestlers don't have a "boxless infobox" in their upper right corner, but we can do something for them that has the same appearance. You know, in writing this, it occurs to me that perhaps we should convert the "boxless infoboxes" into full fledged infoboxes - what do you think? This would really unify the look and feel. Also, it would solve the problem that we have with long item names writing over the "boxless infoboxes" (see sword behind inappropriate prepositions for an example). I'm sure that we could solve this problem another way, but, for several reasons, I like the infobox approach. --Gymnosophist 14:13, 9 November 2006 (CST)
              • I've begun the conversion for effects, and for now I've placed the metadata link in the "infobox" on the first line (instead of hotlinking it to the image). If it looks decent, we can probably do the same thing for items. --Quietust (t|c) 12:57, 18 November 2006 (CST)

Annoying Oddities with Data Pages: Push for a "Data:" Namespace

I think that we erred in using /data as the home for all data pages. We effectively broke the "Random page" link and search, by adding over 2000 entries of non-real pages. There are probably very complicated script workarounds that we could find, but the simplest method by far is to create a new namespace and move all of the pages once and for all. Any comments?--SomeStranger (t|c) 14:30, 26 November 2006 (CST)

  • That sounds good to me. --Starwed 14:45, 26 November 2006 (CST)
  • Though it is of course quite labor-intensive, I would greatly appreciate this change. --TheArchivist 14:52, 26 November 2006 (CST)
    • I'd assume that a bot could handle all the work. --Starwed 15:03, 26 November 2006 (CST)
      • My bot can easily handle the creation of new pages - it's deletion of the old ones that will be troublesome, since it'll require a bot with administrative privileges. It will also prevent users from creating metadata pages underneath their own user page, since it would bounce to a new namespace and not have a working "Back" link. --Quietust (t|c) 17:21, 26 November 2006 (CST)
      • Meta data pages have no use on user pages; we would never really need to take any autoupdating data off their pages anyways. How many user pages will currently be affected?--Dehstil (t|c) 17:36, 26 November 2006 (CST)
  • It's the cleanest way really.--Dehstil (t|c) 15:26, 26 November 2006 (CST)

Any progress on this? I'll have a lot more spare time over crimbo, so it would be nice to get started on Data:monster pages. Who actually has the power to make this happen, and have they given an opinion on it? --Starwed 09:51, 9 December 2006 (CST)

Okay. We have our Data namespace. So I figure now what needs to happen is we have to rewrite some templates to work with the new namespace and then run the bot again to create 2000 more pages on that new namespace. Luckily, the way we created the templates allows us to just alter item to point to the new pages... As far as the old pages go, we do have to delete them which would require either 1400 deletes by admin or giving the bot privileges and having it delete everything (a tad risky if not done carefully). On the brighter side of things, Data pages no longer show up in search unless you check the little "Data:" checkbox at the bottom of the page which means search functionality is no longer broken. Furthermore, "Random page" only turns up pages in the main namespace so the new Data pages will not be popping up every thirty seconds. --SomeStranger (t|c) 08:46, 6 January 2007 (CST)

Monster infoboxes

It might take a while to roll these out (it would be good to first fix issues which item and effects pages raise), but we should establish where the data is going to come from. On the wiki, much of it could be parsed from the location {{combat}} templates, but I'm hoping there is a better way. Is there a good, easily parseable source for monster data out there? --Starwed 15:28, 27 November 2006 (CST)

  • Chances are, parsing the data out of {{combat}} is the best you'll get. It shouldn't be too difficult to extract the information using a few regular expressions, either, as long as no {{combat}} instances include other templates within them. --Quietust (t|c) 15:51, 27 November 2006 (CST)
    • Actually I just found this Monster Guide in a previous comment by Gymnophist. Chances are the creator has a more nicely formatted version, but even if not its a good resource. We might need to combine this with the {{combat}} templates to get all the data we need, though. --Starwed 16:00, 27 November 2006 (CST)
    • Hi, for the Simulator of Loathing datafiles I parse Kittiwake's Monter Guide, Yiab's Parseable yadayadayada, and the HCO Initiative Guide to get synthesized values for all monsters. It would be very easy for me to make my script spit out any kind of parseable format. If you're interested please leave a note on my talk page, or kmail me (DirkDiggler), and let me know exactly how to format the output.
    • The fields I can provide are:
      • HP, Attack, Defense, XP (computed from Attack), Initiative: integers, -1 for unknown, "Scales" for scaling; (from Kittiwakes, except Initiative is from HCO Initiative guide)
      • Elemental attacks + frequencies (if any), elemental defense (if any), and physical immunity (from Kittiwake's)
      • Zone and Monster Frequency (from Yiab's)
      • Items dropped + drop rates (from Yiab's)

and if you recommend a data source I can pull that in as well.

I can do either tagged fields

 ghoul:hp=10,atk=19,def=19,init=35,eltatk1=(spooky,100%)

or structured fields, perhaps as a wiki-pipe table:

 ||monster           |hp   |atk  |def  |init  |eltatk1
 |-------------------
 ||ghoul             |10   |19   |19   |35    |spooky (100%)

or any desired mixture of the two. --DirkDiggler 19:15, 2 December 2006 (CST)

By the way, I also have enchantments for every item in the game, as well some other things (familiar action rate/range info, stuff like that) all in structured and parseable form -- see Parseable Equipment Statistics. I meant to only toss in items starting with 0-e but accidentally added 0-9A-Za-e; I'm not sure what the limits of good taste and database load are for a page, but I'm sure that the Parseable Equipment Statistics page pushes them. I'll upload the whole nut once I know how to do it safely and how to structure the data.--DirkDiggler 19:43, 2 December 2006 (CST)

  • If it's paresable data it doesn't have to look nice to regular viewers...if I were you I would just put a guide to the data on the talk page and don't format it like a table (Just use "|") to split things. There is no "real" limit on page size but if you go over 200kb you are really pushing it.--SomeStranger (t|c) 19:52, 2 December 2006 (CST)
    • Compare Parseable Equipment Statistics (Flat) and Parseable Equipment Statistics. They weigh in at about 75k and 100k respectively. They're equally easy to generate (the same script made both).--DirkDiggler 21:33, 2 December 2006 (CST)
    • I'd vote for the structured fields option. If (for some reason that's not ocurring to me right now) tagged fields are better, might as well use an XML format to make it super easy to transform. --Starwed 08:40, 4 December 2006 (CST)
      • The tagged field format would actually be the closest to what would be needed for the actual wiki data pages - just replace the commas with vertical bars and it'd only be a matter of wrapping the data in template blocks and doing a mass page creation. --Quietust (t|c) 09:01, 4 December 2006 (CST)
      • I'm still not totally clear on what is needed, but I put up the data I have in
      • Would you mind putting in a sample line showing **exactly** what format is desired for monsters, for equipment, and for effects?--DirkDiggler 16:10, 4 December 2006 (CST)

Any chance of reviving this project? I'd really like to get combats using data pages to populate the necessary information, an infobox in the corner for various stats, and the combat listings on location pages also using said data pages. Something similar for noncombats and choice adventures would be nice as well, though not required. --Quietust (t|c) 10:33, 27 March 2007 (CDT)

  • Is all the data we need at Parseable Monster Statistics? It looks fairly inclusive to me, although I suppose it might be out of date now. It seems like the course of action should first be to simply dump all that data (or an updated set) into data pages, using the same template style as used in locaton data pages. The only blockers I can think of are to make sure the data is actually correct and current, and to make sure the format of the data page is agreed upon.--Starwed 11:09, 27 March 2007 (CDT)
  • I'm happy to spin up a newer version of Parseable Monster Statistics... is there anything more or less that page should have? As mentioned, I also have limited info on noncombats taken from Subjunctive KoL's Adventure Spoilers. That's in much rougher shape though. --DirkDiggler 09:47, 29 March 2007 (CDT)
    • Actual element names for "eltdef" would be more useful than numbers (i.e. 1/2/3/4/5 -> hot/cold/spooky/stench/sleaze), as well as a relative frequency for adventures instead of absolute (e.g. for the current data for Hole in the Sky, the Astronomer would be "3" and everything else would be "2"). --Quietust (t|c) 10:01, 29 March 2007 (CDT)

Time to do some necromancy here. What's the chance of getting this started again? It'd be really nice to have things like monster HP on the actual monster page, instead of only on the adventure page like it currently is for most things. So I'd either like to see this restarted, or some more minor change to how monster pages are done to include an HP listing (I like the infobox idea, though, since it puts the info in a convenient format and position). --Flargen 21:53, 8 April 2008 (CDT)

It should be relatively easy for a bot to at least move the information on each location page onto data pages. There's some spading starting again on monster stats, so once that's done we can add in defense values as well. Note that some monsters actually have this already. So if you want to see what it looks like on the page, check out Orcish Frat Boy (Pledge), for instance. --Starwed 23:52, 8 April 2008 (CDT)