Guild Wars Wiki talk:Formatting/Skills/Archive1

Skill icon borders

I'm starting the official discussion for the skill icons here. We need to decide if we want to use the skill icons with borders like we did in GuildWiki or if we want to have them without borders. It's mostly a visual thing as both suggestions have only minimal extra problems.

• The fansite kit icons are mostly without borders, but some of them have 1-4 pixel borders.
• Going without borders is mainly easy, but we need to ask the art team to produce us non-borddered versions of those icons with some border.
• If we decide to use the borders, we can just move the current icons from the GuildWiki, but we need to add borders to the icons of future campaigns later on. (Easy with an ImageMagic script)

As both decisions are pretty easy to carry out, let's decide based on how we like the looks.

I definitely like the borders which make the icons look uniform and users can easily see which skills are elite skills, which ones not. --Gem (talk) 03:12, 9 February 2007 (PST)

Same for me, I like the bordered ones more as well. It's easier to focus, if it's elite or not. --KangaRoo 03:15, 9 February 2007 (PST)

I prefer them too, but it would be easier to simply use whatever's in the fan kit (both now and for future campaigns). Perhaps we should be more pragmatic about it. --NieA7 03:28, 9 February 2007 (PST)

It isn't really that much easier. Executing the simple script from Stabber is a piece of cake. --Gem (talk) 03:31, 9 February 2007 (PST)

There's a script that'll add borders automatically? --NieA7 03:38, 9 February 2007 (PST)

Stabber made one for ImageMagic. You only need to take into account that some fan site kit icons allrady have a 1-4 px border, so you need to separate them first and do them separately. However, we don't need to do anything for a few months now as all of the icons with borders are in the GWiki allready and can be freely used (as far as I know). --Gem (talk) 03:43, 9 February 2007 (PST)

Oh, very neat. Well, if we've got the thing automated then I support borders too. Can we just nab the Guild Wiki ones? And if so is there an easier way of getting them up here than uploading each one individually? --NieA7 04:25, 9 February 2007 (PST)

I do like borders more than no borders. They simply look better ;) Maybe ANet can give us standardized ones? Poke 04:37, 9 February 2007 (PST)

Always been a fan of borders. --Xeeron 05:36, 9 February 2007 (PST)

Yeah, I like the books and the coffee... But seriously, I like the borders too.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 06:17, 9 February 2007 (PST)

Borders ftw --FireFox 08:08, 11 February 2007 (PST)

I'm in favor of borders, too. It adds a bit of class, and the borders used with GuildWiki produced a quite pleasing result. -Eldin 10:35, 11 February 2007 (PST)

It seems like the answer is clear. Feel free to start uploading the images from GWiki. (I suppose they don't have license problems as the work done to the fansitekit versions is trivial and could be easily replicated by anyone) --Gem (talk) 12:21, 11 February 2007 (PST)

Assuming that's the case can't someone like Fyren bring them over en masse rather than us having to upload them all individually? I mean there's a hell of a lot, especially with the grey ones too. --NieA7 12:50, 11 February 2007 (PST)

I dislike the borders, it isn't hard to add a border around with CSS and we should leave the original icons untainted imo. — Skuld 12:51, 11 February 2007 (PST)

Couldn't you have taken part a bit earlier? Well, let's start the discussion again. --Gem (talk) 13:21, 11 February 2007 (PST)

My psychic discussion-seeking abilities are failing today, sorry. — Skuld 13:26, 11 February 2007 (PST)

No prob. I just stopped playing so I have a little time for discussion before going to bed. I don't quite understand why we should upload images without borders and add the borders with css. The borders are very clear opposed to the hazy look of the skill borders for example in the game and imho make the skill icons look far better than they look without them. They also help to distinguish elites from non-elites. (Though they are recognisable without borders too) --Gem (talk) 14:40, 11 February 2007 (PST)

With or without borders, a matter of taste and both sides have good arguments. But we must decide. I am working on the Fire Elementalist skills at the moment. Just the basic stuff, skill name and progression table. Not enough people are filling in the skills, and it is something that can easily be understood and done. I think many people are still unsure if this will be the final style/format of the skills, add in some copyright concerns and many people will be hesitant to "get to work". I suggest providing a link to some templates/examples on the Main Page. Give first time contributers and old GuildWiki veterans a hand what they can do. Most people probably do not even read this discussion here, after all. --Longasc 04:59, 12 February 2007 (PST)

The first week or two of the new wiki will be discussion of policies and style and formatting. Uploading content isn't top priority yet and should be avoided when the corresponding policies and style guides aren't complete. --Gem (talk) 05:01, 12 February 2007 (PST)

Well I am against skill borders, because they are resaved at a horrible compression, the colour for elite skill borders is horrible and it's easy to request versions of the earlier skills without borders. I was never a fan of the borders, and now we have a new Wiki to play with we can't just go and make the same mistakes again. If you want borders for skills, then you could easily include a 1px border in the actual skills template. I mean, compare the images on Image:Vocal was Sogolon.jpg and Image:Soldier's Stance.jpg... that's hardly an improvement. --Santax 04:01, 16 February 2007 (PST)

Well if the request for ImageMagick at Guild_Wars_Wiki_talk:Requests_for_technical_administration gets implemented the skills can be saved as PNGs rather than JPEGs, which would solve the compression problems. I like the thought of incorporating the border in the skill box template though, sounds like an interesting idea. --NieA7 04:15, 16 February 2007 (PST)

The fact that skill borders are used does not relate directly with the compression method used. I have just re-uploaded Image:Soldier's Stance.jpg. I used ImageMagick on my own computer to resize the image and add borders. As you can see there is a considerable improvement in quality between this version and the previous.

I would say that there is very little difference in quality between the first version of this image and the latest version, so I ask that you please do not consider Pakuna's version of the file to be the standard by which all bordered skill images will be produced. LordBiro 04:20, 16 February 2007 (PST)

True, but skill borders necessitate a resaving of the image, whereas if we only use them as porvided in the kit they can be uploaded as is (which is what I think Santax was talking about). I'm not disagreeing with you say as I'm sure they can be done better than our current examples, but JPEG is fundamentally lossy while PNG is fundamentally loss-less. Personally I hope all the icons here can be saved as PNGs once the server side stuff has been sorted out, technically speaking it should be the format of choice for this kinda thing. --NieA7 04:51, 16 February 2007 (PST)

I agree NieA7, I was not meaning to argue with you. JPEG is lossy, but PNGs are typically larger than JPEGs. As an experiment, I altered my script for resizing and adding the border to icons to save the images as PNGs. On average every icon is more than twice the size. Some icons are as many as 3 times the size.

I argued for a long time on the GuildWiki that we should use PNGs for pretty much everything, but I am no longer so certain that PNGs would be better for the wiki than JPEGs.

Really the argument over PNGs and JPEGs should be discussed under a separate heading ;) LordBiro 05:18, 16 February 2007 (PST)

How would Skulds CSS version work (it obviously is not easy enough for me to understand how it is supposed to happen). Would the picture have a border automatically applied by CSS whenever it is used somewhere in the wiki? --Xeeron 05:23, 16 February 2007 (PST)

Well, the way I envision that working is as follows. In the skill boxes we would say something like this:

<div class="skill-box">
  ...
    <div class="elite-image">
      [[Image:Skill.jpg]]
    </div>
  ...
</div>

Or something like that. Then we would add the following to our stylesheet:

.skill-box .skill-image img { border: 4px solid black; }
.skill-box .elite-image img { border: 4px solid gold; }

We could also do something similar with the smaller images by using a template. LordBiro 05:34, 16 February 2007 (PST)

Hmm... just had a thought... we'd still have to get rid of the borders on the Prophecies skills, and we'd still have to get the PNG extension (for compression), but we could just bevel the edges of skill icons, and put a 50% opacity gold border on elite skills. Is ImageMagick capable of this? --Santax 07:29, 16 February 2007 (PST)

Santax, are you under the impression that this would be carried out by ImageMagick on the server? I'm sorry if that sounds like a silly question. It's just that I wondered why you were wondering if ImageMagick was capable of doing this, since if it isn't then we could just use another program, like GIMP, PhotoShop etc. to produce the icons.

No, it;'s just that I'm not familiar with ImageMagick or if it's quicker than PhotoShop or whatever as far as doing these borders is concerned. --Santax 10:43, 16 February 2007 (PST)

Anyway, I don't like the bevelled look. I think that having an opaque, plain border looks professional. LordBiro 08:43, 16 February 2007 (PST)

Really don't like the opaque border, it looks like a drunk effect. --NieA7 02:35, 19 February 2007 (PST)

Considerating that there are many skills, we should use JPEG. The bevelled look is interesting but for simplicity, the plain opaque border may serve best.--Bane of Worlds 09:27, 22 February 2007 (EST)

While the bevel is very "perdy", I've never heard of ImageMagick. I have Photoshop which can bevel as well, but it seems like a time waster, and, as Bane said, the border is simpler. However, in LordBiro's Santax's example icons, I can faintly see due to the opacity where each border segment (top, bottom, left, right) intersect. If you have each segment on one layer we shoudln't see them intersecting. -Eldin 12:35, 22 February 2007 (EST)

The transparent border is quite ugly in comparison to the old style -FireFox File:Firefoxav.png 22:10, 22 February 2007 (EST)

Just so everyone's on the same page: opaque = not see through; transparent = see through; Opaque == old style. :) --Aspectacle 22:21, 22 February 2007 (EST)

I always thought opaque meant "cloudy" (i.e. lets light through but is not clear) whereas transparent means something that's totally clear (effectively invisible), but having looked it up I see that's not quite right. Ho hum. What I meant above was that the partially-transparent border looks like the drunk effect, and I definitely don't like it. Solid border for the win, preferably around the outside of the icon rather than inset within it (and thus obscuring some of the icon). --NieA7 04:49, 27 February 2007 (EST)

Added a correction to Eldin's comment above, since I would never produce such shoddy workmanship ;) hehe. LordBiro 16:44, 24 February 2007 (EST)

