User talk:Nx
WelcomeEdit
Hello! Welcome to UESPWiki. It's always good to have new members. If you would like to help improve any of our pages, you may want to take a look at the following links:
- Policies and Guidelines: UESPWiki standards and expectations
- Quick Editing Guide: a quick guide to wiki markup
- Getting Started: how you can help
If you, on the other hand, would like to spice up your userpage, take a look at this link:
- Userboxes: near complete list of userboxes, including a guide to make your own
When you're editing, it's always a good idea to leave edit summaries to explain the changes you have made to a particular page, and remember to sign your talk page posts with four tildes ~~~~. Also, the "show preview" button is a great way to view the changes you've made so far without actually saving the page (our patrollers really appreciate it!).
Feel free to practice editing in the sandbox and don't hesitate to contact one of our mentors if you need any help. Have fun! --Michaeldsuarez (Talk) (Deeds) 13:05, 13 December 2009 (UTC)
- --Michaeldsuarez (Talk) (Deeds) 13:05, 13 December 2009 (UTC)
Azura's StarEdit
Hey, Nx! I'm new of this patrolling thing so please excuse me if I'm wrong, but the reason I removed your comment and TheAlbinoOrc's, it's because while they don't fall into neither of the two descriptions that you gave in your edit summary, neither of the comments add something that could help the editor who posted the question. And, actually, I should've removed Mikeyboy52's comment too since the topic is of two years old, so it's highly unlikely that the editor who posted is still around. I've decided to live it like that since I don't want to make the same mistakes again, but I still think they should be removed ;) --MC• S'drassa •T2M 18:42, 8 January 2010 (UTC)
New ImagesEdit
The new images you're uploading are great, but where the current one has an incorrect name, please could you just overwrite that rather than creating a new one? That way we keep the contribution history for the old image and a patroller or admin can rename it at a later date. –rpeh •T•C•E• 19:54, 10 January 2010 (UTC)
- I think I read somewhere that I should upload the fixed image at the correct name, but apparently that was written at a time when MW did not support moving images (Help:Images also said renaming was impossible).
- Is there a template to alert admins/patrollers to an image that needs to be renamed? Should I just keep the cleanup template with "wrong name" as parameter? -- Nx / talk 20:02, 10 January 2010 (UTC)
- Unfortunately, there are probably a lot of pages that need updating since UESP moved to 1.14 - I saw you fixed the Patrollers page for instance. Where I've uploaded a new version, I've left or added a {{Cleanup}} tag, although I did consider creating a specific template for it. –rpeh •T•C•E• 20:13, 10 January 2010 (UTC)
- BTW, it's possible to merge page histories by moving the new file to the old name, deleting the old file in the process, then restoring the deleted revisions, and finally moving it back to the correct new name. -- Nx / talk 20:15, 10 January 2010 (UTC)
- Unfortunately, there are probably a lot of pages that need updating since UESP moved to 1.14 - I saw you fixed the Patrollers page for instance. Where I've uploaded a new version, I've left or added a {{Cleanup}} tag, although I did consider creating a specific template for it. –rpeh •T•C•E• 20:13, 10 January 2010 (UTC)
Foul Fagus imageEdit
The new image you uploaded is great! I reverted your first one because it was a tad too bright and has a bit zoomed-out; but now it appears you've fixed it. Good job! :) --SerCenKing Talk 20:53, 31 January 2010 (UTC)
- It's still the same image, I just cropped it and ran a sharpen filter on it. I'll try getting a better screencap tomorrow. Maybe turn off hdr or try different time of day. -- Nx / talk 20:59, 31 January 2010 (UTC)
- Yeah I can see that :p HDR can be a hassle, I turn it off myself when I take image because it kind of distorts the lighting. --SerCenKing Talk 21:03, 31 January 2010 (UTC)
CyrodilicEdit
You're right - but see this. Bethesda aren't consistent, so we have to allow both spellings. rpeh •T•C•E• 23:07, 3 February 2010 (UTC)
FavourEdit
I wonder if you can do a little favour? We have a problem with possible database corruption at the moment. I know you're familiar with the MediaWiki database so if you have time could you come up with a few specific test / fix queries for Daveh to run? Anything you can suggest would be helpful. rpeh •T•C•E• 23:50, 3 February 2010 (UTC)
- I've replied with the only idea I have now, I'll look into it further, but I'm on Windows now so I don't have a proper working environment. I'm guessing since those pages were deleted their content isn't really vital? In that case it might be best to just go the easy route and manually remove them. -- Nx / talk 00:19, 4 February 2010 (UTC)
Monobook.jsEdit
Is there something you can do to your monobook.js page to work around this? Not a big deal if you can't but it seems it should be simple. Thx. ‒ Joram↝Talk 07:46, 15 February 2010 (UTC)
Wanted: CSS-fuEdit
Your CSS-fu is better than mine. Can you explain to me why the inner table in my User:Joram/Wikifu2|sub-userpage top-aligns with class="hiddentable vtop" style="text-align:center;" but not with class="hiddentable" style="vertical-align:top; text-align:center;"? Thx. ‒ Joram↝Talk 00:31, 25 February 2010 (UTC)
- vtop applies the "vertical-align:top" formatting to the table's td, th and tr elements, like this:
table.vtop td, table.vtop th, table.vtop tr {
vertical-align: top;
}
- in the second case you are only applying it to the table element, which is invalid, and unlike text-align, vertical-align is not inherited (according to the spec at least). You'd have to manually add style="vertical-align:top" to every line in your table were it not for the vtop class. -- Nx / talk 01:06, 25 February 2010 (UTC)
JavascriptEdit
I notice you have a few customizations to your monobook.js file. If you have the time, I'd really appreciate it if you could split them off into separate pages under UESPWiki:Javascript and add appropriate lines to the table there so that everybody can make use of them. If you don't have time, let me know and I'll take a crack at it...after I learn enough Javascript to figure out what you're doing. :) ‒ Robin Hood↝Talk 02:23, 16 March 2010 (UTC)
- Most of that stuff is just a workaround for IE6's inability to use :hover on any element. I needed it for a demonstration, that's all. I did add a script I was using that gives you a link to the subpages of a page, but it's a simplified version I discovered after writing mine (the simplification is that mediawiki has a builtin function to add stuff to portlets, so a bunch of my code wasn't needed). -- Nx / talk 10:32, 16 March 2010 (UTC)
- Yeah, I had noticed the subpages and thought that might be handy...with the number of subpages in my user space, you can bet I'll be trying it later today. I had no clue what the hover stuff was doing or why, though the variable declarations made it clear that at least some of the code was working around an IE6 bug of some kind, but that's why I didn't try to do it myself...I didn't understand it at all. ‒ Robin Hood↝Talk 18:26, 16 March 2010 (UTC)
Cookie!Edit
 Your dedication and diligence to the wiki has not gone unnoticed. A user has seen the progress you've made, and has given you a cookie because of it. Good work! The user had the following to say:
