Discussion/archive11
It's like Discussion, y'all. Anything that you might want to draw attention to can be posted and commented upon here. For now, a central location for discussions is more viable than commenting in talk pages, where it may be easily overlooked. --Snickles
Discussion Archives | |||||
---|---|---|---|---|---|
1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 | |||||
9 · 10 · 11 · 12 · 13 · 14 · 15 |
Contents
- 1 Updating Mediawiki
- 2 Place Radio Show Transcripts on Wiki
- 3 Pages to Nuke From Orbit
- 4 Strategy Pages
- 5 GroupMonster template
- 6 Server downtime/midday-migration/spiders (June 27, 2011)
- 7 But what are they?
- 8 tatter redirect
- 9 Data pages and ambiguous names
- 10 Tome / Libram / Grimoire pages don't consider Bad Moon
- 11 Daily Activities
- 12 Data Page Additions
- 13 Post-Valhalla Revamp Stat Gains
- 14 Hatchling Familiar Association / Template Change Request
- 15 Categories updating very slowly
- 16 Dry noodles info all over the place
- 17 Games Mechanics/Modifiers Tables
- 18 Items by ID
- 19 Challenge Path quicklink
- 20 Bosses and autocat=no
- 21 History of Loathing: include more than in-game announcements
- 22 Ads, sound & fury
- 23 Established Standards: Item Pages
- 24 MediaWiki Pages to tweak
- 25 Possible Glitch
- 26 Category Suggestions
- 27 Zapping Pages
- 28 Random Page broken?
- 29 New accounts and spam links
- 30 New Suggested Category For Items
- 31 Shared Counters
- 32 Monster fumbles
- 33 Document URLs
- 34 Dealing with lists: Semantic MediaWiki?
- 35 One time a day usable items...
- 36 Combat messages
Updating Mediawiki
Trying to make an image/link that had hover text, and reading the talk of {{click}}, it seems that is currently impossible. Googling for a solution, it turns out that more recent versions of mediawiki make this trivial. (No need for click at all -- you just use regular image syntax with a link parameter.)
I'm sure there are tons of other nice features we'd get from upgrading, as we're on 1.13 and the current version is 1.16. How traumatic a process would it be, and who can actually make it happen? --Starwed 02:53, 20 January 2011 (UTC)
- No to mention formulas, string functions, image map support (so we don't have to manually split up and upload multi location kol images to use them as links), more math functions, built in image linking, get image thumbnailing/resizing working again instead of failing and having to manually uploaded resized images (though some old cached resized images still work), and also actual search suggestions like wikipedia currently does. --JRSiebz (☎|§|‡) 05:45, 20 January 2011 (UTC)
- +1 enthusiastic vote. --Fig bucket 12:15, 20 January 2011 (UTC)
- +1 here, too. --Club (#66669) (Talk) 18:24, 20 January 2011 (UTC)
I've sent this suggestion on to those who can make that change. --jin 19:03, 20 January 2011 (UTC)
- Any response? --Starwed 19:50, 29 January 2011 (UTC)
- They were going to do it in "2 weeks". And like 2 days later the wiki went down for half the day. I thought that was it, but from what I can tell we're still at 1.13. If we are, we might need to adjust the main page announcement template to mention that the wiki might go down for awhile soon for an upgrade. And then poke the relevant people to make sure it's still scheduled. --Flargen 20:16, 29 January 2011 (UTC)
- Hah, that had crossed my mind too. Glad to here we'll be updating!--Starwed 20:54, 29 January 2011 (UTC)
- I'll follow up on this --FrostByghte 12:40, 6 May 2011 (UTC)
- Hah, that had crossed my mind too. Glad to here we'll be updating!--Starwed 20:54, 29 January 2011 (UTC)
- They were going to do it in "2 weeks". And like 2 days later the wiki went down for half the day. I thought that was it, but from what I can tell we're still at 1.13. If we are, we might need to adjust the main page announcement template to mention that the wiki might go down for awhile soon for an upgrade. And then poke the relevant people to make sure it's still scheduled. --Flargen 20:16, 29 January 2011 (UTC)
- My wiki wishlist (with links this time):
- Get image thumbnailng fixed to stop the following error
Error creating thumbnail: /home/coldfront/domains/kol.coldfront.net/public_html/thekolwiki/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory
- No longer need to use {{click}} (MediaWiki 1.14+)
- As Jick has been starting to use large images with image maps in game instead of a table of images, so we don't have to manually break them up, getting the ImageMap extension.
- Update the version of the ParserFunctions extension, which apparently now includes some string functions.
- Get support for squareroot, floor, and ceiling, which we now use manually made inefficient templates for, {{sqroot}}, {{floor}}, and {{ceiling}}. The Math Function extension only has sqrt, the ParserFunctions/Extended extension has all three, but the info page seems to imply much of it has been added to ParserFunctions, but the ParserFunctions page doesn't confirm that.
- Also, because of this, the template names ceiling and floor we already taken, so to display the ceiling/floor symbols became called {{cl}} and {{fl}}, cl which name conflicted with the existing category link template which was {{cl}} (to go with template link {{tl}}), which became {{catLink}} which defeats the whole purpose of the shorthand template in the first place.
- People always complain about the wiki search, specifically it needing perfect search terms. Wikipedia actually now does a "did you mean FOO" when you search for a misspelling. Looking at its version page, I believe it may be a combination of the Lucene-search and MWSearch extensions. Are we considered a "small wiki", the mediawiki page also mentioned the SphinxSearch extension.
- Get the <collection> parser hook to fail gracefully. Right now, if a blank, question mark, or currently unknown or brand new item number is passed to it on an item page it throws the following php error which messes the the page's css/sytle.
Warning: fopen(http://wikidev.coldfront.net/rsscollection/FOO.rss) [function.fopen]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/coldfront/domains/kol.coldfront.net/public_html/thekolwiki/extensions/collection.php on line 22
It would be nice if instead of bombing the page it would just print some html/text like "Invalid or Unknown Item Number for Collection" where the extension parser hook was invoked, instead of the php error. Maybe catch it or something ;) - And maybe as a bonus, some kind of built in markup for displaying formulas, which a lot of game mechanics pages do, see MediaWiki:Help:Formula.
- Get image thumbnailng fixed to stop the following error
Any updates on the status of this? --Starwed 21:11, 23 February 2011 (UTC)
- I talked to FrostByghte on IRC a few hours ago (Mag wasn't there at the time) and managed to get the thumbnail issue fixed (it was nothing more than a configuration error - the path to a particular program was incorrect); hopefully, the remaining issues will be addressed soon, including the recent extreme slowness with image/page deletions. --Quietust (t|c) 23:36, 2 May 2011 (UTC)
- Mag should be back next week and will dive into this. --FrostByghte 12:40, 6 May 2011 (UTC)
- This is still in the works. Mag is trying to work his resolve up to go through with it. --FrostByghte 13:12, 4 June 2011 (UTC)
- Mag should be back next week and will dive into this. --FrostByghte 12:40, 6 May 2011 (UTC)
- While we're talking about updates, you know how when you edit a page you get the bazillion WAIT! warnings and directions? Can we get a simpler one on the Special:Upload page telling people about the standard image templates? I always have to look up the {{kolimage}} one, and I'm pretty sure there's another for images that had to be renamed, but I can't recall its name at all. (Post preview: I see Flagen's already standardized my last upload.) --Club (#66669) (Talk) 18:03, 3 May 2011 (UTC)
- Get someone to change MediaWiki:Uploadtext.--Toffile 18:07, 3 May 2011 (UTC)
- You're probably thinking of {{modkolimage}}. And I never even knew that page existed, Toffile. I can add some template links to that. --Flargen 18:32, 3 May 2011 (UTC)
- Nearly every message on MediaWiki is configurable without having to do an install. It's all in the MediaWiki namespace.--Toffile 18:38, 3 May 2011 (UTC)
I've updated the wiki to 1.17.0 --Mag 12:06, 25 June 2011 (CET)
- wfElement tags in the code were deprecated, I had to change those to the newer xml::element code tag
- Installed the ImageMap extension (http://www.mediawiki.org/wiki/Extension:ImageMap)
- Updated the ParserFunctions extension as per request
- Changed the cache backend to memcached instead of disk-based caching
- Woooooooooooo!!! Now to find all the templates this broke and de-break them. Looks like {{click}} is busted, but I think we wanted that anyway, and were going to replace that with normal wiki linking with the updated mediawiki. Thanks, Mag. --Flargen 13:56, 25 June 2011 (CEST)
- Good, if something is really really broken, e-mail me at mag@coldfront.net --Mag 14:37, 25 June 2011 (CET)
- The CSS for recipes are broken. Also if someone could turn down the size of "[EDIT]"...at least with respect to the rest of the text.-Toffile 20:22, 25 June 2011 (CEST)
- These are because our custom CSS files aren't being used right now. They're still there and intact, but just not being used. I've e-mailed Mag about it, but haven't heard back about it, other than a request for some examples. Infoboxes are also not formatting correctly due to this. --Flargen 23:43, 25 June 2011 (CEST)
- Is this due to /thekolwiki/skins/monobook/maincf.css not being loaded (I see it in the source) or have the HTML tags simply changed and the CSS needs editing ? (if so, send me an updated css) -Mag 10:56, 26 June 2011 (CEST)
- Ok, I added the following CSS in the MonoBook style, the skin we modified seems to be not fully backwards compatible with the new version, so it needs some hacking and slashing, is it good now or is there still stuff missing ?
<link rel="stylesheet" href="/thekolwiki/load.php?debug=false&lang=en&modules=site&only=styles&skin=monobook&*" />
- Okay, that seems to have done it. Recipe tables and such are now displaying correctly. --Flargen 12:19, 26 June 2011 (CEST)
- These are because our custom CSS files aren't being used right now. They're still there and intact, but just not being used. I've e-mailed Mag about it, but haven't heard back about it, other than a request for some examples. Infoboxes are also not formatting correctly due to this. --Flargen 23:43, 25 June 2011 (CEST)
- The CSS for recipes are broken. Also if someone could turn down the size of "[EDIT]"...at least with respect to the rest of the text.-Toffile 20:22, 25 June 2011 (CEST)
- Good, if something is really really broken, e-mail me at mag@coldfront.net --Mag 14:37, 25 June 2011 (CET)
- The things I've noticed so far are that EDIT for sections is on the left, shouldn't it be on the right after the heading? and smaller? The edit toolbar is missing (ex. the auto sig button, etc.), the enhanced recent changes aren't (un)collapsible because the js isn't working and the m and ! are gray instead of whatever colors they were. Location INFOBOXen aren't being floated right. Still, all these are display issues, all the complicated stuff seems to be chuggin' along. So yay! -JRSiebz (☎|§|‡)
- All of those, except perhaps the edit toolbar thing and the broken js, should be consequences of the wiki not using Mediawiki:Monobook.css and Mediawiki:Common.css, which contains things like the edit link styles and right floats for infoboxes. The others should probably be reported to mag (the CSS thing has been mentioned, but so far unresolved). We'll need to start phasing out now-deprecated templates, like the math ones mentioned above and click. Checking math parser functions:
- Floor of 13.1 = 13
- Ceiling of 13.1 = 14
- Sqrt of 13.1 = 3.61939221417
- Square root doesn't seem to be working/present. --Flargen 09:11, 26 June 2011 (CEST)
- All of those, except perhaps the edit toolbar thing and the broken js, should be consequences of the wiki not using Mediawiki:Monobook.css and Mediawiki:Common.css, which contains things like the edit link styles and right floats for infoboxes. The others should probably be reported to mag (the CSS thing has been mentioned, but so far unresolved). We'll need to start phasing out now-deprecated templates, like the math ones mentioned above and click. Checking math parser functions:
- Woooooooooooo!!! Now to find all the templates this broke and de-break them. Looks like {{click}} is busted, but I think we wanted that anyway, and were going to replace that with normal wiki linking with the updated mediawiki. Thanks, Mag. --Flargen 13:56, 25 June 2011 (CEST)
The sortable tables aren't working right now. I think we were relying on an extension for that? But every other javascripty thing is also missing (edit toolbar is still gone, list of recent changes no longer has collapsible sections, etc.) so perhaps it is something more fundamental. --Starwed
Did some poking around, I suspect that this might be a fix? Couldn't find a way to view current settings, though. --Starwed
- JavaScript should work again -Mag 18:50, 27 June 2011 (CEST)
- Thanks. However, the code for make tables sortable seems to be running twice. In firebug it actually shows that code (eg the ts_makeSortable function) in 3 places, in wikibits.js, which doesn't seem to be executed, but also in a call to load.php and in another call to load.php. --Fig bucket 15:03, 28 June 2011 (CEST)
- JavaScript should work again -Mag 18:50, 27 June 2011 (CEST)
I noticed that images aren't showing up on Cooking Discoveries, but also, my Monster Data pages are crapping out after the 7th row (I would assume because of the parser calls to Data pages).--Foggy
- Yeah, it's being cutoff at 30 parser calls (there should be a category that has pages with similar issues, it's been discussed a bit on the Mr. Shop talk page). There's a setting somewhere in Mediawiki that needs to be adjusted.--Toffile 20:36, 27 June 2011 (CEST)
- This should now be fixed, in addition to the image uploading (as Mag mentioned below). --Flargen 07:43, 30 June 2011 (CEST)
Has someone emailed about image upload being broken yet? It's mentioned in two sections of the page already, so maybe. --Club (#66669) (Talk) 20:37, 28 June 2011 (CEST)
- Yes. --Flargen 02:03, 29 June 2011 (CEST)~
Search problems
Something's going on that I don't fully understand. "upc sticker" doesn't show any results, and "sticker on" and "sticker to" only shows Mr. Store's page (which shows that 1. searches work on shorter words now, and 2. it's broken, since there are obviously other pages that show it if you search just "sticker"). Maybe it searches shorter words, but only to see if Mr. Store's page has it? --Raijinili 12:26, 27 June 2011 (CEST)
- Capitalization issue, I assume. Searching for UPC sticker works just fine (and is a redirect, in particular). --Flargen 13:45, 27 June 2011 (CEST)
- I could look into the Sphinx search engine if the search is really borky ? -Mag 18:52, 27 June 2011 (CEST)
- Search (don't "go") for "UPC sticker", Flargen. --Raijinili 00:46, 28 June 2011 (CEST)
- Huh, interesting. Who does "search" instead of "go", though? --Flargen 02:03, 29 June 2011 (CEST)
Image Uploading
Is apparently broken.--Toffile 22:49, 27 June 2011 (CEST)
- I noticed, too. Probably related to the wiki upgrade. --Club (#66669) (Talk) 20:37, 28 June 2011 (CEST)
- Image Uploads should work again -Mag 22:46, 29 June 2011 (CEST)
Localurl
The {{localurl}} parser function isn't working correctly - when I point it at an image, it gives me the URL to the "File:" page rather than the URL to the image itself (e.g. {{localurl:Media:Appendix.gif}} gives "/thekolwiki/index.php/File:Appendix.gif" instead of "/thekolwiki/images/a/ad/Appendix.gif"), which causes part of {{kolimage}} to not work correctly (specifically, the part that marks images located in "/a/ad/" so people using advert filters don't repeatedly try to reupload them). --Quietust (t|c) 20:18, 2 August 2011 (CEST)
slow updates
- the update queue seems really to have slowed to a crawl recently. i understand that a lot of edits will cause an appreciable slowing of the wiki. my deleting of the unneeded redirect to beaten up took close to two minutes to update. had it been a high-use page or a crowded time of day, or a large page with a great many edits this wouldn't have registered, but it was a quietish day, the page was a redirect (23 chars) and had only two edits. am i being unreasonable? --Evilkolbot 13:39, 28 August 2011 (CEST)
- Evilkolbot, I am experiencing the exact same thing! However, the Wiki IS updating the pages behind the scenes. You just don't see the change until you refresh the page manually, due to some odd caching behavior. --Wrldwzrd89 22:10, 28 August 2011 (CEST)
- i thought it was caching, but i both tried ctrl-f5 and searching but it still took no notice. i'll keep an eye out for something more concrete. --Evilkolbot 22:56, 28 August 2011 (CEST)
- It certainly is annoying. Refreshing the page doesn't always work, adding ?action=purge to the URL seems more effective, but even when it shows the current version of the page it will sometimes present an old version of a page when clicking edit. --Fig bucket 15:43, 16 October 2011 (CEST)
- i thought it was caching, but i both tried ctrl-f5 and searching but it still took no notice. i'll keep an eye out for something more concrete. --Evilkolbot 22:56, 28 August 2011 (CEST)
Collection still failing
Warning: fopen(http://wikidev.coldfront.net/rsscollection/ITEMID.rss) [function.fopen]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/coldfront/domains/kol.coldfront.net/public_html/thekolwiki/extensions/collection.php on line 22
I'm seeing this message an awful lot on newer item pages. Isn't there a way for extension modules to fail gracefully in MediaWiki 1.17, instead of spitting out stuff like THIS? --Wrldwzrd89 12:07, 1 September 2011 (CEST)
Place Radio Show Transcripts on Wiki
Since when do we host radio show transcripts on the wiki? --Quietust (t|c) 02:55, 14 February 2011 (UTC)
- This would be a first. I'm not sure if I like this idea or not. How does everyone feel about this idea? --Flargen 03:00, 14 February 2011 (UTC)
- Sounds like an awesome open invitation for vandalism. "Look, Jick said this, it's in the wiki transcript!" --RoyalTonberry 03:20, 14 February 2011 (UTC)
- Maybe we should leave this one here, just to see what people think about it. Do we need to mirror what's in the forums already? But long term, is someone going to go through all past (and future) radio recordings and transcribe them... accurately? There have been 2 shows a week for how many years now? Also, after one of these is finished the page could be protected to that only admins could change it. Though, I doubt it'd be necessary as vandalism on these pages probably wouldn't be an greater than on any other page, plus edits to them would stick out pretty obviously in the recent changes, even if just changes for a small spelling/transcription error. And, of course, Transcript: would have to be added as an official namespace on the wiki. Just something to think about. --JRSiebz (☎|§|‡) 04:17, 14 February 2011 (UTC)
- i'd have to vote no.
- the wiki is for game and meta-game content only. while the transcripts i've read try to address this (by leaving out the bickering and the your mom riffs) it's still not really something that mostly falls inside the wiki's remit.
- the 600-odd back-shows would be a problem since completeness geekery is definitely a vice we should be proud of.
- while the intent isadmirable, the endeavour awesome and the result both readable and informative, the execution is patchy and the format ugly and inconsistent. i have a feeling that "great job guys, please make it suck less" isn't going to be popular.
- process concerns aside, i doubt the people who transcribe in the forums could be persuaded to do it here instead, let alone as well. who would take on such a task otherwise?
- we all check in-game content all the time by playing it and reading the output. check the text can sometimes be tricky, but it's not overly so. who will take on the task of verifing the transcripts?
- there would be more, but i have to go. forgive poor proofreading, handheld blues. --Evilkolbot 13:04, 14 February 2011 (UTC)
I'm generally ok with this as a use of the wiki. Ideally it could encourage collaborative work on the transcripts --- the current ones are often paraphrased and occasionally misleading. The ability for someone to go in and expand just the interesting sections to be more accurate is nice, and isn't easily possible in anything except a wiki-like environment. The worst thing that could happen is an inaccurate transcript on the wiki, and how exactly is that worse than such on the forums? At least here it can be fixed by anyone who cares to, and in the case that it isn't no one is worse off than the current system. --Starwed 18:34, 14 February 2011 (UTC)
I don't think these transcripts belong on the wiki. Sometimes they are two hours of talking about stuff that isn't KoL.--P4n1q 20:25, 14 February 2011 (UTC)
- I tend to think of the wiki's mandate as serving a specific community, rather than collecting a particular type of information. --Starwed 21:25, 14 February 2011 (UTC)
- I'll vote yes. The transcripts are relevant to the game (in most cases), lots of wiki pages link to them in the forums already, and it's quite obvious they are popular with the community. Inconsistent labeling, the occasional use of the "radio show" tag for threads that are not actually the radio shows, and the need to sometimes page through lots of user posts makes the wiki a better place to archive them. Formatting can be addressed with templates, and if people really want to add old ones that makes an interesting project for them to get into wiki editing. I can't imagine they'd be so unpopular that gross transcription errors would persist for long, or at least no longer than other errors in the more obscure content-corners of KoL. A category would do, no need for a separate name space. I'd say leave them for now, see if people actually visit them and continue to add and maintain them; if it becomes an abandoned project then ditch it later if it's truly a burden. (nb I assume we're just talking about the official jick and/or skully shows, not other radio show transcripts). --Fig bucket 22:30, 14 February 2011 (UTC)
- the best thing about the wiki, for me, is its narrowness of purpose. we don't do everything, we do one thing the best we can. clarity of vision, perhaps. i really don't see that chats about this and that, even game design, have a place here, especially since they already have a home. —Preceding unsigned comment added by Evilkolbot (talk • contribs) on 23:25, 14 February 2011
- I vote no, but I would love (love) a project where we have a single page with links to Forum writeups of radio shows. It solves the editing / formatting / etc. issue. And it fits in with supporting the community, without "stealing" a community project that is thriving in the forums. --Quince23 23:37, 14 February 2011 (UTC)
Pages to Nuke From Orbit
Item Drops (By Location). Who uses it? Should it just be deleted? I ask because this page (like a number of others) tend to be neglected when it comes to keeping them updated. More importantly, it seems to have limited use. What I might recommend is instead a category tag Dropped Item (#location), which would be easier to update. Thoughts?--Foggy 14:29, 27 May 2011 (UTC)
- I wouldn't miss it, I can't say I was ever really aware of its existence. --TechSmurf 18:03, 27 May 2011 (UTC)
- Never used it, never even knew it was there. It seems like a rather inefficient way of doing things. --Lordebon 18:20, 27 May 2011 (UTC)
- Nuked. I think there are probably a bunch of derelict pages that should be destroyed, as they were probably never a very good idea in the first place, and will never likely be kept up-to-date and useful. Also: TheKolWiki:Pages for deletion. Although I am going to bring up something in this vein... --Flargen 20:09, 28 May 2011 (UTC)
Another page I thin that is worth nuking is Skills By MP Cost. It's a big-ass page missing a lot of skills, but for the life of me, I can't fathom the use of it. If the consensus is that it is useful, I'll update it.--Foggy 17:33, 6 July 2011 (CEST)
- What we really need is to be able to just put this kind of crap into a database and have metapages making queries to it. --Raijinili 15:43, 9 July 2011 (CEST)
- That would be awesome. For now those, we could tag skills with (Category:Skills by MP Cost,X), and nuke the page in the meantime.--Foggy 22:05, 9 July 2011 (CEST)
- Eh, I loathe to think of a large DB on this wiki. There's things that this server is good for...and unfortunately pages that attract a ton of edits isn't really it.--Toffile 22:29, 9 July 2011 (CEST)
- That would be awesome. For now those, we could tag skills with (Category:Skills by MP Cost,X), and nuke the page in the meantime.--Foggy 22:05, 9 July 2011 (CEST)
For now, I've edited the Skills By MP Cost page. I think this is something to come back to in about a year to see if people are in fact using it.--Foggy 17:01, 10 July 2011 (CEST)
- i'd agree that the manual restatement/summary pages really aren't worth the effort. Skills By MP Cost is an example of such redundancy, it should get nuked. replacement by Category:Skills (By MP Cost) in the same way we have Category:Food (By Size) would be just marvellous. Current Projects, anyone? --Evilkolbot 18:09, 10 July 2011 (CEST)
- If we were to do that, wouldn't adding a category to the Skills template based on the MP tag be easier?--Foggy 19:06, 10 July 2011 (CEST)
- what's beter than a cat? AUTO-CAT! splendid. could there be any objections? ahem. my template-fu is weak, and my time limited. any volunteers? --Evilkolbot 13:07, 12 July 2011 (CEST)
- Ok, there's a problem with this. Category sorting seems to show only the first character, and sorts alphabetically. So skills with MP cost 1 and 10 and 100 are all in the same category, and that seems unsatisfactory... --Fig bucket 20:23, 12 July 2011 (CEST)
- Yeah, I noticed that problem as well (and sorry about the trailing pipe, I thought I got that). Unless someone thinks this page is important, I say we table this page/issue for now and move on to more pressing pages.--Foggy 20:53, 12 July 2011 (CEST)
- Well, you could always create lots of sub-categories. 0-9, 10-19, etc., and throw in a pretty stupidly long switch statement to categorize each skill precisely (10 and 13 would both go into 10-19, and 10 would be under the 0 listing and 13 under the 3 listing, for example). Otherwise, yeah, I don't think there's a better way around it. Do we want the category deleted? --Flargen 21:15, 12 July 2011 (CEST)
- Ok, there's a problem with this. Category sorting seems to show only the first character, and sorts alphabetically. So skills with MP cost 1 and 10 and 100 are all in the same category, and that seems unsatisfactory... --Fig bucket 20:23, 12 July 2011 (CEST)
- what's beter than a cat? AUTO-CAT! splendid. could there be any objections? ahem. my template-fu is weak, and my time limited. any volunteers? --Evilkolbot 13:07, 12 July 2011 (CEST)
- If we were to do that, wouldn't adding a category to the Skills template based on the MP tag be easier?--Foggy 19:06, 10 July 2011 (CEST)
- On other wikis it is possible to generate tables based on other pages, has that been attempted here? 23:43, 21 September 2011 (CEST) —Preceding unsigned comment added by Dcorrin (talk • contribs)
Strategy Pages
We've got a number of ascension strategy pages, most of which are horribly out of date, and those that aren't tend to be horribly mundane or just plain bad/useless. I think we should delete the majority of these pages, especially the ones dealing with specific ascension types, and leave it to various kol players to write up and maintain their own strategy pages (likely on other sites, or possibly in their user space like stupac2's softcore guide). We could just have a single page that links to such pages, if anything. You can get much better advice from the more skilled players than from the mainspace pages, and pretty much none of them want to write a mainspace wiki article that would be subjected to the edits of others. --Flargen 20:09, 28 May 2011 (UTC)
- Taking a look at them...I'd probably keep stuff like LTSynergy as a historic note. It's no longer a really viable strategy, but it was kind of the most popular NS11 one.
- I would say to delete Advanced Hardcore, Ascension Strategy, Hardcore Class Strategy, both Location Analysis, Pulverizing, Sample Run, Item Analysis. Most of them are covered in other places in the list of stuff.
- I would probably say keep the Bad Moon strategy/sample run and Hoxy. They may need to get updated a bit, but it's still fairly good information to keep for readers of the wiki. Bees Hate You strategy is pretty good as is, it's more or less there for players to get an idea what to expect with unexpected territory. It'll also probably be good for whenever it's no longer the seasonal challenge.
- For the tea party hats one, I'd say that's fairly good. Having a good reference of the more easily obtained hats/buffs is a good way for people an allow them to learn and tweak their runs.
- Familiar/Skill strategy is also a good idea that should be kept. While having various listings of skills and familiar statistics is good, it does behoove as a collector of information to have some editorial discussion on what makes something good.--Toffile 01:35, 29 May 2011 (UTC)
I'd hate to lose the strategy pages just because we can't seem to get anyone to knowledgeably update them, but I do support paring down the total number of pages we have. One thing that struck me when I made some edits to Hardcore Strategy was the redundancy of information when combined with other pages.--Foggy 05:38, 30 May 2011 (UTC)
- I think Bad Moon Strategy (based off salticid's guide) should just point to salticid's guide, which is more up-to-date anyway. There's not much use copying a guide if it's not going to be improved.
- I'd vote for putting them into some sort of subpage for history purposes, and in case anyone wants to look at them for a reference for updating. So no on delete, yes on marking them "Outdated" with the date of marking (and say outdated pages should not be updated with new content).
- Another idea is a complete breakup of the pages into smaller pages. The problem with updating a strategy page is that you basically have to update ALL of it, rather than just some, for it to be useful. If there was some way to break it up into pretty-much-independent pages, it would be more likely to be maintained. Say, Bad Moon Food Strategy, Hardcore Combat Strategy, Hardcore Checklist, etc. Though personally, I don't even maintain my OWN goals checklist in my quest log. --Raijinili 22:20, 30 May 2011 (UTC)
GroupMonster template
I created a new template called GroupMonster, which is supposed to make group monsters easier to tag. However, the template is still a bit broken, and I can't figure out how to fix it. --Wrldwzrd89 02:35, 27 June 2011 (CEST)
Server downtime/midday-migration/spiders (June 27, 2011)
Is it worth adding the server downtime/midday-migration/spiders anywhere? --Itsatrap 00:35, 28 June 2011 (CEST)
- I saw someone started, and put the maint page message on talk, but I can't upload the spider image:
Upload warning
The upload directory (public) is not writable by the webserver. --Club (#66669) (Talk) 01:27, 28 June 2011 (CEST)
But what are they?
Just seen this on the front page: We've just made some changes on the wiki that might temporarily break things in very visible manners.
Very spiffy and all that, but it'd be nice to be told what the changer being made are, so that we can keep an attentive eye out for breakage of things that are known to depend on the changes. I don't see any notification of the changes apart from that front-page note; have I been looking for info in all the wrong places? --Kay Dekker 02:49, 2 July 2011 (CEST)
- It does sound cryptic if you haven't been following the discussion. But it's not a change to anything specific---mainly the mediawiki version was upgraded. This broke some things in real obvious ways; mostly fixed now, but a variety of issues are probably still lurking. --Fig bucket 03:17, 2 July 2011 (CEST)
- I created the announcement template as a general-purpose thing that could be reused whenever we make major changes. It's happened a few times before (reformatting item data pages, for example). Perhaps some extra (optional) parameters could be added to list specific changes/issues? Mostly I was expecting the main people to give enough of a care to post would already be familiar enough with wiki workings (the discussion page in particular) to know what's up. And also for future changes to not have their mention on the discussion page buried in the middle of the page, but be a bit more recent and towards the bottom. But I could easily be mistaken about those. --Flargen 09:18, 2 July 2011 (CEST)
tatter redirect
- the verb "tatter" is used to mean "use a tattered scrap to end combat."
- the link from this word to the imp ws intended to be a secret.
- given this, i'd say the redirect as is should stand. if there's a consensus the other way then fine but that's enough reverting either way. --Evilkolbot 11:11, 10 July 2011 (CEST)
- I personally don't care either way but I think there is something to be said about the fact that the redirect was to the imp for over two years but I do think this discussion is coming way too late. --Chunky_boo 18:38, 10 July 2011 (CEST)
- Both redirects seem valid to me, I don't think a disambiguation page would hurt anybody. On the other hand, I've never heard of anybody refer to the imp as tatter but tattered scrap is the typical shorthand for the combat item.--Melon 00:12, 11 July 2011 (CEST)
- It's not so big a deal for it to be a spoiler (who the heck knows about the puzzle but not about the answer?) but "tatter" IS a verb. --Raijinili 01:53, 11 July 2011 (CEST)
- Both redirects seem valid to me, I don't think a disambiguation page would hurt anybody. On the other hand, I've never heard of anybody refer to the imp as tatter but tattered scrap is the typical shorthand for the combat item.--Melon 00:12, 11 July 2011 (CEST)
- I personally don't care either way but I think there is something to be said about the fact that the redirect was to the imp for over two years but I do think this discussion is coming way too late. --Chunky_boo 18:38, 10 July 2011 (CEST)
Data pages and ambiguous names
While investigating ways of getting around the parser function limit for Monster Compendium pages by reworking Template:Monster to make direct use of the ability to dynamically format data pages, I came across an issue (which compounds into one ore more issues). The main problem is that several monsters (and items, etc.) have ambiguous names. For example, "7-Foot Dwarf" is the name used by two distinct monsters: 7-Foot Dwarf (Moiling) and 7-Foot Dwarf (Royale). This makes trying to do something like {{Data:7-Foot Dwarf (Moiling)|format=Monster}}
not quite function right. The formatting template would try to always link to 7-Foot Dwarf instead of 7-Foot Dwarf (Moiling), since it would always try to use the name
field, which can be ambiguous. I tried setting up inherent dynamic linking with the possibility for non-dyanmic (see option 1 below) at {{test}} by making it look for the data page only when it doesn't find the same-named data provided automatically. This, however, fails to resolve the ambiguous linking and also leads to template looping errors if a field has been deleted from the relevant data page. There's been a tendency for editors, myself included, to completely remove entries on a Data page that are blank. You can see from the current examples on {{test}} (assuming no one's edited since I last did and started typing this) what happens if you completely delete blank entries like quest
and pickpocket
. It breaks when they're absent completely, and functions fine if they're left there but "blank" (I added in blanks for the diary goat, but the drunk goat is missing them completely). So given this, I can think of two plausible resolutions:
- Make it a policy to leave blank entries on data pages, and go through by hand or bot and add missing entries as blanks to all existing data pages. This has the downside of running counter to existing editing trends, as well as necessitating a fair amount of edits. On the plus side, it lets one structure a template so that it can be called as a dynamic formatting template, OR indirectly/non-dynamic. A dynamic call (like
{{Data:dairy goat|format=Monster}}
only needs a single call to the data page to get everything from said data page, whereas an indirect call (like{{Monster|name=dairy goat}}
has to load the data page each time it wants a specific entry from the data page. Being able to do either-or means we have a bit of flexibility, should we find there's a template we sometimes want to use dynamically and other times we don't. In this particular case, we could use dynamic for unambiguous monsters/items/etc., and non-dynamic for ambiguous ones, to make sure links behave as desired/intended. On the downside, that could be a little weird to constantly switch how the template is called on a single page like the Monster Compendium pages. - Add an optional
link=
to the data pages of ambiguously named monsters/items/etc. Then we can just make it so every template that is intended to be used in a dynamic call will use thelink
value for all links, if found, otherwise it will link to thename
value by default. This has the upshot of requiring far fewer edits: only ambiguously named items/monsters/etc. will need it added to their data pages. Unambiguous pages would work seamlessly with no further changes. We'd have to find these pages, but Category:Disambiguation should help a lot with that. Primary downshots are that it means templates won't be quite as well-suited for both dynamic and non-dynamic usage (but I'm not sure there's any this would be relevant for with a built-in way to handle ambiguous names), and how to make ambiguously named pages not cause various malfunctions in other templates may be a little unclear to less well-informed editors (which can be partially resolved by making a note on a standards page or something like that, and may not be a big issue since most of the pages where this would be useful are maintained by our power users).
The second one is my personal preference, but I wanted to see if others had some opinions on them, or extra alternatives to suggest. And sorry if that was needlessly long-winded. I am rather prone to doing that. --Flargen 22:56, 13 July 2011 (CEST)
- The reason the drunk goat breaks on {{test}} is because it's falling back to a {{Data}} lookup (since the {{{parameter}}} is undefined), which you aren't supposed to do when instantiating the entire data page using the "format" parameter. The way the data page template was designed, you're supposed to delete fields to give them the "default" value - if you do "{{Data|drunk goat|pickpocket|Undefined}}", it will return "Undefined" because the pickpocket field was not present, but if you do "{{Data|dairy goat|pickpocket|Undefined}}", it will return "" because the field was present but left blank. If you look at the data pages themselves, you'll also notice that Data:Drunk goat displays "Pickpocket-only items - (none)" while Data:Dairy goat displays "Pickpocket-only items - ". --Quietust (t|c) 23:13, 13 July 2011 (CEST)
- Yes, I realize why it's doing that. The error is happening because I'm trying to make option 1 happen: the template can be used both dynamically or not. For that to happen it both has to look for the parameters to already exist, and if not (assuming a non-dynamic call as a result) it looks for an associated data page with the parameter. So as you note, when the parameter is missing entirely from the data page, this results in a looping error on a dynamic call to the template (but not a non-dynamic). And, yes, I've noticed that the meta-data display gets mucked with a bit; another downside to option 1. I assume that's because the link break appears before the pipe, but I'm not sure; I recall moving the line break after the pipe didn't fix a similar issue with {{battle}} not responding to a blank input correctly. By contrast, my intent with option 2 is to code up templates as either always assuming dynamic calls (all inputs are passed into the template directly, through data page formatting or other) or non-dynamic (all inputs are pulled one-by-one from data pages); not trying to do both depending on the input situation. --Flargen 23:22, 13 July 2011 (CEST)
- What exactly is the advantage of allowing the template to be used both ways? --Quietust (t|c) 23:29, 13 July 2011 (CEST)
- Without adding a link parameter, most dynamic calls to templates would provide erroneous links on pages that had to be given a special name to deal with ambiguity (such as the dwarves). A template that could be used both ways could be used dynamically for a page with no naming ambiguity, and non-dynamically with, to always give proper links. As I said, this would lead to using several different template call formats on pages like the Compendium ones, which would likely lead to an undesirable confusion amongst editors. With a link parameter to help us handle naming ambiguities, I can't think of any template that would be good to be able to use both ways. --Flargen 23:40, 13 July 2011 (CEST)
- I think the basic idea here is that option 1 is a bit ludicrous and would require far too many changes and edits. So any objections to just adding in
link
functionality to data pages/templates? --Flargen 08:38, 17 July 2011 (CEST)
- What exactly is the advantage of allowing the template to be used both ways? --Quietust (t|c) 23:29, 13 July 2011 (CEST)
- Yes, I realize why it's doing that. The error is happening because I'm trying to make option 1 happen: the template can be used both dynamically or not. For that to happen it both has to look for the parameters to already exist, and if not (assuming a non-dynamic call as a result) it looks for an associated data page with the parameter. So as you note, when the parameter is missing entirely from the data page, this results in a looping error on a dynamic call to the template (but not a non-dynamic). And, yes, I've noticed that the meta-data display gets mucked with a bit; another downside to option 1. I assume that's because the link break appears before the pipe, but I'm not sure; I recall moving the line break after the pipe didn't fix a similar issue with {{battle}} not responding to a blank input correctly. By contrast, my intent with option 2 is to code up templates as either always assuming dynamic calls (all inputs are passed into the template directly, through data page formatting or other) or non-dynamic (all inputs are pulled one-by-one from data pages); not trying to do both depending on the input situation. --Flargen 23:22, 13 July 2011 (CEST)
Tome / Libram / Grimoire pages don't consider Bad Moon
The Mystical Bookshelf item pages say this: "When placed on a player's Mystical Bookshelf, this item grants use of the skill [Summon Party Favor, for instance]. This skill can be used in all Normal and Hardcore ascensions thereafter." Clearly, the skills can not be used in Bad Moon, which is a Hardcore path. I think all we need is a little addition: "... and Hardcore ascensions thereafter, except Bad Moon." Don't you agree? --StorellaDeville 07:54, 17 July 2011 (CEST)
- NO permed skill is ever carried into Bad Moon. That was kind of the reason for its creation. I think the general idea for something like this is along the lines of the SGEEA and how we don't note on effect pages that it will remove the effect; we only note if it won't remove the effect. It's ALWAYS one way by default, and as such it is best to list that default at the primary page for the thing in question, and individual pages only get exceptions. --Flargen 08:38, 17 July 2011 (CEST)
Daily Activities
I've started a reworking of the Daily Activities page on the talk page for it. Speak up if you have opinions on the matter before I do it all, so I don't have as much to redo. Talk:Daily Activities#Reorganization. --Club (#66669) (Talk) 05:25, 31 July 2011 (CEST)
Data Page Additions
Monster types
We should probably add the 23 new types to Data:Monster pages. (That'll make templification easy, if nothing else.) Should we hold off until canonical names arise, or just arrogantly assume people will follow whatever convention we lay out? :) --Starwed 18:03, 1 August 2011 (CEST)
- The names seem to have settled down. "Unsquishable" is still a bit awkward and specific to the boots...perhaps "Special" as a type would be better? In any case it'd be nice to have the template altered to include monster type; names can be easily changed then if needed then too. (And, btw, copyable would be another nice attribute to add too.) --Fig bucket 16:08, 3 August 2011 (CEST)
- I'm proposing to add a field called
phylum
to monster data pages (Type has been overloaded to mean something else in the {{battle}} template), and use the {{Combat/meta}} template to tag any page without a phylum added to it. That'll create a list of all monsters that we can go through and fix, and hopefully make it easy for even wiki-noobs to help. - I don't think the unsquishable monsters are a special type -- I think they're just unsquishable, so while we can't currently ascertain what their type is, they still have one. The 22 known types I suggest we use as keywords are
- beast, bug, cosmic, crimbo, demihuman, demon, elemental, fish, goblin, hippy, hobo, humanoid, horror, mer-kin, object, orc, penguin, pirate, plant, slime, strang, undead
- I'm not super happy about stranger -- maybe weirdo would be better? Anyway, unless somone protests relatively soon, I'll start laying the groundwork to implement this. --Starwed 19:44, 5 August 2011 (CEST)
- Odd? Weird? What's wrong with using adjectives? If it later turns out there's a better name, you can just use #switch to make them appear in whatever convention we choose, right?
- While we're on the subject of stuff-we'd-like-to-add-to-data-pages, I'd like to see Group Monsters (what with it being a fundamental, but fairly rare, property that affects damage) and this "Mval" thing that's made its way onto {{meat}} (although as this won't actually change anything I'm not really sure why I want it...consistency, perhaps).--Ryo_Sangnoir 22:42, 5 August 2011 (CEST)
- I would also like to see all of these things implemented. I'd had the same idea for phylum instead of type (in relation to Races of the Kingdom instead of thinking of template parameter conflicts). Group monster would have to accept values indicating 1, 2, 3, 4, >4. Shouldn't be terribly hard, just have a default case in a switch that interprets to >4. And Mval is long overdue. I forget why we haven't switched over to that; intimidation from the sheer number of data pages that would need changing and verification, and/or concern about whether we keep in the current system for legacy matters or for incompletely spaded ranges? I don't think this is one of the things that was tossed on the back burner while waiting for the mediawiki upgrade, though I suppose it could be (we should have proper error-handling parser functions now). --Flargen 23:12, 5 August 2011 (CEST)
- On further thought, defaulting to >4 could be problematic, at least initially. Data pages don't have the field right now, so they'd all default to >4 until their data page was adjusted. We can make the data page pre-load give a default of 1, but do we want to have to edit every appropriate monster to group=1 just so they list correctly? --Flargen 02:34, 6 August 2011 (CEST)
- Okay, looks like we can get the switch to properly interpret an input string of >4 (or 4+ etc.). The next issue is: how to categorize those? If we make a single category with headings the group size, then we run into the issue that only the first character of the heading countings. So trying to categorize the page to "5+, <pagename>" will put it under the 5 heading, not a "5+" heading. If we make separate categories for each, then we run into issues of very small category sizes (there are very few monsters with exactly 4 in the group, but they do exist), as well as annoyingly long category names (Category:Group Monsters (more than four) is ick). --Flargen 02:44, 6 August 2011 (CEST)
- Maybe call any monsters which have a large, indeterminate group size can just be called "swarms." If there are any monsters which have a guessable size (text describes 6 individuals, for instance) we can put that down, I suppose. --Starwed 22:47, 6 August 2011 (CEST)
- I like phylum, and once these fields are part of the Data template, I can updated Monster Data's template to make it easier to figure out which monsters are still unknown. I'd like to see Mval too, and most of the monsters in the kingdom have been spaded. (The few monsters that remain are either one-per-ascension, wartime heroes, etc. that become difficult to spade).--Foggy 23:09, 6 August 2011 (CEST)
- I made Category:Monsters Needing Phylum and the associated template change yesterday, seems to have finished populating itself. I guess we just need to start adding data! --Starwed 23:16, 6 August 2011 (CEST)
- I've added phylum auto-cat'ing to {{battle}}. Currently it just dumps unknown/unsquishables into Combat Adventures, which is where (almost) everything was going before. This could be adjusted fairly easily if we have a consensus. We could even switch from auto-cating the data pages for unknown phyla to auto-cating the base page itself. The individual categories have not all been created just yet (only Category:Beasts so far). They seem to be working just fine, though. I've allowed a few alternative keywords for the same category. For example: odd, strange, and weird all give the same categorization, for monsters yielding strange paste. Others can be added (for other types, too) as seems warranted. Category names could similarly be adjusted. --Flargen 23:57, 6 August 2011 (CEST)
- Since it just came up: a ! should be used for monsters with indeterminate phylum (likely because that monster no longer exists). This is what's used for other fields when they can no longer be determined. --Flargen 12:46, 7 August 2011 (CEST)
- What do we do about Category:Bugs? It's already a category with a somewhat different purpose...do we need a new phylum name, or perhaps move the existing category to something like "Game Bugs"? --Fig bucket 14:21, 7 August 2011 (CEST)
- My first preference would be "Bugs (phylum)", but moving the existing category would be a good second choice. Renaming the phylum to something completely different just seems ill-advised. They make bug paste after all. --Club (#66669) (Talk) 18:58, 7 August 2011 (CEST)
- Huh, I completely forgot about that category. Changing the original Bugs category to Game Bugs sounds okay. --Flargen 03:24, 8 August 2011 (CEST)
- Ok, Category:Bugs is now Category:Game Bugs, and the former lists the bug phylum instead. --Fig bucket 14:52, 8 August 2011 (CEST)
- What do we do about Category:Bugs? It's already a category with a somewhat different purpose...do we need a new phylum name, or perhaps move the existing category to something like "Game Bugs"? --Fig bucket 14:21, 7 August 2011 (CEST)
- Since it just came up: a ! should be used for monsters with indeterminate phylum (likely because that monster no longer exists). This is what's used for other fields when they can no longer be determined. --Flargen 12:46, 7 August 2011 (CEST)
- I've added phylum auto-cat'ing to {{battle}}. Currently it just dumps unknown/unsquishables into Combat Adventures, which is where (almost) everything was going before. This could be adjusted fairly easily if we have a consensus. We could even switch from auto-cating the data pages for unknown phyla to auto-cating the base page itself. The individual categories have not all been created just yet (only Category:Beasts so far). They seem to be working just fine, though. I've allowed a few alternative keywords for the same category. For example: odd, strange, and weird all give the same categorization, for monsters yielding strange paste. Others can be added (for other types, too) as seems warranted. Category names could similarly be adjusted. --Flargen 23:57, 6 August 2011 (CEST)
- On further thought, defaulting to >4 could be problematic, at least initially. Data pages don't have the field right now, so they'd all default to >4 until their data page was adjusted. We can make the data page pre-load give a default of 1, but do we want to have to edit every appropriate monster to group=1 just so they list correctly? --Flargen 02:34, 6 August 2011 (CEST)
- I would also like to see all of these things implemented. I'd had the same idea for phylum instead of type (in relation to Races of the Kingdom instead of thinking of template parameter conflicts). Group monster would have to accept values indicating 1, 2, 3, 4, >4. Shouldn't be terribly hard, just have a default case in a switch that interprets to >4. And Mval is long overdue. I forget why we haven't switched over to that; intimidation from the sheer number of data pages that would need changing and verification, and/or concern about whether we keep in the current system for legacy matters or for incompletely spaded ranges? I don't think this is one of the things that was tossed on the back burner while waiting for the mediawiki upgrade, though I suppose it could be (we should have proper error-handling parser functions now). --Flargen 23:12, 5 August 2011 (CEST)
Odd note. I was modifying the monster phylum en masse by using the Monster_Data_(Y_to_Z) etc.. pages. When I rechecked them to make sure that I hit all of them I noticed something weird. Why don't bosses appear on those pages? (Zombo should be the last entry, but he's missing, same with The bonerdagon and the knob goblin king. Any ideas? --Serin 18:02, 7 August 2011 (CEST)(edit: de-intented)
- (De-indent) Serin, as far as I know the monster lists for those pages are generated manually, so the general reason is "whoever added them in the first place didn't add those". Also, as a result of adding phylum=? to everything, it would be useful to add Monsters Needing Phylum and Impossible Phyla to the battle template, under ? and !. I mean, it would have been nice anyway, but even more now.--Ryo_Sangnoir 21:50, 7 August 2011 (CEST)
- I believe I figured out why they weren't on there, They don't show up under Category:Combat Adventures. I've asked if the category can be an addition to the infobox template on it's discussion page to keep everything consistent. My logic is, If it has a combat infobox it must be a combat adventure, with the exceptions being few and far between.. So, it might be easier just to modify the ones that have the category and don't need it rather than the converse..--Serin 22:08, 7 August 2011 (CEST)
- Pretty much, you hit the nail on the head. To create these pages originally, I used the Category:Combat Adventures to give me a list of every combat adventure in the game...except it apparently was missing several. Missing ones need to be either manually updated, or adventures missing the combat adventure category need to be correct, and once done, I'll go back and recreate the pages (which does not take very long).--Foggy 16:21, 8 August 2011 (CEST)
- We can soon adjust how the battle template responds to ! and ?. The original implementations by starwed were categorizing the data pages missing a phylum entry. It's not difficult to change that, just hadn't gotten around to it. --Flargen 03:24, 8 August 2011 (CEST)
- Another minor change needed to the Battle template: it currently categorizes Hobos as Hippies. --Fig bucket 14:52, 8 August 2011 (CEST)
- Whoops. Fixed. --Flargen 02:53, 9 August 2011 (CEST)
- Another minor change needed to the Battle template: it currently categorizes Hobos as Hippies. --Fig bucket 14:52, 8 August 2011 (CEST)
- I believe I figured out why they weren't on there, They don't show up under Category:Combat Adventures. I've asked if the category can be an addition to the infobox template on it's discussion page to keep everything consistent. My logic is, If it has a combat infobox it must be a combat adventure, with the exceptions being few and far between.. So, it might be easier just to modify the ones that have the category and don't need it rather than the converse..--Serin 22:08, 7 August 2011 (CEST)
With the advent of the boots, one finds himself often wondering about what monster to squish, and having phylum information on the zone pages would therefore be invaluable. To me, the best place would be where "(edit metadata)" is in Template:Combat, right after the monster's name.
Whatever the location and formatting, could someone please include that information in the template? I can't because it's protected... --Groli 17:09, 24 August 2011 (CEST)
Mval support
As far as the other suggestions go, I've added Mval support to the infoboxes on monster pages. See Dairy goat for an example. Working on adding it to all of the other templates that use the meat entry on the data page. I should probably create a helper template to compute the range, come to think of it, since that'll be the most typical application of the datum. --Flargen 09:25, 7 August 2011 (CEST)
- Created the utility template {{meat range}}. I've added Mval support (and preference) to the following:
- {{combat rows}}, and by extension {{combat}} (for location page entries)
- {{INFOBOX_Combat}}, for monster infoboxes
- {{Combat/meta}}, for displaying the data pages
- {{Combat/data}}, for pre-loading data pages
- These all have legacy support for
meat=
, with theMval=
entry preferred if it exists; it won't use the meat entry if Mval exists. The exception being Combat/Data, which no longer loads up a meat entry at all. Any others that need changing? --Flargen 10:10, 7 August 2011 (CEST)- First, thanks for doing this :).
- If we're keeping both meat and Mval on older pages (looking at dairy goat for now), why shouldn't we generate it in the data? Mval is, unlike most of the other information, entirely opaque; although I suppose people tend to leave the meat blank or only put it on the page in the first place, so I'm divided on this, I guess.
- Also, does {{Data:{{PAGENAME}}|format=Meat}} use only the Mval? How does that work? --Ryo_Sangnoir 12:09, 7 August 2011 (CEST)
- Yes, it uses only the Mval. If "meat" were an acceptable input to {{Meat}}, it might attempt to use that entry, instead. But it isn't. This is a particular application of the dynamic formatting of data pages. Notice how every entry on the data page looks like it's passing in a value to a template? That call sticks all of those into the Meat template (in this case), and the Meat template uses whatever inputs it finds applicable. This might be a slight overkill here since it is only using the one bit a data. We could also use: {{meat|Mval={{Data|{{PAGENAME}}|Mval}}}}, but this isn't much savings: it's using #switch instead of Meat as the formatting template. To really understand how it works, you might want to carefully analyze the exact structure and content of a data page, and then figure out what template calls like this are doing. It's what I had to do.
And the opaqueness of the Mval parameter was something I was also concerned about, and am not completely settled on. I'm open to people's opinions. It's kind of a matter of whether we considermeat=
to be deprecated and legacy or not once we've fully implemented Mval. I know of no exceptions to the Mval rule; at worst we might have to tweak the code a bit to better deal with very small Mvals (like with fluffy bunnies, perhaps). So really the meat entry's only real use would seem to be in retaining support of its pre-existing uses so we don't break the wiki as visibly while we upgrade to Mval. Mval can be used to do anything that meat can, and more. --Flargen 12:28, 7 August 2011 (CEST) - Oh, and I kept both parameters on Dairy goat since I wasn't sure if I'd missed an important template that relied on meat, but which I had not added in Mval support to. I suppose it might be easier to hunt that down if meat was removed. However, my goal in these sorts changes is to limit breakage and loss of functionality as much as possible. --Flargen 12:36, 7 August 2011 (CEST)
- I think the key there was that I had no idea what "format=" did. Thanks for the explanation.
I removed themeat=
entry from completely different spider then checked all pages that linked to the data - {{MonsterRow}} used in the Data page lists is the only one I found that still requires ameat=
entry. I would like to deprecatemeat=
simply because Mval is better. We should really write a subsection on Mval (and its relation to the Mer-kin hookspear where it's the "base Meat drop" mentioned) in the same manner that I really should have updated the section on monster defense several years ago.--Ryo_Sangnoir 22:07, 7 August 2011 (CEST)- Seconded on the mval and defense write-ups. Those have been overdue for quite some time. I'll go update MonsterRow if it's still needed... --Flargen 03:24, 8 August 2011 (CEST)
- Oh, right, MonsterRow is a template I was wanting to update to use dynamic formatting. But I hit the snag that the monster name is sometimes different from the monster's page name, and thus we would need to add a
link=
parameter to data pages to generate the correct page links. I mentioned this somewhere in discussion. Further down the page or in the latest archive. Since the pages that seem to use this template are probably only used by a couple of power editors/spades looking for gaps to fill, I'm going to go ahead and change MonsterRow to be dynamic, and we'll have to start adding in link parameters to data pages that need them. --Flargen 03:29, 8 August 2011 (CEST)- Done. --Flargen 04:23, 8 August 2011 (CEST)
- Defense is already present - I went looking for it after I posted that - it's on Monsters, spread out over two sections. Could add Mval to the Meat from Monsters page - I can't think of a better place for it.--Ryo_Sangnoir 14:17, 8 August 2011 (CEST)
- Added the basic info. Further edits welcomed.--Ryo_Sangnoir 14:39, 8 August 2011 (CEST)
- Done. --Flargen 04:23, 8 August 2011 (CEST)
- Oh, right, MonsterRow is a template I was wanting to update to use dynamic formatting. But I hit the snag that the monster name is sometimes different from the monster's page name, and thus we would need to add a
- Seconded on the mval and defense write-ups. Those have been overdue for quite some time. I'll go update MonsterRow if it's still needed... --Flargen 03:24, 8 August 2011 (CEST)
- I think the key there was that I had no idea what "format=" did. Thanks for the explanation.
- Yes, it uses only the Mval. If "meat" were an acceptable input to {{Meat}}, it might attempt to use that entry, instead. But it isn't. This is a particular application of the dynamic formatting of data pages. Notice how every entry on the data page looks like it's passing in a value to a template? That call sticks all of those into the Meat template (in this case), and the Meat template uses whatever inputs it finds applicable. This might be a slight overkill here since it is only using the one bit a data. We could also use: {{meat|Mval={{Data|{{PAGENAME}}|Mval}}}}, but this isn't much savings: it's using #switch instead of Meat as the formatting template. To really understand how it works, you might want to carefully analyze the exact structure and content of a data page, and then figure out what template calls like this are doing. It's what I had to do.
(De-indent)
So it turns out that, if the data on the page is to be believed, possessed can of tomatoes has a range of 2-4, which implies that the range has a minimum of 1. This could be fixed by checking if the Mval is less than 5 and flipping the round up/round down if it is; else we could just ignore this single case. |meat= will also continue to be used on the page darkness.--Ryo_Sangnoir 00:30, 12 August 2011 (CEST)
- Fixed the tomatoes issue (which does have a 2-4 base range). Had to implement {{min}} and {{max}}. Simple two-input versions. We don't seem to have built-in parser functions for min and max. They're very simple to write up as a template, though. I suppose there will be an issue if there is ever a case of Mval=1, unless 0-2 is the actual range observed in-game. I'm not expecting that to come up, though. It can be fixed if it does, once we know how the game actually handles such an oddity. And good catch on darkness. That will mean a meat parameter will always need to be supported; that or error handling has to be added to the Mval stuff to detect non-numerics. --Flargen 01:11, 12 August 2011 (CEST)
- We'll have to keep in meat support for monsters that were retired before ns13 (or whenever the change to upper meat limit was made): while the mval for Gnollish Sorceress and Gnollish Bodybuilder can be obtained from the average meat drop on the page itself, the upper limit would be generated incorrectly.--Ryo_Sangnoir 12:36, 12 August 2011 (CEST)
- Ah, yes, another good point. While we're talking about meat/Mval, I'd like to change the de facto standards for "none". Absent values really should be treated as unknowns. In order to keep meat support in, an absent Mval has to result in defaulting to meat, but if the meat value is also absent (or just an empty string), we should be interpreting that as unknown. Setting meat=0 or Mval=0 (or none/None) should be getting interpreted as None in the changes I've been making. Currently I've made most templates interpret both values missing as meaning "none", since that's what most data pages have been edited to assume. {{MonsterRow}} is an exception (unless it's been edited), and could be used to ferret out data pages not conforming to the new standard. I'd like that to be the standard for data pages in general: missing fields are interpreted as unknown (or unknown-analogue), except for fields deemed strictly optional (like the
link
one I've added in). One has to be a little careful with this, since code of the formparam=|
is actually distinct from a completely missing param entry, as far as wiki parsing goes. Switch statements have to be used to properly pick up on the string "" and interpret it as a missing value. I've already added such things to {{battle}}, since it always annoyed me that a blank entry for a message field (something many people do by nature) was never interpreted as unknown, and simply resulted in a blank string displayed. --Flargen 13:33, 12 August 2011 (CEST) - I've been adding Mval=0 to monsters with no meat. It also seems sensible to do the same thing for items, and element. I'm not keen on adding bounty=none, quest=none, pickpocket=none to vast numbers of pages, though - most monsters have nothing in those sections, so I'd like to keep that optional.
- As an aside - is there a place I can add monsters which need their meat drops checked, where people who spade that sort of thing are likely to see it? 7-Foot Dwarf Foreman is likely Mval=60, but it could be 61, and was last checked by Yiab before the changes, back in 2006.--Ryo_Sangnoir 14:32, 12 August 2011 (CEST)
- I thought I had gotten that zone, but apparently not. My userpage has a list of monsters that were remaining to have their meat drops spaded. Most required special spading techniques. (For DD monsters, booty crab, and cyrpt bosses, you have to use a meat vortex and then run away). Others are monsters we may never be able to properly spade (war heroes, e.g.).--Foggy 15:57, 12 August 2011 (CEST)
- Went through the locations in areas by number. Added Mval. Here are some to look out for:
- Ah, yes, another good point. While we're talking about meat/Mval, I'd like to change the de facto standards for "none". Absent values really should be treated as unknowns. In order to keep meat support in, an absent Mval has to result in defaulting to meat, but if the meat value is also absent (or just an empty string), we should be interpreting that as unknown. Setting meat=0 or Mval=0 (or none/None) should be getting interpreted as None in the changes I've been making. Currently I've made most templates interpret both values missing as meaning "none", since that's what most data pages have been edited to assume. {{MonsterRow}} is an exception (unless it's been edited), and could be used to ferret out data pages not conforming to the new standard. I'd like that to be the standard for data pages in general: missing fields are interpreted as unknown (or unknown-analogue), except for fields deemed strictly optional (like the
- We'll have to keep in meat support for monsters that were retired before ns13 (or whenever the change to upper meat limit was made): while the mval for Gnollish Sorceress and Gnollish Bodybuilder can be obtained from the average meat drop on the page itself, the upper limit would be generated incorrectly.--Ryo_Sangnoir 12:36, 12 August 2011 (CEST)
majorish:
- gaunt ghuol
- gluttonous ghuol - if upper limit is accurate, changed after introduction.
- modern zmobie
- Knott Slanding (hah! haha!)
- generic duck
- war heroes
- War Frat Elite 500th Captain - it was at 200-300 before Enevhar changed it to 100-300 - it may have been nerfed to 100-150?
- Skate Board member
- Molehill
- booty crab
- wandering bees
- nemesis assassins
minorish:
- 7-foot dwarf foreman
- upgraded ram - 80-130 was probably a typo, I suspect it's 80-120. (Foggy: probably. I checked my notes and confirmed 80-120 is the correct range)
--Ryo_Sangnoir 18:58, 12 August 2011 (CEST)
- Well, you could always just add {{NeedsSpading}} or {{NeedsConfirm}} to the page. That makes it pretty clear on the page itself. A change to {{MonsterRow}} could be made to indicate if it is using meat or Mval, as well. --Flargen 23:16, 12 August 2011 (CEST)
Link
As detailed above, it would be helpful if data pages could contain a link=
parameter, to facilitate dynamic data formatting on pages for monsters (and possibly other things to come) whose names are ambiguous. --Flargen 04:19, 8 August 2011 (CEST)
Updated MonsterRow to be used as a dynamic formatting of the data page. To resolve linking issues this would cause, this necessitates that monsters whose stored name is different from the page name have an extra link=
parameter added to their data page, which stores the actual name of the page. I've done this for a few monsters, but not all of the applicable ones. Those whose name is the same as their pagename do not require this parameter be added (but it wouldn't hurt). Could probably set the preload to automatically set this; would only need to be changed on a move. --Flargen 04:22, 8 August 2011 (CEST)
- Preloading up the pagename should now be in place. Just have to add it into existing ambiguous monster data. I made it load up {{subst:PAGENAME}} as the value. Looked like not using the "subst" wasn't going to work, but I suppose it's possible I didn't test the right permutations for that. --Flargen
- Okay, turns out that doesn't work at all. Going to take some thinkin' to figure out of it's possible to do what I was looking to do. --Flargen 05:06, 8 August 2011 (CEST)
Group Monster Size
Requested, to be implemented. There's a potential issue with categorizing properly mentioned in the first subsection. --Flargen 04:19, 8 August 2011 (CEST)
- My vote would be:
- If it's 1, categorise nowhere - that's not a group.
- If it's 4 or more (we can't tell the difference between 4 and more than 4 mechanics-wise, right?), put it in group monsters under "U" or something - we don't know these exactly, but want them to come after the other numbers.
- If it's two or three, put it under 2 or 3.
- Default to one.
I don't know about the benefits of having multiple categories - I can't see the use. I don't think there are that many group monsters.--Ryo_Sangnoir 14:23, 8 August 2011 (CEST)
Post-Valhalla Revamp Stat Gains
Has it been taken into consideration that, now that all signs (sans Bad Moon) have an intrinsic +% gain to a particular stat, it may be more difficult to find the actual stat gains from new consumables? Have any of the new post-vamp consumables been double checked for that? I doubt everyone that has added info about the new pastes took into consideration their sign. --Erich 21:29, 2 August 2011 (CEST)
- Yes, this is something of a problem. I tend to forget it myself. We can modify our series of editing warnings to mention this specifically, but that won't stop every erroneous entry (just as they didn't stop them all before, when it was just stat days in the way). Looks like several of the warnings could use updating, in fact. Otherwise, there's probably not a whole lot that can be done other than relying on attentive and critical editors keeping an eye on such things. There will probably be one or more reliable spaders that will generally take on the task of verifying consumption gains, but you can't always be sure of that. Spaders come and go, often unannounced. --Flargen 00:13, 3 August 2011 (CEST)
Hatchling Familiar Association / Template Change Request
- This is something that's been bugging me for ages. Why don't hatchlings have a place in their item template for "Becomes: <Familiar>"? Just putting it in the notes seems like a clumsy solution, and often means you have to scroll down to see what is (IMHO) the single most important piece of information about a hatchling. Someone brought this up on back page 7, but that post was poorly formatted and apparently didn't get any attention. Therefore I would like to suggest, once again, that the template be changed to include this information. If that can be done, I volunteer to personally update all the hatchings to use the new format.--ManaUser 03:33, 7 August 2011 (CEST)
- Because the {{item}} template is meant to reproduce the in-game appearance of the item description, and almost nothing else that's immediately visible (it also does some categorizations that appear at the bottom of the page). We add very little extra to this. A link or two to a few things, and some descid and itemid stuff in the upper right corner. The {{useitem}} template, however, is formatted to provide links to what the familiar becomes. Click the second image that appears in the When Used item section and it will take you to the actual familiar page. This was added back when the game itself started providing this image. --Flargen 03:38, 7 August 2011 (CEST)
- Well, at least that makes some sense. I still disagree with it, mind you, but I'm glad there's a reason. I didn't know about clicking the image, but that's still not very convenient or obvious.--ManaUser 06:01, 7 August 2011 (CEST)
- Well, I'm willing and interested to hear what other people have to say about it. I think we've had various discussions about the balance between "more usefully obvious" and "things that require laboriously complex or potentially impossible implementations". Mostly in relation to whether we should list what benefits an effect provides on item and adventure pages somehow, instead of solely on the effect pages. --Flargen 06:04, 7 August 2011 (CEST)
- Well, at least that makes some sense. I still disagree with it, mind you, but I'm glad there's a reason. I didn't know about clicking the image, but that's still not very convenient or obvious.--ManaUser 06:01, 7 August 2011 (CEST)
- Because the {{item}} template is meant to reproduce the in-game appearance of the item description, and almost nothing else that's immediately visible (it also does some categorizations that appear at the bottom of the page). We add very little extra to this. A link or two to a few things, and some descid and itemid stuff in the upper right corner. The {{useitem}} template, however, is formatted to provide links to what the familiar becomes. Click the second image that appears in the When Used item section and it will take you to the actual familiar page. This was added back when the game itself started providing this image. --Flargen 03:38, 7 August 2011 (CEST)
Categories updating very slowly
It seems to me that categories are taking quite a while to update -- Category:Beasts is still coming up as empty, although many individual pages like the Zombie duck were placed there hours ago. Maybe the delay is necessary to prevent the wiki from lagging out? Just thought I'd see if anyone knew more about this. --Starwed 06:23, 7 August 2011 (CEST)
- Yeah, I noticed a similar issue with the "too many expensive parser functions" category not emptying out after we had the limit raised accordingly. I suppose we should contact the even-higher-ups-than-us, see if this is the result of a setting being reset in the new mediawiki, or something else. --Flargen 06:29, 7 August 2011 (CEST)
- It's basically due to the jobs queue being overloaded. There's nothing really much to be done, this is how it was on the old wiki as well. It just needs some time to process. If you want to fast-forward it, commit a null edit to a page.--Toffile 06:53, 7 August 2011 (CEST)
- But of course there's something that can be done -- the rate at which the jobs queue is processed can be changed, although whether that's a good or bad idea is not for me to judge. (Oh, and since it was removed from statistics, here we can see the approximate current job queue.) --Starwed 06:59, 7 August 2011 (CEST)
- Job queue might be a bit high since some of the templates that have been edited for adding in phylum support are rather high-use, so it has to propagate the changes through a bunch of pages. --Flargen 07:05, 7 August 2011 (CEST)
- I seem to recall that the job queue processing rate was set to some really low value several years ago in response to these sorts of edits slowing the entire wiki to a crawl. I suspect it's still configured that way, though I'm not sure if it's still actually necessary... --Quietust (t|c) 21:51, 9 August 2011 (CEST)
- But of course there's something that can be done -- the rate at which the jobs queue is processed can be changed, although whether that's a good or bad idea is not for me to judge. (Oh, and since it was removed from statistics, here we can see the approximate current job queue.) --Starwed 06:59, 7 August 2011 (CEST)
The jobs queue is now ~10 times what it was on the 7th, with 17000 jobs to be done. --Starwed 17:09, 8 August 2011 (CEST)
- Holy smokes! 17,000? Where did all of those come from?! --Flargen 02:30, 9 August 2011 (CEST)
- Is it perhaps a naïve queue that can result in a page being in the queue multiple times from multiple different edits? Edit all those mvals in, then edit all those phyllums in, ... --Club (#66669) (Talk) 19:31, 9 August 2011 (CEST)
- The newest mediawiki is actually pretty smart about the queue and while it looks like a large queue, once it gets going, it starts combining duplicate page entries and the queue goes much more quickly. -- sulfur 00:08, 10 August 2011 (CEST)
- Is it perhaps a naïve queue that can result in a page being in the queue multiple times from multiple different edits? Edit all those mvals in, then edit all those phyllums in, ... --Club (#66669) (Talk) 19:31, 9 August 2011 (CEST)
Dry noodles info all over the place
Hey all, I was frustrated because the dry noodles page which I usually use for reference doesn't say which basic ingredients are necessary to make chow meins, but then I found that there are tables with similar info in Pastamastery, Transcendental Noodlecraft and dry noodle guide as well as in the specific pages for Reagent dish, Lo meins, Chow meins, Hi meins, etc.
Not all information is present everywhere, and even stats and advs gain figures vary (not just the recent/rarely used items: even reagent pasta...). I was beginning to work on regrouping all of this mess, but I think there should first be some discussion about what we want in the end. I'm thinking of doing it on the cocktailcrafting model:
- Pastamancery/Transcendental Noodlecraft: all of the up-to-date info, giving the ingredients and stat gains for all dishes, color-coded for easier readability.
- dry noodles: scrap the tables, send the reader to the skills pages.
- dry noodle guide: scrap the tables
- All the dish-type-specific pages: DELETE.
What do you think? --Groli 01:50, 16 August 2011 (CEST)
- I'd add getting rid of the images in those tables; they don't add anything, particularly when most of themare exactly the same. I do see a potential problem with the stat gains and adventure variances cluttering up the tables (though such is limited to the olive/pr0n and asparagus/tofu types of lo and chow mein). Maybe there's some way to work around that? Or ignore it completely? Advanced Cocktailcrafting certainly does with its treatment of the swill drinks and banana drinks.
- Is there a particular need to keep the dry noodle guide at all? The text on the page doesn't do anything but offer opinions (some of which are outdated) and rehash of information which can be gleaned from the tables themselves. I would hope that people wouldn't need the wiki to tell them that adventures per fullness is the (average) adventure gains divided by the fullness of the dish! The information on level requirements would be helpful, though (and probably should be added to the cocktailcrafting pages, too).
- It would probably make sense to modify Template:CookingNav so that it resembles Template:Cocktailcrafting, particularly to remove the links to the dish-type pages and the links which partially duplicate Template:Craft.--Quackosaur 18:20, 16 August 2011 (CEST)
- Any feedback on the work in Pastamancery/Transcendental Noodlecraft? --Groli 20:32, 16 August 2011 (CEST)
- Do the tables particularly need an "Average Adventures per Fullness" column (which I recognize that you didn't put in there)? Also, is there a particular reason to sort things alphabetically? Am also curious if the stat gains and adventures were completely spaded or altered in the consumables revamp last year. For the weaker/different chow meins and lo meins, I suppose the tables could get new headings to reflect different adventure/stat gains.--Quackosaur 16:35, 17 August 2011 (CEST)
- I personally mentally calculate avg. advs per full a lot, so I'd say that the info is useful. There must be a way to include that too without hurting readability too much...
- I thought about putting additional header lines for the lesser lo meins and chow meins, but I feel that it would make things slightly worse. I'm not completely sure.
- As for the data, I went[1] and asked on the KoL Spading forums, and got no reliable source for consumable data. Wasn't there a script that harvested data, at some point? That should be included in mafia to make it a massive spading tool. --Groli 03:53, 18 August 2011 (CEST)
Games Mechanics/Modifiers Tables
I was fiddling around with Critical Hit Chance a few days ago. I started out intending to fix a few errors and omissions in the table but quickly found myself wanting to make a number of changes and realized that there doesn't seem to be any agreed-upon standard for these types of pages. For now I'll just mention some of the major issues I have:
- Ambiguous Types - The equipment types, food, booze, and skills are self-explanatory, but I have issues with the item, adventure, and effect types. (I'm generally ignoring incorrect categorizations.)
- Item - Split into "Spleen," "Potions," and something else (maybe just "Item"?). I partially want to do this because the "Cost" column annoys me. It virtually only applies to potions and the occasional skill. I would assume "item loss" would logically apply to food, booze, and spleen (and potion!) items, so having a column devoted to explicitly stating that would be redundant. The stomach/liver/spleen costs could just go in the "Notes" section.
- Adventure - Split into "Bad Moon (Adventure)," "Monster (Attack)," "Non-Combat," and maybe some other things. Including those all under the same category is misleading, and I don't think differentiation would harm anything. Words in parentheses are for completeness.
- Effect - Is this just the "miscellaneous" category? Some things seem sensible (like Clan VIP Pool Table buffs), but others I'm not so sure about (Holiday Bliss, for one)
So, TL;DR, types should actually reflect what things are. I don't particularly want to get into the source versus effect name issue. It leads me to thinking in circles. Some other random thoughts:
- Effects that can be sourced from many different types of things shouldn't be mushed together in the same entry. So something like Ninja, Please should have three distinct entries in the Critical Hit Chance table to reflect the three different types of sources, particularly because of the duration differences. Hyphenating or using an "x or y" structure in the table isn't amenable to sorting and can be misleading.
- Should every table have a "Hardcore Availability" column? Some do and I'd imagine that some Hardcore players could find a sort-able parameter useful.
- Would it be better to separate off an effect's additional modifiers into a column distinct from "Notes" (say, "Additional Modifiers")? Obviously, I don't want to make the table so horizontally long (which is why I also want to get rid of "Cost"), but some space savings could be achieved simply by inserting some appropriate line breaks in the row headings.
Making any of these changes would be time-consuming, but the tables seem as though they've needed some attention for quite some time.--Quackosaur 05:52, 17 August 2011 (CEST)
- I mostly agree. Maybe sorting by cost can sometimes be useful, though? Anyway, I'll add that the "Always" durations in front of every equipment should be blanked, to make the informative cells stand out. I'll do that right now on Crit. chances, it's as easy as a search/replace ;-) --Groli 04:05, 18 August 2011 (CEST)
So, I've been slowly updating the pages featured in Template:EquipmentList, and it occurred to me that Weapons (by power) and Weapons (by requirement) display the same information; the only difference is that the latter has a table for each requirement/general weapon type as opposed to a giant super table. Personally, I think the 3 separate tables version is slightly more useful, and one giant page is easier to maintain than two, so I'd favor nuking Weapons (by power) from orbit.
But then, this got me thinking: why maintain Weapons (by requirement) in addition to the separate Melee weapons, Mysticality weapons, and Ranged weapons pages? Those three pages don't contain anything that isn't already on (or could be on) Weapons (by requirement); again, it's just more to maintain for little or no benefit. Other than, "It's always been this way, so people are used to it," or concern about loading times for a larger page (I have no idea if this is actually a potential problem?), what argument is there for maintaining these pages as opposed to making them redirects to the sub-sections of Weapons (by requirement)?--Quackosaur 19:42, 3 September 2011 (CEST)
- First, let me say that I understand your frustration. There have been a few times I've gone through and done some massive updating of these pages and I know it's a) not fun b) questionably necessary and c) begging to made simpler. I'd rather see Weapons (by Requirement) nuked, as the one large table can be sorted easily. I also think that at some point, we need to better use metadata to help maintain these pages (similar to how the Monster Data pages only require the name of the monster on the list).--Foggy 19:05, 4 September 2011 (CEST)
- I've proposed deleting the extra weapons pages before, after we got sortable tables. It never went anywhere. But I can fix that in a jiffy. Furthermore, adding extra stuff to item data pages is something Eleron and I have proposed several times. The structure of the item data pages has been changed to the same structure that monster data pages use, so provided we can move data over there we can (re)write templates to use that in much the same way we do with monster data. There are two issues. One is that there are a ton of item pages. Second is that there are several dozen parameters for any given specific sub-type of item, and not all of these are fixed for a given item (jell-o shots have multiple possible results), and perhaps not all (or definitely all) should be migrated to data pages. I'm fairly sure I know how to write things up to handle these issues, but it's a lot of work all told, and will result in some pages having very complicated data pages. That's why it hasn't gone anywhere in months, or advanced since mediawiki upgrades made certain things easier to deal with. --Flargen 19:36, 4 September 2011 (CEST)
- Good to know...as a thought, would it be feasible to not just have Data: as a namespace, but also EquipmentData:, EffectData: and ConsumptionData:? It might help reduce some of the complexity?--Foggy 20:10, 4 September 2011 (CEST)
- It would prevent parameter collisions between different types, but things like {{useitem}} and {{item}} will need even more detection logic than they already do in order to access the correct namespace, or will have to be split up into several distinct templates. The latter would be easier, and is perhaps overdue. Those two templates in particular are practically monolithic. --Flargen 21:38, 4 September 2011 (CEST)
- I created a test template at User:Wrldwzrd89/Template:CombatItem, but I think I've mucked something up in my test. Flargen, I hope you find this useful. --Wrldwzrd89 22:35, 4 September 2011 (CEST)
- It would prevent parameter collisions between different types, but things like {{useitem}} and {{item}} will need even more detection logic than they already do in order to access the correct namespace, or will have to be split up into several distinct templates. The latter would be easier, and is perhaps overdue. Those two templates in particular are practically monolithic. --Flargen 21:38, 4 September 2011 (CEST)
- Good to know...as a thought, would it be feasible to not just have Data: as a namespace, but also EquipmentData:, EffectData: and ConsumptionData:? It might help reduce some of the complexity?--Foggy 20:10, 4 September 2011 (CEST)
Items by ID
(Note: I moved this thread. Still not in the right place, but at least it is at the bottom. Hopefully I haven't screwed up more here. --QVamp 16:16, 18 August 2011 (CEST))
I apologize if this has been discussed. I looked and couldn't find anything.
A few of the ash scripts being written by users, and several external sites, are linking to the wiki items to get more information. However, string linking is notoriously hard to do, and item names with HTML in them, or with foreign characters end up breaking and going no where (Bash-Os actual name still breaks the engine here).
If it is possible, could there be an additional way to link to items using their item #? Maybe something along the lines of index.php/item_num/2373 or something like that? This could simply just redirect to the actual page Creating each by hand would be a daunting and error prone process, so hopefully that can be avoided. Does it make sense to do something like this and is there an automatic way it could be done? --QVamp 17:21, 10 August 2011 (CEST)
- Some wiki advice: On a big discussion page like this, new topics belong at the bottom of the page. It makes archiving much easier. There is even a special "new topic" button at the top near the "edit" button, it is labeled with a "+". Use it.
On your specific question, I'm not a mediawiki expert, but I don't think that can be done automatically and unless automatic it would break. Better to try to get item name linking fixed. "Bash-Ōs boxtop" and the like are indeed tricky business. Seems like a wiki bug. Certainly the search page results for that say "This may indicate a bug in the software." --Club (#66669) (Talk) 20:13, 10 August 2011 (CEST)
- I was hoping for more responses here by people who know this wiki. Adding this automatically *should* be avoided, agreed. But the error rate of this is the same as that of the 'items by number' pages. Are those hand crafted? If so, there appears to be several reasons why this wold be a good idea then. I do know PHP and web tech pretty well, if there is someone more familiar with the programming behind the wiki who could help me out, maybe I could help? --QVamp 16:16, 18 August 2011 (CEST)
- Incidentally, I got through the full list of items in a script I'm working on (granted these may be interpretations of the names through mafia, and not what is actually written in the game). These items kill the wiki:
- Bash-Ōs cereal (the Ō, is listed with an O)
- Bash-Ōs boxtop (same)
- Frigid hankyū (the ū, is listed as a u)
- TΤ◊lisman of Baiø‡ (the ◊, was removed from the name)
- I think that is all of them.—Preceding unsigned comment added by QVamp (talk • contribs) on 07:34, 2011 August 18
- The Items by number pages are hand maintained. I don't understand what you are suggesting that could help with Items by number. This site will not allow you to add additional PHP. It was work enough getting a stock MediaWiki upgrade. If you have a site to host a redirector yourself, then it sounds like you know how to write one. --Club (#66669) (Talk) 20:10, 18 August 2011 (CEST)
- Maybe I misunderstood. Club, you said earlier you didn't know much about mediawiki, so I assumed you were not the maintainer of this site, but your last comment seems to imply otherwise. What I am assuming now is (correct me if I'm wrong) that you/others installed the mediawiki software here, built kolwiki using it, and would prefer to keep the coding completely within that software.
- I took a brief glance at mediawiki, and it does have a huge section on adding your own extensions into the software. I don't have time right now to look more into the extensions, but I could look into it as one of my next projects. That said, do you and/or others maintaining the site think it would be helpful to have something like what I was proposing, if the software supports it. The theory being that the wiki itself would auto-create the 'items by number' pages (and locations, etc.), and would provide a better API to make external linking easier. If this is a headache and something you'd like automated, I'll look into it... if not, I've already figured out the linking rules for my program, so I don't really need it. --QVamp 21:07, 20 August 2011 (CEST)
- I am not the maintainer. I am a long time editor and user. I have observed it taking months to get the software updated. I have never looked at the source of mediawiki nor how to write extensions. I am a professional webmaster and I would be very reluctant to accept an unvetted block of code from someone I didn't know. I expect that that the admins here do not have to time to review an extension custom built for this wiki and would not install one if written. I am not an official voice of Coldfront or the KoL Wiki, I am merely trying to set expectations based on my experiences. --Club (#66669) (Talk) 04:38, 21 August 2011 (CEST)
Challenge Path quicklink
Would it be good to have the challenge path section added to the quicklinks on the main page? Either the small list at the top or the longer one on the right hand side. I know it can be found under ascension, but it is a rather large page, and finding it may not be immediately obvious (especially to anyone new to the wiki). If oyster eggs and mushrooms get their own direct link, I don't see why the challenge paths shouldn't, given their popularity. Maybe even a direct link to the current challenge path (updated whenever the challenge changes, of course). --Lizardking 00:07, 21 August 2011 (CEST)
Bosses and autocat=no
Looking at older bosses, it seems they have autocat=no added, presumably to avoid having them categorised into both Combat Adventures and Bosses (with the latter being a subcategory of the former). However, some of them (like Baron von Ratsworth) were categorised into Combat Adventures as well, anyway, and some bosses (like the Protector Spectre) aren't categorised under bosses at all. In addition, autocat=no prevents them from being added into any categories, including phylum and attack message ones.
What should we do about this? Furthermore, what makes a boss...a boss? Do minibosses count? What about the Best Game Ever, which makes badass pies?
I'd be for removing autocat=no on everything due to it avoiding all categorisation, not just the combat adventures one, and probably sticking a boss=1 entry on the data page of things we want to stick in bosses and not combat adventures. And then changing the battle template to check for boss-ness before sticking in combat adventures once all the phylum stuff is done, because you can't stomp bosses for now, but you also can't stomp things that aren't bosses.
As an aside, the alphabetical sorting appears to have changed from A-Za-z to Aa-Zz at some point, so that's convenient.--Ryo_Sangnoir 19:00, 21 August 2011 (CEST)
- The new ones are because people didn't know how to do the standardized things. We could make boss into a phlyum, though that's something that might have to be changed out. It'd make it easy to not double-cat into combat adventures. On the other hand, there could be non-boots ways of detecting phlyums to come. Indeed, even now things like the safarrri hat and +hobo damage items from hobopolis might be sufficient for detecting phylums of certain monsters (lion->beast and hobo respectively), though with arguable definitiveness (slime hates it doesn't apply to all things in the slime phylum, I think). Better internal handling of Boss categorization would be nice one way or another. Historically, I think "boss" wasn't really based on anything explicit in-game: just a monster that ends a quest line that is more powerful or otherwise more special than other monsters in the quest. --Flargen 01:54, 22 August 2011 (CEST)
- My vote is for adding |boss=1 on the relevant data pages, then on the battle template, changing
|!=[[Category:Combat Adventures]]
to|!={{#ifeq:{{Data|{{PAGENAME}}|boss|{{{boss|}}} }}|1|[[Category:Bosses]]|[[Category:Combat Adventures]]}}
(or something like that), and then adding another check at the bottom, so that bosses don't go in combat adventures, but do go in needing phylum or the other subcategories if we know the phylum (does hobo stogie count as telling for hobo bosses?). Alternatively we could add the boss variable to the pages themselves - this is probably better as it isn't a fundamental property (it's one we've made up).--Ryo_Sangnoir 16:40, 24 August 2011 (CEST)- Here's hoping that the same monsters are unstompable and have badass pie parts. To make things more certain, maybe we should have separate data slots for these two?--Groli 13:41, 29 August 2011 (CEST)
- My vote is for adding |boss=1 on the relevant data pages, then on the battle template, changing
History of Loathing: include more than in-game announcements
As per this thread[2], there needs to be a place for people to go to in order to see what the latest changes in the kingdom have been, and unfortunately not everything is announced.
Changes was never updated much and should probably be nuked. History of Loathing (2011) should include radio announcements, forum announcements and even unannounced changes discovered by the community.
Here's the list of radio show transcript threads, to begin with[3]...--Groli 16:52, 24 August 2011 (CEST)
- This idea is great in theory, but the unfortunate state of Changes tells you all you need to know about how dedicated people are about updating that sort of thing, even the history of loathing pages can sometimes lag behind by a month. Asking people to keep on top of unannounced changes and radio announcements (what are these by the way?) is a lot to ask and sounds like a nightmare to be quite honest. Having said all that, I might have a stab at updating Changes if I get bored because it was a good idea, no promises though (and it would be in less detail, no need to repeat information available on other pages). --Melon 19:15, 24 August 2011 (CEST)
- I'd love to see a page with all those other announcements grouped. I loathe the forums and look at them very seldom (joined 2004, about 200 posts total) and I never listen to the radio show. Mostly I find out about changes via RecentChanges. So if you can muster the manpower to take on that task, it would be wonderful. I think that might be a big if though. --Club (#66669) (Talk) 19:42, 24 August 2011 (CEST)
The page Tuesday was always kept up to date, so I don't think there's an inherent problem in getting folk to contribute. It's just that no one but me was exerting much effort on Changes. If someone creates a forum thread to encourage people to add to it, I think we'd pick up enough contributors to start with. Once people get used to checking it occasionally for updates, they'll add anything they see missing. --Starwed 18:16, 25 August 2011 (CEST)
- I think Tuesday was helped by the fact that it was a regular thing. Now updates and changes and silent nerfs/fixes come out fairly randomly and unpredictably. That makes it difficult to keep up editor interest and attention. I remember at one point feeling it was a competition to beat other editors to add in these things. Not so much anymore. But that could just be me getting all old and crotchety. The History pages have historically always been for official major and minor updates only, though I suppose it might help with keeping interest up if we changed them to be more encompassing. --Flargen 19:04, 25 August 2011 (CEST)
- Thing is, a lot of people would add every change to the game to Tuesday, until it was removed by other editors for not being an "official" Tuesday update. This is definitely a "if you build it, they will come" thing -- if a core group of people get it started, and players start to rely on it to get updates, I think it'll support itself.
- Certainly, I'll pledge to try to update any such page regularly -- the reason I stopped earlier in the year is because I was finishing up my physics PhD thesis, which is just a little time consuming... --Starwed 19:48, 25 August 2011 (CEST)
Ads, sound & fury
No, I don't suppose we can forego ads on the wiki (even if I would be more comfortable if fewer of them felt like scams), but is there any way except turning off the sound on my computer to avoid one of them (for the game World of Tanks in this case) to suddenly start playing loud music? --Notsupposedtobehere 09:38, 1 October 2011 (CEST)
- Depending on your browser, you can block the ad or server it's coming from. Or even have generic purpose ad blocking scripts. I've let the higher-ups know so they can look into removing the ad from the rotation. --Flargen 11:29, 1 October 2011 (CEST)
- Thanks! I guess except for general adblock on my computer, it's on an ad-by-ad basis then, no way to stop all ads that use sound... but I can live with that I guess, it hasn't been a problem before and wasn't that big a problem now. --Notsupposedtobehere 17:36, 1 October 2011 (CEST)
- If you find an ad that has sound, let me know what it's for and I'll try and get it removed. We try to keep sound-based ads out of the rotation.--Nightvol 13:42, 31 October 2011 (CET)
- Thanks! I guess except for general adblock on my computer, it's on an ad-by-ad basis then, no way to stop all ads that use sound... but I can live with that I guess, it hasn't been a problem before and wasn't that big a problem now. --Notsupposedtobehere 17:36, 1 October 2011 (CEST)
Established Standards: Item Pages
Established Standards: Item Pages says to update a selection of pages:
...the latter two which seem a bit dusty and ignored. Continue to update and hope others follow suit, or is there somewhere to discuss the pages' value?--Doucy 00:37, 3 October 2011 (CEST)
- I created the original Items by Autosell Price pages and I've been meaning to get around to fixing them. I probably still have the original scripts I used to create them, but it was done by screen-scaping the wiki. There's better ways I know how to do it now. Items by Name was initially a zapping spading effort and I still associate it with zapping. I'm not interested in that and not the person to talk to. --Club (#66669) (Talk) 05:00, 3 October 2011 (CEST)
- Okay, Items by Autosell is fixed. I wrote a new -- easier to use -- script to generate those and put the link on Talk:Items by autosell price (1-25 Meat). --Club (#66669) (Talk) 22:28, 12 October 2011 (CEST)
- If it isn't used for the zap groups anymore, couldn't items by name just be dealt with through auto categorization? --Starwed 18:03, 13 October 2011 (CEST)
If someone wants to fix the Items By Names pages, here's a list of items that appear to be missing from them. Warning: 1475 lines. That will be a lot of work. --Club (#66669) (Talk) 21:36, 24 October 2011 (CEST)
- Updated list: missing-20111229 -- now 1218 items. --Club (#66669) (Talk) 02:17, 30 December 2011 (CET)
MediaWiki Pages to tweak
Recently Lord Kes made a very good suggestion on Quietust's talk page: edit the copyright warning ("WAIT! Are you following Established Standards?") to better reflect current ascension path stat gains. It occurs to me that editing the new article text to include a policy on redirects would be a good idea, too.
- Are you updating stat gains from adventures or items? Make sure to REMEMBER your Moon sign stat bonus.
- Are you adding a new redirect? STOP and read this checklist:
- Redirects should be in all lower case. This lets the wiki software apply them to normally capitalized links.
- Redirects should not point to another redirect. Check your link carefully.
- Redirects should not be for misspellings.
- Are you adding a new redirect? STOP and read this checklist:
--Club (#66669) (Talk) 22:03, 11 October 2011 (CEST)
Possible Glitch
I use pickpocket as a auto-move to start combats with, and during war, 2 occurrences happened of me auto-pick pocketing and getting nothing, then I moxious maneuver, and then I still have the ability to pickpocket again. Is this a regular thing or is it a glitch? —Preceding unsigned comment added by JackieW (talk • contribs) on 14h October 2011 05:44
- are you by any chance wearing th Bling of the New Wave?
- also, since you're new, two minor points of protocol:
- don't edit archives, they're, like, archived, put new stuff on the pages themselves.
- sign your posts in talk with two hyphens and four tildes (--~~~~) which will give a signature like this --Evilkolbot 09:44, 14 October 2011 (CEST)
- A Real Archive would be protected, such as Archive 4, which is why I can't put the DiscussionArchive template on it. When us regular users create the Archives, we can't protect them. And speaking of archiving, this page seems long... --Club (#66669) (Talk) 01:13, 1 November 2011 (CET)
Category Suggestions
I didn't want to create a new category without getting an opinion or two first. I was thinking, firstly, for a category of monsters that cannot be copied. I think that would be nice. Also, what would folks think of a category for one-shot-kill items, such as the ghost trap, unbearable light, 4:20 bomb (hippy only), etc? I'm on the fence about that one, myself, but regardless, I think the non-copy category would be nice. --Erich 07:43, 17 October 2011 (CEST)
- Monsters that cannot be copied would be a help to players. Although there's a list in the Copying article, not every copyable monster would strike me as not being special. Being able to tell whether or not a monster is copyable by simply looking at its tags in the footer is definitely more elegant than having to search the notes section for Cannot be copied.
About the Instant Kill combat items I'm not so sure. Since a great deal of them only works under certain conditions, like the specific items against the tower monsters or The Guy Made Of Bees. On the other hand, Reusable Combat Items worked out pretty well, so maybe I'm just lacking imagination. --Yatsufusa 13:03, 17 October 2011 (CEST)
While on the subject of new categories, how about a One Per Player category? There's a page for Once per ascension items, but those are not what I was thinking about. I was thinking of The Necbromancer's Wizard Staff, Frosty's iceball, etc. Things the game will only let you have one of at a time, but you can get a second (or third...) one once you destroy the first. --Club (#66669) (Talk) 02:37, 25 October 2011 (CEST)
Zapping Pages
Right now we have a series of pages whose sole purpose appears to be to keep track of zapping information. If we made |zapping= a part of the item template, it would eliminate (I think) the need for these pages. How would we go about doing that in an efficient manner?--Foggy 16:20, 26 October 2011 (CEST)
- There are pre-existing zap group templates place on any zappable item pages. Would be a better place to add any extra zap-stuff to. --Flargen 16:38, 26 October 2011 (CEST)
- It's not the items that can be zapped that are the issue...it's having some way to note that an item doesn't zap to anything...so right now, any that do not zap into anything else would be listed as |zapping=none, unknowns would be |zapping=, and one's who do become |zapping=Whatever.--Foggy 16:46, 26 October 2011 (CEST)
- As a follow-up (I've been pretty busy with a new job these days) I compared all of the items on the items by # pages and the zapping pages. Currently, there are a whopping 1311 items missing, which means even if the items are added, the pages would likely be too large. (And the current sectioning is a little weird right now.) I still think that having a zapping parameter on the item pages would help streamline the spading. As near as I can tell, the steps needed would be: 1) add |zapping=Group for all items currently in a Group 2) add |zapping=! for all items not currently zappable and 3) adding an autocat for all items without zapping info (like Monsters with Missing Phylums). How could that be automated?--Foggy 21:45, 9 November 2011 (CET)
- There were 1475 items missing when I checked on Oct 24. On the generous side, that's 11 items fixed per day, with 4 months of work to go. --Club (#66669) (Talk) 23:27, 9 November 2011 (CET)
- Make a text file that contains pairs of item page names and zap group names, ideally separated by newlines or other characters not valid in page names (such as "#"), then upload it somewhere and post a link to it. Once all of the details are decided regarding how {{item}} is to be modified, I will then write a script to update all of the item pages. --Quietust (t|c) 23:38, 9 November 2011 (CET)
- I've created a file here http://pandamagazine.com/zap.txt ... it contains all known zappable items and all known items that do not zap. I created the zap file from the existing zap pages, but removed the lines listed as Unknown and blank.--Foggy 15:48, 16 November 2011 (CET)
- As a follow-up (I've been pretty busy with a new job these days) I compared all of the items on the items by # pages and the zapping pages. Currently, there are a whopping 1311 items missing, which means even if the items are added, the pages would likely be too large. (And the current sectioning is a little weird right now.) I still think that having a zapping parameter on the item pages would help streamline the spading. As near as I can tell, the steps needed would be: 1) add |zapping=Group for all items currently in a Group 2) add |zapping=! for all items not currently zappable and 3) adding an autocat for all items without zapping info (like Monsters with Missing Phylums). How could that be automated?--Foggy 21:45, 9 November 2011 (CET)
- It's not the items that can be zapped that are the issue...it's having some way to note that an item doesn't zap to anything...so right now, any that do not zap into anything else would be listed as |zapping=none, unknowns would be |zapping=, and one's who do become |zapping=Whatever.--Foggy 16:46, 26 October 2011 (CEST)
Random Page broken?
The "random page" link in the sidebar seems to be broken. Everytime I click it, it takes me to the NG page; a friend of mine has a similar problem only it always takes him to the "Salty Mouth" page. It looks like it sends different people to a random page once, but then doesn't generate a new page on the next click? —Preceding unsigned comment added by Idran (talk • contribs)
- Sounds like perfectly random behavior to me.--Toffile 05:34, 1 November 2011 (CET)
- Yeah, someone else noticed this awhile back, though I'd forgotten all about it. It should take you to a random page every time. Probably a consequence of the mediawiki upgrade. I'll try to remember to get it looked into (again?). --Flargen 05:39, 1 November 2011 (CET)
- I'm using Firefox 3.6.23 and for me it seems to work fine. --Yatsufusa 06:09, 1 November 2011 (CET)
- Yatsufusa: You deleted two comments when you added yours. Try to be careful.
- About the issue, it's not MediaWiki itself, it's the web cache sitting in front of the Wiki. Or you could say it is MediaWiki lying to the web cache. The headers come out with this line "Vary: Accept-Encoding,Cookie,User-Agent", so when none of those three change, the cache thinks it's a-okay to send the cached copy. And shift-reload doesn't seem to work on redirect links in my version of Firefox. For fun (and because it took me less time than fixing Yatsufusa's dropped comments) I tried loading the page with about forty different User-Agents, and got a different link eat time. But if I re-use one, it stays the same. This is a command line tool that does no caching of it's own. --Club (#66669) (Talk) 06:36, 1 November 2011 (CET)
- Does that mean there's no work-around? Before I logged in, "random page" kept sending me to A Smoldering Crater, and now that I'm logged in, all I can get is Anthony Raving, Billionaire Entrepreneur. -GTBacchus 04:40, 3 January 2012 (CET)
New accounts and spam links
I've noticed a recent spate of new accounts for the sole purpose of spamming external links. Are they bypassing the captcha or something? --Itsatrap 17:46, 5 November 2011 (CET)
- They're probably answering the CAPTCHAs via proxy (e.g. tricking other users into filling them in so they can get access to free porn or something), a rather common tactic. --Quietust (t|c) 21:20, 5 November 2011 (CET)
- There's a new one up. It's a shame that they would think that someone would be crazy enough to click weightloss links on a KoL wiki. Rodgerflint 02:11, 6 November 2011 (CET)
- It's a general attack on wikis; kol is just one of many. If you look around, especially on less well maintained wikis, you can see the exact same names (or very slight variations thereof) being created and exact same text being posted (which suggests, if someone were enterprising enough, it would be worthwhile setting up a honeypot wiki, and using the edits found there to help with automatic deletes and bans...) --Fig bucket 02:25, 6 November 2011 (CET)
- Not knowing media-wiki that well, is it possible for us to tweak the create user page to require some knowledge of the game? Nothing hard, but maybe "What color was George Washington's favorite white horse?" type stuff. I do know that reCaptcha has a flaw in that only one word needs to be correct. So if you can OCR that one word, the other one you can get wrong.... --Club (#66669) (Talk) 07:08, 6 November 2011 (CET)
- Pretty sure that's a feature of reCaptcha, not a flaw. It knows what one word should be and checks that you get it correct. The other word is taken from a scanned text (and skewed a bit), and is included so people can verify the system's OCR interpretation of the scanned word. As for making modifications to user creation: a brief look at documentation yielded nothing promising, with this being the best I saw (but it adds significantly to the workload of admins). --timrem 08:10, 6 November 2011 (CET)
- I knew it was by design, but come on, really? I can completely fluff one word out of a reCaptcha box (tested with "x" one of them for this edit) and it will work? Misfeature. --Club (#66669) (Talk) 04:34, 7 November 2011 (CET)
- The point of reCaptcha isn't just to be a captcha, it's also to Mechanical Turk OCR of historical documents to increase accuracy. Most captchas require matching one word, reCaptcha requires matching one word, so it is as good as other captcha systems while also contributing to the accuracy of historical document archival. An overall boon! --Idran 22:49, 11 November 2011 (CET)
- Club, if you get the obfuscated word wrong, it should mark it as incorrect. Only the unobscured word should be bluffable. --Raijinili 13:11, 25 December 2011 (CET)
- Ironically, we have a page about Holiday Weight Gain. perhaps we need to have one of those trippy image-word boxes that FaceBook spams worse than these spammers?--The ErosionSeeker 00:32, 7 November 2011 (CET)
- As I can see from public logs, all new spam accounts try to submit their spam messages in a few minutes after signing up. So maybe as a workaround, you may add delay period to all new account when they will be unable to create or edit any wiki pages (24 hrs after registration for example) --NightBird 19:09, 23 December 2011 (CET)
- People don't sign up to lurk. They sign up when they want to edit something. To stop them from instant gratification would discourage people from logging back in. --Raijinili 13:07, 25 December 2011 (CET)
- it strikes me that the other way round might work. requiring people to make at least one constructive edit in a short-ish time period wouldn't be any work. then we can just ban the rest. a small change to the you've just created an account page. anyway, why would anyone create an account and not use it? --Evilkolbot 13:01, 30 December 2011 (CET)
- To use the non-editing features that require being logged in: the watchlist (and its RSS feed), the timezone and date formatting options, the skin chooser (well, they can hope…), the various other appearance settings. Also, there may be people who want to have an account in case they’ll want to use it quickly in the future. Also also, even those who want to make an edit right away… can easily spend a couple of hours reading up on wiki syntax, etiquette and standards before deciding to hit the ‘save page’ button even once. I think an automatic ban for anyone not making an edit within n minutes after account creation would cause more collateral damage than the occasional false positive from your manual patrolling (although it might be less work still, at the cost of people signing up, getting banned and not bothering to come back). --Xyzzyn 17:59, 30 December 2011 (CET)
- And my favorite, to reserve a name. YEARS ago I created accounts on all of the various wikipedia wikis. And some of those were pretty damn quiet with me having nothing to contribute. But I wanted to ensure that I got the same user name on all of them. Last year I finally was able to merge them into a single account. And for that same reason I created my KoL forum account very soon after creating the player account, even though I loathe webforums. (This wiki didn't exist then.) --Club (#66669) (Talk) 19:24, 30 December 2011 (CET)
- To use the non-editing features that require being logged in: the watchlist (and its RSS feed), the timezone and date formatting options, the skin chooser (well, they can hope…), the various other appearance settings. Also, there may be people who want to have an account in case they’ll want to use it quickly in the future. Also also, even those who want to make an edit right away… can easily spend a couple of hours reading up on wiki syntax, etiquette and standards before deciding to hit the ‘save page’ button even once. I think an automatic ban for anyone not making an edit within n minutes after account creation would cause more collateral damage than the occasional false positive from your manual patrolling (although it might be less work still, at the cost of people signing up, getting banned and not bothering to come back). --Xyzzyn 17:59, 30 December 2011 (CET)
- it strikes me that the other way round might work. requiring people to make at least one constructive edit in a short-ish time period wouldn't be any work. then we can just ban the rest. a small change to the you've just created an account page. anyway, why would anyone create an account and not use it? --Evilkolbot 13:01, 30 December 2011 (CET)
- People don't sign up to lurk. They sign up when they want to edit something. To stop them from instant gratification would discourage people from logging back in. --Raijinili 13:07, 25 December 2011 (CET)
New Suggested Category For Items
Items that Grant Skills -- Infested jerk 04:22, 8 November 2011 (CET)
- We actually have Skills Obtained From Single-Use Items already. It'd be a hard category to make, since skillbooks are marked as "useable", which means we can't autocat items into it without adding an additional field or a manual category.--Toffile 04:47, 8 November 2011 (CET)
- That Category actually fits what I was asking for. Thanks! Infested jerk 07:44, 8 November 2011 (CET)
What do people think about a category/page that discusses shared counters? Maybe a box on the bottom of the page, much like zap groups, that link to all things that share the same counter? Items off the top of my head include GAPs/Navel/Parasol runaways, Bander/Boot runaways, and Idol/Emblem of Ak'gyxoth. --Erich 04:20, 6 December 2011 (CET)
Monster fumbles
Is there some technique to distinguish between misses and fumbles? When I add a new monster it seems that someone will usually correct my fumble message guess, but I don't know on what basis. Nadando 20:14, 10 December 2011 (CET)
- Debuff your moxie to the point that the monster can only miss you if it fumbles (preferably down to 1), then wait until it misses you. High HP and DR/DA, or Hero of the Half Shell plus a shield, will help you survive until the monster gets around to missing you. --Johnny Treehugger 21:30, 10 December 2011 (CET)
A secondary method (perhaps if a monster always hits you) is to use the bugged bugbear. The blocking message it gives will occasionally contain both the critical and fumble text for that monster. (Since one or the other of these methods will pretty much always work, there's never a reason to guess, but it's worth noticing that fumble texts almost never describe a monster missing -- rather, they describe it getting distracted by something, some external thing intervening in the fight, or some similar reason.) --Starwed 00:29, 11 December 2011 (CET)
Document URLs
Might be nice to keep track of the urls the game uses. Snarfblat numbers are recorded already, so we could just note it on the data pages for other types of locations. For NPC stores and the like, not sure where best to record it. --Starwed 03:04, 12 December 2011 (CET)
Dealing with lists: Semantic MediaWiki?
There’s a chronic issue here with lists lagging behind game changes. In terms of whether this is an avoidable problem, there are several kinds of lists:
- those which rely on simple, automatically extractable facts, and really should be kept up to date by a computer, e. g.
- items by name, items by number, food by fullness, booze by drunkenness etc.,
- for an item which is an ingredient, the list of things craftable from it in the Uses section (e. g. Pumpkin#Uses),
- one of:
- list of possible adventures in an area or
- list of areas where an adventure is encountered;
- those which require human thought and cannot be completely automatic, e. g.
- those which rely entirely on wetware involvement, e. g.
- a kind that we don’t have, but might want: custom queries about data which are already available as template parameters on individual pages or could be easily made available, e. g.
- Which drinks of at most three drunkenness give, as a maximum, at least eight adventures?
- What are the best monsters by meat drop which aren’t clover, SR, UR or one-time encounters and appear as combats in an area which is currently in the game and allows olfaction?
Especially for the first kind, I find the present method of hoping that somebody will remember to update all the lists (I usually don’t remember about them) inelegant. My proposed solution is to ask for the Semantic MediaWiki (SMW) extension. This has been briefly discussed before, and Flargen noted server load as a possible issue if it was used, but I’d like to ask about it again.
- Is there agreement about the problems with lists? (Or am I being pedantic?)
- Does anyone have user experience with SMW? Do you think it would work well here? Are there significant applications where it would still fail?
- Does anyone have experience with installing and maintaining SMW? How bad is the extra database/CPU load of SMW really, compared to plain MediaWiki?
- Are there alternatives which could do the same things? (DPL or one of the other extensions also called DPL?)
--Xyzzyn 16:18, 14 December 2011 (CET)
- I don't see how the first kind of list really would benefit from any extension; somebody needs to enter new items properly into the wiki and once they do, the category system largely takes care of it. Wikitemplates can handle the rest. The other kinds of lists need enough human input that we might as well have humans do them; at least that way everybody understands how the pages are built and we don't need to figure out if/how to override a computer-made content decision. My 2¢, anyhow --Improv 19:40, 14 December 2011 (CET)
- Improv, you're incorrect about that. The easy example is items by no: each item stores it's number on the data page, but then must also be entered by hand in items by number. Autocat couldn't handle this, or, if it could, would do so with truly terrible formatting. I have no idea about semantic-mediawiki (the idea sounds good, at least) but if it isn't practical, perhaps some extension to make categories more flexible would help.
- The other solution is to get a bot to handle these things -- wikipedia has all sorts of "janitorial" bots that automatically do these sorts of tasks. Again using items by number as an example, someone could set up a bot to, once per day, update those pages by watching for edits in the data namespace. --Starwed 19:53, 14 December 2011 (CET)
- I like the bots suggestion. Not that items by number is a good example, that one is well maintained. Items by autosell, however, only gets serious updates when I recook the pages. I put my script on one of the talk pages. But I'm not running true wikibots -- that might be fun to learn how to do. --Club (#66669) (Talk) 20:13, 14 December 2011 (CET)
- So let's make a list of everything that is easily bottable:
- Items by Name (list)
- Items by number (list)
- Food (By Size) (category)
- Booze (By Potency) (category)
- Booze (By Level Requirement) (category)
- Items by autosell price (list)
- It seems like items by name would be better served using a category- just modify Template:item to categorize each page based on the metadata. Nadando 20:56, 14 December 2011 (CET)
There are also category like things that couldn't be easily botted, such as the list of hats. But a bot could generate a report of items that are in Category:Hats but not listed there, to make sure nothing falls through the cracks. If we wanted to be really obnoxious it could even add an "unlisted" category to the item, or something. --Starwed 00:41, 15 December 2011 (CET)
Categories don’t really work for anything more than an index of article names (the default ones are way too restrictive; MW extensions of categories still leave stuff to be desired). As for bots, I see some drawbacks:
- Bot code belongs to the bot owner. The only one who can change something (the layout of a list or the criteria) is the owner. This is not ideal in a wiki.
- Stated another way: the code for everything that makes up wiki pages should live in the wiki and be editable by anyone (with reasonable restrictions, as usual).
- As a corollary of implementing a bot that uses structured data from wiki pages (meaning mostly template parameters) for some task, it becomes impossible for anyone to change the structure of those data without coordinating the change with the bot’s owner or breaking the bot. (TL;DR: suppose I have a really great reason for changing all item numbers to Klingon ternary but there’s a dozen bots that depend on them being in hex.)
- If the owner doesn’t find the time to handle them, faults in a bot don’t get fixed.
- The technical barrier to entry of writing and running a bot is rather higher than that of writing semantic properties and requests.
- Semantic markup, when used pragmatically, is pretty in ways that bots aren’t. (But I’ll concede this is a purely subjective view.)
The advantages of bots, as I see them, are:
- They can be written to do pretty much anything. SMW can only do some things.
- Bots are much less invasive from the server administators’ point of view than a new MW extension.
- A smartly written bot might solve a task with much less impact on server resources than an equivalent solution with SMW.
Of course, the two approaches aren’t mutually exclusive. --Xyzzyn 01:34, 18 December 2011 (CET)
One time a day usable items...
What do you guys think about a page with a list of "usable (once a day)" items? (i.e. jingle bell, Handmade hobby horse, Oscus's neverending soda, Outrageous sombrero, etc.) --Gleezus 20:26, 21 December 2011 (CET)
- Oops... apparently there is a Daily Activities page which (sort of) covers this. --Gleezus 20:34, 21 December 2011 (CET)
- If you find anything missing from that page, and don't feel up to editing it yourself, put it on the talk page. --Club (#66669) (Talk) 21:44, 21 December 2011 (CET)
- It looks like all the stuff I was looking for was there, just had to search a bit. Thanks.--Gleezus 15:58, 22 December 2011 (CET)
- If you find anything missing from that page, and don't feel up to editing it yourself, put it on the talk page. --Club (#66669) (Talk) 21:44, 21 December 2011 (CET)
Combat messages
Is there a page listing the various combat messages, like the one I started on the Suburbs of Dis? Should there be? Nadando 19:41, 3 January 2012 (CET)
- There isn't one that I've seen, but if there's a page for haiku combat, it would make sense to have one for... Seussian combat, or whatever you call it. --Johnny Treehugger 19:46, 3 January 2012 (CET)
- Sounds like it should be anapest combat, as the Seussian meter is called. It will be not so obscure a term once people become familiar with the Just the Best Anapests effect. --Club (#66669) (Talk) 20:48, 3 January 2012 (CET)