Aw, the bevelled edges were so pretty! :( Even the transparent edge is better than the opaque one. It's so boring. :( - BeXoR 22:57, 26 February 2007 (EST)

I support the bevelled edges too, looks really nice. I'm ok with the opaque border (simple and elegant). Definitely a no for the transparent border. -- ab.er.rant 04:18, 27 February 2007 (EST)

Bevelled edges looks nice, and the solid ones are good too. Just keep away from the transparent one... Stonekin 14:52, 7 April 2007 (EDT)

On a side note will images still contain the marks that they are hexes or enchantments on the icon? I found that knowing how many hexes and enchantments your build has can be crucial to know it's weakness. Sith 10:26, 1 April 2007 (EDT)

Before adding skills...

Formatting should really be decided. Plan ahead, or we'll be stuck doing work like we ended up doing on GuildWiki. Further, because ArenaNet intends to use the Wiki as ingame support at some point in time, we may need to ask them about designing such things to best work in the future with the game.

To give you some ideas as to what probably needs included in a template/article that could be easily referenced elsewhere:

1. Name
2. Cost (in Energy or Adrenaline)
3. Activation time
4. Recharge
5. Attribute
6. Type (Spell, Enchantment Spell, Hex Spell, Stance, Nature Ritual, Binding Ritual, Skill, Melee Attack, Bow Attack, Spear Attack, Lead/Offhand/Dual Attack, Scythe Attack, Trap, Signet, Shout, Chant, Echo)
7. Effect(s) Type(s) (Heal, Gain Health, Lose Health, Life Steal, Damage, Shadow Damage, Holy Damage, Fire Damage, Cold Damage, Earth Damage, Lightning Damage, +Damage, Blindness, Bleeding, Deep Wound, Poisoned, Diseased, Burning, Weakness)
8. Effect(s) Progression(s)
9. Class
10. Skill Icon
11. Description
12. Elite (yes/no)

However, there are also some less obvious things that should probably be added (hence the planning):

1. Target (foe, ally, other ally, minion, pet, party member, allies, party members)
2. Radius (none, adjacent, nearby, area)
3. Range (none, adjacent, touch, nearby, area, half spell, spell, spear, bow, earshot, sight)

These things should be set in stone before we really get all the skills done. -Evil Greven 06:11, 9 February 2007 (PST)

I agree. It would save time in the long run.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 06:17, 9 February 2007 (PST)

You missed Exhaustion and Requirement (for assassin attack skills, which I strongly suggest shouldn't be limited to lead/off hand/dual but should also include enchantment and hex). --Theeth 12:59, 11 February 2007 (PST)

I know there are some databases with this information in... is there a way that, at least initially, the pages could be generated programatically off them? --Vladtheemailer 06:32, 9 February 2007 (PST)

I, too, agree that we should put a little more thought into this before starting to add skills. People are already using Template:Skill infobox and adding skills. Lets put this on hold for a while until we've made a few basic decisions.

I, too, would like to have some additional information included in the template, like Evil Greven, especially target, target range, effect and effect range. And I'd like to see auto-categorization for pretty much all variables, which will help enormously to maintain lists.

Last but not least the template should be flexible enough that it can be used for skills that are not limited to one profession, and monster skills. --Tetris L 06:57, 9 February 2007 (PST)

Yes, creating skill articles shouldn't be done before we have thought the style and formatting throughly. And images shouldn't be uploaded before the above discussion is finished. --Gem (talk) 07:16, 9 February 2007 (PST)

Oops! I just figured we were going with borders on the images. I won't upload anything further :D Actually it seems to me the admins needed an extra week or so to get policy set straight before allowing everyone and their dogs (refering to myself) upload according to what style they want :\ Even though i'd like to help... I'll probably just linger for a week or so until the dust settles and I can actually see where to line up. --KaYa 07:40, 9 February 2007 (PST)

Concerns about using the template system

I realise that I may sound a little paranoid, but I wanted to post this before the discussions went too far.

There are some obvious benefits to using the template system developed, for the most part, by Fyren and PanSola on the GuildWiki, one such advantage being that there is a reduction in redundancy, allowing quick reference lists of skills to be produced extremely easily.

However the downside is that this method is very complicated, especially to new users, who expect that they will be able to edit skill articles but then find that the edit functionality does not work as expected.

I strongly recommend that we do not presume that implementing the template system, or something similar, from the GuildWiki is the right thing to do at this point. Even Fyren has expressed his hope that we would find a better way of solving the problem on this wiki. LordBiro 13:43, 9 February 2007 (PST)

I am a fan of the quick reference lists, but if they can be somehow maintained without the current GWiki template system I would be more than happy to get rid of it. Does anyone have any suggestions, ideas or knowledge on the matter? --Gem (talk) 13:58, 9 February 2007 (PST)

I don't see anything wrong with manually updating the skill lists. — Rapta (talk|contribs) 12:57, 11 February 2007 (PST)

The GWiki has dozens of quick references for different things. Want to update them all manually? --Gem (talk) 13:21, 11 February 2007 (PST)

Forgive my wiki-ignorance, but what are the alternatives and their advantages/disadvantages? --NieA7 15:39, 11 February 2007 (PST)

The general disadvantage of the template system is the harder-to-get structure with the actual data not being stored in the skill article. That can disencourage new users from editing. The disadvantage of the non-template system is that all reference pages have to be updated manually whenever there is a skill change. This can lead to out of date references or less references pages because much more effort is needed to update.

Truth be told, I was quite opposed to the template system when it was introduced in guildwiki, but I changed my opinion almost 100%. Why? Because skill data is rarely edited (only after skill changes) and there are always enough editors around who know to work templates. There simply is no need for users who dont understand the skill template to edit it, because it rarely needs editing. The stuff new users can contribute (usage notes, etc) is still stored on the normal skill page anyway. And having the template enabled guildwiki to have lots of extremely helpful reference pages with very little effort. --Xeeron 15:58, 11 February 2007 (PST)

I am also for a non-skill page skill information template. With all skill information separated from the skill page itself, it will actually be easier to update the skills for those in the know. As mentioned, updates are the only time this information needs changed, so it isn't really an issue if new-to-wiki users are not sure of how to edit this information. Since this information may be linked to from within game, I also think this is good as the skill information page could be set to only be edited by logged in users (no anon vandals). Also, with a standardized template for skill information, linking to this information from other sources (ie, the game) will be much easier, as there will be much less parsing and logic needed to determine the useful information.

Yet another reason for a skill information template is consistancy. I am already seeing skills show up with progression tables extending well into the icon box, causing the table to disappear, but the cell contents to bleed through in the middle of the icon box. With some bars using cellpadding set to 5, this makes the cells progressively larger at lower resolutions. I haven't dug into how it was done before, but I never had problems with progression bars "hiding" behind the icon box on GuildWiki. EMonk 16:13, 11 February 2007 (PST)

I would have less reservations about moving to a template system if:

1. The official wiki's skill articles were as complete as the GuildWiki's, since in that instance new contributors would be less inclined to produce them
2. We had explored some other options ;)

I realise that #2 is a difficult one, but it's still what i think! LordBiro 16:44, 11 February 2007 (PST)

I would love it if we could find a way to avoid the template system. It's even worse than "normal" inclusions. It confuses the heck out of many users, not just wiki newbies. There must be a better way. Maintaining redundant list manually is not an option though. --Tetris L 23:36, 11 February 2007 (PST)

I've updated quite a number of skill templates and as long as the users know they have to click on the "edit skill details" instead of trying to update the skill page itself, I don't see a big problem. After all, there aren't THAT many people who focussed on those pages, AFAIK. Templates intuitive? No. But easy to use when a little effort has been put in to understand them? Yes, definitely. --CoRrRan 04:49, 13 February 2007 (PST)

You're right that if a user knows how to edit the article then it's easier, but it's still not ideal in my opinion. LordBiro 09:05, 13 February 2007 (PST)

Resetting indentation. As I see it, the requirements for a good system would be as follow:

1. Separation between skill data (cost, recharge, ...) from the skill page (containing cap/trainer and notes). This is, IMHO, absolutely necessary if we want to have quick reference pages that are non-trivial (just links to the skill pages).
2. Ease to edit for novice. While the "Edit Skill Details" link did an ok job, I think it was less than ideal ("edit skill data" might have been better, but still...).

Anything I'm missing? --Theeth 09:14, 13 February 2007 (PST)

Sounds about right to me. To my mind point 1 far and away outweighs point 2. It's not like the average skill changes very often, there's no need to edit them most the time. A slightly less than ideal solution to a very minor problem isn't really all that concerning. --NieA7 12:34, 13 February 2007 (PST)

Given that there have been requests to document skill changes, do we want to design this in a way that might make it possible? --ab.er.rant 18:33, 14 February 2007 (PST)

It would be a very nice feature to have certainly (especially for documenting nerfed builds that were previously famous). We should put a fair bit of effort in that direction, though it's a bonus rather than a requirement. --NieA7 02:02, 15 February 2007 (PST)

When the templates were first introduced, the GuildWiki didn't have the "Edit Skill Details" link, which I believe is what caused a majority of the confusion and frustration for quite some time. Once added, it's still not as easy as a regular article, but it's nowhere near as confusing as it once had been. With that or a comparable link prominently displayed wherever a skill is listed, I have no problem with using a template system. --- Barek (talk • contribs) - 07:36, 16 February 2007 (PST)

I feel that the template system is needed, besides, if the user is so new that they can't find out how to edit the template, would they have enough knowledge to need to do so? -FireFox 08:10, 18 February 2007 (PST)

FireFox, I'm not saying that some system is needed, but presuming that the template system used on GuildWiki is the best option is stifling. LordBiro 10:59, 18 February 2007 (PST)

Fair enough, but have any semi-complete alternatives been proposed yet? --NieA7 02:34, 19 February 2007 (PST)

If the general consensus supports a separation of skill data from the skill page, then that immediately implies users who are looking at the skill page and want to edit the skill data will need to click on a special link as opposed to the usual edit link, or that all the skill data should be somehow supplied and editable and savable when the user click on the main edit link for the article. One thing that can reduce confusion, is to add an instructional comment inside every skill page code to educate user on what link to click on to edit the skill data. Moving on, if skill page and skill data are separate, then within the confines of default MediaWiki capabilities, the only way to display the skill data on the skill page is via transclusions (article inclusion and template usage both count as transclusions). So I think the only thing to consider/explore is a three-way choice:

1. Devise some type of plug-in for MediaWiki so that skill pages and skill reference articles can easily pull up the skill data, in such a way that editing the main article containing skill datas will make the data of ALL relevant skills editable, and when the user saves, the plug-in parses all the data and splits them up into main article data and individual skill datas and update them separately (or alternately load data for each skill in a separate text box). For example, editing Mesmer skills quick reference would load up Domination skills, Illusion skills, etc (either in the same text box or in their individual text boxes), which will then load up individual skill data for all mesmer skills to be edited individually.
2. Use article inclusion with precise naming, such as Echo skill data, for the data on Echo, and use page inclusion (the only improvement over GuildWiki's template system is more intuitive naming, so people who don't click on the right link and can't read comments might still figure out what to edit; the only real downside is you have to type in more stuff, including a colon for page inclusion, like {{:Echo skill data}}).
3. Use templating as on GuildWiki, perhaps use more precise naming such as Template:Echo skill data so people who don't click on the right link and don't read the comment might figure out what to do.

I claim that if there is a fourth alternative, it would have to be another custom plug-in idea that also allows users to edit the data on any skill when they try to edit the article reading the data, and thus it would just be a slight modification of the details for option 1. Feel free to challenge my claim. All of the above, again, assumes the general consensus agrees to separate skill data from skill pages. Alternately we can keep skill data within skill pages, and have noinclude and includeonly tags flying around in skill articles, that was another system GuildWiki tried to reduce redundancy with (skill reference articles just do inclusion of actual skill pages), though I think it might be generally hated more than the current template system. -PanSola 23:14, 22 February 2007 (EST)

Hi PanSola :) I'm glad to see you around!

If we were to go with the option of including skill articles (which you covered in your closing paragraph) would we really need to use noinclude and includeonly? The templates on GuildWiki were getting so full that adding a section for notes would not make the template considerably bigger.

If we were to move all of the information out of Template:Skill Name into Skill Name, and include parameters for "notes", "acquisition" and other information, wouldn't this be enough? Then there would be no need to use noinclude and includeonly. Of course, this is not to say that I would be in favour of such a system ;) LordBiro 16:56, 24 February 2007 (EST)

I stand corrected. You thought of an alternative that is drastically different from the 3 I listed. One criticism I have for this fourth idea, is that template parameters poses restrictions on what content may be entered in. For example, I doubt I will be able to put in a table as a parameter to a particular skill, if that skill has certain properties that is best organized as a table in its notes section. Back on GuildWiki, I have tried to hack around such restrictions, but the best I recall I was able to achieve, is to add arbitrary number of cells to a table. I do not believe I was capable of dumping a table into the parameter of a template (although I can be wrong on this detail). I'm fairly certain there are other types of formatting/symbols that cannot be entered as parameters to a template, and which may be helpful for the notes section of certain skills but not generically useful to all skills.

A second criticism is server performance. For the template system used on GuildWiki and having reference list articles doing massive inclusions, I justified the implementation by arguing that the skill template contains absolutely objective data that do not change often, and are in general rarely edited. I argued that inclusion of 200+ templates that are fairly static poses a much smaller server resource drain. On the other hand, if notes and related skills etc are all now mixed with the skill data, then the skill articles are much more likely to be edited often (compared to the skill templates). Inclusion of 200+ articles that changes much more frequently (sometimes just minor grammatical corrections or whatever) will theoretically pose a much bigger drain on server resources and slows everything down. -PanSola 17:32, 24 February 2007 (EST)

A third point: I would like to point out this choice four does not improve upon the issue of new users, who expect that they will be able to edit skill quick reference lists articles, but then find that the edit functionality does not work as expected. When it comes to quick references lists, this idea has the exact same cons as the template system currently employed on GuildWiki and in choices 2 and 3 above. -PanSola 17:39, 24 February 2007 (EST)

A simple suggestion: If we decide to use the template system, it would be nice to have two links at the top. Something like: Skill data - [edit], [history]. I've found it nice to know when trying to figure out why so many people are complaining on the talk page... -Spot 11:50, 26 February 2007 (EST)

It seems easier to not use templates. While this does bungle Quick References, it makes the articles themselves much easier to make. And a decision should be reached on this soon, since skill pages don't follow any specific format right now. Arkhar 19:40, 15 March 2007 (EDT)

using the template system could only help, and with the edit template it doesn't really hurt anything. -FireFox File:Firefoxav.png 19:56, 15 March 2007 (EDT)

I'm not against using the template system, however I wonder about the use of standard inclusion, as I think this may be easier for new users. However, I would think there would still be a problem with the quick reference lists using standard inclusion, as from my understanding, information in the data article could not be parsed into a useful format for the lists. Can someone please correct me if I'm wrong? I support naming skill templates at a different level than that of GuildWiki i.e. Template:Skill data. --Indecision 20:12, 15 March 2007 (EDT)

I've given an example of how it can be done below ("Noinclude transclusion system"). --Rezyk 02:28, 16 March 2007 (EDT)

Onlyinclude transclusion system

I'd like to submit for consideration: a relatively complete transclusion system for skill data based on noinclude/includeonly onlyinclude tags. Please refer to:

• this sample skill page for Shock, and examine its wikicode. The noinclude tags here are the necessary evil with this system.
• these sample pages that transclude data from the Shock page: * *. (Ignore the other skills besides shock; they're on a different system)

Please ignore the ugly rendered format and other fine details if you can; those should be fixable. My apologies for putting this on an external site, but most of the work was done there already. --Rezyk 02:20, 16 March 2007 (EDT)

Thanks for the example, got me thinking. Could this also be done by using <onlyinclude>{{skill row </onlyinclude>? Also, this section seems broken, surely the whole section (description etc...) is also being included? That would make the page much simpler to read for new users, if it works. Also would this integrate successfully with the skill infoboxes being developed by LordBiro? --Indecision 02:57, 16 March 2007 (EDT)

OMG, there's onlyinclude?! That's what I get for using Wikipedia help pages instead of meta.wikimedia. >_< Okay, I've revised the system to not even need the evil noinclude tags anymore. Sweet. --Rezyk 03:41, 16 March 2007 (EDT)

Answers to questions: the whole section is/was being included...<includeonly> just prevents code from being used on the non-transcluded page view; it doesn't stop other sections from being used during transclusions (that's what onlyinclude does). It looks like there should be no problem integrating with LordBiro's stuff. --Rezyk 03:41, 16 March 2007 (EDT)

Sweet! Sounds good, would be nice to avoid confusing new users (such as myself :)). This could very well avoid the need for having 2 pages to represent a single skill. Glad I could be of some help :). --Indecision 09:29, 16 March 2007 (EDT)

The "noinclude" counterpart of this system is what used to be used on GuildWiki, but in the end we decided to move the skill data away from the skill article. The argument used back then was for performance reasons related to caching (impossible to notice with respect to the editing traffic en.guildwars.wikia and guildwars.wikia combined currently receive, no slight intended). The skill article may be edited often (acquisition notes, recommended skill usage, related skills, etc) whereas the skill data is relatively much more stable. And on a lesser important note, for people looking at quick reference lists and want to edit data, this approach offers no improvement over the template system. Of course with the editing traffic this wiki receives, the difference probably won't be noticeable yet, but I have high hopes for this wiki's future, so I am preemptively concerned.

The only thing this system improves is for situations when a user is looking at a skill's article page and wish to edit the skill data. However, when Anet do skill balance updates, we probably will have old-timer editors who know exactly what to edit and go there directly anyways, whereever that is. So when skill balance updates occur, whether the skill data is located in the skill article or in a separate location makes little difference in my opinion. -PanSola 09:42, 16 March 2007 (EDT)

Hey Rezyk, this has always been a consideration and, as PanSola said, this method was used on GuildWiki for a while. My reasons against implementing the template system is that I am hopeful that another solution, either one that doesn't use templates or one that is less complex, might be found. I think that using <includeonly> and <noinclude> in skill articles is just as complex, and less efficient, than using the template system of GuildWiki, although it does have the advantage of being a little more friendly to new contributors. LordBiro 10:24, 16 March 2007 (EDT)

Regarding complexity: I'm aware of what was discussed on GuildWiki, and this is not quite the same. Note that with the recent onlyinclude change, this system uses zero noinclude/includeonly tags. I will claim that, out of all systems ever considered (including on GuildWiki) that unify infobox and quick reference lists' data, there has never been one as simple as this with respect to wikicode complexity. (But really, I'm just trying to get you to scrutinize the code itself rather than considering outdated GuildWiki attempts. At least pinpoint which parts you consider to still be more complex than the template system.) --Rezyk 14:19, 16 March 2007 (EDT)

I agree that performance is a concern, but think this system merits strong consideration regardless; I suspect that the cost may be being overestimated. (Preemptive concern is good, but can often be misleading) Also, if this performance issue turns out to be the only disadvantage, then we should definitely use this system over separate templates! Explanation: For now, there wouldn't be any real performance difference -- it comes later, when skill data input is completed and stable. We can reap all the advantages and wait until performance is an issue, then switch over to templates as needed. It's not difficult to switch between the two systems and it can be done piecemeal, a few skills at a time. --Rezyk 14:19, 16 March 2007 (EDT)

Quite annoyingly I responded to this last night, but I was quite distracted and it looks like I haven't saved it. :(

My response above wasn't as educated as it could have been. Using onlyinclude is more straightforward than a combination of noinclude and includeonly tags, so on this front I think it is great.

But the issue is still performance. If we were to implement the onlyinclude system then every time a change was made to a skill article (even if this change was outside of the onlyinclude tags) then every quick reference that included it would need to be re-rendered by MediaWiki. At least, this is my understanding of the way that changes to a template are cascaded through all including articles in MediaWiki. A template system, as used on GuildWiki, mitigates this problem since it puts the information elsewhere, meaning that if you alter the description of the skill article then it won't force MediaWiki to re-render whatever quick references it belongs to.

Since more complex quick references have started to be used on GuildWiki the number of edits to skill templates have increased. I don't know if this has affected performance.

To deal with your argument specifically, Rezyk, you're saying that if performance is the only issue (which indeed it might be) then we should just implement onlyinclude in articles and then change over to templates when performance is an issue, since it's easy to change between the two (notice both you and I say "when" and not "if"). This argument does not seem logical to me. If performance is going to be an issue in the future then why implement the least efficient solution first, only to change to the more efficient solution when it becomes a problem? If it is so easy to change from one to the other then why not just use the most efficient solution first?

I am not meaning to say that I disagree with the use of onlyinclude, or even that I favour templates over onlyinclude in articles, I am merely pointing out that I do not follow the logic of your argument. LordBiro 06:55, 17 March 2007 (EDT)

Heh, my wording of "when" started off as "if/when" when I first typed it out. Then I changed it to "if" to be less wordy. Then I changed it to "when" just to avoid any argument about whether or not performance will definitely be a problem. =) I'll try rephrasing my performance argument:

Suppose we were to all reach a general agreement that:

A) We should either use the template system or the onlyinclude system.

