Discussion/archive7

From TheKolWiki
Jump to: navigation, search
Discussion Archives
1  · 2  · 3  · 4  · 5  · 6  · 7  · 8
9  · 10  · 11  · 12  · 13  · 14  · 15


Enhancing the 'Uses' section (crafting)

Hi, I'm fairly new to (editing) the wiki, and was just making a suggestion here. Perhaps, instead of simply listing all the possible things something could be crafted into, possibly dividing them up based on category, such as Cooking, Cocktailcrafting, or whatnot. Take, for example the Tomato - instead of simply listing:

perhaps they can be broken up:

Cocktailcrafting:

Cooking:

Obviously there should be some amount of effort made to make it aesthetic. Perhaps even making it a horizontal table/spreadsheet, to preserve space. Also, a way to mark off what requires special skills (pastamastery, saucecrafting, etc.) might be prudent. Obviously, this would also take a lot of time to rework so many item pages. What do you guys think?

--Naturefreak2101 22:53, 21 February 2009 (UTC)

'Historical' Tag

I'd like to suggest a template for pages about old content. Is there any way we could put a notice at the top of pages that lets readers know at a glance if the item or adventure is obtainable? For example, it is not immediately obvious when reading, say, the Rainbow pearl earring page that the item has been discontinued. Something like...

---Note: This item is no longer available in-game. It can only be found in the Mall at great cost.---

--Darz 19:59, 13 January 2009 (UTC)

Observations and Questions from a Gnewbie

There seems to be lots of bizarre information on almost every page that serves no clear purpose. Other pages could be condensed to be more useful.

  1. Why do item pages list the "plural?" Who cares?
  2. Why do item pages have the top 10 collections at the bottom? Who, besides the people on the list, cares?
  3. Why can't the larval and adult forms of a familiar be on the same page?
  4. On usable items that give a named effect with a duration, could we embed the basics of that effect on the item page? (Example, the Angry Farmer Candy page would tell me what Sugar Rush does, instead of having to click on the link)
  5. Unique items should be removed from comparison tables. Knowing that So-and-So's custom item gives a great bonus to Moxie doesn't help anyone.

--Darz 19:15, 18 December 2008 (UTC)

  1. Because this data exists in-game. Ergo, it belongs on the wiki.
  2. People who want to be on the list. It's also kind of neat that such a database exists. Furthermore, the game has records boards that list just such top 10 collections. So, again, this information belongs on the wiki. And it's really not feasible to stick every last item collection on a separate page; best to just stick it with the relevant item.
  3. Unnecessary clutter. Makes it harder to find the information you want. The pages link to each other, as well.
  4. Eh, well, maybe. It's currently not the wiki policy to do so, with only a few exceptions of "related effects" from "related items". It's a matter that can always be put up for discussion.
  5. What do you mean by "comparison tables"? And this is a holdover from the previous Dressing for Success model, wherein there was a "Deity" class that had access to every item in the game, even custom ones, for purposes of listing the absolute maximum obtainable in something.
    --Flargen 19:23, 18 December 2008 (UTC)

Thanks for the response.

  1. Fair enough.
  2. It certainly doesn't hurt anything.
  3. I would argue that having two pages for the same thing is unnecessary clutter. Obviously the GAME makes a distinction between a "blood-faced volleyball" and a "Blood-Faced Volleyball" but most players probably don't.
  4. I really think it would be helpful, and make things more streamlined. Where can I officially suggest this?
  5. Pages such as Moxie Modifiers. 13 of the top 25 modifiers are impossible for anyone to get. For practical purposes, those items don't exist. They should have pages on the wiki, for sure, but they should not be included in lists like this.

--Darz 19:35, 18 December 2008 (UTC)

  • About your last point, Moxie Modifiers is the comprehensive list. The practical list is Maximizing Your Moxie. --Itsatrap 19:43, 18 December 2008 (UTC)
  • (3) First time I've heard anyone complain about that. From that, I'd argue that most players do make that distinction. (4) has been suggested at least once before, and has merit. I don't much like the hovertext idea on that thread, as it loses a whole whack of formatting and has issues with how long the text stays visible if there's a lot to digest. Probably, {{acquireEffect}} could be modified to read in formatted effect info from effect data pages and replicate it on both the effect page and the item page. My personal preference would be to keep the two separate for reasons of clutter. When I look for an effect, I'm aiming to modify something, and I look on the mechanics lists to do that. Having it on the item page doesn't do anything for me--click once, oh whee, that's what it does, never click the link again. On (5), I am dead set against it. It makes it harder to figure out what's missing and belongs on the page if we filter certain classes of items out; more effort than to remember than "Oh, I can't get this." Besides, where do we draw the line? Most folks aren't ever going to have ultra-rares, nor are they going to spend millions of Meat on rare single-use potions; by no means should we leave them off the page. As Itsatrap pointed out above, the community is working, ever so slowly, on a practical guide to maximisation. --BagatelleT/C 02:49, 19 December 2008 (UTC)

3). While I agree with them being split into 2 pages, I think the Familiar Hatchling pages should make it clearer what they turn in to. I mean, the Familiar pages have a neat bold heading at the top of the page:
Hatchling: (Pic) Wibble Wobble Egg.
However, the Hatchling page has a fairly inconspicuous entry buried in the Notes section at the bottom of the page:
Becomes a Wibble Wobble.
I vote the Hatchling pages should have an equally conspicuous heading at the top of the page such as:
Familiar: (Pic) Becomes a Wibble Wobble.
--Urutsini 11:16, 28 May 2009 (UTC)


Compacting Item Sources

Currently, drop locations are being (slowly (but surely)) reformatted to include monster and noncombat names. For instance, the soft green echo eyedrop antidote:

The Penultimate Fantasy Airship
Irritating Series of Random Encounters
Quiet Healer

Beautiful! However, a few sections down, we have, all by its lonesome:

Now, we have the information for obtaining this item split between two sections, with one big section between them. I propose, in the interest of compatcing similar information for ease of use, pulling item-obtaining notes into the Obtained From section. For example:

The Penultimate Fantasy Airship
Irritating Series of Random Encounters
Quiet Healer
Using a Penultimate Fantasy chest

--TechSmurf 12:46, 21 May 2008 (CDT)

  • You've got my vote. --Quietust (t|c) 17:06, 21 May 2008 (CDT)
  • Nifty. How should we handle things with multiple "other" drop methods, like recipes, stores, etc? Is it time to mirror Effects, and use ==Obtained From==, perhaps with subsections like monster/non-combat/recipe/shop/other? --Bagatelle 17:38, 21 May 2008 (CDT)
    • Hmm. I didn't think of those... Well, let's see. To use the mockup I've been working with...
The Penultimate Fantasy Airship
Irritating Series of Random Encounters
Quiet Healer
Using a Penultimate Fantasy chest
Purchase from The Market for 4000 Meat
Casting soft green echo eyedrop antidote summoning

As for recipes, I'm not sure how to integrate them. Also, this may look cluttered, but keep in mind that no item (that I can think of) is obtained from more than a few sources. Also also, it might be wise to change the section title over to Obtained From. Also also also, a second example:

Cobb's Knob Kitchens
Knob Goblin Chef
Degrassi Knoll
Gnollish Piebaker
Tower Ruins
Bread Golem
Yeast Beast (2)
Guano Junction
doughbat
Purchase from The Bugbear Bakery (50 Meat)
Using a Knob Kitchen grab-bag (1-5)
Using all-purpose flower (35-45)
Using an unrolling pin with flat dough in inventory

--TechSmurf 19:08, 30 May 2008 (CDT)

  • You forgot one :) --Quietust (t|c) 19:13, 30 May 2008 (CDT)
