GuildWiki talk:Style and formatting/Skills/Archive 8


 * Old skill box stuff moved to ../Archive 5.

Restarting Vote for Skill Box
The discussion over the options for the new skill box design has been going on for a long time and become quite confusing. To make things clearer a new page has been created at ../Skill box.

Skill icon upload progress
moved to Community Portal

Categories for "Related Skills"
So far, we are maintaining all lists of "related" skills manually. See Index of Skill Lists. What about doing this with categories? I know, this would be a major change to the way we handle skills, and we'd have to do yet another crusade, going through all the skills, but I think it may be worth it. Considering we'll get about 200 new skills with every campaign and two new campaigns per year, we'll loose overview some day. And if we combine it with some other skill crusade (for example the upcoming landscape info box crusade) it may not be that much work after all. Thoughts? -- 20:07, 3 March 2006 (CST)
 * Fully agree. I think manually kept tables might still have some value (to see a short summary at a glance), but I realy think we should add categories for ease of maintainence. -PanSola 00:58, 4 March 2006 (CST)
 * I have some strong concerns:
 * I can't see a categorization scheme sustaining the info about the skills' general relation (currently given as subheaders like "Skills that profit from Deep wound"), nor profession, unless we resort to severe overclassification. This is a non-negligible loss in practical value IMO.
 * I worry about how well the category structure could deal with various complications I've come across; relations have a strong tendency to not be as cut and dry. (Example: How to deal with the relation between skills that cause healing and skills that cause health gain?  On one hand the distinction between the 2 mechanics has real implications; on the other hand, depending on the interpretation of the terminology, either set could be considered a subset of the other.)
 * I don't understand how there is any benefit of reduced long term maintenance. It seems like people consider categorization to be automatic/free while a list is manual/tedious.  But really...you have to edit in each relation either way!  The only reduced cost I see with categorization is the initial overhead in working out individual pages' layouts (and IMO this freedom of layout in lists is tied to benefits mentioned above).
 * --Rezyk 03:10, 4 March 2006 (CST)


 * I'm inclined to agree with Rezyk. If nothing else, the current format of, say, the Deep Wound page is quite good and helpful.  Any way I can imagine that being done with categories seems messier, uglier, and less immediately informative than having it manually laid out on one page.  The one compelling argument I could agree with is that if there are so many skills that the Deep Wound page needs to be broken up into separate pages, well, that's already like Categories, I guess, but it's not going to happen to all pages at the same time.  --JoDiamonds 04:03, 4 March 2006 (CST)

Skill Efficiency
This has been an idea I've been mulling over for awhile. I'd like to see a skill efficiency table in the skill articles. This would provide a quick reference by which to compare similar skills and their cost-vs-effectiveness ratio. This would likely be in the form of a 3-field table. Divine Healing has an energy cost of 10, an activation time of 2, and a recharge time of 30. 1
 * Example A:

Orison of Healing has an energy cost of 5, an activation time of 1, and a recharge time of 2. 4
 * Example B:

Heal Other has an energy cost of 10, an activation time of 3/4, and a recharge time of 3. 3.5
 * Example C:

