User talk:Tennessee Ernie Ford/Archive 04

They
For the grammar demons out there: TEF uses they for the missing third person, gender-neutral pronoun. This has wide-acceptance among a number of people, although, afaik, it hasn't really been adopted by the largely white-male dominated krewe that gets to write the rule books. And, to be fair to their point-of-view, there are a good number of herstorian types who eschew its use as well. However, until someone comes up with an acceptable substitute pronoun to use when the person is known, but the gender is not confirmed, I'm stickin' with it.
 * TEF Prefers: I know that Chris is a good person, having spoken to them online many times. However, they have never mentioned their gender to me.
 * TEF Avoids: I know that Chris is a good person, having spoken to him/her online many times. However, he/she has never mentioned his/her gender to me.

&mdash; Tennessee Ernie Ford ( TEF ) 04:07, October 22, 2009 (UTC)

Another archive
Congratulations on your annoying-comment free page, that I've just messed up. I see you don't move your page to archive  Random  Time   09:53, June 10, 2010 (UTC)


 * thanks! (I think) This wiki's official archive recommendation pushes Cut/Paste with equal weight to Move. (Plus, I know I can reliably c/p; not so sure I can manage a move without ruining something.)  &mdash;Tennessee Ernie Ford ( TEF ) 10:08, June 10, 2010 (UTC)


 * Well, it's all pretty simple. I stayed by copy-pasta too at first, but from wiki perspective, moving is a lot interesting. And not much harder. The only problem is that you make a few edits more to get the archive boxes on and stuff.--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 11:30, June 10, 2010 (UTC)

So
You back in the world of Tyria, or could you just not stay away from me and my dashing good looks? A F K When Needed 23:15, June 11, 2010 (UTC)


 * A little of both! I'm considering checking out the new quests... and would also review dashing good looks, if only you were @keyboard... &mdash;Tennessee Ernie Ford ( TEF ) 03:44, June 12, 2010 (UTC)


 * The new quests are rather nice. Don't underestimate the peacekeepers though, in HM they rival the Slaver's Stone Summit, and it's worse because they have random skillsets and there will mostly be 1 or 2 people with a res, and you can't know which one until you actually see it being used.--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 05:22, June 12, 2010 (UTC)


 * Ouch!! Defeating those dwarven groups in Slavers' was super-PITA (although satisfying). Random skillsets sounds intriguing! sounds like I've missed a lot since January. (Thanks for the tips.) &mdash;Tennessee Ernie Ford ( TEF ) 06:18, June 12, 2010 (UTC)


 * In NM it's ok, as long as you don't aggro too many (although lvl 15 henchies don't help a lot). Also, the white mantle of the war in kryta (in the "mission-like quests") have some seriously effed up skillsets, with mesmers using WoH and rangers using chaos storm (though their entire build was e-denial I think).--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 06:36, June 12, 2010 (UTC)
 * tl;dr: Vanquish in Proph then do WIK A_F_K_sig_2.jpg A F K When Needed 21:16, June 12, 2010 (UTC)


 * Vanquish? Wow...when I began my sabbatical, I think I had VQ'd maybe 2 zones in proph and I doubt I tackled any of the Mantle areas :-(.


 * BTW: the only WIC I know provides nutritious food to Women, Infants, and Children. In GW, I assume it's War in Kryta? &mdash;Tennessee Ernie Ford ( TEF ) 07:25, June 13, 2010 (UTC)


 * He did say WiK (k, not c). War in Kryta yes. And also, yes, vanq difficulty of prophecies just went through the roof.--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 07:48, June 13, 2010 (UTC)


 * Hey, if you want to be pedantic, did he really say anything? (Insert favorite John Cusack joke here.) Also: my brain draws little distinction between WIC and WIK, possibly b/c they are misspellings of wick or because I used to think the nutrition program was for Women, Infants, and Kids. Regardless (of my misinterpretation, deliberate or otherwise), thanks for the clarification/confirmation. :-)


 * So, it looks like I'll never VQ prophecies... the rewards seem so weak relative to the effort. Sigh. &mdash;Tennessee Ernie Ford ( TEF ) 07:58, June 13, 2010 (UTC)


 * Alas we meet again, my nemesis, The Typo! (all adventures of Nazgir the Great vs The Typo are now available in the better comic book shop in hardback. Subscribe to the Nazgir weekly now and receive 10% off on all of the comics!)--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 08:34, June 13, 2010 (UTC)


 * Do it for the challenge, not the reward :P Also, I think you can team up with someone who hasn't started the war yet and "lose out" on the Peakeepers. --- [[Image:VipermagiSig.JPG]] -- (contribs) &emsp;(talk)  09:19, June 13, 2010 (UTC)


 * Completing Prophecies/EotN (the initial requirement for WiK) will trigger some Peacekeeper spawns in Kryta, but once you visit the Shining Blade Camp, that triggers a lot more of them. And they really aren't all that hard if you've got a good team build.  It's the new White Mantle that are really difficult, and I don't think they spawn at all until after you visit the SBC.  So if you do decide to vanquish Kryta, do Talmark Wilderness last.  &mdash;Dr Ishmael Diablo_the_chicken.gif 14:40, June 13, 2010 (UTC)

