User talk:Saftzie

__NOINDEX__ Archives:
 * 2009-2012 *

Son of Better pengLocations
The proposal was successful; you can implement the proposed changes.

P.S. Not sure if anyone has said this, but I really appreciate you updating the PHAS locations every week, even though most people might take it for granted. I'm sure it has made the lives of penguin hunters easier and has made the wiki a more reliable source than most others.

-- 00:17, January 10, 2013 (UTC)
 * Thanks for letting me know. Also (ps) you're welcome. -- 00:21, January 11, 2013 (UTC)
 * I'm not the most active peng hunter (I can't remember the last time I did), but would I be wrong in thinking that the locations repeat over a certain length of time? Is it possible to automate, either by script or bot, the posting of the locations?
 * Penguins and the bear used to repeat before the update that added Zanaris, Dorgesh-Kaan, and Keldagrim as possible spawns. Since then, there has been no regular pattern, although people still call the algorithm that selects locations "the pattern." The algorithm is a partially unanalyzable (so far) function that makes updating the locations programatically impossible. Penguins are found quickly each Wednesday by flooding w60 (or w71 as some prefer) with lots of people looking for them. -- 23:44, January 10, 2013 (UTC)
 * That's a shame. Boo for Jagex making it actually random
 * They're not completely random, just partially unanalyzable. After studying the new "pattern" for more than a year, some people can predict them with better than 80% accuracy. It's the other 20% that's the kicker. -- 10:27, January 11, 2013 (UTC)

Just used the new table and it is wonderful. thanks for the great work Saftzie. Chrislee33 (talk) 03:51, January 12, 2013 (UTC)
 * You're welcome. Thanks for the motivation to do it. -- 04:14, January 12, 2013 (UTC)

Untitled PoP
Is there any way we can link the crew members to specific pages whilst keeping the table looking tidy with the breaks?

I was linking to the crew member pages specifically because they are orphan pages. Would be nice if we could somehow work this out and achieve it.


 * It's possible to put breaks in the displayed links. I have done so, but someone removes the links. I guess there isn't general agreement to link those pages. -- 21:13, January 22, 2013 (UTC)

Dungeoneering staves stats
Please go inside dungeoneering to verify the stats before updating the page, if you do that you will see those staves clearly have a damage stat, no it is not a strength stat, but it is there (magic). Please go see for yourself Shinigamidaio (talk) 15:20, February 2, 2013 (UTC)
 * You are mistaken if you think I have not verified the numbers. Perhaps you are thinking about how the "damage" number is calculated. It's the spell damage + the user's magic level. There's no contribution from the staff. For example, magic damage for someone with magic level 51 using air blast with an air staff has a damage stat of 444. Air blast is 393. 393 + 51 = 444. Or am I missing some other stat that you mean? -- 15:43, February 2, 2013 (UTC)
 * well this is awkward... sorry... I didn't know jagex added some secret bts encription to staves... awesome...my appologies Shinigamidaio (talk) 15:48, February 2, 2013 (UTC)
 * I wouldn't call it encryption. It's just how max damage is calculated. The merchants on the "beta" servers called all damage stats "strength," which actually makes a lot of sense.
 * Melee damage = weapon damage + strength level
 * Ranged damage = weapon damage + ammo damage + ranged level (until 2 weeks ago, was just ammo + ranged)
 * Magic damage = spell damage + magic level
 * It's entirely possible Jagex could put a bonus stat on staves. But they haven't. -- 15:58, February 2, 2013 (UTC)

PoP
As I said when editing: "QFC? Qatar Financial Centre, Quality Food Centers, Quantum Flow Control -- hard to assume Goof faith when you say: gfto. For now it's a good addition especially with note." So please don't revert again, especially not without a reason. Thanks ;) 13:29, February 22, 2013 (UTC)
 * Speculation is speculation. Take it to the article's talk page, where there's already a section on max level. -- 13:59, February 22, 2013 (UTC)
 * There's a difference between speculation and an estimate. That "speculation" has been there the whole time, it wasn't a problem, and there's even a disclaimer. 16:19, February 22, 2013 (UTC)
 * No. Your speculation is speculation, no matter how many "disclaimers" you want to put on it. Really, take it to the talk page for the article. -- 16:25, February 22, 2013 (UTC)

+1
For Bloom County. 01:57, April 20, 2013 (UTC)

RE:‎Leave like this for now and discuss
Sprite popup works fine for me in Oasis if I log out. Does it not work for you? -- 23:04, May 5, 2013 (UTC)

Not always. It seems to be glitched somewhat. I tried on chrome and IE and it sometimes doesn't pop up. Not sure what the issue is though. 23:06, May 5, 2013 (UTC)

Tackle box
You are coming close to breaking the revert policy on the aforementioned page. Even if Leon Art edits the page back to the version you don't like, could you please try to talk to him about it instead of immediately undoing it again? 16:28, May 8, 2013 (UTC)
 * Sure. FWIW: WhatLinksHere/Tackle_box/Slots -- 16:31, May 8, 2013 (UTC)
 * Oooooohhh, wow, that's amazing how that works :3 Thanks! 17:45, May 8, 2013 (UTC)