Any thoughts on this? - Evil_Greven 16:47, 6 March 2006 (CST)


 * I like it - you can tack it onto the bottom of the skill page, under notes or something. Maybe slightly worried about people not reading the whole article and just getting confused by seeing two similar-looking tables.  Evan The Cursed (Talk) 11:53, 14 March 2006 (CST)


 * This is a good idea at a glance. For quite a while I've wanted to do something similar. But there are a few difficulties to keep in mind:
 * It works fine if you do it for a simple skill that heals or causes damage. But what about skills that inflict/remove conditions or hexes. Is a skill that heals 40 points more or less effective than a skill that heals only 30 points, but also removes one condition or hex?
 * What about skills that affect more than one target within an AoE? Is a skill that deals 40 damage to one foe more or less effective than a skill that deals only 30 damage, but to all foes "in the area"?
 * What about skills that prevent damage, like Reversal of Fortune?
 * many more problems ...
 * -- 01:32, 15 March 2006 (CST)
 * Take Divine Healing, which is listed here, for instance. Its effect is variable -- if it's one person getting healed, the effect is shown. If it's multiple people being healed, simply multiply the numbers by however many people.  My thoughts for this were a general comparison, and the description elaborates on what they do already.  I'd planned this for the skill pages (just the skill in question, not each related skill), not one page out by itself. - Evil_Greven 03:35, 15 March 2006 (CST)
 * I think it's a neat idea, but should be in a separate section, an efficiency comparison for example. Too many skills have variable efficiency rates - how do you possibly compared Heal Other and Healing Seed?  What about the skills/items typically used in conjuction with skills - you'd be foolish to not count Mantra of Inscriptions for some builds for example, as it's standard - the same is true of a 20% enchanting wrapping for example - since it's standard if you are using enchantments for your heals.  It's a complex topic, and while I think a page devoted to it is needed, I don't think it should be a main feature of most skill pages. --Epinephrine 04:59, 15 March 2006 (CST)
 * I think it's a neat idea, but should be in a separate section, an efficiency comparison for example. Too many skills have variable efficiency rates - how do you possibly compared Heal Other and Healing Seed?  What about the skills/items typically used in conjuction with skills - you'd be foolish to not count Mantra of Inscriptions for some builds for example, as it's standard - the same is true of a 20% enchanting wrapping for example - since it's standard if you are using enchantments for your heals.  It's a complex topic, and while I think a page devoted to it is needed, I don't think it should be a main feature of most skill pages. --Epinephrine 04:59, 15 March 2006 (CST)


 * See the thing is, I don't think the charts will show some definitive data. Like finally resolving which is better Healing Hands vs Word of Healing, since that would deserve discussion in another area (like the page I just linked).  I view it more as a simplified, generalized view of how the skill functions.  Not how "good" it is.  Just how effective it can be under certain circumstances.  Let the user/viewer decide -- but help him do so.  He knows what situation he's going to get into, but with those charts he can probably become a bit more keen on which skills will serve his purposes better.  Evan The Cursed (Talk) 12:49, 15 March 2006 (CST)


 * Presented as they are here, they seem interesting. Presented singly on different skill pages, they seem less useful.  The big win is when you can present information like this all on one page, and a page that compares Healing Efficiency seems quite useful.  I'm not sold on the idea that it's particularly helpful on individual skill pages, because the numbers are essentially meaningless in isolation.  Additionally, the things that are being compared aren't always interesting for all spells -- healing spells need to be grouped together, obviously, and direct damage too.  But what about Vampiric Gaze?  It should realistically be on both pages, even though it's effectively bad at both healing and damage output.
 * I'm not sure I have a completely coherent argument here, but it seems like seeing one of those charts on a skill page just isn't that interesting, while making individual pages comparing multiple skills is the better way to present this information.
 * --JoDiamonds 03:18, 16 March 2006 (CST)

