Talk:Main Page

From Discworld MUD Wiki
Revision as of 16:23, 9 April 2010 by Chat (Talk | contribs) (Collapsible navboxes)

Jump to: navigation, search
Filing cabinet.gif Old content for this page has been archived, and can be found at the following locations.
Main Page/Archive 1Main Page/Archive 2Main Page/Archive 3
Main Page/Archive 4Main Page/Archive 5Main Page/Archive 6


What's going on with this stuff?


Where I found that thing. I'm reluctant to just change it to straight links wherever I see it, because I'm not really sure what it's supposed to be doing. But I think something went horribly wrong with it, somewhere. --Ilde 20:22, 29 June 2009 (UTC)

I assume it was some grand plan to create links to skills which would then reside in their own skills namespace? Personally, I think that would be overkill. The random code after the boxes must have been speculatively added against the day that the ParserFunctions library would be installed.
Generally speaking, I've been removing these as I go along and replacing them with just plain links to skills (eg. magic.spells.offensive), as:
  • (Primarily) The code leaking out looks pretty bad, and it can always be added back in later if/as/when ParserFunctions is installed.
  • (Secondarily) I hate to say this, as someone clearly put time/effort into it, but the colours and boxes just look wrong in an article - they clash with the conventional formatting and make the skill unnecessarily stand out.
As an aside, I encountered some naming issues when building articles with skills in:
  • We don't want to use their common abbreviations (eg. 'ma.sp.of') as:
    • Not everyone uses the same abbreviations (eg. '').
    • There are some that are ambiguous (eg. the much cursed '' is either charming or channeling), and we probably want to create disambiguation pages for those.
    • The article title looks a little unprofessional.
  • Similarly, just using the leaf portion of the skills can also be ambiguous (eg. 'misc' or 'points').
  • However, these are both the sort of things that people will enter into the search box.