Waterbirth Dags
Ok, now I see the patch notes part. Sorry about that, was just doing my best with the time I had to make a quick and simple update. No need to erase everything though. Me stating that the exp/hour at Dags will be cut short by a ton is still useful information and if they see it (the readers) near the top rather than the very bottom it will help them get to the point faster.

Mod image can be removed, the hidden part can as well. But leave the date and what exactly happened there for readers to understand quicker. Or send them a link to the patch notes.

Thats just me however.

Can you semi-agree?

Uraninite (talk) 18:29, May 8, 2013 (UTC)
 * The link is in the Trivia section. Also, they're not unaggressive. If you stand in the middle of the room, they'll attack you. It's just not the whole room on you at once. -- 18:58, May 8, 2013 (UTC)


 * Ok, so by near-sighted they mean, they will get you eventually, just not as hostile as they were before such as 20+ or more, but more like 10-15 now?
 * I havent tested it myself yet, so my overall knowlage about this update is rather slim. Again sorry, but we should leave something that is close to the top that shares the news about it, rather than the very bottom. However, I'll leave this final choice up to you new update facts near top of website or update far below the loot tables.  Again, I'm sorry if I caused so much trouble, first time really updating something this major before. :P
 * Uraninite (talk) 19:28, May 8, 2013 (UTC)
 * I had a slayer task that I did there a little earlier. Basically if you're more than 2 spaces away from them, they don't see you, which is pretty much the same as LRC creatures. I had about 2 or 3 on me most of the time. -- 20:12, May 8, 2013 (UTC)

Re: No advertising fcs in articles
Blocked? By who? Rofl. The wiki is for helping, correct? That's all I'm doing.Manswer (talk) 02:00, May 14, 2013 (UTC)

Tackle box article
I don't have a clue what a transclusion is but thank you for fixing it up for me. If you notice any other derping feel free to change it, I'm not 100% sure what everything does around here haha. Duffmaaan (talk) 23:51, June 3, 2013 (UTC)
 * It provides the "Slots" section header for all the pages that import the content. Special:WhatLinksHere/Tackle box/Slots If people want to edit the Slots content, they just click the header, the same as if the content was in the same article. Generally, they shouldn't have to go to the Slots article otherwise. -- 00:07, June 4, 2013 (UTC)

pengLocations
As part of my js restructuring, I've been updating the various imported scripts as well. Seeing as you wrote the original, would you mind reviewing my changes? The main changes are switching to $.cookie over the cookie functions we have in the common.js and wrapping it in closure. There are also some styling tweaks such as enforcing braces on conditionals, moving tabs to spaces (as not everyone has tabs available) and the way properties are set when inserting nodes with jQuery. The updated version can be found here.

I was also looking at how you alter the background colours when clicked. Surely it would be easier to add a class and style the class in MediaWiki:Common.css?


 * I'll have a look at the updates. As for why I did some things a certain way, I kept as much of the previous code as possible and just added new functionality, rather than do a total re-write, even though the change was still extensive. -- 22:53, June 21, 2013 (UTC)

RE: Template:Infobox monster
It was a request from a few people in chat. 14:40, July 2, 2013 (UTC)

Re: Re: pengLocations (redux)
Thanks, I'll get it updated now.

As far as the lighttable script goes, I was thinking something like: I was considering writing it from scratch when I next had a chance, but I can give you a hand with what you have so far if you want?
 * Separate cookies for each table, each called  where tableId is the table's id.
 * Implementing CSS for the hover/click:  and just add the selected class on click/if the cookie says to do so.
 * Basically the same cookie content, just a binary string where 0 is unselected and 1 is selected.


 * There can be multiple light tables on multiple pages. I think the biggest complaint people have about the current code is that the highlighting on one table gets applied to all tables, even across pages. The way I have the js written now, it mostly just lifts the pengLocations code (which is how Quarenon pretty much did it, I think), but with a different monolithic cookie that supports multiple tables on multiple pages. There's a decision to be made if a different cookie for each individual table is desirable. I also thought about using bits for on/off (instead of a whole character), although I haven't implemented that as of now. The cookie part is modular enough that changes shouldn't be too big a deal. At the moment, I just need to test the basic code, though. -- 20:39, July 15, 2013 (UTC)


 * I think I'm essentially done with the code to update MediaWiki:Common.js/highlightTable.js. I've put my current version in User:Saftzie/Beta.js.
 * Rather than a separate browser cookie for each table (or even each page), there are up to 16 browser cookies (maximum).
 * Each cookie covers several pages, based on the hashed page name, and all the tables on those pages. They're named, where hexdigit is the first hex digit of the hash of the page name. I think having a separate cookie for every table or every page could potentially be too many cookies, but having only one would keep anything from expiring if the user kept using any light table anywhere. 16 seems like a reasonable compromise to me.
 * I use a 32-bit Castagnoli crc for the hash. A crc uses minimal coding to calculate. The Castagnoli crc has optimal collision avoidance and uniform distribution in a 32-bit crc.
 * The CSS classes are the same ones that pengLocations uses. That was always my intent. No change is required to MediaWiki:Common.css, although you might want to change the "pengLocations only" comment to include light tables.
 * The browser cookie content is a string composed of the page name hashes and Base64url-encoded binary data for the rows' selection status, so each table still has its own data.
 * There's a lot of new code compared to the old code, but most of it is cookie handling. None of it runs unless there's at least one light table in the article. Cookie data is only stored if the user manipulates the light table in some way. Just loading/viewing the article doesn't create a cookie. For the 39 articles in Mainspace that have light tables, if every page gets cookie data, there would be 685 bytes of data. Of course, I wouldn't expect a user to visit every page with a light table and store a cookie, but the number of pages with light tables could grow, too. So, do we just want to slam it in or try to get some good will first? -- 06:16, July 18, 2013 (UTC)

