Difference between revisions of "Talk:Main Page"

From Discworld MUD Wiki
Jump to: navigation, search
(mail fixed)
Line 1: Line 1:
Mail should work now.
--[[User:Frazyl|Frazyl]] ([[User talk:Frazyl|talk]]) 00:36, 29 October 2015 (EDT)

Revision as of 00:36, 29 October 2015

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

Mail should work now. --Frazyl (talk) 00:36, 29 October 2015 (EDT)


So I finally updated to the latest mediawiki version.

I fixed a few broken things, if you notice other broken things let me know.

When I next get some time I'll try to really delete spam edits, get rid of the spam images, maybe try to allow users to self-register with tricky questions and implement some kind of offsite backup.

--Frazyl (talk) 06:21, 14 September 2015 (EDT)

Link to create an account.

The link above takes me to https://dwwiki.tara.gotdns.org/w/index.php?title=Special:UserLogin&type=signup. Is this the correct hostname or is the server configuration not set to disc-wiki.confusedherring.com? (though I really like the https which I'd love to see on disc-wiki.confusedherring.com) Quotid (talk) 07:14, 14 September 2015 (EDT)


I got access to the files and fixed the obvious php 5.3 failures.

I also deactivated anonymous user creation and anonymous user editing due to the extremely high spam to real-user ratio until those can be fixed to use more effective and less annoying not-a-spambot checks.

To do that we need extensions and so updating to the latest mediawiki version allows having more up-to-date extensions.

There's also the migration to some other hosting announced a while back which should happen soonish at some point. Need php 5.3+, mysql 5+, file access, will need to install phpmyadmin to deal with the db stuff.

So I made a full backup and I'm considering if updating live (by uploading new files by ftp) is possible and how likely is it to crash and burn...

In the meantime, admins can create new accounts if anyone wants to join. The procedure is:

  1. Go to Special:Userlogin, when logged in as admin.
  2. Click on "Create an account" link to get to the account creation form.
  3. With email
    1. Enter a username and an email address, and click the "by email" button.
    2. The account will be created with a random password which is then emailed to the given address (as with the "forgot password" feature). The user will be requested to change password at first login; when he does this, his e-mail address will also be marked as confirmed.
  4. Without email
    1. Without an email the sysop enters the requested password or makes a random one.
    2. Then send password and notice to the user that he should login to change their password.

--Frazyl 05:28, 28 August 2012 (UTC)

For some reason I'm no longer an admin, so with Lexx and Chat idle, anyone who wants an account is going to have to contact you or Gunde in game, and to ask Gunde they need to know who she is in-game. Zexium 13:40, 28 August 2012 (UTC)

Oh I also added Quest and Quest_talk namespaces. Was a 2 lines change. --Frazyl 05:32, 28 August 2012 (UTC)

Heh, I used 5:
// Quest:
define( "NS_QUEST", 502 );
define( "NS_QUEST_TALK", 503 );
$wgExtraNamespaces[NS_QUEST] = "Quest";
$wgExtraNamespaces[NS_QUEST_TALK] = "Quest_talk";
I guess you didn't use the defines or a comment? ;) Zexium 13:40, 28 August 2012 (UTC)
I just added to the bit already in LocalSettings.php:
define ("RESEARCH", 100);
define ("RESEARCH_TALK", 101);