B) When considering server performance only, template is better than onlyinclude. The difference is negligible early on and grows later, maybe becoming rather significant.

C) When considering everything except server performance, onlyinclude has bigger advantages than template.

D) We can transition between the two systems smoothly (don't have to do all skills at once, and don't have to ever break the rendered view).

In that case, it would be best to start with onlyinclude to reap the advantages of C. B is still negligible so we aren't losing out there. As time goes on, B gets bigger. We reweigh B versus C, armed with a more precise measure of B. Maybe eventually, B becomes big enough to outweigh C. IF this happens, we start switching to template. If we had started with template, we'd lose out on the advantages of C (and probably never know if we needed to).

To expand my argument a little: Starting with onlyinclude also gives us time/space to come up with and try out alternative ideas to address performance. For example: manually update the big reference pages with a static list of substs (maybe even necessary if template performance isn't good enough either).

A counterargument: Even if it's easy to switch between systems code-wise, it could be harder to switch socially (getting that consensus later).

Let me know whether or not you follow this logic. I'm not completely advocating a particular way yet either (conditions A & C are still tentative). Thanks for looking deeply into my proposal/arguments.

--Rezyk 09:00, 17 March 2007 (EDT)

Another (perhaps minor) thing to consider is with the traffic this wiki is going to get how often do y'all think that parts of the skill data are going to be accidentally removed if left on the skills page. -FireFox File:Firefoxav.png 12:37, 17 March 2007 (EDT)

Were the z's intentional? I don't think we should be too concerned that people might inadvertently alter a parameter. I think that as long as the parameters are properly named then this won't really happen too often. LordBiro 15:02, 17 March 2007 (EDT)

That's what happens when I don't cut down on wordiness... ;) Looks like the Z key sneaking up on the shift key again. --Rezyk 15:43, 17 March 2007 (EDT)