Re: _
This is some of the stupidest shit I've ever seen. And I spent over an hour yesterday arguing with Ben about a single sentence. 20:05, July 29, 2013 (UTC) (in which I did not participate). Some things do vary from browser to browser, but the mark-up generated by MediaWiki doesn't. -- 20:18, July 29, 2013 (UTC)
 * At this point, it's more about understanding the difference between what MediaWiki does and what the browser does. There was a similar discussion about the difference between  and
 * It effects literally nothing. Just like how my usage of effect in the preceding sentence affects nothing. 20:20, July 29, 2013 (UTC)

Again, that is what mediawiki turns it in to. MY argument is at the opposing end, the client's side. If you type "http://runescape.wikia.com/wiki/Runite Saradominist token", it is redirected by the SERVER to "http://runescape.wikia.com/wiki/Runite_Saradominist_token". However, if you were to type "http://runescape.wikia.com/wiki/Player-owned port#Resource cap" it turns into "http://runescape.wikia.com/wiki/Player-owned_port#Resource cap", which does NOT work. This is client side; and thus the proper notation for the anchor is to include the '_'. For mediawiki, a link to "Runite Saradominist token" is as valid as a link to "Runite_Saradominist_token", but for your browser, an anchor to "Resource cap" is NOT equal to an anchor to "Resource_cap". The fact that mediawiki replaces all spaces in an url, including those in an anchor, to underscores is irrelevant; if mediawiki suddenly, for whatever reason, would stop replacing these, the urls will still work; the anchors won't. IP83.101.44.209 (talk) 04:13, July 30, 2013 (UTC)
 * The text inside  is a wikilink, not the   itself. The fact that MediaWiki replaces all spaces in a wikilink when it generates a URL is the whole point. -- 05:05, July 30, 2013 (UTC)
 * The pagename is a link; an anchor is an anchor, pointing to a place in the page the link points to. An anchor is not part of an url, but rather an addition. My above comment illustrates the difference; which you haven't responded to. On a second note, what reason is there to remove the "_" from anchors? The only reason I've so far seen you state is "but mediawiki fixes it itself". This fix is something we depend on and hope will continue to happen, or the anchors'll break (and no, normal links won't, as illustrated above). Nobody complains if someone changes a wiki-link that points to a redirect page, to link directly to the page it is meant to link to (aka, avoiding a level of indirection, and avoiding a dependancy on the redirect page). This is exactly the same: adding the '_' ourselves, correctly, avoids the indirection and trust that it will always replace that, because otherwise any anchor with a space will fail. IP83.101.44.209 (talk) 05:44, July 30, 2013 (UTC)
 * I am not saying "but mediawiki fixes it itself." There's no "fixing." A wikilink is a wikilink. MediaWiki articles are not written in html, although MediaWiki can pass html along in some cases. MediaWiki generates the mark-up for the entire article, including anything inside, which it happens to convert to  , the href, and any inner html. It's more like a compiler that takes the article source text and generates the mark-up. The mark-up generation is not some secondary function "we ... hope will continue to happen." It's the central function of MediaWiki. As I said previously, you could make the same argument about using a _ for every wikilink that has a space, yet convention is not to include _ in wikilinks, because they're unnecessary. MediaWiki doesn't care about the #. It's all just a link. -- 06:03, July 30, 2013 (UTC)
 * "As I said previously, you could make the same argument about using a _ for every wikilink that has a space, yet convention is not to include _ in wikilinks, because they're unnecessary." => As I said, this differs from anchors in that urls with spaces also actually work; anchors do not. It is by 'sheer luck' that it doesn't care about '#' or anything behind that, and treats it the same. This is not logical behaviour considering it has a completely different function from the page-name entered and parsed to produce a page link. IP83.101.44.209 (talk) 07:25, July 30, 2013 (UTC)