I found the mantle to be a lot easier than the peacekeepers. Only wiped once in Riverside assassination (and that was due to the fecking Mursaat Tower), and wiped a lot throughout Kryta when hunting the bounties.--El_Nazgir 14:46, June 13, 2010 (UTC)
 * Oh, the Ether seal. The burden of caster-heavy groups everywhere.  Random  Time   16:51, June 13, 2010 (UTC)


 * No, the Mursaat Tower, burden of any non-warrior/paragon. I'm a dervish myself and they too much health regen for me + 7 wandings and initial spells to kill, if there are still other dudes around attacking. --[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir meant to sign this previous edit on 08:59, 13 June 2010, but was blasted by a towering Meerkat before he could place the tildes


 * Wow! I really missed out on a lot. So, lots of non-contradictory advice! (A rarity here on GuildWiki &mdash; awesome!)
 * VQ Talmark Wilds last
 * Team up with s/o who hasn't started with Women/Infants/Kids
 * be cautious visiting the SBC (or the SEC, for that matter...although that's more of a real-life issue, I suppose)
 * read EN's new graphic novel
 * give Peas (sic) a chance, but give the Peakeepers (sic) an inch and they'll take all your veges.
 * Anything else? &mdash;Tennessee Ernie Ford ( TEF ) 21:46, June 13, 2010 (UTC)


 * Well, never eat yellow snow, and don't wake up sleeping dragons (oh wait, we did that at the end of EotN anyway...).--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 11:00, June 14, 2010 (UTC)


 * If TEF didn't wake the dragon, he wouldn't be bothered by these darn pea thieves in the first place. Why are you always so late with your useful advice, Naz :P (another thing to consider is looking at the recent Mesmer changes and exploit the fork out of it. Nearby range AoE-KD Psychic Instability omg wtf. Also, Pianc) --- [[Image:VipermagiSig.JPG]] -- (contribs) &emsp;(talk)  15:00, June 14, 2010 (UTC)


 * Yeah, nowadays, discordway is gone from my dervish. I always have a panic mesmer with me now (and an SoS rit with splinter weapon, which is awesome on a scythe ^.^). I guess I could try Psych instability too once in a while, though not on my own mesmer, who is currently also in Panic-mode, because my interrupt-reflexes suck balls.--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 17:54, June 14, 2010 (UTC)

You don't have a choice.
Hi.

If you use a signature template, Wikia will automatically add SUBST: in your signature line, and will continue to do so. The only way around this is to use two signature pages. So, basically, unless you go out of your way to avoid it, you will be substing your signature. A F K When Needed 13:33, June 17, 2010 (UTC)


 * Is that new? I first noticed peeps such as this guy using a non-subst'd sig in Jan/Feb (and it seemed common among frequent contributors at the DA wiki). Or are we talking apples and oranges here? (Or, I suppose OSx and WinOS...apples and microsoft.) Either way, thanks for the tip. &mdash;Tennessee Ernie Ford ( TEF ) 19:43, June 17, 2010 (UTC)
 * I've no idea, but I tried yesterday and Wikia... ah, insisted. A_F_K_sig_2.jpg A F K When Needed 20:28, June 17, 2010 (UTC)
 * Interesting! That's very new; it appears wikia is inserting SUBST: into the beginning of a template, if it's not already in the first 6 chars. It certainly wasn't doing that when I was active on Dragon Age. (there's all kinds of talk pages there using dozens of transcluded sigs). Good for wikia &mdash; doing something actually useful and without harming users. &mdash;Tennessee Ernie Ford ( TEF ) 20:36, June 17, 2010 (UTC)