Reseting indent. I personaly favor the template system since it has proven to work good. GuildWiki did a good job and seperated the effect of the spells (what it says to do) from the trivial parts. The stats of the spells are rarely to be changed and if so the expert editors can do that. Sith 04:49, 2 April 2007 (EDT)

Image redirection?

I think redirecting the image to the skills info page is a good idea, but KangaRoo seems to hate the idea:

1. (diff) (hist) . . m Image:Cleave.jpg?; 10:56 . . (-20) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)
2. (diff) (hist) . . m Image:Cyclone Axe.jpg?; 10:56 . . (-25) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)
3. (diff) (hist) . . m Image:Dismember.jpg?; 10:56 . . (-23) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)
4. (diff) (hist) . . m Image:Disrupting Chop.jpg?; 10:56 . . (-29) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)
5. (diff) (hist) . . m Image:Executioner's Strike.jpg?; 10:55 . . (-34) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)
6. (diff) (hist) . . m Image:Swift Chop.jpg?; 10:55 . . (-24) . . KangaRoo (Talk | contribs) (Why should this link to the article?!)

etc etc etc

Whats the official word on this? -- Scourge 03:42, 12 February 2007 (PST)

There are lots of reasons for the redirect. The best example from GuildWiki are probably the quick reference lists and builds, where the image was the only thing used as a link to the skill article. I'll ask KangaRoo to stop removing them. --Gem (talk) 04:56, 12 February 2007 (PST)

Ah, here's the one who brought me into trouble ;-) *just kidding* It's all undone, I just didn't know they are (or were) used as links in some pages. --KangaRoo 19:32, 12 February 2007 (PST)

For the longest time, I kept clicking on the images of skills in skillbars and I never got where I wanted to go.--The preceding unsigned comment was added by User:Jack .

Attribute levels in skill descriptions

GWiki uses Attribute level 0 to level 12 in the skill descriptions and uses 0 to 15 in the Template:Progression. Since A.Net is using 0 to 15 for its skill-update pages, would it be a good suggestion to move from 0..12 to 0..15 in the skill descriptions? - CoRrRan 04:29, 13 February 2007 (PST)

Good point. This has lead to confusion after game updates quite a few times when people just copied ANet's text. I'd support switching to ANet's standard. Or how about 0...12...15, to cover both? --Tetris L 04:34, 13 February 2007 (PST)

That might be a better solution indeed. (I'm a big fan of gwbbcode's skill database and I know that 'tool' also provides 0..12..15 for skills.) I even know that it parses that style from 0..15 to 0..12..15, perhaps something that might be possible with MediaWiki coding? But I guess the skills should then be set up with templates, like GWiki. (Correct me if I'm wrong, not a MediaWiki-expert) --CoRrRan 04:38, 13 February 2007 (PST)

I have been opposed to both the 0..12 notation and the 0..15 notation. However, 0..12..15 sounds kinda cool! hehe LordBiro 09:04, 13 February 2007 (PST)

I am now worried that CoRrRan's 0..12..15 has just created a monster, and his name is LordBiro. ;) — Gares 09:09, 13 February 2007 (PST)

0-12-15 sounds good to me. I have no problem with 0-12 seeing as that's what's in game, but there always seems to be headaches when skill updates are rolled out so this'd be a good compromise. --NieA7 11:34, 13 February 2007 (PST)

0...12...15 is the best choice, but if that doesn't work out we should keep with the in-game system, ie 0...12. --Gem (talk) 11:40, 13 February 2007 (PST)

If this could be set as variables in the skill description, it would work. I was thinking about doing such a thing before on the GuildWiki, but became busy with real world stuff after copying the template to my sandbox and never did work on it. Something like prog1 prog2 prog3 variables that automatically filled in the values in the description, depending on which progression bar (or level) they came from. I am not a wiki coder (newb to it), but I don't see why it could not be done. The main problem with this is it would further distance your average user from knowing what was going on if they went to edit a skill's details. EMonk 11:49, 13 February 2007 (PST)

Well, again, please don't presume that we will be using the template. To think in the same terms as we used on the GuildWiki will only limit our imagination as to what other solutions we could come up with. LordBiro 11:58, 13 February 2007 (PST)

I personally think that 0..15 is horrible and dumb. What significance does 15 hold? 12 is the highest without runes, 16 is the highest with runes. Those two numbers are important, 15 is basically second highest, which doesn't make sense to me. If people weren't so used to the 0..15 and 0..12 formats, I'd suggest a 0..12..16 format. But if that isn't an option 0..12..15 is superior to 0..15 and 0..12. --Vindexus 17:32, 13 February 2007 (PST)

From what I remember, A.Net skills guys put two numbers into each skill, then there's a program that generates a curve between those two numbers. The attribute levels for A.Net's numbers are 0 and 15. On a side note, I don't mind the idea of 0..12..15 at all. Those are the real key attribute level points as I understand it.--VGJustice 18:48, 13 February 2007 (PST)

And 15 is what the update notes use. :) --Gem (talk) 10:36, 14 February 2007 (PST)

Correct, A.Net uses the 0 and 15 values to calculate the linear dependence between all skills. Referring to GWiki, where 'we' use the template formats, it also calculated every value dependent on the 0 and 15 attribute values. Then you'd have to manually change the skill description to use the 0..12 style. This created a lot of extra work. I agree with Vindexus that 0..15 doesn't mean anything to the regular GW player, but for A.Net it is vital, as the skills are calculated from those two values. Why not use that in the wiki? And since I've been using gwbbcode (which also uses 0..12..15-style), I've become used to it. --CoRrRan 10:23, 15 February 2007 (PST)

Speaking of gwbbcode - look at this conversation on my talk page. If it's true that gwbbcode uses a 0..12..16 format, then ALL the elites are wrong. Please say it ain't so - I couldn't bear having to go over them all again for the third time :( Oh, and while I'm on the subject: where ingame can you display the skills with 0..12..15 format? I know I've seen it, but Priest of Bally just shows me the skills at my current attribute setup. Am I losing the plot here, or is it lack of sleep? --Snograt 21:54, 7 March 2007 (EST)

And on another note: if you're smart, you download the gwbbcode from the gwshack website, open the archive and locate the skill_db.php-file. In this file is EVERY SINGLE SKILL with 0..15 attribute levels. HTH in your effort. --CoRrRan 09:00, 9 March 2007 (EST)

I can't figure out from the above discussion what the consensus was, 0..12..15, 0..15, 0..12..16, what should be used? — Anja 06:25, 22 March 2007 (EDT)

AFAIK: 0..12..15. 0..15 is used for progression calculation and 12 is of course the obvious max for secondary professions attribute lines. -- CoRrRan (CoRrRan / talk) 06:43, 22 March 2007 (EDT)

I also like 0..12..15 more. However, currently some users are changing skill pages from that system to 0...12...16 - I think it would be good to have some sort of consensus about this soon, at least to prevent people from wasting their time like this. Erasculio 19:35, 28 March 2007 (EDT)

1-15 sucks! My trapper and SS necro use 16 in their attributes permanently. How are we going to know now? - BeXoR 20:53, 28 March 2007 (EDT)