Using a flat dough (1)
  • OK, I can get behind this. So list all obtain methods under Obtained From, list recipes separately in their own section as is currently the case. A couple of "obtain methods" we haven't been listing are untinkering (should we list it when it's usually obvious from the pasting component field and the uses section?) and really weird obtain methods like Summon Mayfly Swarm (which haven't been listed on monster/location pages--should we? Kind of feels like a "global mechanic" rather than a location-/monster-specific one to me.). --Bagatelle 15:21, 31 May 2008 (CDT)
  • I'd rather the "Using..."/"Purchase.."/etc. part of the text not be bolded. The bold black text just looks weird to me. Bold blue for the links is fine, but not the black. And I don't think we should bother with things untinkering, unless it is the only way to get the item (like a tisket). I don't like having the rolling/unrolling pins either, but at least those particular things only go on a single page. --Flargen 15:28, 31 May 2008 (CDT)
    • Agreed about the untinkering-- a note on the category page for meatpasting is sufficent, except where untinkering is the only souce of the items. I was trying to think of a way to integrate recipes, but if Bag's fine with leaving them as they are, I am too. For now, I'm undecided about things like the Mayfly swarm. As for the formatting (and the bolding), I haven't fiddled with lists long enough to know how they work-- no internet at home for the time being. --TechSmurf 16:07, 31 May 2008 (CDT)

A little late to this discussion, but I think I'd prefer to follow a consistant format for items obtained via stores,usable items etc...:

Cobb's Knob Kitchens
Knob Goblin Chef
Tower Ruins
Bread Golem
Yeast Beast (2)
NPC Stores
The Bugbear Bakery (50 Meat)
Usable Items
Knob Kitchen grab-bag (1-5)
all-purpose flower (35-45)
flat dough (1)

--Starwed 15:47, 7 June 2008 (CDT)

  • OK, so how about:
Obtained From
Location 1 (pre-/post-quest note as necessary)
Combat Adventure (blank or number in parentheses) (conditions like semi-rare, one-time, clover, other mechanic required)
Non-Combat Adventure (ditto)
Location 2
...
Buy/Reward
Store (X Meat)
Quest (quest condition, e.g., done as Frat/Hippy)
Use
Skill (min [may be zero]-max)
Item (ditto)
Weird Mechanic Jick Pulled Out of His Donkey or Donkey-Analogue (otherwise known as "Other")
Page summarising said weird mechanic (e.g., Summon Mayfly Swarm)
Recipe

...

(Funky divs to prevent headings from appearing in the TOC.) --Bagatelle 16:15, 7 June 2008 (CDT)

  • Resurrect'd! I like the way you broke it up-- might want to split up Buy/Reward, though. Still mulling over it. As we're all in agreement in regards to going forward with the idea, we just need to bang out a final format. I'll put one together tonight, and once we get it squared away, I say we go full speed ahead with this one. --[TechSmurf][T][C] 11:27, 5 September 2008 (CDT)
    • So. Making a few things up for example purposes...
Batrat and Ratbat Burrow
How Does He Smell?
Cobb's Knob Kitchens
Knob Goblin Chef
Degrassi Knoll
Gnollish Piebaker
Tower Ruins
Bread Golem
Yeast Beast (2)
Guano Junction
doughbat
Items
all-purpose flower (35-45)
Knob Kitchen grab-bag (0-5)
unrolling pin (with flat dough)
Stores
The Bugbear Bakery, 50 Meat
Skills
Advanced Doughcrafting (Without The Way of the Dough (3/Day)
Advanced Doughcrafting (With The Way of the Dough (5/Day)
Quests
Typical Tavern Quest (as a Disco Bandit) (5)
The Ultimate Loaf Quest (200)
Other
Casting Summon Mayfly Swarm against a Yeast Beast

I think that should cover all (or most, at any rate) possible obtain methods. Anything beyond the location/item/store/skill/quest classification should fall into "other". Recipe should stay right below the Obtained From section, unless someone can think of a smooth way to integrate that into this whole setup. So. Any further tweaking needed? --[TechSmurf][T][C] 00:06, 6 September 2008 (CDT)

  • Looks good. I'd like to bring up one point I made earlier about obsolete items/drop locations. Do we want to treat these differently? Black paisley oyster egg is currently one big mass of bold text with unclear line break locations. Zombie pineal gland isn't "obviously" undroppable unless you scroll down and read the notes. Three options off the top of my head: leave them as they are currently, put into the Notes/History sections, create an Obsolete subsection for the drop location. --Bagatelle 11:36, 7 September 2008 (CDT)
    • Top-of-my-head solution: Add an Obsolete Areas/Methods section-- to reuse the wad of dough we've been so fond of--
Batrat and Ratbat Burrow
How Does He Smell?
Cobb's Knob Kitchens
Knob Goblin Chef
Halloween
Wad Queen (Occurs with Dough Outfit equipped)
El Dia de Los Muertos Borrachos
La What Is Spanish for Wad (When level 1-4)
Ancient Yuletide Dough
disintegrating sheet music
Effect
Drops while in Form of...Baker!
Items
all-purpose flower (35-45)
Punchcards
Instructing a dough construct to KNEAD DOUGH
Stores
The Bugbear Bakery (50 Meat)
Skills
Advanced Doughcrafting (Without The Way of the Dough 3/Day)
Advanced Doughcrafting (With The Way of the Dough 5/Day)
Pulverize
full list of items
Quests
Typical Tavern Quest (as a Disco Bandit) (5)
The Ultimate Loaf Quest (200)
Summoning Chamber
Dough Demon
The Cake-Shaped Arena
Every 10th win with a Wad of Dough that Also Acts as a Familiar equipped (Sometimes)
Gifts
Short explanation
Custom Items
Short explanation
Ascension Reward
Class/Path restrictions
Other
Casting Summon Mayfly Swarm against a Yeast Beast
Obsoleted Areas/Methods
The Haunted Gallery
empty suit of dough
Items
sober pill (3)

Now, that should cover everything. I hope. Unless anyone can think of anything else, I'mma start converting pages soon. Verily. --TechSmurf 22:42, 7 September 2008 (CDT)

  • Here... We... Go! --TechSmurf 23:04, 8 September 2008 (CDT)
    • What, we're not going to wait for Coolguy to do all 3000+ items himself? Also, are we going to list pulverize sources? --Bagatelle 02:38, 11 September 2008 (UTC)
    • Edited prototype above to consolidate and match specifications actually being applied by editors... Previous revision is here. --Bagatelle 00:44, 12 September 2008 (UTC)
      • Edited again. Er, at this point, the "Other" section looks increasingly redundant. --Bagatelle 17:14, 13 September 2008 (UTC)
        • Too many sections? Too few? --Bagatelle 03:53, 21 September 2008 (UTC)
          • I knew I forgot one... the Pulverize lists are manageable for the elemental ones (for now...), but for the twinklies, it's... nutty long (e.g., twinkly wad). Should full lists be encouraged, or do we just want to redirect people to the equipment by power/requirement lists where the list is long? --Bagatelle 16:09, 21 September 2008 (UTC)
            • It is kind of large. But I like having the full list of sources. Is there any way to have collapse-able sections, so the list could be hidden by default and expanded if desired? Otherwise another page makes sense, at least for twinklies. --Fig bucket 18:48, 21 September 2008 (UTC)
              • Or, maybe we can add two extra columns (Pulverize Yield (wad.nugget.powder); Pulverize Type [elements]) to some of the equipment list tables, and have the Obtained From section link there. In this case, there wouldn't be any need to maintain the separate twinkly/nugget/wad pages, as adding items to the equipment lists would automatically nudge the editor to input the yields. The yield pages would be nice and short, and the equipment list pages are vertically long anyway. Oddly enough, there used to be a fairly large yield table on the Pulverize article, but it got nuked 'cause it was so long... --Bagatelle 02:28, 23 September 2008 (UTC)
  • Barring any other changes, I'll put these into the Established Standards shortly. --TechSmurf 01:01, 13 September 2008 (UTC)
  • The only thing I don't care for is that word "obsolete" again. It has a negative junk connotation to me, I fell like it is insulting the old methods/items. How about instead of "Obsoleted Areas/Methods", any of the following: "Unavailable Areas/Methods" or "Removed Areas/Methods" or "Former Areas/Methods" or "Past Areas/Methods"? I think I personally like "Unavailable" or "Former" the best, but anything is better than useless, I mean obsolete ;-) --JRSiebz (☎|§|‡) 01:20, 13 September 2008 (UTC)
    • "Former" maybe? I keep repeating them aloud like a crazy person. ;-) --JRSiebz (☎|§|‡) 01:22, 13 September 2008 (UTC)
    • I don't think it really matters--we've got an entire category devoted to Obsolete Adventures, and various location indices have a section for retired content. On the other hand, "Former" is certainly much less of a handful to type or scan. --Bagatelle 17:14, 13 September 2008 (UTC)
    • I whined about the word "obsolete" there too! Heh! --JRSiebz (☎|§|‡) 06:58, 14 September 2008 (UTC)
      • Whoops. I've got no opinion on it either way-- "Obsoleted" was just the first thing that came to mind. Former works for me, sure. --TechSmurf 16:25, 14 September 2008 (UTC)
  • After seeing this in action - and yeah, I know I'm late to this particular party - one thing that seems to be missing in the obsoleted availability sections is some indication of when the item was available through that method. For example, Mr. Store familiars list the place and the cost, but don't say when the hatchling was available - that info is only found in the Notes section which is presumably meant to be removed when the info is transferred to the Obtained From section. --GalenKemensen 22:05, 26 September 2008 (UTC)

Considering the trend, I'd like to push for having the drop rate listed after the monster that drops an item. Not having to go to each individual monster's page is less inconvenient. For example, stealing from the example at the top: soft green echo eyedrop antidote:

The Penultimate Fantasy Airship
Irritating Series of Random Encounters (21.2%)
Quiet Healer (29.6%)

Is this possible? --Blzbob 21:58, 18 April 2009 (UTC)

  • Could it be done? Yes, they're just numbers. I'm not so thrilled with the idea of it actually being done, though. Starting to feel like clutter. Especially when you consider that some items drop up to 4 times from a single monster. --Flargen 00:14, 19 April 2009 (UTC)


Monster data pages

As monster data pages have been added, they're using the convention for Defense set by QNM in the AFH forums. This isn't the same as used elsewhere on the wiki. Briefly:

  • Before NS13, the typical monster had defense=attack.
  • After NS13, monster defense was reduced by 90% across the board. Further more, +ML effects now increase defense by 90% of the ML increase.

From what I see, the "QNM convention" is to use the original value as defense, and put the factor of 90% into the damage/hit formulas. (This makes sense, considering how ML works.) But it's at variance with the currently accepted definition of defense used on the wiki, and I don't think this has been discussed. Personally I don't care much one way or the other; AFAICT, it's just an issue of what convention to use. So, thoughts? (Or corrections, if I've misunderstood something.) --Starwed 14:12, 22 May 2008 (CDT)

Originally, I started adding both the core defense and variable defense values into the data pages, because I feel both of them are useful. However, it was decided on my talk page that we should only add in the core defense values for 2 reasons; one is that we can change the template to automatically produce the correct result at +0 ML or even a range of values without having to fill the data pages with more numbers, and also because if the formula ever changes, we won't need to re-do every single monster page again.
To be honest, discussing this stuff on my talk page only was probably a bad idea, but oh well. --Melon 14:31, 22 May 2008 (CDT)
I'm not talking about static vs. variable, but how we define monster defense on this wiki. Whatever goes in that data field should be consistent with how the word Defense is used elsewhere.--Starwed 15:34, 22 May 2008 (CDT)
It would be more helpful to end-users to have the base value recorded, so they don't have to do the nuisance 0.9 conversion. I haven't really been keeping up with the Monster Stats project, but my understanding is that MD isn't always 90% of MA, and the two have a small independent variance. For these reasons, I think putting the actual base value in would be most useful. --Bagatelle 16:15, 7 June 2008 (CDT)
  • I'm coming very late to this party. On the AFH page, I record the base attack and defence value for most monsters. This base defence needs to be multiplied by 90% to get the actual defence you will find. For example: Hellions have a base defence of 52. That means their actual defence is 47, and their safe moxie value is 54. If you want to get very accurate, base defence varies from 45-49 and so safe moxie is really 56. This currently isn't being calculated properly by the wiki templates, which looks at the base defence of 52 and calculates a safe moxie of 59.

Why make it complicated and not include the 90% factor in base defence? Because as Starwed pointed out, that's how ML works. Defence = ceiling[(Base_Defence + ML_Mods)*0.9].

I don't much care how the wiki displays this information, as long as it is changed to something accurate.-QuantumNightmare 21:39, 7 September 2008 (CDT)

Was this ever resolved in any fashion? Currently, the "coded" (Base Defence) value is what's stored on the data pages; however, the Hit Chance and Weapon Damage pages (both of which are a little out of date anyway, in particular crits on the Hit Chance page) just use 'Monster Defence', so the ceiling(X*0.9) part of the formula isn't mentioned anywhere (besides the Monster Level page, which is hardly intuitive). This means that most users are just getting the wrong numbers. I think the box should show the 'apparent' defense as Defense; for the majority of users, that's the number they want to see ("If my Muscle beats this number, I will usually hit"). And there's plenty of room in the infobox to display (Base: X) immediately to the right of it. The data pages can still simply contain the base defense value, since it's trivial to calculate the actual defense from it. So the only thing that would need updating would be the infobox template.--Salien 20:08, 20 January 2009 (UTC)

  • No, never really resolved. The matter would probably be a lot easier to come to a fix/agreement on if the wiki had enough parsing capabilities to dynamically multiply and floor/ceiling things. It'd certainly make it nice for using {{meat}} on monster pages, since then you could add functionality for just specifying the average and the template would automatically spit out the range, average, and standard deviation for the monster. As is, I don't think the wiki has any such capabilities, and hence why it's essentially impossible to have a nice way of encapsulating mechanics like this. --Flargen 01:01, 21 January 2009 (UTC)
  • Well, technically, #expr is supposed to be able to modify with CEIL, FLOOR, etc, but it keeps bouncing bugs when I try it in preview. I can only assume the ParserFunctions extension installed here is wonky, 'cause it works on the big WP. However, I think CEIL can be faked using
    {{#ifexpr:0.9*defense = {{#expr:0.9*defense round 0}}|{{#expr:0.9*defense}}|{{#expr:0.9*defense + 0.5 round 0}}}}
if I understand how rounding works on this Wiki. I.e., if 0.9 of the base defence is a whole number, use it, else add 0.5 and round to the nearest one. Kinda clunky, but I think the math works out. Also, holy Jick, I hate template syntax. --BagatelleT/C 04:47, 21 January 2009 (UTC)
  • Huh, sweet. Where do you learn about these parsing functions, anyway? And, yes, that should work perfectly. And you shouldn't really ever be able to see a value ending in .5 after multiplying it by .9, at least not for anything one would expect us to be using it for. That requires a non-terminating decimal number (it's rational, of course, but in any case it definitely doesn't come from an integer). --Flargen 05:23, 21 January 2009 (UTC)
  • Teh maths and teh google are my frens an I have no life T.T --BagatelleT/C 05:35, 21 January 2009 (UTC)
    • Well, I went ahead and implemented a {{ceiling}} and {{floor}} function, so the resolution of this defense issue should essentially just now be up to getting an admin to modify the relevant locked templates to calculate apparent defense from the coded defense (stored in the data page). And I implemented the ability to quickly calculate monster meat drop statistics to {{meat}}. Although in the process I discovered the wiki's parsers also can't handle powers, so I went with a variance instead of standard deviation. We'll hopefully be able to phase both that and even the average out from monster drop ranges, once someone gets around to pointing out on some appropriate page or another that the distributions are all triangular (which is much more useful and complete information). --Flargen 07:30, 21 January 2009 (UTC)
      • Wow, quite a flurry of fast and awesome responses. :) So... How do we request an admin to update the template? Just pick one and leave a note on their talk page? It looks like SomeStranger was the last to do anything to that template, but Quietust and Starwed were doing the bulk of the work on it...--Salien 21:47, 21 January 2009 (UTC)
        • Well, there's the rub. Getting an admin to change a locked page can be a difficult task. I recommend the sacrifice of a few chickens, a deal with the devil, and at least 4 bowls of ice cream. I'm not sure if I'm technically allowed to advocate endlessly pestering them until you get some sort of productive response. But I know it doesn't always work. And sometimes, even when an admin hops on board, nothing happens. --Flargen 00:22, 22 January 2009 (UTC)

Duplicated Content

quests and locations

In the past, others have noted that many of the Location/Quest pages are practically 100% duplicates of each other (cf. The Lighthouse Keeper/Recover the Lighthouse Keeper's Gunpowder, Gnorbert, the Elder Gnomad/Going Postal, Talk to the Deep Fat Friars/Deep Fat Friars' Gate Quest; contrast with The L33t Tr4pz0r's C4b1n/Mt. McLargeHuge Quest). Would anyone object to deleting quest text/results from Location pages? --Bagatelle 16:15, 7 June 2008 (CDT)

The problem with the keeper in particular is that there's very little content that isn't specifically related to the sidequest. A while ago I fixed a similar issue with Yossarian in the junkyard, although right now there is now page for "just" Yossarian (they all go to the quest page). Deleting quest details from location pages would seem appropriate. But that means we'll have to delete most of the content from pages like Olaf the Janitor, who is like Yossarian in that he's little more than a quest vehicle.. --Flargen 16:45, 7 June 2008 (CDT)
I think bare location pages are fine, it's just the nature of the beast. But but duplication duplication is is bad bad. --Bagatelle 20:29, 13 June 2008 (CDT)

familiars

We've got lots of familiar clones (many familiars use the volleyball formula, for example), and once /dev introduces another one, it triggers required updates on lots of pages. For example, when a new volleyball gets added, Hardcore Familiar Analysis, Stat Gains from Fights, several familiar index pages, and probably no small number of places on the strategy pages ought to be updated, but aren't. How can we best make this easy to update and to navigate? Footer templates (possible bloating of the footer area with hybrid familiars)? Explicitly list everything that acts like X on X's article? Create a template that substitutes similar types (e.g., {{volleytype}} to place a regular text list of all things acting like volleyballs). Other? --Bagatelle 16:15, 7 June 2008 (CDT)

I'd kind of like to see the imitators categorized. "Volleyball Familiars", "Fairy Familiars", "Hybrid Familiars", "Volleychaun" (maybe), that sort of thing. Might have to have a subcategory in some of those for things that normally act at half weight, like the WAF and PBS (which can conditionally be made better, but are effectively half-weight by default). Volleyballs/sombreros could perhaps be a subcategory of "Stat Gain Familiars", since there are a few familiars that give stats in other ways. Won't fix all of these issues, but using categories should help us cut down on the excessive and ever-growing lists for familiar analyses. Or maybe I'm just in a category-happy mood of late. --Flargen 19:08, 8 June 2008 (CDT)
I don't know, if we categorise, say, volleychauns, that would currently be a four-member category. Seems kind of bare to me. And then when linking familiar lists, typing [[:Category:xyz|xyz]] is such a handful. --Bagatelle 20:29, 13 June 2008 (CDT)
The category link would be easier than typing out [[Cymbal-playing Monkey]]/[[Attention-Deficit Demon]]/[[Nervous Tick]]/[[Hunchbacked Minion]] though. Which is what the analysis pages currently do. It certainly is a small category (which is why I said "maybe"), but it does make this particular issue easier to deal with. I'm not sure if a template would really work, since you might want a list to be formatted slightly differently depending on the situation. You could desire an ordered, or unordered, or comma-separated, or backslash-separated list et al. You could probably code a parameter into the template to allow for various formats, I guess. And, as with the animated familiars thing below, it would at least be self-updating, assuming the familiar page is correctly categorized. --Flargen 20:59, 13 June 2008 (CDT)

The animated familiars seem to have the fact that they're animated noted (e.g., Attention-Deficit Demon#Notes). This has the potential to get out of hand. Shall we add a category/page for animated images (familiars + monsters + items), for those interested in such things? --Bagatelle 16:15, 7 June 2008 (CDT)

A category sounds like a good solution. Unobtrusive, self-updating, and since animated things are usually noteworthy it would seem like a justified category. --Flargen 16:45, 7 June 2008 (CDT)
Ah, yes, auto-updated, I like. --Bagatelle 20:29, 13 June 2008 (CDT)


Dressing For Success

This has already been brought up on the DFS talk page (and a few of the maximizing talk pages), but I felt I'd bring it up here in hopes a few more people might chime in. That thing being: currently the standards for the Maximizing pages set the allowable stats at 150, which may now need to be increased. Now that Hobopolis and the El Vibrato content are out, we now have a lot of items that require stats higher than this, some of which are very useful for Maximizing various things. We need to have some assumed stat level, so that the stat pages can correctly calculate the effect of percentile boosters. The current value of 150 (and the value of 100 before that), were based upon (roughly) the main stat needed to fight the NS. Now that there's a reasonable amount of content only available after that point (I don't think anything required a stat beyond the 80's before El Vibrato and Hobopolis), it seems time to update the stat standards. What does everyone else think? Any other thoughts you might have on how to format and construct these pages would also be useful. Of particular concern is that the meat limits may need reworking, thanks in part to the recent inflation (and the general fact that the best items will inflate regardless). --Flargen 18:55, 6 July 2008 (CDT)

Totally unrelated to the above, but seeing as there's an appropriate title on this page I thought I'd add this here. I'm mentioning this on this page in the hopes that more people will take notice. Anyway, the Dressing for Success rewrite discussion has gone on long enough and doesn't seem to be going anywhere anymore, so does anyone mind if I crack on with it? I should have plenty of free time tomorrow. Basically, I'm going to completely rewrite the main page, then go about adding in the funky tables to some of the other pages (and will have to finish the rest off later). Some details still haven't been sorted out, but we can sort that later and finally remove that damn banner from the main page. P.S. If anyone here is good at making an appropriate template for the pages I won't get round to updating immediately, one would be great to have thanks. --Melon 20:15, 14 October 2008 (UTC)

  • Yeah, it's too bad discussion has died down. I'd prefer to have the other issues settled first, so we can do everything in one go. Given how stagnated things have gotten, I think the best way to proceed would be either to do a slew of work like you're proposing, or to edit {{ANNOUNCE Discussion}} to say we're moving onto Step 2: ??? to garner more comments. What do you mean by templates? The pages are all tables, so I don't see how templates would make things easier. Or do you want to write repetitive code, like the legend, just once? In that case you can use Stone sphere When Used section or {{Improved booze}} as a model. --BagatelleT/C 22:40, 14 October 2008 (UTC)
    • I actually meant something like the Needs Work or Needs Content things that you put at the top of the page, but more awesome :p . It's totally unnecessary, of course. Actually, now that you mention it, making the legend into a template would be a good idea, but I'm sure I can figure out how to do it. --Melon 22:52, 14 October 2008 (UTC)

Wiki Discussion Points Announcement Template

As an aside to Flargen's comments above, would anyone object to having an announcement template to flag current Wiki policy discussions/large-scale tasks on the main page, when there are no holiday/IotM announcements? I realise we already have places to discuss projects and standards (the current page, duh), but talk has a tendency to stagnate here. Perhaps if important discussion points were given more prominence, more people would keep an eye on it and make it easier to gather consensus and move forward with work (e.g., poor Coolguy doing a solo 3000-page Wiki item page run, or TechSmurf's neat suggestion to compact item sources which has languished). Also notice how I cleverly phrased my question "would anyone object..." so if no one responds I can do whatever the Jick I want yeah, that's the ticket. --Bagatelle 20:38, 6 July 2008 (CDT)

  • It's aliiiiiive. --Bagatelle 13:25, 13 July 2008 (CDT)
    • I didn't notice when you first posted this idea (whups), but I am 100% totally cool with it. Good way to get projects more into the public eye. --TechSmurf 13:29, 13 July 2008 (CDT)

Prismatic Damage Template

Prismatic Damage seems to be one of Jick's new favorite things. Perhaps we should update the element template to include Prismatic damage, too? I'm imagining something like:

Yes? No? Not enough yet to warrant it? --TechSmurf 02:33, 16 July 2008 (CDT)

  • I would definitely go for it. Seems like a good idea. Plus it looks really cool. The key would be to have an easy link to a page that describes prismatic damage, since its a lot less common and many people may not know what it is. Thedufer 10:20, 1 August 2008 (CDT)


Advanced Farming Page

I'm working on updating this page (see the discussion page for it) but have run into a problem. How do we deal with a familiar weight increaser, given that it no longer is a linear increase of meat drops? Each familiar weight increaser is less effective than the previous, so we have to make some assumption about the starting weight of the familiar, I imagine. Ideas? Thedufer 21:06, 28 July 2008 (CDT)

I'm not a notable individual around here, but it seems to me that anyone farming at all is going to have a 20-lb familiar and its +5 equipment. So for things to be effective in determining relative bonus, you need to start from there. And, considering that it's the Advanced Farming page, it might be safe to assume that the player has Amphibian Sympathy and is buffed with Empathy of the Newt. --Irregular 18:09, 5 August 2008 (CDT)
Those assumptions are probably valid, but the problem is that we are separately evaluating each item/effect/etc. So we need a weight to assume each one starts at to get a rough estimate of the gains it gives. Like, say, pretend each effect is acting on a 30 (maybe 35?) pound familiar and evaluate cost-effectiveness based on that. I'm sure this will/has come up on wrt other optimization-type pages.Thedufer 20:52, 7 August 2008 (CDT)

Inline templates

Like how Wikipedia has citation needed, and such. I suggest:

"testing needed"
"changed?"

I guess that's it. It's for the long pages, like Advanced Hobopolis Mechanics, where there's a lot of text and we might want to pinpoint the places which need checking, and to alert the readers that some data might not be correct.

Or we can start putting "Needs Content" in sections as well as articles. Thoughts? --Raijinili 21:32, 2 August 2008 (CDT)

  • We do have a {{NeedsReview}} template for references, at least. --Flargen 21:36, 2 August 2008 (CDT)

Hatrack effects on individual hat pages

Not sure if this has been discussed already, but I thought it might be useful to have the hatrack effects on the individual pages for each hat. I'm sure it's not that uncommon for a player to obtain a hat and immediately look it up on the wiki. Perhaps a template would be in order. Thoughts? --Pantsless 22:45, 5 August 2008 (CDT)

  • I think this came up when the Hatrack first came out, but... Eh. Not really necessary. There's a full list of hats and effects already on the Hatrack page-- putting them all on the item pages would just be redundant and unwieldy. --TechSmurf 23:22, 5 August 2008 (CDT)

Subcategories of Combat Skills

Any support for the five 30MP and five 120MP Hobo skills having their own two categories, which would also be a subcategory of Hobopolis skills? --Raijinili 18:35, 9 August 2008 (CDT)

Item usage summary

  • over at Ol' Scratch's salad fork there's some debate about whether the most important information about an item should be summarised in its own section, separate from the notes. for the fork a summary of the adventures gained from food.
  • i'd have to say that i'd be against this. a notes section is enough, and the notes can be structured to have the important ones first. --Evilkolbot 03:10, 17 August 2008 (CDT)
    • I agree. Are people really that lazy that they won't scroll down a bit to see if they can find more information on what the thing does? I can certainly understand the desire to have "important" notes be readily accessible. However, it is often the case that entries in the notes section are nonsense without having certain sections preceeding the Notes section. And even those that can be made sensible will probably require some awkward rewriting in a number of cases. I don't like the idea of effectively splitting the notes section into multiple parts, either. So I say keep the notes together; the "notes" section itself makes the information readily accessible. --Flargen 03:45, 17 August 2008 (CDT)
      • If the most important information about an item were summarized in its own section, then we would have to have a new section for a lot of game-related notes for each item. (which means going through every item again to create new sections for them) Established Standards: Item Pages is very clear: you put sections in the order listed and you put things under the right section. In any case, the attempt to change the standards for that page were undiscussed. --CG1:t,c,e 07:28, 17 August 2008 (CDT)
        • I'm not asking you to change your standards in general. However, I don't see the problem with making exceptions for certain pages. The fork and mug pages, for instance, are primary candidates for this. Why should every page follow the same formatting in cases where that formatting is less than helpful?--DarthDud 14:04, 17 August 2008 (CDT)
    • I'd agree mostly, although a similar point was brought up at #Effects and Game Messages. Having a single section is not at all bad in the fork case, but some longer pages (e.g., Crimbo P. R. E. S. S. I. E. (familiar)), one has to scroll back and forth to get specific information. TechSmurf's on-the-fly solution there was to put the information right in the bullet intro. It gets even worse for the references on Comma Chameleon; luckily we don't care about references (delete delete delete). --Bagatelle 10:32, 17 August 2008 (CDT)

Quick Question

Question. I know that you can link an item using this

listItem|Uranium Omega of Temperance

Is there a way to link it where ONLY the artwork is used without the words? I'm not sure if that's been done. Wanting to work on a table but only want to use art to try to save space instead of all the words. (not doing it with the medals, just used that as an example.)--Ashallond 22:11, 18 August 2008 (CDT)

  • {{click|link=Uranium Omega of Temperance|image=Fmedomega.gif}} --[TechSmurf][T][C] 22:15, 18 August 2008 (CDT)
    • Of course, if you do it that way, you have to manually specify the image filename. A custom template could automatically fetch the image from the data page, though I question how useful such a template would be in the long run... --Quietust (t|c) 23:21, 18 August 2008 (CDT)
      • Modify the click template to have an optional field-- |item. If item is filled in and the other fields are omitted, it pulls the image from the metadata. Though that might be an overly-convoluted solution to the idea. --[TechSmurf][T][C] 23:46, 18 August 2008 (CDT)
      • Well it'd be helpful for tables when youa re trying to keep track of sets and things. a nice visual set of everything that still would link to the item page. I can do the weird workaround as Tech posted, but a template would be nice to have as an option. Not that Tech's second comment made ANY sense to me. --Ashallond 20:35, 19 August 2008 (CDT)
        • Ashallond, is this this the effect you're after?
          {{Test/ListItem|lime|notext=1}} -> {{Test/ListItem|lime|notext=1}}
          I added some simple conditionals to a test copy of ListItem - see Template:Test/ListItem for details. It's not a high-use template, so any performance implications from copying those mods to the real ListItem template should be negligible.
          As a side point, it seems to me that there are several templates - ListItem, InlineItem, InlinePlural et al - which basically do the same thing with minor variations; perhaps some folding could be done here? --GalenKemensen 12:38, 29 September 2008 (UTC)

Forum link template

Can we get a template so that we can link to the official forums without having to CAPTCHA? Something like {{forum|showpost.php?p=2932311&postcount=306}}. Or is it the Coldfront stance that we should discourage forum links?--Raijinili 17:52, 6 September 2008 (CDT)

  • Why not just [http://forums.kingdomofloathing.com:8080/vb/showthread.php?t=103391 RNG Thread] to get RNG Thread like regular links? I don't see why we need a special template. And what CAPATCHA? --JRSiebz (☎|§|‡) 19:40, 8 September 2008 (CDT)
    • The CAPTCHA you get when you're not an admin. ;) --TechSmurf 20:20, 8 September 2008 (CDT)
    • You mean every time you add an external link to a page you get a CAPTCHA?!!! Wow. that's annoying! I understand doing that to help prevent spam, but after an account is like a month old or so, I assume we don't need to do that to an editor anymore, ick! --JRSiebz (☎|§|‡) 22:16, 8 September 2008 (CDT)
      • This thread amuses me :P.
      • On a more useful note, putting a time expiration for the CAPTCHA can be easily exploited with dummy sleeper accounts. I think I've seen this on Wikipedia. I would propose that the CAPTCHA for links be one time, triggering a flag that says that this account can use links (though this might be difficult and/or tedious to do). The solution I would prefer, though, is that some sites be whitelisted. After all, very few links are from anywhere other than kol.coldfront.net, [A-Za-z0-9]*.kingdomofloathing.com, and the big clan forums like Iocaine Powder, Noblesse Oblige, and any other forums which do spading and that I don't remember right now. Hardcore Oxygenation. --Raijinili 00:46, 9 September 2008 (CDT)
        • On the other hand, I would never get to see "discoramen" again. --Raijinili 08:33, 9 September 2008 (CDT)
          • Don't forget Alliance from Hell and Hogs of Destiny. There's some spading going on there too. --Shoptroll 15:00, 10 September 2008 (UTC)

Missing Images

So I noticed the software got upgraded, but I'm noticing that various pages have broken image links. What can we do about this to help out? --Shoptroll 15:00, 10 September 2008 (UTC)

  • It's possible that the pages you are viewing were cached before one of the necessary mods was fixed and reinstalled (without which clickable image links wouldn't work). If you find a broken page, simply Edit the page and then click Save without making any changes and it should fix it (or simply wait a while - I made a similar null edit to the {{click}} template to force such pages to be recached, but the wiki's job queue processing rate is set so ridiculously low such that it'll probably take over a day to get through the ~4000 pages it had queued up) - if they aren't fixed, indicate which pages they are so we can figure out what's broken with them. --Quietust (t|c) 16:35, 10 September 2008 (UTC)
    • Tried this out on the Club of the Five Seasons. That fixed it. I'll do this with other pages I see it happening on. Thanks! By the way, clicking the link to insert the signature macro doesn't do anything aside from scrolling the page back to the article text box. Using Firefox 3. --17:16, 10 September 2008 (UTC)
    • Besides a "null edit", when you are editing a page, for example, the url is "....index.php?title=PAGENAME&action=edit", you can also purge the cache with "....index.php?title=PAGENAME&action=purge" (in your address bar) to refresh the page without having to save an edit. --JRSiebz (☎|§|‡) 00:37, 11 September 2008 (UTC)

Edit Toolbar

The edit toolbar (toolbar with images like button_sig.png and others) above the edit box while editing a page - seems to be missing since the upgrade too! --JRSiebz (☎|§|‡) 00:40, 11 September 2008 (UTC)

  • In Special:Preferences, I have "Show edit toolbar (JavaScript)" checked, and had adblock/noscipt disabled (and tried other browsers) and I can't get it to show up. I need my ETB! I keep forgetting how many dashes and tildes to use to sign posts! ;-) Was something removed/overwritten in the upgrade? --JRSiebz (☎|§|‡) 02:30, 13 September 2008 (UTC)
    • Edit toolbar is back now... yay! --JRSiebz (☎|§|‡) 21:29, 16 September 2008 (UTC)

Image Uploading

So, trying to upload an image just now gave me the error "The upload directory (public) is not writable by the webserver". Neat! --TechSmurf 00:02, 13 September 2008 (UTC)

  • Image uploads work now, yay!--JRSiebz (☎|§|‡) 21:29, 16 September 2008 (UTC)

Misspelling Category

The game has a fair amount of typos. The wiki, in turn, copies all those typos down verbatim. The game, however, has a fairly good system for correcting these typos. We don't. For instance, Doc Galaktik's Ailment Ointment had a typoed use text for well over a year. No idea how long it's been fixed, but, it has. Thus, I propose a typo category for tagging pages. This way, we can have a lovely little list of pages to check, instead of just occasionally noticing something months after its been fixed all willy-nilly. Yay? Nay? --TechSmurf 16:23, 14 September 2008 (UTC)

  • Yea. Something inline we can tag right after the error that links to the spelling thread, and autocats like {{NeedsReview}}.
Teh [sic] surpringly [sic] strong branches.
--Bagatelle 17:14, 14 September 2008 (UTC)
    • Tada! --TechSmurf 17:40, 14 September 2008 (UTC)
      • Barring any opposition, I'm going to start popping this in within the next few days. --TechSmurf 03:12, 15 September 2008 (UTC)
        • How do you plan to use this on things which have typos but which can never be observed to have been fixed? Like large stone triangle's use text, or other one-time content? Shall we only use it on things that can actually still be observed and verified in-game? --Flargen 05:43, 15 September 2008 (UTC)
          • Ooh, good point. Stick to tagging things that can still be observed, then. One-time things probably don't get fixed, and we have no way of telling either way. --TechSmurf 06:04, 15 September 2008 (UTC)
          • Well, we can ask Jick to fix it in-game even if it's invisible, just so it can be both correct and faithful on the wiki. >_> --Raijinili 12:05, 18 September 2008 (UTC)

Diff Engine

Was the Wiki lag spike this morning due to upgrading the diff software? Patrolling RC now, the changes aren't highlighted in red anymore, and I'm finding it more difficult then nromal too fnd tpyos or check for minor errors with just the strikeout formatting. --Bagatelle 20:36, 14 September 2008 (UTC)

  • I'm not really liking this change, either. The old way of showing changes with diff was much more easily parseable. --Flargen 05:43, 15 September 2008 (UTC)
  • Did this change just this morning? I believe it is due to a css file restore that Mag had to do to get the edit toolbar to work again. --SomeStranger (t|c) 11:07, 15 September 2008 (UTC)
    • Nope. Toolbar wasn't working when the diff changes were noted. And they're still around, too. --Flargen 20:51, 15 September 2008 (UTC)
    • Strange. On a mac with safari at work diff seemed to be using the old red-highlight system. But back at home on my PC with opera it's still got this bothersome underline/strikeout jazz going on. --Flargen 02:41, 16 September 2008 (UTC)
  • I'm getting underline (green) /strikeout (yellow) for changes ;-) --JRSiebz (☎|§|‡) 21:37, 16 September 2008 (UTC)

It appears enhanced RC isn't working either--it won't expand collapsed entries (while it works on a couple of other wikis where I have an account). Wiki r broken ;.; --Bagatelle 00:28, 16 September 2008 (UTC)

  • Mine's working, check to see if "Enhanced recent changes (JavaScript)" is checked in Special:Preferences and that you aren't restricting JS on your side ;-) --JRSiebz (☎|§|‡) 21:33, 16 September 2008 (UTC)

After 2 months of being unbelievably lazy I finally got around to fixing this. Refresh your cache to see the red highlighting again.--SomeStranger (t|c) 16:53, 27 November 2008 (UTC)

Unconfirmable

There are a good number of pages, which, due to various reasons, are nigh-impossible to confirm information for. We're going to have to admit defeat for a good number of these-- no one still has the images and formula for the Level Reduction Booth, Oil Nog has gone the way of Dodo Cola. It'd be awesome if we had some way of tagging these pages, much like the unverifiable tag built into the Item Template. Maybe I'm just crotchety and tired of seeing these things in the various Needs Work pages, but hey. They're not going to be resolved, so tagging is a bit moot. Potential example:

Tombstone.gif Content on this page cannot be verified--
it is no longer accessible in the game.		 Tombstone.gif

Header templates, I got a million of 'em. --TechSmurf 22:44, 20 September 2008 (UTC)

  • Hm, interesting. Can't you haxxor /dev for the information? I thought you had spies on them, using which you stole deep, dark, dirty sekrits. On a related note, shall we make a concerted effort to decategorise/add into an obsolete (oops, I mean "former") category as well, so obsolete (oops, "former") content doesn't show up in category lists with active content? --Bagatelle 03:53, 21 September 2008 (UTC)
Well, at least for items, we could potentially drop a <includeonly>[[Category:Obsolete Items]]</includeonly> or some similar thing into the verify=2 field of Template:Item. It looks like there is a category in place with adventures, so I suppose that would only leave locations or effects.--Toffile 00:21, 6 November 2008 (UTC)
(Resurrect'd!) We could do that, but as this will be applying to not just items, but adventures, zones, and whatnot, a template to apply to all pages would work better. Also, while there is already a category in place for retired adventures, I had this template more in mind for things which need content but can no longer be checked (like the few things I linked up top). One-time events which were never fully poked, ancient content, that sort of thing. Barring any sudden opposition, I'll put something together tomorrow. --TechSmurf 10:18, 8 February 2009 (UTC)


Size and Quality

Personally, I think we should put the size and quality of each food/booze item/ingredient on their respective Wiki pages. Naturally, we'd have to do some spading, and we'd need to answer these questions: How can we tell if an item follows the Size/Quality rules, as most foods introduced after NS13 are supposedly exceptions? Is it possible that some items follow the Size/Quality rules, even though they have ranges greater than six? Yeah.--Larryboy 21:37, 1 November 2008 (UTC)

  • It takes as massive amount of data to spade Qs. Furthermore, cropping formulae are better understood now. The issue isn't that some things have big ranges, but things with ranges that are too small. Like a lot of NS13 stuff. See the latest postings in the HCO thread.--DarthDud 06:50, 4 November 2008 (UTC)
    • I can't find the latest postings on the HCO thread. Do you have a link?--Larryboy 21:22, 4 November 2008 (UTC)
      • This thread. Look at the recent posts on the last page for good summary info.
        What would people think about adding more precise ranges to the wiki where possible? For instance, noting both min and max of a food... including the decimal? Maybe even a little note about the average? This should be doable for a very large number of foods and boozes soon. Maybe I'll create a subsection on the SQ page to kick around ideas for standardizing this on all consumption pages.--DarthDud 03:32, 14 November 2008 (UTC)
        • Well, there are the Best Foods and Best Drinks pages where averages have an obvious and important role. They currently just use the mid-point of the range as the average, while noting that for some items this is inaccurate. We could perhaps do something like the {{meat}} acquisition template that includes average and standard deviation entries for the adventure gains. Stat gains, too, I guess. I just fear that the item entries themselves would be made bulky and ugly because of this. --Flargen 07:11, 14 November 2008 (UTC)
          • Well, for foods, you don't have standard deviations. You have a range, as indicated in the below screenshot, that includes a decimal. So, I guess, what I had in mind was listing ranges on pages as X-Y.Z, instead of merely X-Y as is currently the case. I don't think this would bulk up the page appreciably. It might, however, be very confusing for those who don't understand how the notation works (1-1.2, for instance, would mean a result of 2 happens 20% of the time, but that a result of 2 is possible isn't immediately evident from this notation). I personally don't think it would be a huge problem, and people would quickly understand, and it would be a lot more informative than the currently available info on consumption ranges, but I'm biased. Of course there are other issues too, such as how to put the relevant info on a page (max before cropping) that allows those with sufficient interest to calculate how opossum/blender effects affects on a given consumable. Maybe consumables could have a little box in the top-right corner, like zones do, which summarizes such significant info, while leaving the page otherwise unchanged from how they currently are? Blah, complicated. :S--DarthDud 18:44, 14 November 2008 (UTC)
            • Okay, I looked at the thread page, it seems to have some pretty good data that we could use. Additionaly, it gives a formula with which one can determine the possible range of qualities from any given consumable. How should we use this? Should we put them in the Best Foods page? Or some of the recipe pages?--Larryboy 14:21, 15 November 2008 (UTC)
            • If the main concern is clarity, listing the base range with decimals is perfectly acceptable if we just superscript the adventure gains and link to the S&Q article, much like how the drop chances are linked to the Statistics Notes and how the "Moxie for no Hit" fields in the location index pages are linked to Safe Adventuring. I don't know if a floating infobox will be feasible due to consumables which have multiple possible results, like the pr0n cocktail. --BagatelleT/C 04:08, 17 November 2008 (UTC)
  • Here's a screenshot of the item spindler showing the size/quality of the flute of flat champagne --JRSiebz (☎|§|‡) 03:42, 14 November 2008 (UTC)
    • Woah, where'd you find that?--Larryboy 02:40, 17 November 2008 (UTC)


"Melee Damage" changed to "Weapon Damage"

I commented on the "Bonus Melee Damage" discussion page before finding this page, or finding Quietust's Bot request section on his user talk page. I don't want to request a bot to change all of the items though, since I can't confirm that there isn't any instance of just "Melee Damage" left. I don't have any Brimstone or Hobopolis items--among others--so I haven't confirmed that all instances of melee damage have been changed to weapon damage in game, although I assume they have. It appears as though all items that gave ranged damage still only affect ranged damage (including the 9-ball, for example, which now gives both +5 weapon damage and +5 ranged damage). --Qwertys 00:22, 6 November 2008 (UTC)

  • Item pages include links in the upper-right corner that let you check the in-game description. Just be logged into the server corresponding to the number at the time. --Flargen 00:24, 6 November 2008 (UTC)
  • Yeah. Aside from what Flargen said, I've done a random sampling, and it looks like it's changed. Probably best to boot up the bot and make the needed moves.--Toffile 00:27, 6 November 2008 (UTC)
    • I've put a request up. I'm going to go make the needed changes to any non-item page that currently uses melee damage.--Toffile 00:38, 6 November 2008 (UTC)

New "Dressing for Success" table colors should be added to wiki site css

This evening, I wanted to start working on the "Maximizing your Meat Drops" page. I was gonna use the "Max Item Drops" page code as a template. When I went to edit it, I saw that all the pretty colors in the tables were defined using hex codes. Can someone with the permission to do so edit the css and set it so the colors correspond to a simple class name (i.e., class "ultra-rare", class "dungeon", etc.) to make it easier to edit and maintain? -- Alphacow 01:10, 9 November 2008 (UTC)

  • While we're mentioning desired style sheet classes, how about one for all of the recipe tables and such? Most of the tables on the wiki have a lot of their settings in common, in fact. --Flargen 01:27, 9 November 2008 (UTC)
  • Actually either of you can edit it yourself at MediaWiki:Monobook.css. Just be careful when making edits so that you don't mess up site-wide css. Clear your cache to see any changes you make.--SomeStranger (t|c) 16:45, 27 November 2008 (UTC)
    • Actually, we cant:
      You do not have permission to edit pages, for the following reasons:
      This page provides interface text for the software, and is locked to prevent abuse.
      This page has been locked to prevent editing.
      --Flargen 20:01, 27 November 2008 (UTC)
      • what change would you like made? --Evilkolbot 23:42, 27 November 2008 (UTC)
        • All (or almost all; might be a few I haven't converted yet) recipe tables contain the following at the start of their definition:
          style="text-align: center" border="1px" cellspacing="0" cellpadding="3"
          If that could be compacted into a single stylesheet class, it'd simplify the existing tables and make future ones a lot easier to put together (without having to copy-paste one from another page). I believe the other table parameters can be defined in a style; can't remember, how, though. Been too long since I did much of anything with stylesheets. I should probably look that up, though. I always liked stylesheets. I think alphacow's issue could be resolved by looking up color names accepted by style; like style="background-color: chartreuse"
          For when you really need that kicking green-ish background.
          --Flargen 23:56, 27 November 2008 (UTC)
          • If we're going to make styles for recipe tables, I've got one simple thing that will make them work nicely - simply create classes for enough rows to cover the most complex recipes (such as the ninja pirate zombie robot head) and make it so td gets the grey background color and th is plain white, saving us the trouble of having to override specific cells. --Quietust (t|c) 05:22, 28 November 2008 (UTC)
            • Ohhhhhh, I like this idea a lot. That would definitely clean up the tables a lot. --Flargen 08:09, 28 November 2008 (UTC)


Other css stuff

Tooltips

So, I've been playing around relearning css. Lately I've been trying to figure out how to use CSS to get tooltips added to {{click}}. The good news is, I know how to do that. There are various examples to be found just by gooling "css tooltips". Such as this one, or this fancy bugger, . The bad news is that you can't seem to get predictable behavior from the stuff across all browsers. Opera 10 alpha acquires slight horizontal scroll bars fromt he rightmost tooltip on the first page, for example. The fancy tooltips seem to work. Also, these styles can't be defined in-line on pages, since they use pseudoclasses. Those have to be added to stylesheets. Or in the <head> section of the web page. The plus side is that having some tooltip styles set up will allow us a fair number of new potential options. Such as having a tooltip display what an effect does on the page for the thing you acquire the effect from (such as on angry farmer candy). Or to add clarifications to what things mean, such as with the arena ranking images in the current version {{familiar}}, without cluttering up the page itself or forcing click-throughs. The latter isn't always that bad, but we seem to get a fair number of requests for eliminating these sorts of things in some fashion or another. --Flargen 13:18, 20 December 2008 (UTC)

  • We don't actually need CSS for this--from other stuff I've done on the web, I know you can use hovertext/title attributes to do this. E.g.,
    • <span class="hovertext" title="hi">hover me pls</span> gives:
    • hover me pls
  • The above could be handled with whatever template you wish without messing with CSS. Bonus: I know for a fact it works for Firefox and IE; not sure about Opera though. However, Firefox is a bit finicky in that it, by default, cuts off the tooltip text at a certain length. I think FF users would actually have to download an add-on to bypass that. --BagatelleT/C 22:44, 20 December 2008 (UTC)
    • Well, the class="hovertext" part is referring to a css declaration. I could have sworn I tried using titles and it not working like I wanted to. Is the title attribute considered deprecated by now? And, do you consider a long message like like this text has to be well-suited for the title attribute? Also, do we really want it to display "Title: " before the relevant text? I was looking to use it for less of an actual title and more of a "here's what this junk means in a nutshell". --Flargen 02:19, 21 December 2008 (UTC)

Recipe Tables

As for using stylesheets for the recipe tables, the following code will do the job:

table.recipe{ 
    text-align: center;
    border-collapse: collapse}
table.recipe th{
    border: 2px solid black;
    background-color: #FFFFFF;
    padding: 3px}
table.recipe td{
    border: 2px solid black;
    padding: 3px}
table.recipe tr.row1{
    background-color: #FFFFFF;}
table.recipe tr.row2 {
    background-color: #EEEEEE;}
table.recipe tr.row3{
    background-color: #DDDDDD;}
table.recipe tr.row4{
    background-color: #CCCCCC;}
table.recipe tr.row5{
    background-color: #BBBBBB;}
table.recipe tr.row6{
    background-color: #AAAAAA;}
table.recipe tr.row7{
    background-color: #999999;}
table.recipe tr.row8{
    background-color: #888888;}
table.recipe tr.row9{
    background-color: #777777;}

The NPZR head goes all the way up to row 8 or 9 I think.

This is how we could then define a recipe table: 

{| class="recipe"
|- class="row1"
! {{grimacite smith}}
| [[chunk of depleted Grimacite]]
| [[chunk of depleted Grimacite]]
|- class="row2"
! {{equals}}
| colspan="2" | [[depleted Grimacite hammer]]
|}

Yielding:

Grimhammer.gif chunk of depleted Grimacite chunk of depleted Grimacite
Equals.gif depleted Grimacite hammer

...which should look like this when the styles are in place:

Grimhammer.gif chunk of depleted Grimacite chunk of depleted Grimacite
Equals.gif depleted Grimacite hammer

Compare to how we currently do it: 

{| cellspacing="0" cellpadding="3" style="text-align: center;" border="1px"
|- style="background-color: #FFFFFF"
| {{grimacite smith}}
| [[chunk of depleted Grimacite]]
| [[chunk of depleted Grimacite]]
|- style="background-color: #EEEEEE"
| style="background-color: #FFFFFF" | {{equals}}
| colspan="2" | [[depleted Grimacite hammer]]
|}
Grimhammer.gif chunk of depleted Grimacite chunk of depleted Grimacite
Equals.gif depleted Grimacite hammer

So, we get the same results in the end (unless someone else's browser has an issue, in which case point it out and we can probably find a hack/workaround). The practical upshot is that with the styles pre-defined in the wiki css files it'll be much less messy to define these recipe tables, as well as to read the code for them. --Flargen 13:18, 20 December 2008 (UTC)

  • This would be a nice addition. If you have the motivation to make the appropriate changes (or we could just grandfather it in...?) I'll add the appropriate CSS to the wiki system files..... Unfortunately it seems that most of the wiki-folks usually responsible for large sweeping reformatting changes are MIA so you seem to be going through all of your suggestions alone :/--SomeStranger (t|c) 21:27, 21 December 2008 (UTC)
    • Since I haven't encountered a large batch of html tables recently (although I haven't gone out of my way to find them recently, either), and I'm on holiday break, I should be able to manage converting the tables to use pre-defined styles, chunk by chunk. If we could get Quietust's attention enough to have Quietbot do it for us, that'd be extra sweet, but I'm not sure how much effort that coding would take. I believe I've made the coding of the recipe tables pretty consistent so far, but I wouldn't be terribly surprised if there are a couple of bad eggs, or even unconverted tables, on the wiki somewhere. I know how to find all of the pages to be converted, though; just look at what links to {{equals}}. --Flargen 21:34, 21 December 2008 (UTC)
      • As of a few hours ago, there were still well over a hundred pages using old HTML-style recipe tables, and QuietBot is currently in the process of converting them to MediaWiki markup using the above listed "old format" - once everything's consistent, I'll put together another script to switch to the named styles. --Quietust (t|c) 16:14, 3 February 2009 (UTC)
        • I've gone ahead and added the recipe table styles to MediaWiki:monobook.css, and the sample above seems to be working nicely. --Quietust (t|c) 14:55, 4 February 2009 (UTC)
          • The conversion is now in progress, and I've also temporarily changed the style so that empty table header cells appear with a black background instead of a white background so I can more easily verify that they're being converted properly - once the conversion is done and I've verified the results, I'll change it back to a white background. --Quietust (t|c) 16:24, 4 February 2009 (UTC)
            • ...aaaaand I'm done. --Quietust (t|c) 18:56, 4 February 2009 (UTC)

Pre wrapping

As has often been noted, pre tags do not auto-wrap. And, moreover, any line on the wiki that starts with a space will be parsed as being in a pre tag. 

Like this.

To enable line wrapping (in most current browsers; IE is something of a retard, as would be expected), and saving us a fair amount of trouble when reading talk pages that just had in-game descriptions copy-pasted in all their leading-spacing-glory, add the following to any relevant <pre> styles: 

white-space: pre-wrap

I was going to demonstrate it's wrap-tasticness, but then IE had to prove itself too dumb to properly handle even its own special word wrapping style element (word-wrap: break-word). And I didn't want to bork all you primitives over with that. --Flargen 13:18, 20 December 2008 (UTC)

  • Shhh. No one cares about IE. --BagatelleT/C 22:44, 20 December 2008 (UTC)

Category:Needs Spading

I was reviewing this today, and I was wondering if anyone would object to possibly splitting it into a few subcategories. Just the basic ones where we could filter it out into more specific areas, such as effects, drop frequencies, stats, etc.

I bring this up, as Spading and Needs Content are overlapping a bit, to the point where Spading should be used (exact gains, drop frequencies) but NeedsContent is being used lieu of it. I did a survey, and I think there are close to 100 pages where Content should be replaced with Spading. (I got about 118, but I'm lowballing it in case I made a mistake). I did some work in eliminating unneeded tags, but there are still about 126 articles in the NeedsSpading queue. Changing the tags would severely overload it.

If we split up NeedsSpading, maybe by just using a switch in the template and a few flags, it would allow for an easier assessment of the backlog. Anyone have any suggestions or comments. —Preceding unsigned comment added by Toffile (talk • contribs)

  • I'm fine with moving things from Needs Content to Needs Spading and such as necessary, but I don't really think we need subcategories for spading. At worst, there's a couple hundred pages tagged, and the information needed is fairly straightforward. What's needed, I feel, is just more vigorous efforts in keeping all the Needs Work categories clean. --TechSmurf 23:57, 11 November 2008 (UTC)


Odd question for wiki-techs

When I'm not logged in, the wiki thinks my IP is 81.26.219.30, which is shell.wunk.net. I went to www.wunk.net and found it's the site of someone who did design work on coldfront. I was wondering why the wiki thinks my IP is that, and if it's the same for everyone.—Preceding unsigned comment added by NoodleHannah (talk • contribs) on 09:57, 27 November 2008

  • Yes, something is up with the IP tracker for the Wiki. It's why one can't ipblock without locking the Wiki out to non-administrators. >_> --Toffile 15:08, 27 November 2008 (UTC)
    • After consulting with FrostByghte, we discovered that the Squid proxy was sending its outbound connections from 81.26.219.30 (which was apparently the default network interface on the machine running the Squid proxy), even though it was listening for them on 81.26.219.48 (where MediaWiki was expecting them to come from) - as a result, the Wiki wasn't recognizing that it was being accessed by a proxy and wasn't looking in the appropriate place for the source address. A quick bit of research turned up the proper Squid config setting and now everything's working nicely again. Hooray. --Quietust (t|c) 04:57, 14 February 2009 (UTC)

Updates to {{familiar}}

So, I noted on Template Talk:Familiar that I was looking to have the familiar template updated so that it would completely convey the arena specs of the given familiar. Seems that part of the template hasn't been updated in quite some time. The main question is: "How should we format it?". I wanted to see if we could get a few more voices on this before a change was made, since it will cause a fairly noticeably change in the appearance of familiar pages no matter how we do it. There are a couple of formatting ideas by JRSiebz and me in the template talk. I've also given a test implemention of one of my own at Template:Test. Any thoughts? --Flargen 09:23, 14 December 2008 (UTC)

Skill Navigation/Categorization

Sort of a torrent of questions. First, would it be a good/useful thing (to anyone other than me) to have a formalized grouping, or navigation table for 'sets' of skills? Such as the trivial skills, the starting combat skills, maybe the passive elemental resistance skills. Maybe even passive HP-increasing skills. (Less so the Meansucker or Gnomish or Spookyraven Manor Quest skills, because each of those skills is only two pages away from each other anyway.)
Second, what would be the way to go about it? Making Category: Trivial Skills, Category: Starting Combat Skills? Or having a table a bit like the zap tables. Or both, or something else I haven't thought of? --Unnatural20 07:48, 15 December 2008 (UTC)

rl calendar of loathing

  • in light of certain regrettable (and deeply regretted) incidents, attention has been drawn here at fortress kolwiki to a new source of content, one which j&co assure is most definitely canon.
  • i refer, of course, to the kol calendar and its descriptions of all things temporal.
  • now that we have to include its text in full, the question arises of how and where.
  • i've never seen one. i'm guessing that our busy (and sometimes angry) little beavers have added most of it, but my search-ninja skills are failing me.
  • some questions:
    1. how much of this text is included already?
    2. how much is missing?
    3. should there be a summary page, or is it enough to add the text to the holidays concerned?
  • any answers? --Evilkolbot 19:58, 17 December 2008 (UTC)
    • apparently not. i'm guessing that the post-calendar holidays have the full text included, but that the handful that pre-date the calendar just have something from the top our collective heads. as a sample i've put the text from the calendar (which should be checked for format and content) as the first thing on the page, a la Festival of Jarlsberg. i was at a loss as to how to title the player-made description so i used "Details" but that sucks too.
    • as for the incident hinted at above, i think what i really objected to was the inclusion of a single fact as a note, which is so not what is usual here.
    • got to go, my class on "getting what you want through empathy and understanding 1.01" just started and i don't want yo miss yet another week. --Evilkolbot 22:16, 4 January 2009 (UTC)

Spading Brother Smothers's Blessing

Howdy, I spent 280 turns spading Brother Smothers's Blessing at the orcish frat house. I put all my results on the talk page. Could someone who knows what they're doing look at the data? Thanks, --JeffAMcGee 23:29, 19 January 2009 (UTC)


Adventure gain ranges

I'd like to change consumables to match the underlying minimum and maximum values instead of simply displaying the range of possible observed results after rounding. An example of this would be changing hell ramen to 22.0-28.4 instead of 22-29. (Another alternative would be 22.4-28.4 since that's how it works in practice due to an ancient bug, but I'd prefer 22.0.) --Eleron 09:20, 21 January 2009 (UTC)

  • Explain what that means. I hear people mention this, but have no idea what it means in practical terms. What is 28.4 adventures? And I think this is sort of like the monster meat drops stuff. I was able to get the {{meat}} template to automatically calculate a range, average, and variance (the deviation isn't possible, due to some wiki glitches), for example. But it would frankly be much better if we got a good explanation of the mechanics of monster meat drops up somewhere, and just use a link to that rather than listing the various statistics. --Flargen 09:33, 21 January 2009 (UTC)
    • When calculating adventure gains from an item, it is based on min and max values (22 and 28.4 for ramen). This is done by choosing a random integer from 22 to 28, and then adding +1 turn 40% of the time (instead of 20%, which would be correct). Similarly for fettucini (21 to 28.8), it chooses an integer from 21 to 28, and then adds +1 turn 80% of the time (instead of 40%). For the fettucini, 22 to 28 will be the most common adventure gains (all equally probable), while 21 will happen 20% as often as those, and 29 will happen 80% as frequently as the middle ones. I could write up pages about both the meat drop and adventure gain range if you'd like to link to them :) (and hopefully afterwards someone can make those pages readable instead of my sometimes terse writing). The expected adventure gain from an item is (min + floor(max)) / 2.0 + (max - floor(max)) --Eleron 10:01, 21 January 2009 (UTC)

I started adding values for some items. Could it be displayed in a friendlier way by adding support to the template?--Eleron 18:39, 28 January 2009 (UTC)

Well, you kinda have to play to the lowest common denominator (ie. people are stupid and will just say "zomg I got 29 adv, not 28.4!" and edit the wiki back to 29) so perhaps for people who do care, or are just curious, you could put in the Notes: section "The actual maximum value is 28.4, which means only 40% of the time will it round up to 29 adventures." and just edit that as necessary based on the spading completed. I think leaving the base numbers as 22 and 29 would be fine in that example. If there is a different way to word it, that would be fine, but I think that's still something better left in notes (for those people who will really use the exact info)--WhiskeyJack 18:46, 28 January 2009 (UTC)

  • I think the "simplest" way would be to use title attributes, and to have the food template have minadv and maxadv parameters. So that the end result would end up something like this:
AdventuresYou gain 22-29 Adventures.
--Flargen 20:05, 28 January 2009 (UTC)
    • Well, I made that addition to your changes to {{adv}}, but to propagate it through to food pages will require an admin updating {{useitem}}. And, to be frank, there's at least 2 other things on this discussion page which are actively awaiting for the mythical admins to rise from their torpor and feast on the souls of the livingmake some changes around here, and have been for over a month. So, you know, cross your fingers, and maybe leave out a few offerings of delicious brains. --Flargen 20:16, 28 January 2009 (UTC)
      • We could go with something like adv={{advrange|min=22.0|max=28.4}} instead, if getting useitem changed is really difficult? It's not as good since it's not connected to the item in the same way (and thus we can't add any extra text outside the number area), but we could do that right now. It might also look a bit scary when editing, but if the range is known it's unlikely to be something that should require changes anyway :)--Eleron 20:22, 28 January 2009 (UTC)
        • Most people don't notice anomalous things like that, or don't care, or don't edit the wiki, so I wouldn't worry about it. To be fair, people would act less stupid if you wrote the rules clearly.
          1. The average yield is (min + max)/2 + decimal bit, or just (min + max)/2, if you include the decimal in the adventures, which seems like the simplest way to do it. Why do you prefer the other way? The min and max in your example are written in different ways and are just ingredients to a formula. They don't tell people anything.
          2. The page I linked to says that all foods have a range of 7, which is wrong, so is everything there wrong? Quality seems like a pretty meaningless concept if it doesn't predict the range of adventures, but is just an average. In the case of hell ramen and fettuccinni inconnu, it's not even that, since your average is different from the one here. How does this whole thing work for hell ramen and fettuccini inconnu?
        • You've explained it really badly, I think. Mar 23:16, 28 January 2009 (UTC)
          • OK, this is how it works. Consumables in the game do have a size and a quality. These were set when creating the content, and are a part of the items, just like the description and the text you get when eating them. They also have minimum and maximum values for adventure gain, which are usually based on the quality and size fields in the way it was explained in that forum thread. These 4 numbers are all part of the item itself, entered by TPTB. The quality is not the same thing as the average number of adventures gained from an item, it's just a number that's used to compute the minimum and maximum adventure gain values. These min and max values then determine how many adventures you get when eating the item. This is the important part. When we start from the same values as those actually used by the game, we can perform exact computations and thus get correct results.
          • Here is how it works for hell ramen. It has a size of 6 and a quality of 7.4, which were used to create an initial range from (6 to 6*7.4) adventures. This was then chopped down to (6+16 to 6*7.4-16), or (22 to 28.4). That's where the numbers come from.
          • Then the question is how to display these values. When eating the item, you will see adventure gains from 22 to 29. However, you would see the same thing if it gave (22 to 29) or (22 to 28.1), so some information is lost if that's the only data that's available on the wiki. By including these correct values in the wiki, we can for example display it as something like You gain 22-29 adventures (25.4 average), or something similar. The average is indeed just (22+28)/2+0.4, but writing that with wiki-like formulas gets a bit complicated. --Eleron 00:18, 29 January 2009 (UTC)
            • Ok thanks, I got confused. How is the range decided? Is it 6-8 where the min is an integer? Is it the closest value to 7? That's really clever. You're starting with the internal data, and then calculating the result, bugs and all. That's why it's confusing, otherwise it's not so bad. Just giving the result of 22.4 would be better Mar 02:16, 29 January 2009 (UTC)
  • Hello there. I'm kind of split on the issue of displaying decimal adventure values which has the potential to become very confusing. I'm more inclined to use Flargen's solution so that the especially astute adventurer has the data available should he or she choose to super-optimize runs. However, I'm just one person of the three that seem to be active on this page. Provided that an explanation page is created for the decimal adventure gains I could theoretically add an '*' at the end of the word "adventures" to give an explanation of how those gains actually work. I'll make a blank edit to {{useitem}} once all is decided so that it propagates. Drop a line on my talk page if I forget :).--SomeStranger (t|c) 00:35, 29 January 2009 (UTC)
    • Great! Flargen already set up {{adv}} that way, so all that's needed is a way to pass the numbers through useitem. Could you e.g. make it send it to {{adv|min={{{advmin}}}|max={{{advmax}}}}} instead of {{adv|amount={{{adv}}}}}}} if advmin exists? Or something similar with better names, all that's needed is a way to get the numbers through. :) --Eleron 01:05, 29 January 2009 (UTC)
    • I can do the max/min thing, but I'm going to wait until the job queue empties out so that I can actually see the template edits I make. (Since Flargen just changed a few thousand pages when he updated Template:adv)--SomeStranger (t|c) 01:18, 29 January 2009 (UTC)
      • And while you're at it, mind adding those css definitions for the recipe tables? Quietust is either silently protesting writing a bot routine to make the changes, or is just otherwise preoccupied with other aspects of life right now, but I'd be happy to go through things manually. "Grandfather them in", I think you said.
        As for where to add an explanation of the decimal figures that would appear in the Title attribute, would Category:Food work, or are we looking for something more prominent? Like Adventures, or maybe its own page? I suppose it is technically at Size and Quality; maybe just needs a little clean-up/rewrite. --Flargen 12:25, 29 January 2009 (UTC)
        • Quick thought, Since changing (at least) some of the adventure gains to having decimals, a few times, people have either reverted it or posted questions on the talk page for said items. I've been sending them to here Discussion#Adventure_gain_ranges for information about it, but it would be nice if there was a different place for it. Size and Quality would be my suggestion, if anybody cares. --Alabit 18:23, 1 February 2009 (UTC)
  • this is just wrong. (well, maybe that's me, but hear me out.) saying that an adventure range is (a.0 to b.c) makes no sense. you never receive a fractional adventure gain, so putting one on the page is at best confusing. besides, the (a.0 to b.c) notation suggests that you will get (a to b-1) adventures, or b or b+1 in a ratio of .c, which is not the case.
  • i'd say that the ranges should be changed back to integers, and a note added as to this extra percentage of an adventure with a link to text describing the mechanic. all this should definitely be added to the template. --Evilkolbot 19:02, 1 February 2009 (UTC)
    • Read above for why it's right and what it means. And we were in the process of hiding the decimals from casual viewers. But we need someone with admin powers to actually change {{useitem}} to use the associated changes to {{adv}}. Do you happen to know of one? --Flargen 19:57, 1 February 2009 (UTC)
      • hmm, if only there was someone like that. oh, wait, do you mean me? i've never tested my template powers. you need to tell me where to go and what to do. --Evilkolbot 20:03, 1 February 2009 (UTC)
        • See {{Test/useitem}}. SomeStranger prepped up the relevant change to use the new option for {{adv}}. Won't cause any compatability issues with any existing foods; just adds the option to pass in min and max adventures, which are then rounded appropriately, and a Title attribute is added over the adventure range to show the decimals that were originally passed in. If you wish to add in a clickable note for the mechanic, you can put an asterisk after the {{adv}} call to link to Size and Quality. Or perhaps add that asterisk directly to adv, instead. We can then put in a subsuection on the S&Q page describing how to add the "fractional adventure" information, how to find it on pages that have it, and how to interpret it correctly. --Flargen 20:42, 1 February 2009 (UTC)
          • Oh, and if you need me to, I can tell you how to write the template code to link in the way you think would be best. In {{Test/useitem}}'s code, you will see a {{#if:{{{minadv|}}} line, than ends in a call to {{adv}}. After that adv call you could just add [[Size and Quality|*]]. I can add the relevant explanation of the fractional wiki display to that section. --Flargen 20:51, 1 February 2009 (UTC)
            • Checked it myself, looks like it'll have to be added onto {{adv}} directly. Not a big issue, but it does mean that the job queue is about to skyrocket as I make that addition. So, uh...come back in an hour or two while the wiki propagates the change? --Flargen 20:58, 1 February 2009 (UTC)
    • I know I'm kinda late to this thread, but I'd really rather display the decimals explicitly. There's really no purpose to hiding knowledge in title attributes. With a prominent wikilink to the S&Q page for explanation (which I see has been brought up above), an enquiring user only has to click the link once to know that there's the possibility of rounding up when there's a decimal. <rant>Not that people would actually read it, given the spate of erroneous stat day edits we see.</rant> We could probably do something similar for {{combat}} and ML variance for the location index pages. Also, in the future, it might be a good idea to use {{ANNOUNCE Discussion}} to bring attention to policy discussions that have Wiki-wide effects so people who don't patrol (the great majority of users, I'd wager) won't revert stuff that's going to be implemented. --BagatelleT/C 02:40, 2 February 2009 (UTC)
      • sorry to seem like i was shirking but i was called away. i'd still not be happy with the decimals being displayed directly against the adventure ranges, since the actual amount of adventures you get is always an integer. the decimal fraction is merely a quirk of calculation which changes the distribution and not the number. by all means add it into the data somewhere (mouseover is a reasonable compromise) but don't make it explicit, it's just nonsense. --Evilkolbot 12:44, 2 February 2009 (UTC)
        • The decimal fraction is not a quirk of calculation nor nonsense. The decimal fraction is there as part of how the item was created, just like monsters have say attack and defense values. 28.4 is part of the item, 29 is not. I'm not opposed to displaying things like the range of numbers you might see if you eat the item without milk, munchies, fork, opossum, pride or gluttony just because people are used to seeing that, but that's _not_ a property of the item. (It also gives people the wrong impression about how adventure gains work.) It's not that important though, as long as the correct value can actually be entered in the template such that the wiki contains correct information somewhere, and that it can be found by those who care (e.g. like {{Test/useitem}} and {{adv}} work right now). --Eleron 15:12, 2 February 2009 (UTC)
          • 28.4 is part of the item? no it's not. no-one ever got a fractional number of adventures. ever. the .4 is absolutely an artefact of calculation. the adventure range received by players is always integral. the numbers "22.2 to 28.4" mean you will receive 22 to 29 adventures. that's its range. the fractional parts don't change the range. whether it's 28.1 or 28.9 the upper bound of the range will always be 29. what changes is the distribution. the range and distribution are two entirely separate pieces of data. they should not be represented together. full stop. --Evilkolbot 17:35, 3 February 2009 (UTC)
            • You seem to be confusing "part of the item" with "part of the player's subjective experience of the item". The distribution IS an inherent property of the item . That you can only detect this over numerous observations does nothing to contradict this. Otherwise, by your argument, all drop rates are either 0 or 1, since a player only ever sees the item or doesn't. You'll never see 50% of an enchanted bean! --Flargen 17:58, 3 February 2009 (UTC)
              • you're validating my point. the range of the drops for an item is, indeed, generally 0 or 1. since this isn't exactly notable, what is explicitly presented is the distribution of an item, which, for enchanted beans, is 50% for each. putting "number dropped" on the page and assigning 0.5 to it is either confusing or meaningless. --Evilkolbot 18:12, 3 February 2009 (UTC)
                • 28.4 is part of the item. When you are born under the opossum moon sign, this value of 28.4 is changed. By hiding this information, you are making it impossible for users to find the effects of opossum and blender on any items in the game.-QuantumNightmare 18:19, 3 February 2009 (UTC)
                  • sorry if i did not make myself clear. i am not advocating that this information be somehow hidden. it should definitely be included on the page somehow. fractional adventure ranges are not the way forward, though. the question "if i use this item, how many adventures will i get" is one that should be answered at a glance, exactly in the same way that including the number of items you get does. the integer ranges will do this. forcing people to do maths, however simple, does not enhance clarity. if a reader wants to ask "what is the most likely number of adventures" or "with what probability will i get the maximum number" then by all means give them the data to work it out for themselves. --Evilkolbot 18:30, 3 February 2009 (UTC)
                    • This is just about semantics. When I say that the item's adventure gain range is say 22.0-28.4, that's because it's a part of how the item itself is entered into the game. This range must be stored with precision including all known decimals. Whenever you click on [eat] to consume this item, a lot of code is run, which then gives you X adventures, where there's also a range on this X value, which depends on the item the code is run for as well as numerous other factors. In this case with no modifiers active the possible values of X are integers from 22 to 29. When talking about a consumable giving adventures to a player, it makes sense to attempt to describe this X value in some way. This is not the same thing as the item's adventure gain range (which is defined by the game as part of the item itself). That's all. It's obviously confusing because both ranges could meaningfully be referred to as the adventure gain range, but we're talking about the one very specific definition that is used internally for storing items in the game. Not about what's displayed to users on the page, which could be something different and should consider the usefulness of what's presented. An actual item drop example of this would be that an item has a 100% drop rate, but is rejected 50% of the time. This would mean that the internal drop rate was 100%, and that's what should be stored for the item. However, it should absolutely not be displayed to the user as 100%, since that would be terribly misleading (and something as crazy as that would warrant an in-line description).
                    • Anyway, the most interesting values for metagame evaluations that a player is interested in when evaluating whether the food is worth eating are in approximate order the expected/"average" value of X, the chance of getting >N adventures, the range of X values you might gain, and the full probability distribution of values. The average gain should definitely be displayed, and the way the adventure text is currently formatted I agree that it makes sense to show a shorthand describing the range of X values, i.e. 22-29. You do not actually gain a range of adventures from eating the item, but it's understandable and not too wildly misleading as long as the true expected value of X is also listed, which we'll be able to do. That's a presentation issue though, so I consider the original issue of whether the item's adventure gain range should be included somewhere on the wiki as soundly settled on "yes". Just not by replacing the range of X values in the text, and that's no longer considered since we've developed a better solution by now anyway that's just waiting for the useitem template to be pushed. --Eleron 22:57, 3 February 2009 (UTC)

This was originally just about being able to place the correct data for adventure gain ranges somewhere. However, it has attracted quite a bit of attention and expanded beyond that. I believe it's useful to have this policy discussion about where data should be stored for items and how to display this information on the pages. Because of that, I'm starting a new section for this purpose, where the focus will be explicitly about data storage and information presentation.--Eleron 10:53, 2 February 2009 (UTC)

So we've decided to put the distribution in the notes section instead of the in the adventure range, right? So I can take out the decimals from the food. Mar 02:34, 3 February 2009 (UTC)

  • No, notes is definitely not the right place. I have no idea how you came to that conclusion. --Eleron 12:54, 3 February 2009 (UTC)

This issue appears to be resolved. We will store the adventure gain information, but use templates to format it nicely. --Eleron 09:28, 8 February 2009 (UTC)


Complex Table Sorting

Hi. The tables in Best Foods, Best Drinks, etc cannot currently be used with the table sorting code in Mediawiki:Common.js since they use rowspans. I'd like to propose some changes to that code to accommodate these kinds of tables. These changes allow these tables to be sorted/resorted while preserving (well, recreating) the rowspan structure. This would not affect anything other than tables explicitly changed to use this code. Since I cannot edit that page myself, here is what would have to be done:

1. Two new table classes, "nopajama" and "complextable". (Could use just one, but it may be useful to have both). These are only used to identify the tables. For each such table instead of using class="sorttable" in its definition it would use class="sorttable complextable nopajama".

Changes to Common.js:

2. Modify line 140 so it doesn't use pajama papering for nopajama tables: 

if (ts_alternate_row_colors && table.className.indexOf('nopajama')<0) {

do a similar thing at line 250 to stop it from re-applying pajama-papering after sorting: 

if (table.className.indexOf('nopajama')<0) ts_alternate(table);

3. Specifically for the best foods etc, since they use "-" in otherwise numeric fields and that messes up the script's heuristic identification of what is a numeric column, the matching code in ts_resortTable that tests for the ts_sort_numeric function at current line 203 needs to include "-": 

	if (itm.match(/^[\d.,-]+\%?$/))

4. Add code in the ts_resortTable function before line 185 to check if the table is a complextable, and if so de-optimize just before regular sorting: 

  var doopt=(table.className.indexOf('complextable')>=0) ? true : false;
  if (doopt) {
    var rows=table.rows;
    // first, unoptimize the table
    for (var i = rowStart; i < rows.length-1; i++) {
      var cells1 = rows[i].cells;
      var cells2 = rows[i+1].cells;
      for (var j=0;j<cells1.length;j++) {
        var rspan = cells1[j].getAttribute('rowspan');
        if (rspan && rspan>1) {
          var cn = cells1[j].cloneNode(true);
          if (cells2.length<=j) 
            table.rows[i+1].appendChild(cn);
          else
            rows[i+1].insertBefore(cn,cells2[j]);
          cells1[j].removeAttribute('rowspan');
          cn.setAttribute('rowspan',rspan-1);
        }
      }
    }
  }

5. Add another check near the end of the same function (before current line 243) to re-optimize it if it was de-optimized: 

  if (doopt) { 
  var rows=table.rows;
  // now, reoptimize the table
  for (var i = rows.length-1;i>rowStart;i--) {
    var cells1 = rows[i-1].cells;
    var cells2 = rows[i].cells;
    for (var j=cells2.length-1;j>=0;j--) {
      if (cells1[j].innerHTML==cells2[j].innerHTML && 
        rows[i-1].getAttribute('bgcolor')==rows[i].getAttribute('bgcolor')) {
        var rspan = cells2[j].getAttribute('rowspan');
        if (rspan) {
          cells2[j].removeAttribute('rowspan');
          rspan=parseInt(rspan)+1;
        } else {
          rspan=2;
        }
        rows[i].removeChild(cells2[j]);
        cells1[j].setAttribute('rowspan',rspan);
        }
      }
    }
  }

I've tried this out with a copy off-site, and it works very nicely. --Fig bucket 16:23, 15 February 2009 (UTC)

Fixing regular table sorting

I've noticed that table sorting in general doesn't always work properly, depending on the column contents and its current sorted state (and not connected with the above changes :)). The main problem seems to be the way the script heuristically figures out which sorting function to apply, ie whether to sort by alpha/date/currency/numeric/req. It does this by pattern matching the text in the first non-empty row of the column, and that just doesn't work well in all cases. The "req" sort, for instance, tries to sort stat requirements, assumed to be expressed as text like "10 mysticality", "5 Muscle", or "None". But it does not recognize it when abbreviations are used, like "10 mys", which is what most of the tables actually do use. So, all the tables that have requirements in that form get sorted alphabetically (default sorting method) when there's a stat requirement in the first row (since it's not recognized as a stat sort), and then get sorted as stat requirements once/if "None" shows up in the first row. This makes the sorting behave oddly; check out how Shirts sorts when you click on the "Req" column to resort a few times for an example of the problem. The 1st and 2nd clicks sort alphabetically (not by stat req). At this point "None" rises to the top, and so stat req sorting is used for the 3rd click. However, it fails to recognize the 3-letter forms of stat names and associate appropriate numeric values for sorting; everything ends up equally weighted at 0 and sorting doesn't change the order. The button appears to stop working altogether.

This seems like a simple thing to fix, just add the 3-letter abbreviations to the match test. But that stat sorting gets applied whenever "None" shows up in the first row whether or not its really a stat requirements column, e.g., to the Prereq column in MP Restorers, which then doesn't sort properly. Similar problems show in recognizing other column types; e.g., the power column in Star chart isn't sorted numerically when "n/a" rises to the top from previous sorting.

To avoid these problems it should be possible to specify the column type manually, overriding the heuristic choice. The basic idea is to add a class to a table header row (similar to the existing "unsortable") which would force that column to be numeric, alpha, stats, etc. (still defaulting to the current behaviour). To support this the following changes would be required in Mediawiki:Common.js:

Modify ts_makeSortable to parse the cell's class and pass an extra argument to the event handler (replacing the body of the for-loop in lines 135-138): 

		var cell = firstRow.cells[i];
		var sortType='auto';
		var unsortable = false;
		if (cell.className) {
			var cns =  cell.className.split(' ');
			for (var j=0;j<cns.length;j++) {
				if (cns[j] == 'unsortable')
					unsortable = true;
				else if (cns[j].indexOf('sort_')==0 && 
                                          cns[j].length>5) 
					sortType=cns[j].substr(5);
			}
		}
		if (!unsortable) {
			cell.innerHTML += '  <a href="#"' + 
          'class="sortheader" onclick="ts_resortTable(this,\'' + 
          sortType + '\',' + colloffset + 
          ');return false;"><span class="sortarrow"><img src="'+ 
          ts_image_path + ts_image_none + '" alt="↓"/></span></a>';
		}

(nb: cut-and-paste from edit; wiki is interpreting the arrow and no-break spaces in showing that innerHTML assignment code).

Change the header of the event handler to accept the new argument and declare a new variable (replace current line 166): 

function ts_resortTable(lnk,sortType,colloffset) {
	var sortmap = {sort_alpha:ts_sort_caseinsensitive,sort_numeric:
                ts_sort_numeric,sort_date:ts_sort_date,sort_currency:
                ts_sort_currency,sort_req:ts_sort_req};

Modify the event handler code to make a heuristic choice only if the override is not present (insert at current line 215 to embrace the heuristic pattern matching): 

         sortfn = sortmap[sortType];
         if (!sortfn) {

and then close the above if-statement on current line 229: 

         }

Finally, the stat sorting function needs to work with abbreviations if the forcing is to work, so current lines 379-381 need a few extra cases: 

  case "mus":
  case "muscle": return a[1]+3000;
  case "mys":
  case "mysticality": return a[1]+2000;
  case "mox":
  case "moxie": return a[1]+1000;

The columns that currently don't work properly would then have to be modified to add the appropriate class specifier, sort_alpha, sort_numeric, sort_req, to the header field. If someone makes the changes above I don't mind going through the tables themselves. I made a test (off-site again); compare the sorting in this version of the Star Chart to the existing one by clicking on the Power and the Requirements columns (nb first column doesn't sort because I didn't replicate the full nest of templates used in that column). --Fig bucket 18:42, 23 February 2009 (UTC)

Retrieved from "https://kol.coldfront.net/thekolwiki/index.php?title=Discussion/archive7&oldid=606300"