$wgExtraNamespaces = array (
  100 => "Research",
  110 => "Quest",
  111 => "Quest_talk",

$wgNamespacesWithSubpages[RESEARCH] = true;
--Frazyl 08:33, 29 August 2012 (UTC)

So there's some tables/rows in the db that use latin1 encoding and most of them use binary... (Something like this ALWAYS happens :() Which is probably not good for the upgrade since starting with 1.15 latin1 is not supported. I think the only way to fix those is editing the dumped sql to make it uft8 and drop/add it back, but the dump is a bit over 200 MB, which most editors don't handle well. :( --Frazyl 08:10, 28 August 2012 (UTC)

I have an idea about that. Take the dump, use awk or similar to split it into separate one per db table files, use iconv to fix the table files that need fixing, then cat it back into a single dump. Zexium 13:40, 28 August 2012 (UTC)
Except for spam it we might just be ascii text anyway. Unfortunately it's a lot of data to try and find any bad text in it, but if there's any corruption it can be reversed. Also I can dump table per table, some tables are just cache or will disappear after the upgrade. --Frazyl 08:33, 29 August 2012 (UTC)
Has the new account creation system been advertised on the boards at all? As for admins being inactive on-mud, I admit that, but perhaps an open page can be set up here to request an account? Яehevkor 22:19, 28 August 2012 (UTC)
It's just temporary. We have like 1 new user every few weeks versus hundred of spam attempts per day. Unfortunately I have a project due in a week but I hope to resolve this better soon. Preferably by upgrading mediawiki which would make installing up-to-date extensions possible. --Frazyl 08:33, 29 August 2012 (UTC)

Registered user spam

Some spambots register themselves and modify Idlechasing. This is probably because http://www.idlechasers.com/wiki/index.php/Main_Page now redirects there.

I protected it so only administrators can edit it. If this remains the only target for this spam, that I recall was the kind present on the idlechasers wiki, then they should tire of failing at some point.

Any changes can be placed in the talk page and will be put soon.

Or I guess we could just include another "real" page that's editable. Yeah that sounds nice. --Frazyl 21:55, 1 June 2011 (UTC)

Ok after a false start I moved Idlechasing to Idlechasing_real so the last one is editable by registered users and is included in the former. I hope that the spambots are dumb enough to just try on Idlechasing which will fail because it's protected. --Frazyl 22:02, 1 June 2011 (UTC)

In regards to the whole spamming thing, I did a tracert on the IP address of the most current one ( and it resolved to rdns.ubiquityservers.com. Is it possible to just block all access from that domain somehow? I looked into it a wee bit and seems that specific company is used as a source by a large number of spammers, probably as a proxy of some sort. -- Baldarov 2 June 2011
They're a data center leasing servers. The ips are probably just compromised computers so blocking whole ranges is unlikely to fix anything because they'll be compromised computers outside that range, most of the ips will be collateral damage.
What we could do is not make new user be confirmed automatically. Not sure what restrictions there are on uploading files but if it's not protected by the captcha we could try to add that to it. --Frazyl 21:53, 2 June 2011 (UTC)
I've done a little searching - apparrently ubiquityservers are well-known for hosting spammers. Therefore, I've just tried putting in a set of range-bans on their entire domain. It's unclear whether the wiki actually supports range-blocks or not (there's a system setting that controls it; I can't tell whether it's set or not); we'll wait and see whether this eliminates the current lot. --Chat 14:11, 5 June 2011 (UTC)

I think we could cut nearly all the spambot edits by installing Extension:TitleBlacklist.

  • We could block usernames with numbers or with CamelCase. Regexp could look like
  • We could block creation or move to pages having names used for spam but not for normal pages for example:

That way by blocking keywords the spambots will need to keep coming up with new ones and if we spot patterns in user names we can block those too. --Frazyl 23:27, 20 September 2011 (UTC)

Why not use /[a-zA-Z]{3,12}/ ie just restrict wiki user names to valid mud users. Add a note on the user creation page to contact one of us on the mud with tell or mudmail if their wiki name isn't being accepted, and "wiki user names are subject to the same constraints as player names" without stating what those constraints are - players should know what the constraints are, non players probably don't have much reason (if any?) to edit the wiki anyway. It seems that most of the spambot names have numbers on the end, and if we can control the regex at the admin level, then we can always lift it for 5 minutes if someone has forgot their pw and wants to create a new user with name + digit. Zexium 13:13, 16 February 2012 (UTC)
Sounds good to me. --Chat 18:49, 16 February 2012 (UTC)
Sure, we could require users to fit /[A-Za-z][a-z]{2,11}/ (spammers use names like WossnameThingy) but we can't without access to the server as far as I know.
We need some extension to block some user names, merge those phony users into anonymous and prevent creation of bad pages and block other stuff like blanking most of the page which can be detected automatically by AbuseFilter with various rules.
I posted links to extensions on Drakkos' talk page. The new host for the wiki needs to update mediawiki and install extensions to help fight spam.
I'm not too keen on hosting the wiki on my home connection but I might do a test export/import when I'm less swamped with things in a week or so.
--Frazyl 19:12, 16 February 2012 (UTC)

Is it possible to block user registrations for names that start with "Chenxuej[0-9]"? We have had 4-5 different usernames in the past days for that. --Gunde 07:52, 12 July 2012 (UTC)


Does anyone think installing the CheckUser extention would be useful, for blocking the IPs of the spammers? Яehevkor 12:25, 8 September 2011 (UTC)

Maybe but when blocking a user it says it blocks the last ip used by that user. Do we suspect the spammers use different ips to create the user and then to make changes?
What I'd like to use would be RevisionDelete to be able to delete revisions that are spam or gibberish so spammers can't link to the revisions (not sure if they do that though but maybe that's why they keep coming). This does not seem to be an extension but I don't see (show/hide) or (del/undel) buttons in history so it doesn't seem to be working.
To revert lots of bad edits by users we could consider Extension:Nuke. --Frazyl 14:21, 8 September 2011 (UTC)
Oh right to find if the spam users are in the same ip range and block that. Yes that would be useful. --Frazyl 16:22, 8 September 2011 (UTC)
I have php code that can do a basic "is this a valid mud character" name check. However, I have no idea if it can be incorporated into the wiki software or not .... Zexium 23:54, 20 September 2011 (UTC)
Thing is players often enough do not use a mud character name for wiki account. Though I suppose it could be mandatory for new ones. It would certainly be easier to check if they exist. Not sure how to include that check either. --Frazyl 00:02, 21 September 2011 (UTC)
As written it's an includable file with a single function that returns "true" if the name given is a valid character name. It uses the php sockets interface to open a telnet session and do a finger at the login screen, so there's no login (username / password) needed.
Ok, update - I spent some time this evening modifying a copy of the confirmUserCreate function for the version of wikimedia that we're using to incorporate a test of "is a currently logged in mud user with an mud account created at least 1 day ago". I *think* it's good to go. All new user accounts that weren't being created using character names of players would need to be pre-authorised by wiki admins, but I don't think that should be an issue. I can dial the test back to use "is a valid player charactername" with either or neither of "the character is logged into the mud" and "the character was created at least 1 day ago" instead of using both the secondary conditions as at present, but I don't think the triple check (valid player character, logged in, created at least 1 day ago) is that onerous a combination. Zexium 22:38, 14 October 2011 (UTC)
That sounds nifty. I'm wildly guessing there might be a way to hook in like extensions adding user creation checks presumably do without overwriting the function to avoid having to patch mediawiki with each version?
If you could put it up somewhere we could check it up. Mmm. Is there some means of preventing lots of requests in a short time?
I'm looking at that following a chat with Mishal (dwpriests wiki). Also, as a precursor filter, blocking any usernames outside the permitted lengths on the mud (less than 3 characters, more than 12 characters, containing digits). Actually, the latter qualifications I could implement easily, it's preventing the extension hitting the mud too hard when the wiki gets hit with an autocreating script that's the bigger issue. I'm thinking of a separate table of requests and if a site hits some threshhold (trying to create characters too fast, or too many failures in a given time) hooking back to the ip banning function. But this is a lot more effort than just patching the createUser function. Also, I have no idea how much of this could be done by, for example, prohibiting user names that include digits, have more than 12 or less than 3 characters in the existing wiki software. Eg if we can define a regex for a valid user name, use /[a-z]{3,12}/i and a message like "Ideally your user name should be your mud character name. User names are subject to the same character and length limits as the mud applies". Bear in mind that anyone whose mud character name is hijacked here can contact a wiki admin by mud-mail to get the issue resolved! Zexium 20:34, 17 October 2011 (UTC)
You could check Extension:TitleBlacklist, because it blocks users based on regexps in addition to other things and it should be compatible with Mediawiki 1.12.0+.
Looking at the subversion source files it adds a hook "$wgHooks['UserCreateForm'][] = 'TitleBlacklistHooks::addOverrideCheckbox';" to check various things.
In fact if the source is not too difficult to work with it would probably be a good idea to add functions to that extension so we could also block new pages with that code (because unregistered users post spam even despite the captcha). --Frazyl 00:45, 18 October 2011 (UTC)
For putting it up on the site you'd need to ask Drakkos to do it, I don't think anyone else has access.
Not yet, I need to mitigate sending repeated requests at the mud if we get hit by a script first. As I don't actually run a wiki myself, I need to work out the best way to marry such functions to mediwiki. I might create a new mediawiki extension that's designed specifically for validating against dw, rather than patch the existing one. Zexium 20:34, 17 October 2011 (UTC)
Checking fast I did not find any way to pre-authorize user names or do much of anything to users except modify groups or block them. Possibly creating a new user while logged in as admin might bypass checks but you'd need to turn it over to the user after that... --Frazyl 19:32, 17 October 2011 (UTC)
As an academic exercise, I pulled the latest 500 ips from the block log showing only single ips, and identified /16s that had 4+ hits and /24s that had 3. The following ranges were hits:,,,,,, Zexium 03:31, 21 September 2011 (UTC)


As of this announcement , judge now works in a completely different way. This means that:

  • All of the existing weapons rating data is invalid.
  • We can't use the judge-method to determine a weapon's rating either.

There will be a short period of silence, followed by a long period of swearing, followed by changes to several templates. Please bear with me. --Chat 19:08, 10 January 2011 (UTC)

OK, I now think we've got enough research on Judge to start putting weapon ratings back in. A word of caution, however: Please don't add any weapon ratings in unless you:
  1. Have read Research:Judge
  2. Have a JIR of at least 220 in the appropriate weapon class (If you don't know what a JIR is, go back to step 1).
Or your information won't be accurate.
--Chat 19:46, 19 January 2011 (UTC)

Shortly I'll update the weapon infobox for entering judge data for overall, attack and parry with strength between 8 and 24. Provided it doesn't go horribly wrong and need to be reverted for fixes.

It should be easy to extend it beyond 24 if need be, just some copy paste but I'm not sure anyone is testing beyond that.

As a side-effect, the old judge overall, attack and parry data will not show anymore. This is necessary because without str we don't know what the old data was and it needs to be rechecked or entered. This is consistent with similar past updates.

The prototype for the new infobox filled with new data will be in Fine sabre.

Unfortunately, it's not possible to just copy the data from the tables because it reads the string, not the number... It's possible it can be made to work with numbers with more work.

--Frazyl 01:13, 25 May 2011 (UTC)

Ok it works now as in Fine sabre. I'd just like to put table lines for the str table but it doesn't want to work.

For those weapons done by Baldarov and others with the "Strength/Judge Results table" the info in that table was the one to use anyway, not the data without str in the infobox that's not shown anymore.

Todo: see if I can muck up something so we can put the numbers 1 to 14 instead of the label like "rather good" to place the info in the infobox for all those pages. Another day though. --Frazyl 03:16, 25 May 2011 (UTC)

I like the idea to summarize everything to one side of the weapon page. However, an opinion - aesthetically, the fine sabre example looks, well, overly busy on the weapon info column now. Would it be possible to do a multiinfobox? The front box could be as it has been, but have the Str-16 (being median 9 to 23) relevant judge info displayed. Then, if a person so desires, the second info box could just show the expanded judge info. If preferred, I can move this thought to the template's discussion area. --Groth 03:35, 25 May 2011 (UTC)
That's an interesting idea. But looking over all the str variations would take 14 clicks and wouldn't the buttons to show all available str be rather similarly spammy? Then again I'm not very knowledgeable on the multipane infobox things, maybe it can be made to work...
Would it help if the other judge info were put on top? --Frazyl 03:59, 25 May 2011 (UTC)
Oh maybe if instead of rather good (11/14) it was just "11 rather good" that would save 1/3 lines. Or I could scrap the string name to save on vertical space... --Frazyl 04:04, 25 May 2011 (UTC)
Ok changed it. It looks much more compact now. Still wish there were lines between rows. --Frazyl 04:36, 25 May 2011 (UTC)
Regarding the click for your str part there could be links to click for each str there is data for and one to show all. I just have no idea how to make that work with css at the moment. --Frazyl 07:10, 25 May 2011 (UTC)

I made the infobox accept numbers instead of string so you can put "11" instead of "very-good" as a first step to be able to enter the data from table in the infobox. I also tried to make a template {{Judge-str}} to make entering data take less typing but it doesn't work yet. --Frazyl 20:03, 25 May 2011 (UTC)

Ok it works now, you just need to type for example
It then substitutes this when you save the page so that it looks like you didn't use it but it was used when converting Rose-hilted long sword. --Frazyl 05:52, 26 May 2011 (UTC)

It wasn't easy, but the dynamically updated table for weapons is done for Daggers.

Basically for every weapon page we need to change

{{Infobox weapon

and replace it with


The data inside the template also needs to be updated to have the str versions like: Judge-overall-13 = pretty good

Numeric values also work like: Judge-overall-13 = 9

For now I put the values for 13 str in the table because there's no space for all possible str. Not sure if or how to make the str shown change.

On another topic, is there still what we can call "excellent xxx" weapons? Is someone going to update those pages with what, max overall value or do we scrap the pages?

--Frazyl 03:55, 30 May 2011 (UTC)

I synchronized the weights from the old table for daggers, some of those were more up to date than the pages for the weapons. Those checked with a balance should be bold as before. I weighted the delicate black stiletto, it wasn't the same weight for both. The new table is up and running, there's still a bunch of daggers with tables to move to the weapon_data. --Frazyl 08:28, 30 May 2011 (UTC)

For weapons using multiinfobox it is not possible to just include multiple boxes at once with current code. The solution is to create one sub page and place just the weapon_infobox inside them and then include those in the multiinfobox like in Switchblade. You then load the sub pages in the weapons table but not the main page and they'll all show up! :) --Frazyl 21:31, 30 May 2011 (UTC)

In regards to the weapon box info, should the "Appraises as" paragraph still be needed if all of the info is going to be in that? Seems a bit redundant to have the same exact data in two places. If it is due to some items not having exact measurements then I can see those being around. On a completely different subject, it is possible that the custom axes have a possibility of 10 different judge values for each type (5 weight categories, plus an additional one if weapon is stone which adds additional 20% to weigh, possibly changing judge as well) --Baldarov, 3 June 2011

Mmm. Well appraise serves as a nice way to verify the weapon type (there were some copy paste errors in the past it seems). I think the only thing that's sometimes in appraise and not in the infobox is the colour. There's the rough dimensions but I'd rather not have those in the infobox to prevent the weight issue of not being sure if it's exact. Plus the measuring tape can be carried around and the balance not. So yeah I guess after I do a check to verify the weapon types are in the right category I guess we won't strictly need it anymore.
For the custom axes we can do 10 different infoboxes I guess... Or maybe include 5 on top and 5 on the bottom. I need to check on what data I can include from Research:Flails for the custom stuff.
Baldarov could you please check and if possible fix the table in {{Wr-speed/doc}}? I tried to put something from the weapons in the wiki but I'm really not sure especially of those I made up that starts with "?". --Frazyl 23:34, 2 June 2011 (UTC)
I checked it out and put some new entries based on what the other categories have. I've not seen any others than what's listed there (I've looked also). I've been GFR'ng some of the heavier weapons in hopes of getting some other categories but I've not had any luck seeing any. I can compare swords now though so I can at least verify the order. Need a witch mocking in order for it to work though atm. I've started on the ordering of custom axes. Hope to get that cleared up too. -- Baldarov 00:01, 3 June 2011 (UTC)
Thanks. I've integrated those speed for the infobox and tables. Looks much better than just "?".
I'm thinking maybe if you GFR the lightest weapons they might go even faster? If you fail GFR it makes it heavier so you could try that on heaviest weapon to see if it goes slower.
I can cast GFR and mock if you see me online but I'm mostly trying to finish the weapons. :S --Frazyl 00:43, 3 June 2011 (UTC)

Work in progress

Need more info on ranged judge:

Changed to {{Weapon_data}}:

Summary tables:

They had to be separate for the code to work and trying to pass the judge data just failed.

Parametric judge

You may have noticed some weapons pages being converted to use the {{weapon data var}} template.

This is because I've cracked the formulae for strength's effect on judge (works on all swords so far, at any rate) - so weapon data can be derived from a single number for each of overall, attack and parry, rather than an array from 9-23 str, and still produce the same results.

Pages with parametric judge format have various benefits:

  • They take up a lot less template-expansion memory.
  • They provide a much finer-grain measure - parametric overall judge, for example, has a range of 0-201 instead of 0-14 - so allow better weapon comparison.
  • They can be used to extrapolate judge values at strengths outside the 9-23 range.

In order to determine what the parameters actually are for a given weapon, however, we still need the full judge/strength set (in most cases from 9-23 str, though there are some weapons that can be converted with less data).

Therefore, please:

  • Continue the good work gathering full judge/strength info.
  • Once full judge info is available for a weapon, either:
    • Convert it to parametric form yourself - you'll need to do a fair bit of trial-and-error with the parameters to make the results match up; or
    • Put the page in Category:Weapons ready to be converted and I'll get around to converting it at some point.

--Chat 21:19, 3 June 2011 (UTC)

I've tagged a bunch, there's more in Special:WhatLinksHere/Template:Rbkey that are missing 9 to 12 but have 13 - 23. --Frazyl 22:27, 3 June 2011 (UTC)

Vertical-select tables

I've added a new feature that collapses the rather large judge tables down to a single judge line, with buttons to change the strength the line uses. See Copper short sword for an example of it in action.

Please take a look, and let me know if you think this should be the correct long-term format for judge data (in which case all the weapons will be converted to use it), or whether you think something's not right.

--Chat 17:31, 4 June 2011 (UTC)

Well I think it looks great :D. Just wish I could figure out how that parametric thing works so I could change stuff if needed later on.
So... I guess the next step will be to add the same strength thing to the main weapon lists somehow?
Alas, it won't be that straightforward. The vertical-select code requires the full table to be available in the article, and then works by hiding all but one of that table's rows. The server won't be able to cope with having 15 strength rows per weapon on the weapon list pages.
If we want to do something similar on the list pages, then we'll need to use another way. The most obvious solution would be to implement the parametric judge formulae directly in javascript and invoke that on the weapon list pages; I'd rather not do that until we're more sure that the current formulae work, however.
--Chat 20:16, 4 June 2011 (UTC)
It looks nifty but I'd like it if there were a show all button to switch back to seeing them all (and another to collapse it back I guess).
I guess it would be even niftyer if there was a list of the str buttons available to click on...
For the weapon tables for now I guess we could show a few. Like 13, 16, 20 maybe? That way you look at the closest one to your str if that's doable. Until we decide what to do next.
Mmm. Could we pass a parameter in the url for example str=14 and use that in the wiki templates to show just that? --Frazyl 21:25, 4 June 2011 (UTC)

Str variants of weapon type tables

Ok I've made completely dynamic tables for every str from 9 to 23.

No change for entering data, just modify the individual weapon page and add it to the base weapon type page. The base page is the "13" one, clicking on 13 return you to the base page.

The other pages include the base page so you can just go to the str you wish to see. The links for the other weapons type are the same str as you're currently viewing since the most likely use case it going to your str then look the different types for your str.

I had to change the templates a lot after doing lots of pages and it seems that as a result the pages are rather sluggish loading but it should stabilize after all the pages have been updated in the cache or something like that.

--Frazyl 01:37, 3 July 2011 (UTC)

I've put the "unknown" that replaced the "?" smaller because it was too visually obstructing for indicating lack of data.

I feel that the ? were easier to locate and took less visual space, not sure if the more verbose unknown is better. --Frazyl 22:39, 22 July 2011 (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)

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)

So, will someone create a quest namespace for quest articles? Or should we put them in the research namespace?

The primary advantage of a quest namespace is that this will stop quest pages appearing in Special:Random, which can send someone who doesn't want to be spoiled to a quest page and it will stop them appearing in default search (happens when the article doesn't exist) Special:Search, which will reveal the context of the search, that is unhidden quest info.

--Frazyl 18:31, 7 May 2010 (UTC)

AFAIK, creating a new namespace requires editing the server's LocalSettings.php; as such it's something that only Drakkos can do, so you should speak to him.
Please don't move quests into the Research: namespace - that will end up polluting Research: with things that aren't research, and we don't want that.
--Chat 22:45, 7 May 2010 (UTC)
Hey, what about the Help: namespace? It is somewhat appropriate and not really in use (the only thing in it is Help:Contents), and I don't think Special:Random catches pages in it.
--Ilde 18:42, 25 March 2011 (UTC)

Ok, so I came up with a few ideas to improve quest pages. For the namespace I was waiting for the captcha to be installed first so as not to ask too much at once...

So I made a template {{Prehidden}} that basically is like {{prebox}} with white on white text. The advantage of prebox is that it preserves line breaks and spaces and other characters without breaking out too easily as with <p> (making a list with * or : makes everything after visible) while removing then obsolete <br> tags and allowing some formatting like bold or italic. Also it puts a pretty box around the text.

See Alchemists'_Guild_quests for examples.

If it is agreeable we could turn {{Hidden}} like {{Prehidden}} unless there something that I didn't think of.

As for quest duplication, it is possible to include pages with {{Include}}. It's only a matter of merging quests into the subpage and the template includes them with formatting and a link to the included page.

As for what includes what Unofficial_quest_solutions looks good, there's some difference to the structure of the Discworld quest pages though.

If we get a namespace for quests, I was thinking that each quest could get its own page in non-hidden text, which would then be included in the lists in {{Prehidden}} boxes. So if you don't want to be spoiled too much you can check the lists and to edit the quest and to be spoiled it would be easier to see it all at once in the quest page. It would use a tweaked include template.

--Frazyl 07:02, 11 June 2010 (UTC)

Ooooo! The include templates are a neat solution for the duplication issue; kudos for that. --Ilde 03:04, 12 June 2010 (UTC)

Slight issue, when including a page with the template include it doesn't work. You'd think it would check if there really was a loop, but no it just refuses to do anything. The only workaround that comes to mind is to make duplicate {{Include}} templates, one per level. --Frazyl 07:14, 11 June 2010 (UTC)

Ok all pages have the same format and duplicate quests have all been merged except for Sentimentalist and Distant Exhibitionist which have several versions.

Some quests fitted several areas, put them in the most important area. To place a quest in several areas would mean putting the quests in individual quest pages and including those in all list pages that is concerned, but we said that would be too many pages so we'd need the quest namespace. --Frazyl 02:01, 9 July 2010 (UTC)

It occurred to me that while we can't include the text of the quests that could go in several places in more than one place (because we can't include sections, only pages as far as I know with mediawiki) we could place links to the quest.

Might be worth going through the quests vs the mud quest pages to put stubs for quests missing and links to quests that are somewhere else, at some point.

--Frazyl 23:20, 13 July 2010 (UTC)


Right, after doing some analysis on the anonymous IP addresses we've been getting spam from, I've identified netblocks owned by Nobis Technology as containing many (alas, not all) of them. To give an example, all four of the IP range blocks I previously implemented have been from this set!

I've therefore blocked the entire lot. Hopefully this will cut down the spam load somewhat. The list of their domains is at the ARIN WHOIS register, may be worth checking it if spam spikes in future in case they've been assigned new netblocks.

--Chat 23:50, 17 May 2012 (UTC)

Hopefully this'll help. If not we may have to consider something a little more drastic. Яehevkor 00:04, 18 May 2012 (UTC)

I've now coded a script that can analyze recent IP blocks and match them to network domains - the results can then be used to work out which netblocks to ban.

  • The code is at User:Protectbot/source/block-analyzer
  • I've been running it with the Protectbot account, but I think it will work for anyone - though non-admins would need to tune the rate limit down.
  • You'll need to use the various NIC's whois servers to get the list of an organization's netblocks, once the script identifies a suspicious owner. Unfortunately, none of them have quite the same interface, so each takes a bit of getting used to.
  • I've generally applied the rule of '3+ spam IPs = block', but there's necessarily a degree of judgement involved. It would be a bad idea to block BT, for example, even though there are multiple spam IPs in their netblocks, as many legitimate contributors will also be using them.
  • This method won't work for spammers that create accounts on the Wiki - the mediawiki software defaults to an (IMO, idiotic) restriction that no one can see the IP that creates an account, thus we can't block based on it. That said, the CheckUser extension fixes this, so may be worth installing.

--Chat 22:46, 23 May 2012 (UTC)


The (re)captcha doesn't seem to stop them. I was wondering if it's some default implementation of re-catpcha for Mediawiki, and if so, if we can slightly modify it to fool their spam software (since I assume that they're just stupid bots targetting mediawiki wiki's, rather than specifically this wiki). --Aeatan 13:51, 26 May 2012 (UTC)

There's many extensions we could add to deal with spam including asking a question about the mud, but none of us have access to do that. Need a new host. --Frazyl 17:56, 26 May 2012 (UTC)

Spam Redux

Is it using special:wanted pages to identify pages to create? Zexium 02:13, 13 July 2012 (UTC)

Alias vs Aliases

These two pages should probably be merged or moved to be more intuitive with links added between them. Either Alias should be a section of Aliases and then move Aliases to Alias or move Alias to a new page (i.e. Alias Tip and Tricks) and then move Aliases to Alias. As it is the nice information on either page might go unnoticed by users when they search for the opposite page's name and there probably shouldn't be a page of both the singular and plural of a given thing (with singular being more standard). I would go ahead and fix them, but I'm not sure which solution would be preferable. I'd lean towards the new page somewhat give the way the alias info is already separated into different pages and to keep the page from getting overly cluttered. --Sigil (Talk) 18:34, 5 September 2012 (UTC)

I merged them because the info seems to not repeat, the table of contents at the beginning allows to go to the bit of interest. I think it's not too overly long.
--Frazyl 03:26, 6 September 2012 (UTC)

Upload problems

I keep getting this message:

Upload warning
The file is corrupt or has an incorrect extension. Please check the file and upload again.

...when I try to upload an image. I've tried saving the image as a .gif, as a .jpg, and as a .png, but get the same thing every time. It's not over the size limit, either--only about 8-54KB depending on format. Is anyone else having this problem?

ETA: The image in question, uploaded elsewhere: [2]

--Ilde 00:44, 15 January 2013 (UTC)

Oups upload_tmp_dir wasn't in open_basedir. Please try again.

--Frazyl 02:32, 15 January 2013 (UTC)

Ok seems to work fine now. Feel free to rename, was just testing it worked.

--Frazyl 02:47, 15 January 2013 (UTC)

Aha! Great, thanks.  :D ETA: Annnnd uploaded a new version since I managed not to crop the first one properly. --Ilde 03:39, 15 January 2013 (UTC)

Email new password not working

Apparently the "email new password" button on http://dwwiki.mooo.com:8080/w/index.php?title=Special:UserLogin&type=login isn't working, and this error message appears if you try:

Error sending mail: PHP is not configured to send mail

I got this same error message just now when I tried to set an email address in my preferences, too. (Although it did save the email address I used. I speculate that when you set an email address it attempts to send an email, presumably to confirm it, and that's what caused the error message.) --Ilde 07:31, 16 March 2013 (UTC)

Should be fixed. --Frazyl 11:34, 16 March 2013 (UTC)

TM wiki gone

As Aphaea noticed, the TM wiki is gone, but archive.org still has several snapshots, this is the latest one. Aphaea has started copying data across, I was just wondering: Would it be better to have the TM stuff on the skills' research pages? --Gunde 16:05, 28 March 2013 (UTC)

I think it's fine either way. I'd prefer if all the bonus ranges were on the same page because it means less clicking. The way Aphaea is doing seems fine to me, especially since there's links to other skills to help navigation. --Frazyl 17:42, 28 March 2013 (UTC)

Working on creating a house format for the TMs section being added to all the skills pages.

So far removing all anomalies at the start of fields and capitalzing them however I will be aiming to have the 'action taken' field in a set format rather than it is now, before i work out how this will be i would like peoples input (If this page is still used --Ascdren 13:27 30 march 2013 (UTC)


Should a link to Languages be include on the homepage under Game Systems? --Zala 18:59, 11 October 2014 (UTC)