Description Inconsistency
Currently, we have an inconsistency in the skill descriptions. Some of them are the same as the description in the game and list the skill type at the start as well as the "This is an elite skill" if applicable. Others are missing this information, since it's redundant with the skill box and categorization. I think we should get rid of this inconsistency and make one of the two systems the standard. Which one should it be, though? I should note that the in-game description also includes the attribute at the end, and that's almost never included in the description here. So I suppose we're already not following the in-game description exactly. Personally, I think we should also leave out the rest of the redundant information. --adeyke 18:31, 24 March 2006 (CST)
 * The "standing" policy is supposed to be "use identical text from in-game description", where the attribute part doesn't count as part of the descrition (cuz it's grey?).
 * On the basis that even the game does not consistently include "This is an elite BLAH" in the descriptions of elite skills, and we do have an alternate clear and obvious system marking elites, I agree with leaving out the redundant information. -SolaPan 19:30, 24 March 2006 (CST)
 * I've recently crusaded away both the "This is an elite skill" and the leading skill type labels. So that's fixed now.  However, there are some things I'm not quite sure about, and I don't want to accidentally crusade in the wrong direction.
 * Notes or Usage Notes? I'm thinking Notes.
 * 1/2, 1/2, or &#189;? I'm guessing &#189;.
 * Enchantment Spell or Enchantment? I'm thinking Enchantment.
 * Attribute: None or just no line for that?
 * I'm pretty sure the "... more to be added ..." lines should be removed.
 * Health sacrifice in skill box or no?
 * I also noticed that there's an exhaustion icon, but this isn't part of the skill info box, though it could be useful there. Is this something that's been considered?  That'd be a more significant change (instead of just cleanup), so it wouldn't be part of this crusade. --adeyke 23:10, 11 April 2006 (CDT)
 * We are getting a new skill box anyways, so don't worry about things beyond the description. Stabbot will take care of the rest. -PanSola 23:49, 11 April 2006 (CDT)
 * Okay. Thanks for the heads-up. --adeyke 00:26, 12 April 2006 (CDT)
 * I'm in favour of "Enchantment Spell" (or maybe "Spell: Enchantment") in the skill boxes. Sure, enchantments and hexes sound like they're types of spells, but so do rituals and the game doesn't treat those as spells. I'd prefer it if it was obvious from looking at the skill box that enchantments and hexes are also spells. The game refers to hexes and weapon spells as 'Hex Spell' and 'Weapon Spell' in the skill descriptions, for the sake of consistency I think enchantments should stay categorised as 'Enchantment Spell' even though they game just says 'Enchantment'. -- Gordon Ecker 04:41, 18 April 2006 (CDT)
 * I thought the game actually says "Enchantment Spell". I support whatever the game says, unless the game says multiple things. -PanSola 05:27, 18 April 2006 (CDT)


 * My votes are for:
 * Notes (Shorter and more general is just better.)
 * Enchantment (Many skills refer to enchantments, and not just enchantment spells.  Players know what they are and won't be confused.  In my opinion, this falls into the "too basic to not assume people know it" information.  We shouldn't try to do basic education on every single page of the wiki.)
 * &#189;/&#188;/&#190; (Second choice would be 1/2; make it look as good as it can, or make it as simple as it can be. Don't feel very strongly about this, though.)
 * Remove all the "more to be added" crap. This is a wiki, there's always more to be added.
 * We should include health sacrifice in the skill box.
 * We should include exhaustion in the skill box. It's a cost of the spell, like adrenaline, energy, health, and activation time.
 * --JoDiamonds 10:53, 18 April 2006 (CDT)
 * Assuming one of my skill boxes win the vote, health sacrifice and exhausion will be in the skill box whether you like it or not d-: -PanSola 12:57, 18 April 2006 (CDT)

New Progression
What's going on with the new progression templates? I thought we were moving away from the "lots of little templates" and towards the "all encompassing templates". The new Progression Top/Main/Bottom (especially Bottom) seems to be going back towards the old way of doing things (old beast boxes/item boxes/skill boxes/etc...). --Rainith 14:42, 11 April 2006 (CDT)
 * I didn't realize we were moving away from the "lots of little templates", and I don't consider 3 as being a lot. The old beast box etc were EXCESSIVE amoutns of little templates, as opposed to simply being little templates.  Anyways, my main motivation for splitting up the progression into 3 parts is because unlike Template:Progression, I can't easily upgrade the Template:Progression2,Progression3,Progression4,Progression5,Progression6,Progression7,Progression8,Progression9 and Progression10 to scale from 0 to 20 w/o editing individual articles that use them.  So since we will have to edit the articles to scale to 20 anyways, might as well switch to a more modularized system which could potentially save us some long-term trouble.
 * I am against excessive use of lots of little templates. However, when modularization makes sense, I support its use, especially if it avoids "lots of all encompassing templates". -PanSola 14:46, 11 April 2006 (CDT)

Addition of blank template
I added a blank basic template under the example one. Would it be better to change their order (that is, provide the blank and then the prefilled as an example) or is it better as is? Or should I do away with it altogether? --HopefulNebula 02:45, 5 June 2006 (CDT)

Do not use include/templates for Skill Quick References

 * ''moved from User talk:PanSola