(enter newb) What if we do something new? I like the idea of the 0...12...15 system to keep consistent with the official Guild Wars site and all the updates. Then, why don't we create a standard "Note:" or something below the skill description listing the numbers for the 16 attribute damage. Consistency + GWW exclusive = all the information one could desire. Heck, if anyone had the energy and brains, we could even include another note that lists the +1 attribute 10-20% (or whatever) damage amounts. That would not be me. :-) lol BTW, can someone give a quick lesson on how to do the 0...12...15?? What code do you use? Is it: {{gr|#|#}} Can you use that code on all varying numbers (energy, damage, etc.)? Thanks! --Mask 01:16, 31 March 2007 (EDT)

Uhm, all other numbers can be seen in the progression box, which is slowly but steadily being added to all skill pages. It shows all values at all attribute levels (standard is max 18, but that can be changed).
Yes, you do the 0..12..15 with the {{gr}} and put the value at attribute lvl 0 and the value at attribute lvl 15, like this {{gr|0|15}}. And it works on any numbers, damage, energy, adrenaline, anything you want :) - Anja Astor 03:50, 31 March 2007 (EDT)

...or we could do that. :-) I see it on Arcane Larceny. Looks good to me. --Mask 13:05, 31 March 2007 (EDT)

I disagree with using 0-12-15. At least leave it in the code for calculations and such but highlight useful numbers. 0-12-16 has always been the basic numbers we use when creating builds. Why do you want do display useless information ? Leave to 12 but never show this awful 15 that is not meaningful. I don't care for patch notes numbers...12:12, 5 April 2007 (EDT)Truthseeker

OMG what were you thinking with 0...12...15? Its so awkward. Personally, I think Anet should consider using 0...12 or 0...16 because 15 is awkward. and the 0...12...15 looks weird and nowhere in game would you see 2 breakpoints like that. even 0...12...16 would be ok but the max amount (excluding uses of Glyph of Elemental power and the likes) should reflect the actual amount you could use. 15 is like, you can get around this high but really higher. 12 and 16 make sense because it would be how high you could go with secondary and primary profession but the 15...I know I'm late to the table but I just started wandering around in here and its icky looking =(. JediRogue 22:52, 27 June 2007 (UTC)

Actually, if you think it should be 16 instead of 15, then it should be 13 instead 12. -- ab.er.rant 00:21, 28 June 2007 (UTC)

Why would A.Net change the 0...15 skill progression when EVERYTHING in this game is based on it? And you'll get used to it. ;) Personally, I wouldn't even go higher than 14, just because I don't use any Major or Superior runes in PvP, but I find that 15 holds such a big significance, that it is warranted to use it like this. --  (CoRrRan / talk) 11:47, 28 June 2007 (UTC)

Synergies?

I just wanted to share an idea that I had on skill articles. Currently, GuildWiki lists related skills (e.g. duplicates or similar effects) towards the bottom of skill pages. I was thinking that it would be possible to have a similar, but additional heading on Guild Wars Wiki skill pages for skills that combine well together, although they have different effects (e.g. searing flames + glowing gaze or quivering blade + plague touch are some I can think of atm). This skill synergies listing would have a short note about how the skills combine. I think this would be helpful to assist people searching skill information to construct their own builds. Of course, this information could always just be incorporated as part of the notes on a skill page, but I think the information may be beneficial anyway. Please let me know what you think, or if the expected number of synergies would be too great. --Indecision 19:22, 19 February 2007 (PST)

It's a nice idea but I imagine there'd be too many and as a feature it'd be too contentious - kinda like having a mini-build on every skill page. --NieA7 02:08, 20 February 2007 (PST)

Just what NieA7 said. -- (gem / talk) 14:32, 20 February 2007 (PST)

I'm not really interested in what skills will synergize with said skill, I'd rather just stick with related skill. Jack 14:43, 20 February 2007 (PST)

This is a difficult subject. I like the idea, and when we were discussing the build policies on GuildWiki a number of people said that we could eliminate many builds by describing which skills work well together. It's something I'd like to see on skill articles, but I think many of the reasons that certain skills are better than others is down to more complex relationships. For example, Vampiric Bite and Vampiric Touch work very well together, provided you are a primary Ranger with very high expertise and a skill like Offering of Blood.

I don't think this would have the same problems as build articles. If we are only listing situations in which the skill is most useful then we should be able to define some criteria for that. Maybe not, but I wouldn't like this to be ruled out simply because it is possibly contentious. LordBiro 04:43, 21 February 2007 (PST)

I agree it is a difficult subject but it was mentioned by me previously. We currently do have some of that on the other wiki like for Balanced Stance where it suggests synergy skills that work with it. I personally, see no problem with more information but if it gets to cluttery, biased, lengthy, or involved then some trimming may be in order. Complete builds are of course a bad idea but adding something to Vampiric Bite like "This skill is commonly used by [Ranger]s that have high ranks in [Expertise] to reduce the energy cost allowing constant and repeated use of the skill." wouldn't be too far fetched IMO. Could even add it under a new heading called "Synergies" instead of the general "Notes" section if breaking it out for each skill is needed.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 05:06, 21 February 2007 (PST)

I am also seeing a lot of synergy comments on the other wiki being removed since more experienced players already know about them. This then promotes a wiki to be more elite oriented which I think we want to avoid as this is supposed to be a teaching site of information. Here's an example. This information may be straightforward to an experienced Paragon or Ritualist player but I didn't know these things when I started out as one and only learned later. I support a skill synergy section or comments for each skill 100%. It's about the availability of info, not the assumption you already should know it.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 07:59, 21 February 2007 (PST)

Just to clarify, my intention was that skill synergies based solely on personal opinion should not be added, as these would be open to interpretation and the sort of build-related hate that went on over at GuildWiki. Additionally, skill synergies becoming builds should be restricted by formating choices. Rather, only skills that have demonstrable and factual synergies should be posted (this is not to say that such synergies will always be obvious, particularly to first time players). I would think that we would avoid creating vast lists for skills that might have too many synergies (such as Signet of Illusions). Instead it may be possible to provide the Signet of Illusions synergy on the Arcane Thievery page (i.e. one-way linkage).

Reading through the comments above, I agree with LordBiro that there definitely does need to be some criteria in place for this, if it were to go ahead. In answer to Vallen Frostweaver's discussion re: more complex relationships, this is where I believe a guide would be relavant (e.g. touch ranger guide), as opposed to synergies, as I see this as outside the scope of the synergies section (possibly included in notes). Finally, the idea behind synergies was never to replace the Notes or Related skills sections, as these are valuable in their own right. Rather, this idea was designed to provide visitors to the site with further information about skills, and selecting appropriate skills for use. This may also ease pressure on guides/user builds (if these end up making an appearance in whatever form) as mentioned above by Vallen Frostweaver. This allows the clear statement that Frenzy and Heal Signet have excellent synergy, as do Echo, Arcane Echo and Mending, thereby preventing the Frenzybot and Triple Mending builds/guides from ever needing to be posted. Sincerely hope people can recognize sarcasm inherent in last statement. --Indecision 02:16, 22 February 2007 (EST)

You wrote a lot there but I can't tell what you said. No offense meant, but you lost me. The only part I was sure about was the sarcasm.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 09:43, 22 February 2007 (EST)

Sorry, was a bit tired and got carried away with supposed clarification... To summarize:

+ Synergies should be based on some sort of factual criteria, as opposed to personal opinion.

+ Preventing a possible synergies section from becoming a mini-build section should be handled by the formatting guideline of the skill page (e.g. The synergies section of the page is used to list individual skills that logically combine well with this skill. The synergies section does not focus on multiple linkages (e.g. skill->skill->skill) or the attribute levels of a character, and is not a place for opinion based builds.).

+ For skills with a large number of synergies (e.g. Signet of Illusions), only skills that are strongly correlated with the skill should be linked (e.g. thievery/copy spells).

+ For more complicated relationships than those at an individual skill level (such as expertise + touch skills), I think that a separate guide article would be more appropriate.

+ If a synergy section were to be included it wouldn't replace a Related Skills or Notes/Comments section but would be additional.

+ I agree that a synergy section may help reduce the pressure on guides/user builds or the need to create so many.

Hope that makes the above mess a little clearer. The trouble with doing this will be deciding on criteria for what is a valid synergy (avoiding frenzy-healsig and echo-mending). --Indecision 10:43, 22 February 2007 (EST)

Thanks. I can support all those. Common sense seems to be the rule but you pointed out a lot of possible misconstrued thoughts. So the example I gave of Vampiric Bite with Expertise would not appear in a synergies section by your standards though the information that it would be reduced in cost by Expertise would remain in the notes section. That's fine with me. I like how you have it currently. Anyone else have any ideas for or against this kind of thing? If I don't see any/many responses I'll start directing a few to this discussion. Thanks Indecision for explaining further.--File:VallenIconwhitesmall.JPG Vallen Frostweaver 11:32, 22 February 2007 (EST)

Green numbers

Should we use the values for 0..12 like the in-game descriptions or 0..15 like the update notes use? Some skills, like Orison of Healing, use 0..12 while others, such as Call of Protection, use 0..15. -- Gordon Ecker 21:09, 22 February 2007 (EST)

From the section above it seems there's a consensus to use 0..12..15 instead of either of the other two options. --Dirigible 21:13, 22 February 2007 (EST)

Call of Protection has 0..15 because that was one of the pages I added. I haven't changed anything here since I found out that the formatting for skills pages hasn't been finalized yet. Someone else added Orison, and they probably copied verbatim from GWiki, which uses 0..12 from what I've seen.--VGJustice 00:16, 23 February 2007 (EST)

Whether I should be or not, I'm getting my information from gwBBcode, which uses the 0..12..15 format. Instead of waiting for all the discussions to finish, I've gone ahead and added 90% of the elite skills, using the somewhat-broken Template:Skill infobox ;) --Snograt whisper 01:29, 23 February 2007 (EST)

Make that 100% :D --Snograt whisper 02:37, 24 February 2007 (EST)

It's not used anywhere that I'm aware of. The Skill Monitor and the unlock image use 0...12. The update notes use 0...15. -- Gordon Ecker 22:39, 7 March 2007 (EST)