watching
If you find yourself on a (media)wiki with no "watch" links, you can append  or   to a page URL to watch or unwatch it. (Use "&" instead of "?" if the URI already has a "?" in it, and edit the action= if it's already got one, but you know that.) -- ◄mendel► 22:35, June 25, 2010 (UTC)
 * cool! - I should have thunk of that. (Easier than manually editing my watchlist.)
 * I suppose partly I wanted admins to see it might be useful to have a watch button. (Not everyone is going to have a friend who suggests some simple wikifu, as above). Thanks for the tip! &mdash;Tennessee Ernie Ford ( TEF ) 22:41, June 25, 2010 (UTC)
 * We've been discussing that on irc just a short while ago, I think AFK wouldn't mind making one. It has to be a "dumb" button though, because it won't know whether you're already watching the page or not. -- ◄mendel► 22:52, June 25, 2010 (UTC)


 * So, the encyclopedic wikis can has watch buttons (that know whether you are/are not watching), but others (e.g. Answer sites) cannot? Is this a wikia not understanding what they are offering issue? or something more fundamental? somewhat rhetorical question - just seems odd to me &mdash;Tennessee Ernie Ford ( TEF ) 23:05, June 25, 2010 (UTC)
 * Wiki thought it was a good idea to cut the "page bar" from the Monaco version they run on "answers" type wikis. I have no idea why. -- ◄mendel► 23:22, June 25, 2010 (UTC)

Polling data
I continue to play Guild Wars... Weekly or more often Several times a month What game?

Validation
Verification of sampling community I visit TEF's talk page b/c His User/talk page is on my watchlist I patrol RC I lurk everywhere I don't visit TEF's talk page.

Not A Poll
I consider you a friend, don't use a watchlist.

Havn't voted on the second one, want me to go with the "watchlist" option or leave it? A F K When Needed 22:26, July 4, 2010 (UTC)


 * eh, they are both more silly than serious intent, so... either; feel free to use "watchlist" (spiritually true, if not technically). I suppose, "I lurk everywhere" is also correct (patrolling RC would count, with a liberal definition of "everywhere")


 * Regardless, thanks for participating! I am sorta curious how many of us what hang out @GWiki still play. &mdash;Tennessee Ernie Ford ( TEF ) 00:27, July 5, 2010 (UTC)
 * I stopped playing in any way actively for a long time, but in the recent months have made an effort at God Walking Amongst Mere Mortals. When that's over with I would imagine I'll only log on once in a blue moon to add something to my HoM.
 * For the love of God I hope ArenaNet release a date (and stick to it) soon. While the new info is great, without a date being released - forget the date being near - it's largely trivial imo. A_F_K_sig_2.jpg A F K When Needed 12:41, July 5, 2010 (UTC)

de jure
I noticed that, but I wasn't going to go into it. I'm also fairly certain that people without mathematical training are going to misunderstand "Expected" (as opposed to average), but maybe you want to give a confidence interval? ;) -- ◄mendel► 05:57, July 5, 2010 (UTC)


 * I think ppls without statistics training will grok "expected," so it's mostly for pedantry's sake (in the vernacular, I'm sure "expected" = " average" = "slightly less than what I should get"). De jure is the opposite; it's a $5 phrase where a nickel word will do. Mebbe "average" should remain, but we can surely do better than de jure.


 * Re: confidence interval. I almost re-wrote that section; it rubs me the wrong way that we say, "equal chance of winning on each circle" and then later say, "but in the center circle, you can last longer without restocking." (That has the air of a contradiction.) But I couldn't figure out any way to express that without statistical justification (and beyond the scope of the article). So, even though you were joking about it, ... it's not a crazy idea to convey variance or, despite the equivalent odds, that there are good reasons to sit on each circle, depending on what you want to achieve, how long you play, etc.


 * However, the article should be tl;dr, which it mostly is: all circles same for lucky, outer circles good for unlucky, longer lasting in center. &mdash;Tennessee Ernie Ford ( TEF ) 06:37, July 5, 2010 (UTC)
 * They aren't longer lasting in the center. The chance is just lower that you'll get a short run right away (but the chance that you get a long run is also higher?) Mmmmh, I should run some monte-carlo on that ... -- ◄mendel► 14:07, July 5, 2010 (UTC)
 * Right, the third (implied) bullet is that standing center, with limited tickets (= 250*# of slots down to just a stack), you are more likely to suffer a bad run during which you are losing far more than 1 ticket out of 18. Of course, you are also less likely to enjoy a bonus streak, in which you are losing less than 1:18.


 * The problem I have with the "longer lasting" or "less likely ...bad streak" text is that the implication is: stand in the center, play longer (on average), → therefore play more games, → therefore earn more lucky points, contradicting one of the other main points (it doesn't matter where you stand for Lucky).


 * So, if you can easily run Monte Carlos, it would be useful (and game changing) to know the extent to which bad/good streaks plague/benefit the player. I would imagine that for N=1 ticket stack, it matters little. But perhaps for N=20+, center is 80% likely to give you X rounds while corner might be only 50% likely (well, I'm sure it's not nearly that extreme). (Also, probably also useful to run a simulation for indeterminate tickets, over 72 hours.)


 * If that's true, that would mean that the center/corners have the same expectation for winning lucky points. However, except for the theoretical player who nine rings for 1000s of hours, the rest of us might be better off in the center. (Well, except for my main toon, who, until this weekend, was growing the Unlucky title about 3x faster than Lucky, due to a faulty lockpick supplier.)


 * In the meantime, I'm leaving the text alone. &mdash;Tennessee Ernie Ford ( TEF ) 16:51, July 5, 2010 (UTC)

No, the expectations don't change. (And the center/corner do have the same expectation re:lucky, as that's based on the number of tickets won.) Imagine you have ten tokens left, and play one round. So if you're lucky, you last a lot longer in the corner; but it's also more likely for your game to be over. If you start with 15 tokens, the numbers change to corner: 6 and 2 and center: 3 and 2 rounds; if you sum them up, you get So when your tickets run low, and you're not going to buy more, the advice is to stand in the center if you have 15-19, and to stand in the corner and hope you strike it rich if you have 10-14 tickets.
 * On the corner, you get 11% for getting enough tokens to play 5 more rounds, 22% for playing one more round, and 67% for game over.
 * In the center, you get 11% for playing 2 more rounds, 44% for playing 1 more round, and 44% for game over.

Before you ask, the numbers are lower than the average return because I haven't figured the return on the rounds you are now able to play. -- ◄mendel► 19:37, July 5, 2010 (UTC)


 * what happens simulating the very large numbers that players typically have going during AFK weekends? e.g. 3, 20, and 40 stacks? &mdash;Tennessee Ernie Ford ( TEF ) 21:17, July 5, 2010 (UTC)
 * I've went as far as coding a Python function that simulates the game with a given number of tickets on any position, but haven't written the part where this is done repeatedly and the results tallied.
 * I would predict that for large numbers (e.g. 750 or 10000 tickets) there's no visible difference. It might be interesting to find out how much empty space you should have in your inventory to not lose any winning tickets, though. -- ◄mendel► 22:57, July 5, 2010 (UTC)

Just want you to know
This made my day. You won the Greatest Edit Summary of July 5th Contest, ed. 2010. Your prize has hereby been granted. --- -- (contribs)  &emsp;(talk)  17:03, July 5, 2010 (UTC)
 * I agree, best summary of the day. 5 points --  Random  Time   17:09, July 5, 2010 (UTC)


 * Aw, shucks. Ty.  &mdash;Tennessee Ernie Ford ( TEF ) 17:45, July 5, 2010 (UTC)


 * /agree.--[[Image:El Nazgir sig.png|Talkpage]]El_Nazgir 18:28, July 5, 2010 (UTC)

Rewording
Explaining anything has always been my weakest part. Many thanks for rewording that mess I made, it was barely readable. Your wording skills continue to amaze me :)  ***EAGLEMUT***   T  A  L K 18:24, July 11, 2010 (UTC)
 * Why thank you. (Of course, it's much easier to reword than to word, so I am but a short person standing on the shoulders of giants.) &mdash;Tennessee Ernie Ford ( TEF ) 19:04, July 11, 2010 (UTC)

non-chaotic alignment
I'd like to remind you that your personal .css aligns table headers left. To edit an article to effect a hard centering via  would be adding clutter to the page that the general editor does not profit from, not to mention alienating people who may like their headers left-aligned (not sure if there are any, but I'm talking hypothetically here anyway). However, susbt'ing the wherever you run across it is beneficial. If you wanted table headers that span multiple columns always centered, you could add the line .stdt th[colspan] { text-align:center; } to your [ monaco.css]. Of course you could do analogously for, if you so desired. -- ◄mendel► 22:04, July 11, 2010 (UTC)
 * argh! I completely forgot about the alignment in the css; I meant that as temporary rather than perm. Whoops. I'll fix that momentarily.


 * Also, does this wiki support the other wikimedia coolnesses of "wikitable" and other classes? I don't think we have a demo (or link to a demo) that helps illustrate. (Obviously, non-standard tables should get something other than "standard table" classes.)


 * Thanks for the re-alignment! &mdash;Tennessee Ernie Ford ( TEF ) 00:27, July 12, 2010 (UTC)


 * BTW: I hadn't seen a reliable way to force-center wiki table headers before; thanks for that tip, too. &mdash;Tennessee Ernie Ford ( TEF ) 00:32, July 12, 2010 (UTC)

Effective editor guide
Wow, that's a large edit to the Mesmer guide. Good job. --  Random  Time   22:51, July 13, 2010 (UTC)


 * Thank you! (It needs at least another (big?) revision (not including the obvious gap in PvP). I'm hoping someone else will be inspired to update it.) &mdash;Tennessee Ernie Ford ( TEF ) 23:20, July 13, 2010 (UTC)


 * My only complaint is that you need to follow GW:ULC on the section titles. &mdash;Dr Ishmael Diablo_the_chicken.gif 00:05, July 14, 2010 (UTC)
 * And that is one small complaint.
 * I plan to soon start work on a Mesmer to try out one or two things and the newly updated guide might now assist me with that. Thankies. A_F_K_sig_2.jpg A F K When Needed 22:43, July 14, 2010 (UTC)


 * My pleasure. I hope that you take note of the many things that what needs fixing. I think the two easiest elites to start with are Keystone Signet and Panic. KS allows the Mez to avoid energy management and still nuke/interrupt/hex. Panic + Wastrel's Worry pretty much nerfs any clumps of foes. (Get a tank to ball them up and they are damned if they use skills, damned if they don't.)


 * Thanks for the compliment. &mdash;Tennessee Ernie Ford ( TEF ) 23:25, July 14, 2010 (UTC)

FC table
In this edit, you edit the first column from e.g.  to. Why? Both should be bold, and the left version correctly labels the cell as a header; and it is center-aligned instead of left, which looks better to me. What advantage do you see to your edit? -- ◄mendel► 20:17, July 16, 2010 (UTC)


 * I've been wondering the same thing since you did that to the [ Daily forecast]. The end result is the same, so why use the version that requires a greater amount of source text?  &mdash;Dr Ishmael Diablo_the_chicken.gif 20:31, July 16, 2010 (UTC)
 * Must be User:Tennessee_Ernie_Ford/monaco.css acting up again. ;) -- ◄mendel► 20:56, July 16, 2010 (UTC)


 * (edit conflict)
 * That is b/c I keep forgetting that my stdt doesn't match the wiki's in two subtle ways (one which doesn't matter and one which does). I've got things setup so that  has a light gray background (headers that have same coloration as the rest of the table drive me nuts). Consequently, when someone uses a   on a row cell, things look dorky to me.


 * tl;dr my screw up. I'll fix it. My apologies for making it look dorky to 99% of the wiki.
 * alternative tl;dr what Mendel said, &mdash;Tennessee Ernie Ford ( TEF ) 21:00, July 16, 2010 (UTC)
 * Those are the row headers, though. Would you like some .css that does not (or differently) colorize row headers (strictly speaking, don't color &lt;th> tags (  cells ) in the first column unless they're in the first row)? -- ◄mendel► 21:51, July 16, 2010 (UTC)


 * Erm, by "row header," I meant "the first cell in a row that acts as a label for the row" rather than whatever  was originally designed to be.


 * And yes, I would love it if I could shade the ! first row of every table without colorizing the ! first cell of a row. &mdash;Tennessee Ernie Ford ( TEF ) 21:57, July 16, 2010 (UTC)
 * Well, the following should fix the Fast Casting table for you; but it'll probably look ugly on some other pages, link me to those that do and maybe I can make it better.

.stdt th { background:lightgray; } .stdt tr:not(:first-child) th { background:transparent; }
 * -- ◄mendel► 22:43, July 16, 2010 (UTC)


 * So far, so good. Thanks! &mdash;Tennessee Ernie Ford ( TEF ) 05:56, July 17, 2010 (UTC)
 * To open your other eye,
 * .stdt - something with class="stdt", usually a table
 * tr - a table row inside that table (or in a table nested within that table)
 * :not(:first-child) - not the first element in its parent = not the first row in a table
 * th - a header in any row that fulfils the conditions above, i.e. isn't the first
 * background:transparent; - use the background of the elements "behind" it: row or table or page.
 * This rule trumps the other rule (that sets the lightgray background), because it comes later and is more specific. However, any  formatting on the page will override both rules. -- ◄mendel► 07:33, July 17, 2010 (UTC)


 * One problem with that is that it will override formatting if a table uses header cells as a footer, like on drop rate tables or... bah, can't think of any better examples. Not sure if that matters to you, though.  &mdash;Dr Ishmael Diablo_the_chicken.gif 13:48, July 17, 2010 (UTC)
 * Yes, but unfortunately there isn't any .css that says "do this if the next sibling is whatever". Of course if we added class="header" to rows like these, private formatting could match that easily. -- ◄mendel► 14:28, July 17, 2010 (UTC)

vandalistically
Re [ this edit], I usually prefer for active users to "police" their talkpages themselves. This means that unless outright vulgarities (or worse) are posted – and I wouldn't count "dumblesnatchet" as one –, the users themselves are in the best position to judge whether what they see is a friendly rib from an acquaintance, inoffensive nonsense, or an attempt at vandalism. -- ◄mendel► 17:17, July 19, 2010 (UTC)
 * In general, I agree. In this particular case, I felt that it detracted from a public conversation between Felix & TEF and that, therefore, either TEF or Felix could decide whether it was interfering nonsense (as opposed to silliness). (Being nonsense, I couldn't tell if offense was intended. Being from an IP, I didn't feel it was likely to be friendly or acquaintful ribbing.)


 * If your goal was to get me to rethink my actions, you have succeeded. If you wanted me to be less likely to repeat the same under similar circumstances, I am open to further persuasion. &mdash;Tennessee Ernie Ford ( TEF ) 01:15, July 20, 2010 (UTC)
 * And the [ actual outcome] doesn't convince you, either? (Mind you, I didn't know that when I wrote the above.) -- ◄mendel► 03:33, July 20, 2010 (UTC)