What are you trying to achieve, and wouldn't it be better to experiment on non-live pages? Hank 22:19, 11 May 2006 (CDT)
 * I thought I was done with experimenting. Then as I was pushing it live, I discovered I was wrong.  Now Ithink I'm done with experimenting again, so I'm pushing it live again.  -PanSola 22:21, 11 May 2006 (CDT)
 * Gah! Can you not explain what you're trying to do? Is this related to that subst issue above? If so there is a simple solution. . Hank 22:57, 11 May 2006 (CDT)
 * I'm keeping things dynamic, but using template instead. -PanSola 22:59, 11 May 2006 (CDT)
 * It is a terrible idea. Can I talk you out of it? You will kill the server with a page such as Mesmer skills quick reference. Not to mention template pollution and confusion for editors. Please use subst. Hank 23:03, 11 May 2006 (CDT)

Like you said, template stuff are cached, so I don't see why it'll kill the server. SKill articles get edited often, but not the skill details that are being put into the templates. I think subst still defeats the entire motivation behind GuildWiki talk:Style and formatting/Skills/Archive 4. Namely, we need to remember to update multiple articles when a single skill changes. I see little benefit in re-subst compared to manually updating Mesmer Skills quick reference, Interrupt Spells Quick Reference, Mantra Quick Refernce, Signet Quick Refernce, Degen Skills Quick REference, or a sixth article whenever Anet changes skills between ladder seasons. -PanSola 23:08, 11 May 2006 (CDT)


 * I never said "template stuff are cached". That would be wrong in any case. I have considerable experience with the MediaWiki templating engine, so please let me examine the proposal again. There is no principal difference in recaching if the skill quick reference article includes or  . The costs are identical. Every time a page that has about a 150 templates or so is rendered, it will still query every single template at the database to see if it needs to rerender.   So you do not avoid any cost in separating a fixed portion of a skill article from a variable portion. MediaWiki templates are not robust enough for a page to have more than a couple dozen of them without consuming a terrible amount of memory. This is by design.. Hank 23:19, 11 May 2006 (CDT)
 * If the article Rush has been edited, but all the edits happen in the noinclude section, then is the render engine robust enough to not re-render it (when loading a page containing ?  It still makes a difference between 150 queries and not having to re-render, or 150 queries and HAVE to re-render because an artiticle got stubbed, or someone while editing a non-included part of the article, suddenly decide to adjust the whitespace in the included section to make the raw text in the edit box easier to read. -PanSola 23:26, 11 May 2006 (CDT)


 * No, it will force a recache of all pages that include a page whenever the text of the included page is changed. However, this is not the issue. Stripping noinclude sections takes nanoseconds. What is the bigger issue is that a page that includes 150 templates will cause O(150) database queries every time, even if the templates themselves have never been touched since the last render. The strain on the database is far greater than the computation required to rerender the page. Hank 23:27, 11 May 2006 (CDT)


 * Darn, and this is including features since MediaWiki 1.6, not just 1.5 and prior right? I would've thought if MediaWiki figured out how update link tables to deal with categories used inside templates, then this wouldn't be a problem. -PanSola 23:38, 11 May 2006 (CDT)


 * It is true of MediaWiki 1.7+ CVS as of last night. Like I said, by design. There have been no plans to "pre-cache" templates or any other suggested alternative because it was deemed long ago that it is worth paying the price of querying the DB for every used template. Hank 23:44, 11 May 2006 (CDT)


 * I guess it's no huge surprise the wiki is becoming so unbearably slow, then, with the recent template-craze (I'm not referring specifically to this, but the general use of templates everywhere)... of course, it's easy for me to be smug, I've never liked templates in the first place (beyond very limited use, anyway). --Bishop (rap|con) 23:39, 11 May 2006 (CDT)


 * BTW, the "recent template-craze" is about editing, changing, and updating templates. We aren't using templates in any articles we weren't using them before.  In fact there is a net number of reduction of templates being used, as teh armor and skill articles each used to use about 10~15 templates each, and now it's more like 3~4.