I'm beginning to think I'm going senile - see Attribute levels in skill descriptions above. I was absolutely certain I'd seen this range in-game, now it appears that I didn't. I think I need to lie down :( --Snograt 08:04, 8 March 2007 (EST)

Perhaps you have seen that 0..15 range when you hover over a skill used by a foe. I believe it then shows a range of values, instead of an exact value. And this might be 0..15 --CoRrRan 08:55, 9 March 2007 (EST)

Everything shown in game is 0...12, but the game engine and game update notes use 0...15. -- (gem / talk) 09:02, 9 March 2007 (EST)

/resign ...looks like I'll be taking CoRrRan's advice and ripping the skill levels from the gwbbcode db then. My new motto: "Look before you leap." --Snograt 09:09, 9 March 2007 (EST)

Skill page formatting

⇒ Moved from Guild Wars Wiki talk:Formatting/General#Skill page formatting

Well, hopefully this is the right place for this. I am responsible for creating the majority of the Elite skill pages, and have taken the liberty to edit the ones I didn't create so that they'd match the ones I did. Take a look at Cleave for an example.

{{Skill infobox
| name = Cleave
| campaign = Core
| profession = Warrior
| attribute = Axe Mastery
| type = Axe Attack
| energy = 0
| recharge = 0
| activation = 0
| adrenaline = 4
}}

== In-game description ==

[[Elite]] [[Axe Attack]]. If this attack hits, you strike for +'''<font color=green>10..26..31</font>''' damage.
== Acquisiton ==
* [[Marika Granitehand]] ([[Iron Mines of Moladune]])
* [[Arlak Stoneleaf]] ([[Ice Caves of Sorrow]])
* [[Gornar Bellybreaker]] ([[Thunderhead Keep]])
* [[Linka Goldensteel]] ([[Frozen Forest]])
* [[Chkkr Ironclaw]] ([[Mourning Veil Falls]])
* [[Razorfin Fleshrend]] ([[Rhea's Crater]])
* [[Chor the Bladed]] ([[Marga Coast]])
== Notes ==

*This skill costs 4 [[Image:Adrenaline.png]][[adrenaline]]. This note to be removed once [[Template:Skill infobox]] has been fixed.

{{skill-stub}}

In my humble opinion, this is a nice, simple and clear format that gets the facts across with no fuss. I'm particularly fond of my green numbers - +10..26..31 - but I can imagine there will be moans about color-blindness (even though it exists in-game ^^). The note about adrenaline is only necessary until LordBiro finishes with the Skill-box (ParserFunctions notwithstanding - and there's a similar note for energy upkeep enchantments).

Questions arising

• [[Elite]] [[Axe Attack]], [[Elite]] [[Axe]] [[Attack]], [[ Elite Axe Attack]] or none?
• similarly; capitalisation: Axe Attack, Axe attack or axe attack?
• green numbers; yes or moan no?

I want to crack on with the non-elites soon, but I don't want to get into a multi-fronted edit war :D

Thank you for listening --Snograt whisper 22:49, 26 February 2007 (EST)

Hey Snograt :) you are very pro-active!

Before I say anything about my thoughts on the use of green, please do not use the <font> tag. It is deprecated in XHTML. A better alternative would be to use <span style="color:green;"></span>.

I will go through your questions individually:

• On GuildWiki the format [[Elite]] [[Axe Attack]] is used. The only option I'm not comfortable with is [[Elite Axe Attack]] since it's not helpful for the reader!
• I would say that, since the article should be lower case, 'Axe attack' would be preferable.
• I don't like green numbers :P

LordBiro 08:32, 27 February 2007 (EST)

The in game text is "Axe Attack". I agree that having the Elite and Axe Attack linked separately is the best way to go. - BeXoR 08:43, 27 February 2007 (EST)

If that's the case then I agree with BeXoR. LordBiro 08:44, 27 February 2007 (EST)

You say the article "should" be lower case, but has that actually been decided yet? I really dislike ULC as a policy so I've been keeping an eye on it, last I looked I was outnumbered in my preference but it hadn't actually been finalised. Personally I kinda like the green numbers, I think I'd be inclined to keep them... --NieA7 09:40, 27 February 2007 (EST)

I apologise, I should not have said that. In my opinion the article should be lower case, but this is not policy at present. LordBiro 10:12, 27 February 2007 (EST)

No need to apologise, I was just wondering if I'd missed something somewhere :) --NieA7 12:13, 27 February 2007 (EST)

I forsee a lot of editing whatever happens. Either UC to LC or green to nogreen, even if yesgreen then it has to be span styled. (I should have known that looking at my sig!) Sigh - anyone got a spare bot? :D --Snograt whisper 18:55, 28 February 2007 (EST)

Would this come in use? {{gr|1..2..3}} → 1..2..3...0...0. Only if the green numbers are kept, of course! --- Barek (talk • contribs) - 19:23, 15 March 2007 (EDT)

The template that Barek has going would simplify a green numbers system, but we should really decide on end-product format and worry about coding next. I'm in favour of green numbering, maybe tables too? I think Axe attack would be best, it's grammatically correct after all. So, in short, changing Axe Attack to Axe attack, removing the note, and adding a Related skills section to the above theory would be a fine format in my opinion. Arkhar 00:11, 16 March 2007 (EDT)

Barek, that is simply amazing :) I freely admit that maybe I'm a little over-fond of the green numbers - it's just that it's probably the first time in my life that I've had an idea that people like! Keep the li'l green numbers - they're my babies :D --Snograt 05:48, 16 March 2007 (EDT)

Skill icon categories

Would it be ok if I categorized all the skill icons? Either in one big category or in profession and campaign categories, if someone prefer something, say so. — Anja 07:35, 1 March 2007 (EST)

If you think it would be helpful then go ahead! I have no opinion on the categories used. LordBiro 08:29, 1 March 2007 (EST)

Why would you want to anyway? I doubt it'll be useful to categorise based on professions and campaigns. If I want to look at a category of skills, I'd go look at skill categories, not skill icon categories. Categorising for professions and campaigns makes it exactly the same as skill articles. Once the skill articles get categorised with things like "Category:Causes bleeding", "Category:Enchantments", etc., are you planning on duplicating that on skill icons as well?

If you want to categorise as "Category:Skill icon", then I think it's fine. But categorising in a way that will duplicate or mirror the categories on skill articles? I ask again: Why? I hope it's not just categorising for the sake of categorising. -- ab.er.rant 08:34, 1 March 2007 (EST)

EDIT: I reread your post Anja, sorry, misunderstood. -- ab.er.rant 08:36, 1 March 2007 (EST)

I'll do it to one big category then :) Not really necessary with more, as you say Ab.er.rant, since the skills are already categorized. And, no, I wasn't planning on adding more categories ;). First thought was one big category, then realised other people might want professions and/or campaign, so I added the option :) — Anja 08:44, 1 March 2007 (EST)

Progression Table

see here -- note I'm referring to visual, not formatting -FireFox File:Firefoxav.png 22:48, 9 March 2007 (EST)

It looks delicious. The colours are really good. I tried altering the skill box to match the colours, but the dark green is too dark, and the light green is a bit lighter than "lightgreen". I think we should use this progression table, or something similar, for our skill articles.

While I don't really want you to change it, I was wondering if there was any way we could improve upon this table? What about a change in shade as the value changes? I don't know, just something to make it a bit more digestible. LordBiro 03:49, 10 March 2007 (EST)

I think its sexy. A couple of skills I have created pages for need a progression table. — BlackGeneral File:Blackgeneralstar.png (talk|contribs) 03:54, 10 March 2007 (EST)

This looks great. I don't like Biros shade changing idea, it would take too much attention from the content. But yeah, go for it! -- (gem / talk) 14:51, 10 March 2007 (EST)

The progression bar looks chic so I definitely approve it and any additional improvements on the visuals could distract the user from the article like Gem have stated.--Bane of Worlds 00:01, 11 March 2007 (EST)

I like the green progress bar, but why is only one set of green numbers bolded? Shouldn't it be both or neither? Gordon Ecker 00:36, 11 March 2007 (EST)

Does it need the top cell? Everyone should know what those tables are or be able to figure it out without needing the heading on it. - BeXoR 01:23, 11 March 2007 (EST)

I thought it might look nicer than the section tags -FireFox File:Firefoxav.png 01:25, 11 March 2007 (EST)

If it's replacing a section heading then that's fine, it probably is better in the table. - BeXoR 01:27, 11 March 2007 (EST)

I like it, but I agree with Gordon about the bolding. --Rainith 01:43, 11 March 2007 (EST)

I also agree about the bolding, I hadn't noticed it. LordBiro 08:16, 11 March 2007 (EDT)

Looking at the code it appears that every cell in the "duration" row is preceded by an exclamation mark, meaning it produces a TH instead of a TD. I don't know if this was intentional, but it doesn't make sense. LordBiro 08:18, 11 March 2007 (EDT)

(reset indent) Modified from Firefox's work (changed colours to match skill box and tweaked a few things): User:BeXoR/Skills - BeXoR 09:07, 11 March 2007 (EDT)

That's great BeXoR! I tried messing with the colours myself, but I produced nothing that I thought was right, but this is just perfect. Good stuff! LordBiro 09:28, 11 March 2007 (EDT)

Yes, that hits the spot! :) Just left a comment (in the wrong place I now see) regarding the color - but this looks dandy :) --The preceding unsigned comment was added by User:Fox .09:32, 11 March 2007 (EDT)

Yeah, nice. -- (gem / talk) 11:48, 11 March 2007 (EDT)