you want "this"?
Here, Dr Ishmael mentions something that you wanted and that my demo doesn't address. What would that be? Populating the locations table? Unfortunately I can't see the pages where he achieved this. -- ◄mendel► 05:42, July 20, 2010 (UTC)


 * I think things are worth automating b/c Nick will be repeating requests...and after 137 weeks, we will be playing GW2 and, one hopes, have no time to keep his articles up-to-date. I also believe that, whenever possible, it makes sense to separate data storage from the storage architecture from the presentation. Currently, we combine data with templates.


 * Others (including Doc Ish) suggested that this might be a lot of trouble; obviously, it's not worth making things overly complex as there is plenty of WiK that needs help, too. The follow list includes those things that I hoped might be reasonably achieved with enough benefit for the wiki:


 * Store dialogues; populate Nick article automatically using appropriate wiki code.
 * Separate Nick location/request data from the Nick template.
 * use the (now distinct article with) Nick loca/req data to automatically tick off the relevant locations on our countdown from 137.
 * Ideally, be able to add information to the data table with other points of interest (e.g. farming locations), so that those, too, could be automagically retrieved.


 * Generally, wild ideas like this get discussed a bit before people start coding. It might be worth taking a step back to see what is worth doing and if there are better/worse ways to do it (seems like there might be some options). Does that help enough? &mdash;Tennessee Ernie Ford ( TEF ) 05:56, July 20, 2010 (UTC)
 * before people start coding -- Well,that's what the demo code is for. Sometimes you have to see what works and what doesn't. And it's fun.
 * In MediaWiki, usually the wiki pages are the data, and the templates are the presentation, at least when it comes to infoboxes and such (or categories!). When you try to keep data out of the pages, stuff gets complicated, as with the skills. If you keep a page separate and say, "that is our database", you lose a lot of the ad-hoc-ness and flexibility that wikis are; and you get, judging by the "past dialogues" page, humongous pages that don't work well with the system architecture.
 * A few numbers:
 * "Nicholas the Traveler/Past Dialogues" now has sections and  bytes.
 * The average dialogue is thus bytes (~640 bytes).
 * In the end, a new dialogue will have gotten added 137 times.
 * The page is then bytes long.
 * Every revision of that page gets stored in the database. Hence, the complete history (notwithstanding eventual corrective edits) is around 640*(sum of 1 to 137) bytes long, that is bytes (6 MB).
 * That seems frightfully ineffective. We used to get a warning when page sizes exceeded 32kB.
 * The Semantic MediaWiki (SMW) puts this concept on its head as throroughly as wikis did to web1.0 content. The wiki pages become the database, and the page names are its unique identifiers. The beauty is that the code is hidden from the page: a page that uses infobox templates looks the same with SMW as it does without; the SMW markup can simply be stuffed into the template. The DPL extension predates this, and it, too, provides a simple means to access data stored on pages that has often sufficed for us, with no extra coding needed - all the logic is in the query. When I looked at this last year, I found it fairly difficult to find good illustrations of how these tools work; maybe you can find some now, but if you don't, I'd gladly answer any questions you might have.
 * With that in mind,please ponder my data in locations idea; would this be ok with your "separation of data and presentation" goal? (I could probably rig up some demo queries with the Zaishen Quest data, which is already stored this way.)
 * I think that what Dr Ishmael may have had in mind for the "past collections" was to make each table row a template call (with rising ID parameters); the template would then keep running tallies of the "statistics" which would then be available below the table automatically (but not on any other page). It might even be possible to do the location boxes that way, if you used a variable for each location, possibly automatically named. However, this would probably lock the page into a "huge table with data below" layout, because otherwise the code wouldn't work - and judging by the talkpage of the extension on mediawiki.org, it might not work even then. You don't know before you try.
 * What is it about my discussion style that helps drama explode? -- ◄mendel► 10:33, July 20, 2010 (UTC)


 * Wow! What was that post like before you shortened it ;-)


 * Lessee... if I understand correctly, you propose that dialogue and location data be stored together. Seems sensible to me. The dialogue is generally short enough that it's not going to add that much (percentage-wise) to the data table. Plus, paralleling the zaishen tables system is also sensible; no reason to have two distinct methods if one will do. (Assuming that the z-data algorithms are robust enuf to handle the two Nicks.)


 * I have to trust the technical experts on SMW vs. Variables storage and processing needs because I don't have any direct experience. It's all the same to me: a bunch of gobblygook that makes sense only if one has the relevant rosetta stone. If the tech experts disagree, then, sure, examples are probably the best way to resolve it.


 * What I meant by discuss first was to make sure that anyone taking the (humongous amounts of) time to code should get a chance to hash out the goals/requirements, to make sure (a) there aren't simple ways to achieve the same, (b) that there aren't other issues that make sense to address at the same time, and (c) to help articulate the methodology and to be able to proceed incrementally in (near) lock-step with the non-techies involved. It was not intended as a criticism (implied or otherwise) of anyone except myself, hence the adjective wild; the idea was to make sure that the suggestions were tamed first.


 * Both solutions also seem to have merit in terms of viability and repeatability. Both also seem to have some minor issues in accessibility to the non-gurus among us (something worth noting and dealing with as we get closer to an 0.8 version.)


 * I'm not sure about the tallying approach, since it seems vulnerable to data-entry error (enter the wrong location and whammo). Aren't we simply tablulating how many visits to each zone? (When the answer for 137 weeks will be "0" or "1")? But maybe that requires 137 columns (yes/no for each location). I do that sort of thing in Excel all the time and leave it as either a dynamic query or a refreshable pivot variable. I have no idea of what is easy/not in SMW/variables.


 * " What is it about my discussion style that helps drama explode? " Srs question? &mdash;Tennessee Ernie Ford ( TEF ) 17:55, July 20, 2010 (UTC)


 * You misunderstood my proposal. I took the opportunity to clarify it with more bells and whistles, please look (and comment) at Template_talk:Nicholas_the_Traveler.
 * And yes, that was a serious question; you might answer it here or via email. -- ◄mendel► 21:07, July 20, 2010 (UTC)


 * My memory was actually a bit off there; what he had actually requested was a way to "automatically populate the location list (at the bottom of the page)", which was not the section that I had linked to at that time (that was the summary tables, not the checklist). However, I have now fulfilled that requirement at User:Dr ishmael/Nicholas the Traveler test.  &mdash;Dr Ishmael Diablo_the_chicken.gif 18:37, July 20, 2010 (UTC)