BTW, so when it checks whether a rerender is needed, does it do a diff, or does it look at timestamps of most recent modification? -PanSola 23:42, 11 May 2006 (CDT)


 * Timestamps mostly. The most accurate answer is that it first asks any of the object caches if the referenced template with the referenced parameters have been invalidated, and if any of them answers yes, then it queries the template article's timestamp to see if the invalidation was the result of a modification or because of other cache coherency conditions. But, generally when it gets to the second stage, it has already made two database queries (though to much more memcacheable tables than the full article itself). Hank 23:48, 11 May 2006 (CDT)


 * So if I compare a page that uses 150 templates (which take no parameter and only contain plain text), versus a page that has 150 links, does the number of queries differ? I presume queries are needed to decide whether links should be rendered as to the articles directly or to an edit page for new article creation. -PanSola 23:52, 11 May 2006 (CDT)


 * You are right that queries are needed to verify the existence of links, but the problem is far simpler, as databases are very efficient at answering existence queries. Also, it should be noted that existence queries are possibly the most cacheable queries possible. I should make one other point clear, because I am not sure if I conveyed it correctly. The O(150) queries are needed on a recache, but not on every visit of the page. Presumably the quick reference page has far more views than the skill articles change, so there is still some amortization. Hank 23:58, 11 May 2006 (CDT)
 * "The O(150) queries are needed on a recache, but not on every visit of the page" I definitely misunderstood you earlier. Another question: does use of embedded images generate the same type of quieries as use of templates?  And is MediaWiki smart enought to only send one query if a particular image is embedded 150 times in the same article? -PanSola 00:03, 12 May 2006 (CDT)


 * The MediaWiki rendering code does nothing clever about images, but the database layer in the MediaWiki code is clever enough to remember the result of asking if an image exists (and where its imagefile can be found) the first time the render layer makes the query. So the next 149 queries finish about a thousand times faster because no database queries are needed. Hank 00:11, 12 May 2006 (CDT)

Hmm, back to an earlier point, because the O(150) renders only happen on a recache, which only happens when the included article/template is modified, and becasue we only expect the skill details part to be modified between ladder seasons, I feel the usage of the templates will only cause a relatively insignificant amount of server drain (note this is different from including the full skill article, which gets edited OFTEN and produces big server stress). Comparing it to the benefits of keeping information centralized, I am still supportive of using the templates. IF I am proven to be wrong and it does have a non-negeligable impact on the server, we can always (and easily) subst them at that point. This is my opinion after considering all the evidence presented above. -PanSola 00:27, 12 May 2006 (CDT)


 * Recaches are not triggered only by changes. Any number of things can trigger it. For instance, the there may simply be too many entries in the object cache, in which case some entries are expired using a LRU algorithm. Also all cached objects have a forced hard expiry time after which a rerender is forced no matter what. Also some pages are simply uncacheable for various convoluted reasons and I have to read the cache code again to convince myself that the quick reference pages are cacheable. I still think that if you want a centralized location, then the difference between and  > is minor. Hank 00:34, 12 May 2006 (CDT)


 * By the way, if you want to persist with your plan, I would suggest making "subpages", ie., Rush/Skillbox, instead of polluting the Template namespace. Hank 00:38, 12 May 2006 (CDT)
 * I consider the difference to be major if we have to redo the subst. Or more precisely, if we have to remember to do the subst on other articles.  I didn't realize sub-pages take parameters.  I thought only articles with colons in their names do.  Why is the way I use the template namespace considered as "pollution" btw.  That concept is relative foreign to me. -PanSola 00:42, 12 May 2006 (CDT)


 * There is nothing special about pages in the Template: namespace except that Template: is the default namespace for transclusion, just like     is the default namespace for normal articles, etc. All transclusions can take arguments. It would be rather hard to test out templates in user subpages if they didn't. About pollution -- wouldn't you prefer all pages about the "Rush" skill to be named "Rush/somethingorother" rather than half being "Rush", half "Template:Rush", and the remaining half in some other place? I would. Plus, I was browsing the Special:Allpages in the template namespace earlier to see what sorts of templates you guys use, and I would hate to wade through 500 templates with no real purpose. Hank 00:45, 12 May 2006 (CDT)


 * Another reason for subpages just occured to me. Talk:Rush/Skillbox would naturally be a real subpage of Talk:Rush then. Hank 00:48, 12 May 2006 (CDT)


 * Hmm, the overall GuildWiki practice has a trend to make transclusion be as easy (ie short) as possible, as evidenced by Template:Monk, Template:G, and so on. As a 6-month GuildWiki user and not familiar with other major wikis, I'm not particularly bothered by the fact that some info of Rush is in Template:Rush, especially when that info is accessible and has an edit link to it from the Rush page (and any page that transcludes Template:Rush.  We are trying to categorize all our templates via Category:Templates instead of using Allpages, since similar templates won't get grouped together anyways.  Besides, if something is a template (I consider Template:Rush to be a template, not just a subpage, but our views obviously differ), it makes the most sense to put it in the template namespace.  It's a template that takes parameters and controls how information about Rush is displayed in other articles.  Anyways, I'm going to leave this entire issue just hang here for half a day or so, so others can voice their opinions. -PanSola 00:54, 12 May 2006 (CDT)


 * What is hard about including a "subpage"? Just add to every article. This is so systematic that it can be templated into  to be added at the top of every skill article. The quick reference pages will presumably be created by clueful people who will know to include  . A half day's cooldown is good. Hank 01:00, 12 May 2006 (CDT)


 * I'm late to the discussion, but I think Karlos would be furious about some info being in Rush and some being in Template:Rush. I wouldn't be furious but I agree with his issue on redundant data.  --68.142.14.79 05:24, 13 May 2006 (CDT)


 * The proposal is to have some info about Rush in Template:Rush, some different info about Rush in Rush, which includes Template:Rush. This is called splitting the data as opposed to having redundent data.  Redundant data is the alternative: All info about Rush in Rush, half of the same info about Rush is in Warrior Skill Quick Reference, and also in whatever other quick reference articles or build articles that want to include Rush's information.   The third alternative to avoid Split Data or Redundant Data, is to have a very very over-worked server. -PanSola 05:46, 13 May 2006 (CDT)