The table looks really nice, but if there are attributes >100, then I find the difference in column-width not really appealing. (User:CoRrRan/Sandbox#Now with >100) -- CoRrRan (CoRrRan / talk) 14:26, 11 March 2007 (EDT)

True. The cell width should be sae for every cell. -- (gem / talk) 14:53, 11 March 2007 (EDT)

Might be able to add a &nbsp ; but as for forcing cell width, it depends on the person's default font and text size so I wouldn't encourage that. - BeXoR 15:08, 11 March 2007 (EDT)

I don't like the idea of fixing the cell width. I really have no problem with different column widths. LordBiro 15:29, 11 March 2007 (EDT)

I like the style of the table (and agree with the fixing column width thing), but the font's rather small - can't we use a larger one? --NieA7 07:49, 13 March 2007 (EDT)

I disagree with both a change in font size and a change in column width :P Sorry NieA7! hehe. LordBiro 07:58, 13 March 2007 (EDT)

It is a bit small and hard to read, but I'm not sure if font size is the change we want. Maby some more space between the numbers and the cell borders. -- (gem / talk) 08:02, 13 March 2007 (EDT)

Damn it Biro, first time I say anything in days and I'm instantly persecuted ;.; So unfair... Anyway, I have to squint at that font on a 17" 1280 x 1024 TFT screen. My sight's not perfect but I bet lots of people who'll be looking at it won't be 20/20 either. Uneven column widths really bug me too ¬.¬ Can the progression tables be given a "width 80%" tag or something, so they take up a reasonable amount of screen real estate regardless of resolution? --NieA7 08:15, 13 March 2007 (EDT)

(ri) Check out User:BeXoR/Skills again. - BeXoR 08:07, 13 March 2007 (EDT)

Numbers are much better, font for the key's a bit squitty though. And again with the uneven columns. --NieA7 08:15, 13 March 2007 (EDT)

The skill infobox is the only one that doesn't match the style of all the infoboxes on the wiki, and I don't know how this is going to look compared to that. I don't know why everyone is being so nitpicky about the even column widths, it's not that big a deal. Now we're going to have to expect every contributor to know to add the space before the number. I don't even know that most contributors would know how to do that.
All in all, the first revision of this was fine. The information was clearly presented. This is just getting nitpicky. - BeXoR 08:20, 13 March 2007 (EDT)

If it's not discussed now it probably never will be, and even if it is it'll be harder to implement. These are just comments, not cast iron rules that must be obeyed, there's no need to get particularly excited about it. --NieA7 09:42, 13 March 2007 (EDT)

It is much more readable now. -- (gem / talk) 08:27, 13 March 2007 (EDT)

As for the progression: gwiki used a progression parser, probably using the ParserFunctions. Is this not going to be used for this wiki? I know there are some issues with the skill itself being templated, but the progression parser is an entirely different thing, right? Or am I still too inexperienced in MediaWiki to not know that these things are linked in a way? -- CoRrRan (CoRrRan / talk) 08:31, 13 March 2007 (EDT)

I agree with BeXoR. The colour change was the only change that I thought was useful, and even then it wasn't necessary. I think that the changes to the font size and the proposed forced column width are detrimental changes. I don't care if you disagree, the table looked better before. My opinion is fact :P

• If you are having trouble reading 0.9em (i.e. approx 90% of the default font size) then how are you not having trouble reading the default font size? If you are having trouble reading 1em then you should increase your default font size. :I
• Please do not make column widths the same, that's going to be a nightmare. If you add spaces then the contents of a cell will be off-centre. If you define a width then columns with only single or double digits will look different from those with double and triple digits. It's so unnecessary.
• Please do not alter the width of the progression table. It should only be as wide as its contents require. If greater padding is required then fair enough. If the width was 80% it would collide with the skill box and look terrible.

I liked this progression table because it was small, simple and elegant. Let's just keep it as FireFox originally designed it, plus the colour changes. LordBiro 12:29, 13 March 2007 (EDT)

A couple of extra points I should add: I don't want to appear callous on the font size front, but I really think if you have trouble reading 0.9em then you should alter your settings.

And as for using an extra space in the cells to even the column width, it doesn't really work. With most fonts a space is slimmer than a number. In BeXoR's example the first cell is 25px wide and the last cell is 28px wide. That might not be an issue to some people, but as a perfectionist it's making me cry. Please make it stop. LordBiro 12:34, 13 March 2007 (EDT)

I agree with LordBiro's statements. -FireFox File:Firefoxav.png 12:38, 13 March 2007 (EDT)

I can read all the text on this page fine, and I've not had to squint at anything at Guild Wiki (or, in fact, at pretty much anything I've come across on the web). I don't see how using a teeny-tiny font for progression tables here improves anything, and personally I think it makes it a lot worse. It's a retrograde step, the numbers are arguably the single most important thing on a skill page so there's no need for them to be hidden away. The width thing is more personal (I'm more irritated by unequal cells in a table than unequal spacing within cells in a table. But then again your last comment seems to be along the lines of "make all the cells equally wide", which is what I want anyway o.O ), but font size is an accessibility issue. Content over style and all that. --NieA7 12:53, 13 March 2007 (EDT)

hidden in plain sight? -FireFox File:Firefoxav.png 13:00, 13 March 2007 (EDT)

Plainly a needle in the haystack? --NieA7 13:05, 13 March 2007 (EDT)

Reset indent. I would like the progression table to use the default font size for the number. There is no reason to make it smaller. What comes to adding extra spaces, I don't like it. Forcing the table to a certain width is probably not necessary. Padding for the cells makes it more readable to me. -- (gem / talk) 13:08, 13 March 2007 (EDT)

Agreed about the font size - I really don't see what we're supposed to be gaining by making the numbers smaller. --NieA7 13:11, 13 March 2007 (EDT)

I'm going to stop commenting on the font size :P As long as no extra spaces are added, no column widths are fixed in the style and the size of the box is not forced into a certain width I can stay quiet! LordBiro 14:54, 13 March 2007 (EDT)

Then we have a consensus. :) -- (gem / talk) 18:17, 13 March 2007 (EDT)

You know it's a good compromise if everybody comes away without something they wanted ;) --NieA7 06:50, 14 March 2007 (EDT)

Indent reset: A few proposed revisions. (A) we have ParserFunctions now! Lets make the scaling auto-populate rather than manual in each cell. (B) On the attribute level bar, I would suggest only bolding attributes 0, 12, and 15 as those are the three levels of the effect that we've decided to list in the skill description. (C) The example stops at attribute level 16 - but there are ways to get attributes of higher levels, even if just temporarilly. This should go to at least 18, although I wouldn't be opposed to 20. --- Barek (talk • contribs) - 10:52, 15 March 2007 (EDT)

Oh, and yes, I agree that font size of 90% is a pointless change. The full size font will fit fine, and the reduced font looks absurdly small on higher resolution screens. --- Barek (talk • contribs) - 10:57, 15 March 2007 (EDT)

Stop adding things Barek!!! D:

May I also add that the colours need to be changed as per User:BeXoR/Infoboxes#Colours. I recoloured everything so that the colours actually made sense instead of just picking something that another box didn't have. I've updated User:BeXoR/Skills with the new colours, but meanwhile can we try and get the scaling box to fit beside the infobox like it did at gwiki? It looks nice that way but I don't know how to code it. - BeXoR 10:59, 15 March 2007 (EDT)

Bexor - in your example, I would still suggest having only attribute levels 0, 12, and 15 bolded. The attribute's name should be wikified. The effects should be scaled automatically (not manually maintained). Extent the bar to at least attribute level 18, although 20 would be better. And per LordBiro elsewhere, don't use the &; code for the space, use a padding setting - although, in honesty, I would just leave it out of the effects range entirely as it'll be a pain to manage. --- Barek (talk • contribs) - 11:03, 15 March 2007 (EDT)

NOTE: I realise that the auto-progression will be a challenge to replicate - Fyren created it on GuildWiki, and he has expressly NOT dual licensed any of his template work. So, we're left needing to re-develop it. Fortuneately, it's mainly just using math expressions to calculate each cell - the formatting can be done by us as we choose here. --- Barek (talk • contribs) - 11:11, 15 March 2007 (EDT)

The only thing in that is the table style which should be followed, with the thin borders and colours, etc. The actual data I'll leave up to everyone else. I am gettin disconnected from this crappy dial up I'm on so I can't do it myself but just use that style when whatever you choose is finalized. - BeXoR 11:12, 15 March 2007 (EDT)

A set of parserfunction expressions for a progression table was developed under GFDL at http://en.guildwars.wikia.com/wiki/Template:Progression . =) See http://en.guildwars.wikia.com/wiki/Category:Progression_tables for sample usages. --Rezyk 12:21, 15 March 2007 (EDT)

Do those auto progression tables work with 2+ changing attributes, if not would they be easily modifiable to do so? Also could someone please explain how the skill box, the progression table and the descriptions and stuff all fit together concisely such that I might understand wth is going on and maybe help out without going utterly off track? Perhaps someone could start to fill in the formatting guilelines? *hopeful smile* --Aspectacle 21:12, 21 March 2007 (EDT)

Template

Are there meant to be dual pages like this: Template:Troll Unguent Troll Unguent? - BeXoR 07:27, 15 March 2007 (EDT)

As far as I know, this was something that wasn't going to be used in this wiki. But I can be mistaken. -- CoRrRan (CoRrRan / talk) 09:40, 15 March 2007 (EDT)

No decision has been made yet IIRC -FireFox File:Firefoxav.png 12:27, 15 March 2007 (EDT)

In this particular case, Troll Unguent isn't linking to the template, so I see no reason for the template. Arkhar 19:38, 15 March 2007 (EDT)

I'd prefer templates to make it easier to create quickrefs. -- Gordon Ecker 05:22, 16 March 2007 (EDT)

I think there is a possible solution to that without using templates, explained up there. — Anja 05:50, 16 March 2007 (EDT)

Sorry, I should've been clearer. I was referring to quick refereces like this or this, which list certain relevant numbers for quick comparison. -- Gordon Ecker 06:22, 16 March 2007 (EDT)

And those numbers cannot be pulled out of a normal article but must be pulled out of the template namespace? Or will the code just clutter the skill page too much, so it becomes hard to edit? Just want some clarification, so I can have a relevant opinion on this :) — Anja 08:24, 16 March 2007 (EDT)

I'm not an expert on templates, but I believe that the numbers cannot be pulled out of a normal article. Templates can define values, which can then be called by other templates for "complex" quickref articles. Another problem with simply using <noinclude> is that the current skill article format is fairly bulky, even for "simple" quicref articles like this. I can think of two options. One option is to use a template with an "edit skill details link" for the skill description and quickref data like Guildwiki ("view" and "history" links could also be added), which has the advantage of keeping the skill data in one place, making out of date quick ref data unlikely and the disadvantage of being less intuitive to edit. The other option is to keep the skill descriptions in the main skill article, and having templates with names along the lines of template:<skill name> skill data, template:<skill name> quick reference data or just template:skill name, which would have the advantage of making the skill articles more intuitive to edit, and the disadvantage that quicref data is more likely to be overlooked and not updated. Quickref data shouldn't clutter things too much, as it could go at the bottom of the template, and wouldn't require any alteration of template:skill infobox, see Guildwiki's Expert's Dexterity template for an example. -- Gordon Ecker 20:19, 16 March 2007 (EDT)