|
- Thanks, but I don't really deserve a cookie for that. I'm just good at finding and using others' work. :) -- Nx / talk 23:55, 16 March 2010 (UTC)
- Well, there's been a lot of other help and advice that you've given as well, so take your cookies where you get 'em. :) I second rpeh's cookie! ‒ Robin Hood↝Talk 00:19, 17 March 2010 (UTC)
Thanks!Edit
|
Your dedication and diligence to the wiki has not gone unnoticed. A user has seen the progress you've made, and has given you a cookie because of it. Good work! The user had the following to say: |
Block Limit ExtensionEdit
Just wanted to point you to the latest goings-on in this discussion. Thanks in advance! --GKtalk2me 15:35, 22 March 2010 (UTC)
#IconEdit
Hi Nx. I ran across a small bug in #icon today that I'm hoping you can figure out a better way to fix than I can, given that I don't know PHP at all. The problem occurs when you use code like {{#icon:OB-ico-UOP.png|Label|18|Oblivion:Oblivion}}, which fails to produce any hover text only if you specify a size; if you don't specify a size, all is well.
- No size: {{#icon:OB-ico-UOP.png|Label||Oblivion:Oblivion}} (hover text works)
- Size specified: {{#icon:OB-ico-UOP.png|Label|18|Oblivion:Oblivion}} (no hover text)
Looking at the code for Icon.php (see Extension:Icon), search for "toHtml". The only hit you get in the file is the line that causes the problem...it (or MediaTransformOutput.php, it looks like?) somehow fails to properly parse the title parameter. My primitive solution was to replace the line with:
$imageString = "<img class='iconimg' style=\"vertical-align: middle;\" src='${iURL}' alt=\"{$alt}\" title=\"{$alt}\" width=\"{$width}\" height=\"{$width}\" />";
This works, but while I may not know PHP, I understand enough of what I'm reading to know that that's redundant with the transform a few lines above, and probably not the most elegant way of doing things in any event. If you have a better solution, I'd like to hear it so we can submit it to Dave. Based on my testing, MW 1.15 no longer has the issue that 1.14 does (unexpected hover text on linked Files, like this: [[File:OB-ico-UOP.png|link=Oblivion:Oblivion|18px|Label]]), so #icon will become redundant, but until then....
Also, if you install Icon.php on your wiki for testing, be aware that the latest version is fubar'ed in terms of the extension hook code. The version I sent to Dave a while back uses this instead, which I cobbled together from other extensions and did the monkeys-typing-randomly thing until it worked <g>:
$wgExtensionCredits['other'][] = array(
'path' => __FILE__,
'name' => 'Icon',
'version' => '1.6.2',
'author' => 'Tim Laqua',
'description' => 'Allows you to use images as icons and icon links',
'descriptionmsg' => 'icon-desc',
'url' => 'http://www.mediawiki.org/wiki/Extension:Icon',
);
$wgHooks['ParserFirstCallInit'][] = 'efIcon_Setup';
$dir = dirname(__FILE__).'/';
$wgExtensionMessagesFiles['Icon'] = $dir.'Icon.i18n.php';
$wgHooks['LanguageGetMagic'][] = 'efIcon_LanguageGetMagic';
function efIcon_Setup( &$parser ) {
# Set a function hook associating the "example" magic word with our function
$parser->setFunctionHook( 'icon', 'efIcon_Render' );
return true;
}
Thanks for any help you can give! ‒ Robin Hood↝Talk 23:55, 23 March 2010 (UTC)
- It appears that the problem is a result of the extension using the same "bugged" code for generating a resized image. Let me see if I can find the change in MW1.15 that fixes this -- Nx / talk 00:14, 24 March 2010 (UTC)
- This bug is fixed in MW 1.14.1 [1]. -- Nx / talk 00:24, 24 March 2010 (UTC)
- Thanks for looking into it so quickly. Is there anything we can do with the existing #icon to work around it? I think we're a lot more likely to get Dave to change a line or two of code than to upgrade to MW 1.14.1+. :) ‒ Robin Hood↝Talk 01:57, 24 March 2010 (UTC)
- MW 1.14.1 is a minor update, it literally takes less than a minute to do, I know, I've done it on RW. Just download the patch (without interface changes) from here, extract it into the wiki's base directory and run "patch -p1 < mediawiki-1.14.1.patch" . You can run "patch --dry-run -p1 < mediawiki-1.14.1.patch" to see if there are any problems without applying the patch (which might leave some files updated and some not) -- Nx / talk 09:12, 24 March 2010 (UTC)
- It occurs to me, the problem with the icon hover text can't be fixed in MW 1.14.1 because that's what my testing wiki is and it exhibited the same problem with the Icon.php code. ‒ Robin Hood↝Talk 07:39, 25 March 2010 (UTC)
- You're right, but you shouldn't be right. I don't get it, there's no difference in the code between MW 1.14.1 and MW 1.15.0. -- Nx / talk 09:55, 25 March 2010 (UTC)
- Ok, I figured it out. MediaWiki 1.15 still has this issue, MW 1.16 doesn't. -- Nx / talk 11:36, 25 March 2010 (UTC)
- Here, if you look at the revision log, the 3 latest commits (excluding the latest one which is just a file move) fix this issue. -- Nx / talk 11:41, 25 March 2010 (UTC)
- You're right, but you shouldn't be right. I don't get it, there's no difference in the code between MW 1.14.1 and MW 1.15.0. -- Nx / talk 09:55, 25 March 2010 (UTC)
- It occurs to me, the problem with the icon hover text can't be fixed in MW 1.14.1 because that's what my testing wiki is and it exhibited the same problem with the Icon.php code. ‒ Robin Hood↝Talk 07:39, 25 March 2010 (UTC)
- MW 1.14.1 is a minor update, it literally takes less than a minute to do, I know, I've done it on RW. Just download the patch (without interface changes) from here, extract it into the wiki's base directory and run "patch -p1 < mediawiki-1.14.1.patch" . You can run "patch --dry-run -p1 < mediawiki-1.14.1.patch" to see if there are any problems without applying the patch (which might leave some files updated and some not) -- Nx / talk 09:12, 24 March 2010 (UTC)
- Thanks for looking into it so quickly. Is there anything we can do with the existing #icon to work around it? I think we're a lot more likely to get Dave to change a line or two of code than to upgrade to MW 1.14.1+. :) ‒ Robin Hood↝Talk 01:57, 24 March 2010 (UTC)
- This bug is fixed in MW 1.14.1 [1]. -- Nx / talk 00:24, 24 March 2010 (UTC)
<- Well, if we went to MW 1.15, the File command would support all the same options as #icon does except for external links, and at least in basic testing everything seemed to work the way we'd want it to here, so the issue would no longer be an issue because we wouldn't need #icon any more. :) I did find one bug in testing, but that's unrelated (in MW 1.14.1, resizing a pic using [[File...]] destroys PNG transparency). Anyway, thanks for looking into it and replying on Daveh's page as well! ‒ Robin Hood↝Talk 17:05, 25 March 2010 (UTC)
- The tooltip did not work properly for me in MW 1.15. Does the icon extension work properly on 1.15? -- Nx / talk 17:06, 25 March 2010 (UTC)
- You're right. When I checked the tooltip using Wikipedia a few weeks ago, it worked fine, and I'm pretty sure the reported version at the time was 1.15, but perhaps they'd upgraded to 1.16 and I didn't notice or there was a behind-the-scenes upgrade. I just tried it on Obliviowiki, which is using 1.15.2 and it failed there. ‒ Robin Hood↝Talk 17:14, 25 March 2010 (UTC)