So far, I've been creating them with their full name, and at some point in the future I plan to add in the common abbreviations as redirects or disambiguations as required.
--Chat 21:33, 29 June 2009 (UTC)
It may be worth later creating something similar but less stylised, to create skill statements that look something like:[[Magic_(skill)|magic]].[[Magic_(skill)#Methods|methods]].[[Magic_(skill)#Methods.Mental|mental]].[[Magic_skill(skill)#Methods.Mental.Charming|charming]] (which comes out as: magic.methods.mental.charming) or just [[Magic_(skill)#Methods.Mental.Charming|magic.methods.mental.charming]]. Either way, if we use them as templates now instead of ordinary links, it becomes much easier to change later. --B (t) 22:13, 29 June 2009 (UTC)
That's true. Though personally I think it's nicer to just link the whole thing directly to the full skill (since if you link to every level it's easy to misread the whole thing as one link and click the wrong part--and how often do you care about a category skill, i.e. magic.methods, anyway?) and have the leaf skills in categories. So faith would be a category containing faith.rituals, faith.items, and faith.points; faith.rituals would be a subcategory containing faith.rituals.offensive, and so on. Not that templates would interfere with that, of course. --Ilde 03:13, 30 June 2009 (UTC)

These boxes are left over from the merging of my wiki with this one; the player who was adding the magic articles had a Grand Plan that I didn't quite understand, but it made her happy and looked like it was probably useful, so I went along with it. -TherionAndAlts 07:22, 16 September 2009 (UTC)

Anonymous users and spam

Should we consider disabling anonymous editing to reduce spam? Do we feel that anyone is likely to particularly want to make anonymous contributions? Personally, I'd like it because it would stop me making edits while logged out, but it would also mean much less despamifying. A CAPTCHA extension may also be useful, but there are valid points against it. See also Mediawiki manual: combating spam. -Taepha 07:29, 24 July 2009 (UTC)

Proactive or Reactive? Unless it becomes a real problem, I think it's better to react to it case by case. If it becomes a major issue then is the time to consider proactive solutions. As far as I know we've only had one instance? Zexium 10:33, 24 July 2009 (UTC)
Rather a few more than one, and I'm a big fan of proactive. ;) See Special:Log/block for a list of IPs we've blocked (most are spammers, and some committed multiple instances of spamming). It also seems to be getting worse. I've blocked eight IPs today, not that doing that helps. I'm currently protecting (making user-editable only) pages after a few attacks, as once the bots start on a page, they won't stop. Special:RecentChanges seems to be filling up with spam and spam fixing. -Taepha 10:56, 24 July 2009 (UTC)
ns and whois lookups suggest that these may be botnets. Whether knowing this helps or not I don't know. Zexium 11:47, 24 July 2009 (UTC)
Yesterday I would have agreed with a reactive stance; today we got a whole bunch of spam dumped on us. I had thought that the spam bots were naively targetting direct links from the main page (makes sense - they have less computational work to do that way), in which case simply protecting all links from the main page would have worked nicely. Unfortunately, today's aren't following that pattern.
For now, I've pre-emptively protected the main page - it's a very obvious spammer target, and I'm slightly surprised it hasn't been hit already.
In the long run, we want a solution which:
  • Will stop most of the spam (I doubt we can stop all of it)
  • Won't discourage people from just coming along and editing.
To that end, I think it's possible to use captcha without being heavy-handed about it - one of the common wiki captcha options is to require it for edits made from non-confirmed accounts which are attempting to insert links to 'unrecognized external sites'. This would have blocked all the spam we've had so far, with a pretty minimal effect on legitimate edits (especially if '' is a 'recognized external site'), so would be pretty much ideal. That would get my vote.
--Chat 17:33, 24 July 2009 (UTC)
Happy to agree, although do I even have a vote anyway :) Zexium 17:57, 24 July 2009 (UTC)
A low level captcha would be a good approach. We will have to make some sacrifices which may discourage random editing, but that's unavoidable if we want to stop the spam. We could add a limited protection and if that doesn't stop the majority of the vandalism we could step up to a higher level. Using captcha on adding external links would not solve every problem though, as there seems to be a lot of gibberish vandalism. Rehevkor 19:32, 24 July 2009 (UTC)
I'm for the captcha option as well; this is getting ridiculous. But looking at the history I do see a few legitimate edits by anonymous users, so it doesn't seem the right thing to block anons entirely. --Ilde 19:56, 24 July 2009 (UTC)
Blocking anons entirely should never be an option. But we will probably have to limit it in some way. Rehevkor 20:14, 24 July 2009 (UTC)

As an aside, I managed to get the files pointed to on by the linkspan (which were malware aimed at windows, what a surprise) removed, and hopefully web admins will be improving their own security .... maybe it's worth remembering for an incident like this that other websites might be affected and we may be in a position to warn them too ..... Zexium 00:33, 25 July 2009 (UTC)

I know what might be useful. If the wiki could announce recent changes using an irc channel on Probably just a flight of fantasy though. Zexium 13:36, 10 August 2009 (UTC)

There's always the RSS feed:
-Taepha 23:57, 10 August 2009 (UTC)

We're getting pounded with spam again; I've had to block 9 IPs in the last 48 hours :(

Any progress on the CAPTCHA issue? --Chat 09:40, 14 September 2009 (UTC)

Maybe instead of a CAPTCHA, etc., we could do what TV Tropes does: disallow edits from non-logged in users, but have a default "anonymous" login (with the username and password shown in the "You need to log in to edit" message). Would that be an easier thing to set up? It seems to work well for them. --Ilde 23:37, 14 September 2009 (UTC)

Well, wasn't that fun. I've just finished dealing with a very large spam influx - I think I've blocked/deleted/protected more IPs/pages today than the sum of all block/delete/protected by everyone previously.
My analysis of the pages hit suggests that the spambots are all following the same algorithm:
  1. Start at main page
  2. Follow any link to another page
  3. Follow any link from that page to another page
  4. Edit and spamify
In other words, all pages hit are within two links of the main page. Unfortunately, this encompasses a vast number of pages. I've pre-emptively protected all the pages that are immediately linked from the main page, but there are simply too many for me to deal with all the second-degree links.
If we get much more spam on this scale, then we're going to be overwhelmed, so I think the case for installing some kind of anti-spam extension is becoming urgent.
--Chat 18:17, 9 October 2009 (UTC)
I hope to god that was a one off. I don't envy you having to deal with that. Further measures to stop spam will be essential is it continues on that level. Rehevkor 01:18, 10 October 2009 (UTC)

Moved Newbie Guides Section... that all our Newbie-Friendly articles are now in one place. To this end:
1. Added the articles and external links that were in "A Newbie's Guide to Discworld" to the Newbie Guides category.
2. Redirected the link on the main page to the category article.
3. Profit!
-TherionAndAlts 10:00, 25 August 2009 (UTC)

Judge crackdown

Despite various pages indicating that this is unwise, people are still:

  • Creating/editing pages that imply that there are 10 judge categories (example: '08/10 (Very good)', here) - there aren't, there are actually 15.
  • Creating/editing pages that use someone's judge category to compare or rate weapons (example: Category:Excellent swords) - this isn't helpful as judge category is subjective - what you judge a weapon as isn't necessarily the same as what someone else does, depending on ad.ev.we bonuses.

Now, I don't attach any blame to individuals here - people can't be expected to read all talk/research pages, and many of the latest ones are probably arising from copy/pasting existing articles - however, this needs to stop.

So far, I've been taking a softly-softly approach on this subject:

  • {{infobox weapon}} will accept being called with just a judge category, and will even tolerate things like '8/10'.
  • I've set the template's documentation to request that people don't do this.

Unfortunately, this just isn't working - more of the offending articles keep being created - and the more people add articles with these issues in, the harder our future job will be to fix them. It's hard for me to contact individuals on this matter and ask them to stop, as many of such edits are made by anonymous IP.

To that end, I'm now taking a somewhat more forceful approach to this matter:

  • I've tweaked {{infobox weapon}} and {{judge}}. Any edits to pages using either of these as of a week from now will automatically refuse to display a judge rating, and will instead display nice red text requesting that the editor stop using the deprecated syntax and provide their bonus. Note that this should only affect edits after that date - so we won't suddenly get a giant swathe of red-texted infoboxes in existing articles at that point.
  • I've created two new warning templates - {{Judge category is subjective}} and {{There are not 10 judge categories}} - which I shall be adding to the worst offending articles. These can also be added to logged-in users' talk pages.
  • I propose deleting all of 'Category:Excellent swords/axes/maces/etc.', and shall do so in a week's time unless there are serious objections. For now, each of these will be tagged indicating that it is a candidate for deletion.

Obviously, these will be fairly drastic changes - therefore, I've time-delayed them by a week to give people time to discuss/object/complain. Until that time, all that will happen is that various articles will have warning tags added to them.

If you have any questions, objections, or other discussion on this subject, please raise them here in this section (remember to indent and sign your posts!).

--Chat 17:26, 14 September 2009 (UTC)

How strange; I wonder how the idea that there are ten judge categories got started, then.
  • goes off to edit the category pages*--Ilde 23:02, 14 September 2009 (UTC)
I wondered that too; with hindsight it seems like a rash assumption, but I can think of several good reasons why people would have thought 10 to be the correct number:
  • Coilla's weapon page may have been the original source.
  • Many people have ad.ev.we bonuses in the region of 200, at which there are 10 categories (plus 'Poor' as 'category zero')
  • Quite a lot of other things (eg. vurdere, condition) have 10 or 10+1 categories.
  • 10 is a nice round number
--Chat 23:18, 14 September 2009 (UTC)
Reasonable. Hmmm... I was going to suggest some "whatevers with ratings of 94 or over" categories to replace the "Excellent whatevers" ones, but that's not really necessary, what with the sortable tables. --Ilde 23:29, 14 September 2009 (UTC)

I've been the one creating the weapons articles, and yes, Coilla's was my original source (I've been judging the weapons myself but used Coilla's /10 system, since I hadn't yet run across any weapons worse than "pretty poor"). The IP in question is me; I occasionally forget to log in.

I wasn't aware of the discussion regarding this subject until just recently. In the future, if you wish to discuss something I'm doing, please leave it on my talk page, where I'm more likely to see it. ;)

I've updated the weapon pages (all of them as needs it, I believe) to reflect the proper number of judge categories. I propose repurposing the "Excellent" category pages to display weapons whose upper rating is 100; keeping the "100 club" (or whatever) page is handy given that many players will only wish to view the best weapons available in game.

Furthermore, these pages allow someone to sort only "100 club" weapons by weight, number of specials, and so on. Mind, if any of you know how to write a table with multiple sortable parameters, that'd be even better; but in the meantime, the pages perform a valuable function. -TherionAndAlts 12:04, 16 September 2009 (UTC)

See my comments at Talk:Judge (I moved the previous discussion from Research:Judge to there) - I think it's still pretty ambiguous as to what should/should not go in the 'best weapons' categories; and for that reason we're probably better off just sticking with a sortable list in the main category.
--Chat 16:24, 16 September 2009 (UTC)


The main talk page was getting pretty big, so I've archived the old bits off.

The process for doing this is:

  • Archive talk pages when you start seeing the "WARNING: This page is X kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections." message when editing them.
  • Move any sections which have not had edits within the last 30 days to the archive page.
  • The archive page is called 'Talk:pagename/Archive X', where X is 1, 2, 3, etc.
  • Put the {{talkarchive}} template at the top of each archive page.
  • Put (or update) the {{archives}} template at the top of the main talk page.

--Chat 17:25, 16 September 2009 (UTC)

Viewing figures

Just thought you guys might like to know - unique daily visits to the site for the month of December 2009 broke 1,000 - we hit 1,001, as a matter of fact.

For interest, here are the figures for the past few months:

Mar 2010        1104
Feb 2010        1212
Jan 2010        1114
Dec 2009 	1001 	
Nov 2009 	919 	
Oct 2009 	796 	
Sep 2009 	676 	
Aug 2009 	540 	
Jul 2009 	398 	
Jun 2009 	279 	
May 2009 	165

Great work everyone - many thanks for your continued work in making this wiki a great resource for DW players everywhere! Drakkos 21:54, 3 January 2010 (UTC)

January 2010 hit 1114 unique daily visits, FWIW. Drakkos 00:21, 2 February 2010 (UTC)
February 2010 : 1212
Interesting. Increasing fairly consistently. Rehevkor 13:31, 2 March 2010 (UTC)


Ever wanted to add an article that had multiple infoboxes in it?

If so, you've probably come across the Ugly Infobox Stacking Problem, and ended up with something like this:

Main Page
Weapon information
Precise dimensions No information
Material No information
Weight Lots
Thaums/sec  ? stable / ? talisman / ? max
Hands 7+1
Commands Dest
Melee type Misc weapon
Judge data
No melee judge information
Main Page
Stat item information
Con Dex Int Str Wis
+2 +1 0 -1 -2
Main Page
Poison information
Effect Pain
Other names

Mn Pg
Crushed Womble Soul
(highlight to see)

Or, worse, this:

Main Page
Weapon information
Precise dimensions No information
Material No information
Weight Lots
Thaums/sec  ? stable / ? talisman / ? max
Hands 7+1
Commands Dest
Melee type Misc weapon
Judge data
No melee judge information

Main Page
Stat item information
Con Dex Int Str Wis
+2 +1 0 -1 -2

Main Page
Poison information
Effect Pain
Other names

Mn Pg
Crushed Womble Soul
(highlight to see)

To deal with this, I've created the {{multiinfobox}} template, which you can use to combine multiple infoboxes into one nice single one with tabs, which swaps between the different infobox types when you click the relevant tab.

With multiinfobox, the above become:

Weapon Stat Item Poison
Main Page
Weapon information
Precise dimensions No information
Material No information
Weight Lots
Thaums/sec  ? stable / ? talisman / ? max
Hands 7+1
Commands Dest
Melee type Misc weapon
Judge data
No melee judge information
Main Page
Stat item information
Con Dex Int Str Wis
+2 +1 0 -1 -2
Main Page
Poison information
Effect Pain
Other names

Mn Pg
Crushed Womble Soul
(highlight to see)

Enjoy :) --Chat 23:48, 26 January 2010 (UTC)

That is amazing. :D I guess we finally have a neat solution to those weapons with two different states, too! --Ilde 01:44, 27 January 2010 (UTC)
That is handy. Anyone familiar enough code wise to incorporate this? Would be handy for custom infoboxes, and would make making new ones easier. Rehevkor 03:23, 28 January 2010 (UTC)


I tried to add a template for showing the meaning of abbreviations on mouse over but I can't seem to make it work.

I'm not sure if this needs to be done by someone who can escape the tags < > so it works or if I'm missing a dependency...

I believe this template could be helpful for:

  • Using shorthand while allowing people to hover over it and see the whole meaning.
  • Allow some data in tables to be shortened or not showed until you hover over it, since some things like description can be huge and not really helpful to always be displayed but interesting to have if someone wants to check it.

I suppose being able to show/hide columns could do it for the second, though I'm not sure how that could be done.

Frazyl 17:30, 2 March 2010 (UTC)

Fixed the template. 'abbr' isn't a tag that this wiki's parser allows, but 'span' works fine.
--Chat 18:13, 2 March 2010 (UTC)
There's just a slight issue, there's no visible indication that you can hover over it to get more, it's not putting the dotted underline...
Failing that, normal underline wouldn't be too bad, trying to add <u> to the template didn't work and anyway it's deprecated, using style="text-decoration:underline;" doesn't seem to work either for some reason....
Frazyl 19:44, 2 March 2010 (UTC)
No problem - using the 'border' elements works well as a pseudo-underline. See {{Lmoney}} for an example of where this sort of thing has been done in this wiki.
--Chat 22:28, 2 March 2010 (UTC)
Yay, Happy! Thanks!
Frazyl 22:52, 2 March 2010 (UTC)

Quest pages

What's the plan for the quest pages to remain in sync? That is, quests are duplicated on several pages, odds are modifications on one page won't be made on all of them unless everyone is aware that the quest is also present on another page.

I thought that maybe there was a wiki thing in place so that sections from one page came from another or that they mirrored each other but apparently not. Not sure if that's something that actually exists. Anyone know?

Barring that, should we remove duplicate quests and replace some of them with links? Or some other way to keep all the quest text in sync?

I came up with some ways to handle the issue:

  • Make a page for every quest, the other pages link to the quest page. Downside is there will be lots of pages.
  • Put all quests on one page, then the other pages link to the section of the quest. Probably a bad idea because the page would be too big.
  • Make sure each quest is only on one page and that other pages are only links. Would need to decide on a level (domain/area/city) which would hold the real quest text.
  • Add comments in the source of duplicated quests that the other version needs to be updated as well. People could miss that though.
  • Insert idea here.

Or does everyone feel quests duplicated on several pages is no big deal after all? Frazyl 22:31, 14 March 2010 (UTC)

The third one would be easiest, but... eh. The first one is probably the best solution (possibly we could even stop using hidden text), but I don't like that they would then show up in Special:Random. They do currently, but it's not especially important because 1)there are comparatively few of them, and 2)spoilers are hidden and mostly below the fold anyway. There are only 1,234 content pages currently, so if we added a few hundred quest pages they'd be a significant portion of that. Maybe if we had a separate namespace ([1]) for them? Then they wouldn't show up randomly. --Ilde 02:23, 15 March 2010 (UTC)
A separate namespace sounds good especially if it allows us to show the text unhidden. As it turns out Special:Random also excludes redirects, so we could add redirects from the normal namespace for pages people might search or we want to link to... Probably only entry pages with warnings like Category:Quest pages and Unofficial_Quest_Solutions. --Frazyl 02:53, 15 March 2010 (UTC)
I actually like the hidden text as it enables me to uncover the mystery line by line if required (for example if I get stuck just because I cannot figure out the right verb, "exacto" comes to mind...). --Gunde 23:19, 31 March 2010 (UTC)

Line wrapping and <pre> tags

As pointed out be several people, <pre> tags cause issues because long lines are not wrapped when they don't fit the browser's width, making the user scroll to see it all and breaking the look of the wiki.

I've tried to fix with the {{prebox}} template so that it would function like a <pre> tag with line wrap but replacing newlines doesn't work for some reason (<nowiki> tags not working? might help, not quite sure.)

I've found an extension to use string functions with special characters by using standard c-type escape character sequence: StringFunctionsEscaped, this would most likely allow the template to work.

But then I stumbled on a possible way to fix the <pre> tags themselves, it would appear that adding this (to the existing pre section) in css might fix it:

pre {
 overflow-x: auto; /* Use horizontal scroller if needed; for Firefox 2, not needed in Firefox 3 */
 white-space: pre-wrap; /* css-3 */
 white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
 white-space: -pre-wrap; /* Opera 4-6 */
 white-space: -o-pre-wrap; /* Opera 7 */
 /* width: 99%; */
 word-wrap: break-word; /* Internet Explorer 5.5+ */

Adding this to the pre section in main.css file in a locally saved copy (save Web Page, complete) of a page of the wiki with <pre> tags works for me in Icecat (Firefox rebranded).

Obviously I can do none of the above myself, perhaps adding to css might work pretty well enough with the least effort for people with modern browsers?

It would also fix the formatting if you put many white spaces at the start (same as <pre> tags) which would be hard to hunt down.

The template could then just use <pre> itself. --Frazyl 04:40, 17 March 2010 (UTC)

Fixed thanks to Drakkos! Thanks! Frazyl 22:42, 31 March 2010 (UTC)

Collapsible navboxes

By popular demand, I've now imported all the relevant javascript/css for making navboxes collapsible, and set all existing ones as 'collapsed' by default.

This means that by default, pages with navboxes on will look less cluttered than before (especially if it's a short page with a big navbox).

All navboxes are now by default collapsible, and start collapsed. You can change this, if you wish, by altering their 'state' parameter:

  • 'state=plain' results in a navbox that can't be collapsed.
  • 'state=collapsed' results in a navbox that can be collapsed, and starts collapsed.
  • 'state=uncollapsed' results in a navbox that can be collapsed, and starts uncollapsed.

--Chat 20:23, 9 April 2010 (UTC)