Gordon, the example that Anja mentioned above, which uses <onlyinclude> inside an article, could be used to produce quick references just like the ones on GuildWiki. LordBiro 20:23, 16 March 2007 (EDT)

It would still only work for the "simple" quickrefs. -- Gordon Ecker 21:36, 16 March 2007 (EDT)

I put up some basic examples of "complicated" deep wound quickrefs at http://en.guildwars.wikia.com/index.php?title=Guild_Wars_Wikia:Sandbox&oldid=12068 . Is that what you mean? --Rezyk 22:52, 16 March 2007 (EDT)

I've just had a double check, because your response, Gordon, was so certain. It would not only work for "simple" quickrefs. Anything we could do with templates we could do with <onlyinclude> in articles. The only difference is where the information is located, and the location of the information is an important consideration (as discussed above). LordBiro 06:17, 17 March 2007 (EDT)

Are you sure? According to this article on the Wikimedia meta-wiki, <noinclude>, the <includeonly> and <onlyinclude> do not allow the kind of flexibility that would be required for "complex" skill quick refs like this. -- Gordon Ecker 06:47, 17 March 2007 (EDT)

Perhaps I am mistaken, but where in that section does it say that we would not be able to use this in the way we expect? LordBiro 06:58, 17 March 2007 (EDT)

Sorry, I missed Rezyk's example. You and Rezyk are correct, the skill data does not need to be inside a separate article in the template namespace in order for the data to be called by another template. The part about <noinclude>, <includeonly> and <onlyinclude> tags threw me off. -- Gordon Ecker 07:05, 17 March 2007 (EDT)

Phew :) I was worried I'd missed something. I've produced a very simple example at User:LordBiro/Skill name. It is annoying how similar "onlyinclude" and "includeonly" sound, when they in fact do very different things. LordBiro 07:24, 17 March 2007 (EDT)

The reason GuildWiki uses templates instead was due to server-performance issues, which I've also mentioned in a previous section here. -PanSola 08:31, 5 April 2007 (EDT)

Adding gwBBcode support

I would really like to implement gwbbcode onto the wiki. It is afar simpler and efficient way of displaying skills that the gwwiki one. gwiki.fr has done it and it really a great feature. PogS 07:00, 23 March 2007 (EDT)

This should by handled through Requests for technical administration. -- Gordon Ecker 19:44, 23 March 2007 (EDT)

Really seems pretty easy to edit the skills. --VeNoM 22:31, 28 March 2007 (EDT)

Acquisition

I'd propose that for acquisition, the location of where you get it from is specified before the boss or the trainer or the quest name. It's kinda the same reason why we list campaign before boss name. -PanSola 07:04, 31 March 2007 (EDT)

What about adding the Profession Changers to the Skill Acquisition? I've added those in the few Skills I've edited: [[1]] -Arduinna 06:15, 3 April 2007 (EDT)

Format

It's hard to get the skill pages filled out until we decide how we're going to do it. So, I think we should decide on a final format. Are we using templates? Are we using green 0..12..15 progressions, tables, both, or neither? How will we document skill properties (cost, activation time, recharge, etc.)? And just what information should go on the skill page (Description, aquisition, related skills, etc.)? Once these have been decided, a final format should be posted with a sample skill, and all the skill articles should be made/edited in that form.

As for my opinion on the above subjects, I'm against templates, in favour of green numbers and maybe tables too, putting properties in the box with the picture as it is now, and posting headers on In-Game Description, Aquisition, Related Skills, and Notes. Arkhar 19:53, 15 March 2007 (EDT)

You might want to read the majority of this page, most of your questions are being discussed above.  :) --Rainith 21:37, 15 March 2007 (EDT)

Neither the green numbers or progression tables threads suggest which would be used, but I suppose for sake of clarity I should find somewhere to merge my thread up there somewhere. Arkhar 00:04, 16 March 2007 (EDT)

Adrenaline

Can we include both the strike and point costs? I'd prefer something like this: 4/80. -- Gordon Ecker 22:50, 17 March 2007 (EDT)

How about 4 (80) or 4;80 ? (trying to avoid the fraction look) --Rezyk 23:05, 17 March 2007 (EDT)

Hmm..the adrenaline point metric was completely player defined, right? Then we could also consider "3.2 ". Too wierd? --Rezyk 23:11, 17 March 2007 (EDT)

Edit conflict... I'd prefer the 4 (80) of the 3. At a quick look, 4/80 looks like "four out of 80" and 4;80 looks like some messed up time. --Rainith 23:12, 17 March 2007 (EDT)

Yeah, using brackets makes it more intuitive. -- Gordon Ecker 23:24, 17 March 2007 (EDT)

Brackets look better. --VeNoM 22:17, 28 March 2007 (EDT)

Skill progression mkII

Please take a look at User:Aspectacle/Sandbox. It is an auto-progression skill template using the latest style from User:BeXoR/Skills. It currently only does 2 variables for a skill (are there skills which have more than two?) Feedback welcome - nay encouraged. ;) --Aspectacle 02:17, 28 March 2007 (EDT)

Yeah. Most Binding Rituals have a spirit level, a duration and one other variable, and Anguished Was Linwah has four variables. Would it be possible to alter the template so that you can specify a stop point for the progression? Some attributes can reach an effective rank of 18, some can reach an effective rank of 19 and some can reach an effective rank of 21. Also, for some reason the attribute 20 damage value in the second example progression table has an errant carriage return. -- Gordon Ecker 02:21, 28 March 2007 (EDT)

Ok - I'm not too sure how to deal with variable maximum levels - I suppose I could add another variable which is the maximum level and stop at that? I just noticed the carriage returns... it is from the if statements putting in extra information if they're blank. I'll see if I can fix it up. --Aspectacle 02:35, 28 March 2007 (EDT)

Fixed! :) --Aspectacle 03:02, 28 March 2007 (EDT)

Just a note to redraw attention to this - and say that if there are no objections to this template I will move it into the main space tomorrow. --Aspectacle 18:43, 28 March 2007 (EDT)

Can you remember to match the colour to the current skill infobox colour if it isnt already done. - BeXoR 20:59, 28 March 2007 (EDT)

Well done, and I agree matching colors to the linked skill would be even better! --VeNoM 22:31, 28 March 2007 (EDT)

Hmm... why not match the colour to the respective skill's profession's colour? — Rapta (talk|contribs) 23:05, 28 March 2007 (EDT)

Sorry, where I typed "skill" I meant profession/class color. --VeNoM 23:35, 28 March 2007 (EDT)

As to colour - while I'm not a huge fan of the green (particularly the light shade) I like some consistency to the main skill box. But I don't have a strong enough opinion to argue for it. --Aspectacle 01:08, 29 March 2007 (EDT)

How about making the columns to be of the same width? -- ab.er.rant 23:00, 28 March 2007 (EDT)

Forcing a column width will suck for people that dont use default font size. - BeXoR 00:14, 29 March 2007 (EDT)

Aye - I think that there was a reason that I didn't change the style from your page Bexor - there are just so many things to consider and so many opinions! That aside I've added a few parameters on the template so you can preview in User:Aspectacle/Sandbox to see different column width, and turn on and off the smaller size. --Aspectacle 01:08, 29 March 2007 (EDT)

I'm a fan of having the box as small as is readable. LordBiro 06:00, 29 March 2007 (EDT)

Like I said - so many opinions. I'm moving what I have into the mainspace, as the comments I'm getting are all about the appearance. Appearance can pretty easily be changed (dynamic colour aside!) and people should be using the template rather than the tables simply for the consistency and ease of it. I've selected the small font, no fixed column, matched green format to go out with - y'all can start a war over that choice and fix it up if it doesn't suit. :) --Aspectacle 19:39, 29 March 2007 (EDT)

I support adding it. Oops - I'm late ... I see it at {{skill progression}} already!  :-) --- Barek (talk • contribs) - 00:05, 30 March 2007 (EDT)

:) Yup - I'm working through 'A' on the Category:Skills list at the moment. This game has too many skills. --Aspectacle 00:11, 30 March 2007 (EDT)

I edited into the template the code that can make the color bars variable depending on the profession (use the parameter "prof"). But I reverted it out for now. If concensus is to use it, the code can be found in the template's history and restored. --- Barek (talk • contribs) - 00:35, 30 March 2007 (EDT)

I love that progression bar! It's exactly the way I hoped it would be implemented.

I don't know if I like the idea of progression bars being the same colour as the profession, but I don't feel as strongly about this as I do about having infoboxes certain colours. LordBiro 07:48, 30 March 2007 (EDT)

(ri)I am undecided about the prof colours, but definitely against changing the infobox colour to match professions. I don't think it would be that bad though. Depends on how many people want it and why. - BeXoR 10:31, 30 March 2007 (EDT)

Personally, I prefer the single color for all progression bars - I like consistency. I mainly just worked the code because I was bored, and to make it available if others wanted it. --- Barek (talk • contribs) - 10:34, 30 March 2007 (EDT)

I like the idea of having the progression table following the color of the profession - the consistency there would be within the profession, instead of within the skills. But I don't really care that much either way - the current progression table is very good. It feels like there is a consensus in using this template - maybe now would be a good time to add something about it in the main "Project Page" of this discussion? I think that way more people would help Aspectable in changing the skills (as he said, this game does have too many skills : D). Erasculio 10:46, 30 March 2007 (EDT)

Agreed on about that it is time to add information into the main project/formatting skills page so that it may prevent some confusion on the formatting of the skill pages.I'm assuming we no longer need to add the "In game Description","Skill Details", or the "Description" anymore as most editors decided to do away with such and unneeded.--Bane of Worlds (talk • contribs) 12:37, 30 March 2007 (EDT)

See the formatting page for a quick overview of the style which I have been applying to the articles I've editted so far. --Aspectacle 17:49, 30 March 2007 (EDT)