Looks like this subject isn't something most ppl keep an eye on. I'll continue ahead with the project. -PanSola 01:06, 13 May 2006 (CDT)


 * Subpage or include only it or something&mdash;polluting the template namespace is a BAD idea! Hank is right on the money here. If I knew anything about this "subst" thing you keep bringing up, I'd argue about that too. :) &mdash;Tanaric 21:12, 13 May 2006 (CDT)


 * Okay, after rereading this, I see I was mistaken before about what you were doing. But now I'm unclear on how the new templates either simplify editing or decrease server load.  The QR pages will still include the same number of templates as far as I can tell.  QR would include, which ends up using  versus QR including  which through includeonly/noinclude would use .  Is the change just to reduce the number of lines in the skill articles that the unknowledgeable shouldn't touch?  --68.142.14.79 22:06, 13 May 2006 (CDT)
 * Compare to the original plan of including skill articles directly in quick reference pages, the use of the templates do decrease server load. The reason is, in the original plan, whenever someone edit the article Mantra of Recovery, perhaps to correct a spelling on a usage note, perhaps having a revert war on the edit note, or whatever;  whenever someone edit that article, all other articles that include Mantra of Recovery (various quick reference pages) would have to rerender their own cache.  The plan of using the template reduces server load because re-render would only be needed if someone edit the actual skill details of Template:Mantra of Recovery, as opposed to if someone edit the skill article directly. -PanSola 22:19, 13 May 2006 (CDT)
 * Hank said that (he thinks) "the difference between and  > is minor."  --68.142.14.79 22:35, 13 May 2006 (CDT)
 * I believe he said it under a different context. Specifically, he said it in the context of having data being centralized.  I believe he wasn't talking abut different in teh sense of server load. -PanSola
 * Before that sentence, he was discussing MediaWiki's caching, so I don't think so. --68.142.14.78 00:37, 15 May 2006 (CDT)

The "Plan"
So here's what my planned template will feature (not all features implemented):

1. When in the quick reference view, the ability to hide or override the profession/attribute column, the stats symbols, the description, the skill type, and/or the campaign. This will be done by providing parameters to whatever is being included (be it a template or a subpage).

Example syntax: (the "row" is used to trigger the special quick reference view.

Usually just including Backfire will cause it to display everything. But if you set any of the fields to "hide", the entire column will be hidden. Even the icon can be overridden or hidden.

2. Ability to add custom notes. This can be done by either overriding existing fields (say I want the column that used to display attribute to change to % speed increase for a speed article), or by adding a "notes" parameter.

Except the custom notes functionality, everything else have been implemented.