Energy denial
You refer to your low set's 25 energy as your "base" energy several times throughout your edits. I understand you're talking about your basic 30 adjusted by your low set modifications, but I think this is misleading and/or something of a misnomer; the 25 displayed energy while in a low set isn't the base of your energy but rather the top of it. If your energy bar were vertical, it would be the top 25 of your total 72. As you equip higher energy sets, the visible line extends deeper downward to allow you to draw on reserves. Without finding ourselves in conflict edits or revert wars, we should agree upon semantics for article solidarity. Ethigenetic 21:27, July 21, 2010 (UTC)


 * I'm conflicted about turning a glossary article into something more substantive. It seems to me that your useful advice belongs more prominently in guides to PvP and to energy management. Consequently, I was aiming at something different than you were.


 * I might also have had different audience in mind, the one which spent its formative game years with a single weapon set, and has had their impressions altered by the horizontal and statically sized blue bar. To this audience, "base" is a way of describing initial energy; high-e sets add to that base. Left to my own devices, I would hesitate about using "up/down" or "base/top" because of the default horizontal bars; I would probably try for a gas/petrol tank analogy to avoid any confusion.


 * Having thought about it some more, I have to admit that the picture you paint is more useful; the concept of "reserve" is more likely to help people overcome their original impression than anything I was aiming for. Consequently, I'm content to follow your lead and respect your word choice (only stepping in if I think something is unclear).


 * I do think your shorter explanation above is very helpful and, if combined with some images of vertical blue bars, I think that would make a fine glossary article. I would like to see the more detailed version in the appropriate guides; I believe that they have a wider readership than the glossary items.


 * Thanks for taking the time to ask me my views. &mdash;Tennessee Ernie Ford ( TEF ) 22:22, July 21, 2010 (UTC)


 * If you're wanting to move some of that content into a guide, there's this and this that are in need of some major updates anyway. &mdash;Dr Ishmael Diablo_the_chicken.gif 22:29, July 21, 2010 (UTC)


 * Thinking about this, I get the mental picture of a horizontal blue bar with the monster munching on it from the right (and reaching some sort of stop sign?) and the player adding to it on the left.
 * Actually, what the player has is 72 energy, but the low set exposes only 25 of it to be taken; and switching to progressively higher energy sets exposes more energy. Thus, 25 is the base exposed energy (you can't expose less), and you expose more as that energy gets used up. -- ◄mendel► 05:22, July 22, 2010 (UTC)

collapsing the dialogues
Your testing: div.dialogue { display:none; } div.dialogue:hover { display:inherit; } I can't imagine that working, because you can't hover something that's not there; does it work? I'd try something like div.dialogue { max-height:2em; overflow:hidden; } div.dialogue:before { content:"Move Cursor here to see full dialogue!"; color:orange; } div.dialogue:hover { max-height:none;} div.dialogue:hover:before { content:""; } limits the height of each dialogue section to approximately the size of a line of text, with margins. ensures that the dialogue that doesn't fit this height does not get displayed (else the dialogue would run into the next section). inserts the  in front of the dialogue, and as you see, you can specify any formatting for it. (You could e.g. make it smaller if you wished.) The  undoes the height limit, which expands the section to show the full content when you hover your mouse over it. The  removes the message by overriding the   defined earlier.

The problem with this approach is that if you want to interact with the bottom of the page, the section expands on you once you move your mouse through it, and only when you move to the sidebar or to the bottom of the page (you could pull your cursor all the way down off the window or at least into the status bar) does it collapse again. So an improvement is needed: limiting the  of the section as well, ideally, to display our :before message fully, but not more; and adding a background or a border to it to indicate the "active area". The final version (which, of course, you might want to tweak to make it look the way you like) is this: div.dialogue { max-height:2em;overflow:hidden; max-width:18em; text-align:center; padding:0.5ex 1ex; border:thin solid silver; border-radius:1ex; -moz-border-radius:1ex; -webkit-border-radius:1ex; } div.dialogue:before { content:"Move Cursor here to see full dialogue!"; color:orange; } div.dialogue:hover { max-height:none; max-width:none;  text-align:left; padding:inherit; border:none; } div.dialogue:hover:before { content:""; -- ◄mendel► 06:08, July 22, 2010 (UTC)


 * Hey thanks for this. I think I'm gonna stick with no display for the moment; it's pretty rare that I care about the dialogue details. (e.g. only when someone points out to me that our old debate regarding Giant's Basin has been given new ammunition in the WiK dialoges) (I will try it out on something else, tho!) &mdash;Tennessee Ernie Ford ( TEF ) 07:09, July 22, 2010 (UTC)