GuildWiki talk:Style and formatting/Builds

Older Stuff

• /archive 1
• /archive 2
• /archive 3
• /archive 4 - discussion and vote on nightfall builds

And that my Friend, is all I Really needed...

Xas's argument is by far the best argument against the builds. It Makes several great points about the scope. I am offically changing my stance to Delete in the greater interest of the Wiki. I will be copying my Build content to my userspace until such time that it can be tested and will be removing any tags, when Nightfall is released i will retest and re evaluate it. All i really needed was a good reason behind it all, Thank you for taking the time to put things into context. [Xasxas's View]--Midnight08 09:15, 24 August 2006 (CDT)

Ah well cheers mate! I've been getting withdrawal symptoms for the GuildWiki, look at this not a single edit yesterday! Plus my comments are actually making sense, what's going on! Oh and it's great to see you around again Karlos, it's been a while and I like seeing you around even more when you're agreeing with something I've said! --Xasxas256 09:19, 24 August 2006 (CDT)

Someone has to counter your level-headed style with some powerful skills of their own. :) --Karlos 09:30, 24 August 2006 (CDT)

Wow level-headed, that's a new one, no..body..'s....eveee...r...caaaal..ed me thaaat! /sniff /tear :P Also I got a new nickname apparently, "Xasa" (see above). I think I've got one counter for NEA and that's sleep, I feel my work here is done! But tomorrow is Friday and I'll be sleep deprived and bored at work so watch my ability to write a cohesive argument fly out the window! Just so long as Gravewit can help me, save me from Tor! --Xasxas256 09:43, 24 August 2006 (CDT)

lol misspelling FTW, but i like the nic so im keepin it... easier than tryin ta not mess up typin xasxsa, bah xasxaxs bah xasxax bah... xasxas, there we go.... --Midnight08 10:08, 24 August 2006 (CDT)

Dang it, there ya' go using level-headedness and logical reasoning to convert someone who was ready to storm off into someone with good potential to be a productive regular contributor here. If you keep that up, we'll wind up being the most popular Guild Wars fansite available to the community. Oh, wait, we already have that ranking! --- Barek (talk • contribs) - 10:59, 24 August 2006 (CDT)

Why not stick with Xas? That's what I use. On topic: Xas relly seems to have turned the tide. :) -- (talk) 11:02, 24 August 2006 (CDT)

That works too=P --Midnight08 11:12, 24 August 2006 (CDT)

Yeah, I have to agree that Xas' comments seem to be spot on. I don't really agree with the process we currently have of archiving poor builds, and I think this feeling carries over to Nightfall builds. <LordBiro>/<Talk> 13:08, 24 August 2006 (CDT)

And here I thought I was going to get to move some articles. Darn. — Rapta (talk|contribs) 13:10, 24 August 2006 (CDT)

I feel that after reading this article in more detail and seeing that Midnight is upset at the opposition to keeping Nightfall builds that I should go into a bit of detail as to why I feel that they have no place on the wiki.

In order for the wiki to stand above the rest I feel it has to follow some principles, one of which is that it should focus on providing information that would be useful to the average player and vital to those players who play often. While it was opening a can of worms I think that providing build articles is useful. This is because some builds are vital to playing GW. If you played PvP and got killed by a touch ranger, and then came to the wiki and couldn't find out what a touch ranger was, we would not be living up to this principle.

One of the other principles that I think is important is that we should not weigh the wiki down with an unnecessary articles. If an article is only useful to the author then it shouldn't be in the wiki (or at least it shouldn't be outside of their namespace). It's not fun having to wade through categories trying to find what you're looking for. I absolutely hate the builds categories at the moment because they are bogged down with untested builds that I don't give a crap about.

So combining these two principles I feel that it's important that we provide as much information as is useful without providing too much. I think that Nightfall builds fall into the "too much" area. This is because build articles are very practical articles. They tell you how to play the game a certain way and how to achieve a certain goal. It makes sense to me to say that if a build cannot be used by a player then it is not useful. None of the Nightfall builds have any practical use at all at the moment, so I see no reason why they should be kept. <LordBiro>/<Talk> 14:16, 24 August 2006 (CDT)

What you put here pretty much corrilates(i know i spelled that wrong) to what xasxas said in a posst on his namespace. Reading that caused a 180 in my point of view, and as u can see if you look at my namespace i have now copied my Nightfall build and requested deletion on its page. I have also started inquiry into what it would take for me to make a build only wiki that would be a place for builds and hopefully would work alongside guildwiki so that we could possibly move some of the clutter over time from here to there and only have the well tested builds taking up space on the main wiki, while general build testing and other build ideas would have their own areas on BuildWiki (making this because of my love of builds and the upcoming release of Nightfall and NWN2 will cause me to become a 1 man build factory... So i'll want a place for them all=P). Not every1 will agree with that idea either but a seperate location for builds would allow the inconsistancy and speculation inherrant in builds to be kept away from the wiki proper. --Midnight08 14:33, 24 August 2006 (CDT)

Responding to one point you brought up: "I absolutely hate the builds categories at the moment because they are bogged down with untested builds that I don't give a crap about". That is right and due to the fact that the way builds are put into categories is messed up atm. Only tested builds should be in those categories. That will empty a good bit of the categories, but it does not sense to have untested, potentially very bad builds in the categories for farming builds, GvG builds, etc. I'll change the example syntax so that new builds will have commented out categories, which can then be commented in if voted on positively. Btw, unfavored builds should never be in any other category apart from unfavored. --Xeeron 04:57, 25 August 2006 (CDT)

that's a good idea, i've done that with stubs, but i'd not considered it with untested. sounds like a good bored at work project. --Honorable Sarah 09:05, 25 August 2006 (CDT)

actually, most people find builds via the PvE or PvP categories, taking untested out of there would make those categories easier to follow, but it would also mean those builds in untested would less likely to ever get proper testing. --Honorable Sarah 09:16, 25 August 2006 (CDT)

Also, removing the categories means that untested builds need to explicitely specify whether they are for PvE/PvP(HA/RA/TA/...) instead of relying on the categories. --Theeth (talk) 09:57, 25 August 2006 (CDT)

So, if removing categories would cause issues, the next idea would be to Add Categories. IE PvP - Tested, PvP - Untested - more work, but keeps the info needed and allows for a seperation. Oh and just so you know, im trying to convince the rest of my guild to put some effort into helping test untested builds... I think i might start holding guild contests for constructive submissions... The more people he have that are focused on testing the untested builds, the faster we can get through them. --Midnight08 10:34, 25 August 2006 (CDT)

the possiblities for error in that scenario are immense --Honorable Sarah 10:54, 25 August 2006 (CDT)

Personally I think it's important we only show those builds that are useful. I would rather remove untested builds from the build categories and increase the chance of an untested build not receiving exposure than having loads of untested builds filling up the build categories and making it difficult to find builds that actually work.

If an untested build becomes suddenly very popular (i.e. if Touch Ranger had never been heard of, but then suddenly everyone was using it) then the bbuild would be tested more quickly and moved to the proper category, so I don't think we run the risk of being out of date if we take untested builds out of the "live" categories. <LordBiro>/<Talk> 13:59, 25 August 2006 (CDT)

my objection is threefold:

1. it puts a wall between untested and general usage that people will attempt to bypass (by improperly marking tested, etc).
2. it adds a catch 22 to the testing process; to be tested, it needs exposure, and to be exposed, it needs to be positivly tested.
3. the only people who would see it are the people who are already patroling recent changes or are already doing sweeps through the untested category, and we already know that's not enough people to counteract the influx of new builds.

--Honorable Sarah 14:43, 25 August 2006 (CDT)

Why not add a link in Builds and on the Main page? That way people would find them easily and probably test them. -- (talk) 15:05, 25 August 2006 (CDT)

I can see your viewpoint Sarah, but I don't think it's right to list builds when those builds are untested. We would not publish game behaviour or skill information or anything else on the wiki if we had not tested it, so why should we behave differently for builds?

I realise that builds are different to other articles but I still think that they are based on facts and not just opinion. You can 'measure' how succesful a build is based on how well you can achieve a given task using 8 skills. <LordBiro>/<Talk> 15:54, 25 August 2006 (CDT)

LordBiro, I disagree with your example, an untested build is like an article stub, not an untested peice of information. When it is tested and complete, it is like an article with stub removed. So, untested is like the stub tag. What I would like to see is that the unfavored category not be linked to anywhere and kept only for archival uses only. i.e. to point a creator of a similar build that such a build was rejected before. --Karlos 05:15, 26 August 2006 (CDT)

I didn't mean to suggest that untested articles should be deleted, but I do still think that "untested" is different from "stub". I know that builds are different to articles, but I think that we have a situation at the moment where the build categories are filled with untested builds, and I don't approve of this situation. Let's say I am playing AB and I want to find builds that I know have already been vetted. It's not easy to find those builds at all. I would say that, without opening every article in Category:AB builds I can't see whether they've been tested or not. I personally think that only those builds that have been tested should be put into these categories. I feel pretty stubborn about this one :P <LordBiro>/<Talk> 05:32, 26 August 2006 (CDT)

Same thing. Untested builds should be in their own category/categories and not in the same categories as the tested ones. It's hard to find the good builds at the moment. -- (talk) 05:41, 26 August 2006 (CDT)

• Builds not getting exposure: They are linked from the builds portal, plus those actually testing more or less are those that know how the category thing works.
• Losing the info: I commented out the categories, not delete them. Click edit build and you will see them. If anyone thinks that is to much work, replace <!-- with <nowiki> and they will be displayed (but the build page will be a bit more ugly). I dont care but I wont go through all the builds again myself.
• Having categories like untested-AB-builds would make a total mess out of the already complicated structure. --Xeeron 05:45, 26 August 2006 (CDT)

Agreed Xeeron. Not sure if commenting out the categories is the best solution, but it's my favoured option so far. <LordBiro>/<Talk> 05:47, 26 August 2006 (CDT)

karlos, the unfavored categories should already be isolated, nothing should link to unfavored builds, but i'll start again and make sure of that. if we are going to remove categories from untested builds (which i disagree with, but i've covered those reasons) then commenting is the only way to preserve that information without making the page look ugly. fortunatly wiki supports html comments when everyone understands. finally, several PvP players have already stated their unhappiness with our builds process (something about not moving fast enough for the metagame, i don't really understand it, i don't PvP enough), and i think isolating untested is just going to make things worse. --Honorable Sarah 13:24, 26 August 2006 (CDT)

The problem with these people complaining is that they demand us to have perfect builds (and right after they are introduced into the metagame!) but almost none of those complaining are actually submitting builds. IF a really good build ever arrives here, it usually is out of untested in less than 3 days. But builds that noone writes will never become tested. --Xeeron 17:34, 26 August 2006 (CDT)

ok, i've run into a real practical problem. i can't test PvP builds, because i'm a horrid PvP player, so i usually go into PvE builds and look for untested builds. since xeeron jumped the gun, i'm having a hard time finding which builds i actually can test. first i have to start in the massive untested category, then i have to go edit the page every time to see what categories it's in and then decide if i'm qualified to test it. not very practical --Honorable Sarah 18:39, 26 August 2006 (CDT)

lol :) I'm going to bed now, but I felt I had to share that. See you guys in the morning :D <LordBiro>/<Talk> 18:44, 26 August 2006 (CDT)

I usually use the recent changes. All old builds are on my watch list, so I scan recent changes for new builds and quickly decide whether I'll test it or not. --Xeeron 16:51, 27 August 2006 (CDT)

New subheading

I'm starting to wonder if, despite the mess it would cause, having Category:Untested PvE Builds and Category:Untested PvP Builds would be the best option. <LordBiro>/<Talk> 04:34, 28 August 2006 (CDT)

Agree. To see further detail (RA, TA, HoH) you should open the articles thou, but this would be the ideal solution imho. -- (talk) 04:58, 28 August 2006 (CDT)

OK, it has been a bit since the last entry here, but we still need to do something. Currently half the untested builds have commented out categories, while the other half has normal categories. I really dislike having special "untested PvE" categories, but whether we do that, comment out all categories, leave the builds in the normal categories, we should decide on one, because currently it is very inconsistent. --Xeeron 10:00, 31 August 2006 (CDT)

Vetting categories are badly named

Tested by whom? Unfavored by whom? One man's unfavored build is another's tested build. As a wiki with a large and diverse population, GuildWiki should not deem to speak its unimind with a univoice. This goes double for builds, which are highly subject to the whims and preferences of individual players. Please rename these categories to be descriptive rather than nominative. For example:

• Valid (and viable) (instead of tested)
• Obsolete (instead of unfavored)

149.9.0.27 08:44, 28 August 2006 (CDT)

Tested builds - the best builds on GuildWiki, tested and proven workable by the community.

Untested builds - new builds that have not yet received sufficient testing to warrant upgrading to tested status.

Unfavored builds - builds that have fallen out of grace, either through inefficiency or that have fallen into disuse because of nerfs. Maybe you can still find inspiration among the debris.

I think the descriptions make it sorta self explanitory. --Midnight08 09:15, 28 August 2006 (CDT)

Agreed with Midnight. Obsolete seems to be a missleading name compared to unfavored. --Xeeron 11:34, 28 August 2006 (CDT)

In agreement with Midnight. The answer to the question of "Tested by whom" can be found in each discussion page of each build. Also, using viable and obsolete does not make it much different from tested and untested... I don't understand what you mean by nominative. Isn't claiming a build to be obsolete or tagging it as viable also nominative? --Ab.Er.Rant (msg Aberrant80) 11:40, 28 August 2006 (CDT)

I agree that "unfavored" is a better fit for that category; but I can see an argument to rename the "tested" category; afterall, even the unfavored builds have been tested. I don't think that "Valid" is a good name either. Maybe something like "recommended", "favored", or "viable" would be a better category name for that group of builds. --- Barek (talk • contribs) - 11:46, 28 August 2006 (CDT)

'Approved'?

In many ways, while I didn't initially agree with anon, I do have to say that I think it makes sense. There's something wrong with determining whether or not a build is good or not based on the opinions of 3 or 4 people. Certainly those people can say whether or not the build is fundamentally flawed, but is it fair that, if the first 3 people who review a build dislike it, that build should be moved to "unfavored"?

I think, while it would make our jobs far less easy, it would make more sense to split the builds into groups based around things that we do have the right to say about them, even if only 3 or 4 people have reviewed them. We can determind quite easily which builds are:

• Useable, valid, viable - those builds that work.
• Flawed, invalid, unviable - those builds that have some fundamental or intrinsic flaw in them that mean they cannot be used.
• Obsolete - those builds made obsolete by a change in the way the game works.
• Popular, succesful - those builds used very often, like touch ranger or 55 monk (although I dunno how popular that is).

Of course, I'm not sure if we should split up builds into these groups, and if we did I'm not sure categories would make a lot of sense, but either way, I do think that anon has a point. It's not right to say whether a build is tested/unfavored based on 3 people's opinions. <LordBiro>/<Talk> 11:56, 28 August 2006 (CDT)

• Usable, valid, viable: The current tested
• Flawed, invalid, unviable: unfavored
• Obsolete: archived
• Popular: Featured (past featured) builds

It is all there. --Xeeron 12:34, 28 August 2006 (CDT)

And about "if the first 3 people who review a build dislike it": Most builds spent days, weeks or even months in untested before they are finally moved into unfavored. If those people that like the build are out there, they definitly have had time to step forward and vote. --Xeeron 12:45, 28 August 2006 (CDT)

I don't doubt that the current categories map well to the groups I've listed, but it's more about what we call those groups and how we populate them. "Tested" could mean anything. Even referring to tested as "good" is very ambiguous.

The current terms "favored" and "unfavored" imply a personal preference to the build, and I don't think that this is what we should be testing a build for. I prefer terms such as "valid" and "flawed". We should be asking "does this build work or not?" not "do I like this build or not?". For many of us on the wiki I think we already do that, but we should say it because those coming to the wiki might not understand that.

I propose something like:

• Successful (currently not a category, but similar to Past_featured_builds)
• Valid (currently tested)
• Untested (the same as untested, could possibly do with a better name)
• Obsolete (once succesful but now unworkable builds)
• Flawed (builds which don't work and never have. Builds here probably shouldn't be archived but deleted after a certain period of time)

That's what I think at present anyway ;) <LordBiro>/<Talk> 13:07, 28 August 2006 (CDT)

They may indeed spend many days or months untested. They may still even be untested even when people vote on them, because I've noticed many instances of this. For example, an Assassin build gets a comment like "No opener" when it uses a skill-based opener like Iron Palm. This happens incredibly frequently. People vote without testing and it simply angers me. The whole voting process should require in-depth comments by the voters as to why it will or will not work. - Greven 13:31, 28 August 2006 (CDT)

The voting puts the builds in 'tested' tatus, so the people really shoud test them. It is not too much asked if we ask them to really test OR have in depth comments explaining why it can't work etc. -- (talk) 13:48, 28 August 2006 (CDT)

meta:Voting is evil. I have stated my general disdain for the vetting practice and the results it produces on gwguru before. I would earnestly advocate a repeal of this procedure and an implementation of the BOLD, revert, discuss cycle for categorizing builds, and editing on wikis in general. gr3g 14:04, 28 August 2006 (CDT)

Yup. I think that utter bullshit should be just deleted on sight, while good builds should be improved as much as possible with discussion. -- (talk) 14:10, 28 August 2006 (CDT)

I think that there seems to be at least some agreement that the way in which we deal with builds is not ideal. While I think it's possible for a vote to establish whether or not the build is workable I think we can agree that this is not how the vote is currently used and I don't think that changing the semantics of the categories would solve this (but I do think we should change the names of the categories anyway).

Instead of having a vote would it make sense to say that a build must meet some pre-requisites in order for it to be "promoted" from untested to valid? <LordBiro>/<Talk> 15:50, 28 August 2006 (CDT)

Hmmm maybe I am just too much an defender of established practise, but ...

Doing away with votes would do away with some of the problems of votes. However, what would you get in return? BOLD, revert, discuss for builds? OMG, revert wars go! That would increase the amount of trouble with builds tenfold. Builds would just from unfavored to favored on a daily basis. I can imagine the talk pages after "utter bullshit" gets deleted on sight, when not everyone agrees it was utter bullshit in the first place.

The vote process might not be perfect, but it prevents all that.

Similarly, what would any "pre-requisites" be? Sure, we can make some rules about following the format and using proper grammer, but layout and proper grammar is the last problem of bad builds. There is no objective way to tell a good build from a bad, only subjective ones. That is why we gather more than one opinion. If 3 people say that it is bad, than it is much more likely to be bad than if one person thinks that the build is bad and starts editing it right away, or worse, deleting it. Until you present me the never-wrong-god-of-guildwars-build-making, any process that lets single persons substancially change builds (e.g. delete them/put them into unfavored), will in my mind always lead to big trouble. --Xeeron 16:53, 28 August 2006 (CDT)

Ok, maybe tested can be renamed to viable if it needs to, although we can always make the definitions of our terms more visible. If we're worried about problems of opinion, where the testers just don't like a build personally, then we keep our unfavored builds visible as well, and not just delete them. We archive obsolete builds, but we keep unfavored builds, in a sort of like use-at-own-risk or feel-free-to-test-them-and-prove-us-wrong kind of thing. If we get rid of the voting and vetting, how would we even be able to categorise the builds? Having prerequisites is the same thing, people will just argue that some of the prerequisites are unfair. --Ab.Er.Rant (msg Aberrant80) 20:11, 28 August 2006 (CDT)

Xeeron, I agree that "There is no objective way to tell a good build from a bad", therefore we should not say whether a build is good or bad. There are objective ways to say whether a build is flawed or valid, and so I think we should use these terms. I would imagine that many of the builds in "unfavored" are not flawed, and so it could well be that the flawed category is smaller than the unfavored category, but this isn't a problem because there would also be another group containing those builds that are popular. <LordBiro>/<Talk> 02:51, 29 August 2006 (CDT)

If you can come up with objective ways to tell a flawed build apart from a valid one, I would be most happy. However I dont believe it is possible (feel free to prove me wrong).

"There is no objective way to tell a good build from a bad", therefore we should not say whether a build is good or bad: That reasoning is flawed. Just because there is no perfect (i.e. objective) way to tell a good build from a bad does not mean there is no way. Look at how this is resolved all around the world: How are films rated? By people voting for oscars. You might not totally agree with them, but the probability that you like this years oscar winner more than the not-even-nominated B-movie are quite high. If you cant have objective criteria, you need to use subjective ones. And to make subjective criteria less arbitrary, you need some way to aggrigate many subjective opinions. The vote is a tool to do exactly that. --Xeeron 07:56, 29 August 2006 (CDT)

I think it's very easy to tell a flawed build from a valid one. Most of the builds submitted so far, even the ones in unfavored, are valid builds, because they do what they say. "Flawed" is a very different label from "bad". Flawed implies that there is something fundamentally wrong with the build. This could be that the build is broken or that the author of the build has not understood how the game works. This would not include opinion calls such as "I think this build isn't that good because I played it in tombs and got killed".

You might be able to conclude that the authors understanding of the game mechanics are flawed, but as long as he puts 8 real skills from no more than 2 professions into the skill bar and distributes 200 attribute points, you can never say his build is flawed. It is allowed by the game mechanic and thus works. However what we are interested in are not builds working as in "being possible" but working as in "an effective solution to the problem". You wont be able to get objectivity into that. --Xeeron 04:25, 30 August 2006 (CDT)

Yeah Xeeron, I do see your point there. I do think there is need for reform when it comes to classifying builds, and I don't think that the names we have for the categories is correct, but I do see your point that that the vote will probably have to remain. <LordBiro>/<Talk> 06:58, 31 August 2006 (CDT)

What are people's opinions towards GuildWiki:We_are_not_The_Oscars? :P <LordBiro>/<Talk> 09:08, 29 August 2006 (CDT)

BRD is the only way out of indefinite editorial deadlock, which is the situation for a large number of currently untested builds. If someone boldly makes one of them favored, and someone else objects with a revert, then that will refuel the discussion of that build. Consensus can then be renegotiated between the two involved parties in the revert. I think you have misinterpreted what BRD means. It is not a license for open revert wars as 3RR (or 1RR) still applies. It is merely the most effective editorial tool there in open-content wikis.

This is, by the way, orthogonal to the naming issue raised by the thread starter and LordBiro (with which I somewhat agree, but not strongly). I should probably refactor this discussion elsewhere. I think, by the way, that the vetting process is too quick to promote articles to "tested" status. There should be some minimal grammatical, stylistic and editorial polish to these build articles. (Yes, I know, {{sofixit}}.) gr3g 07:18, 29 August 2006 (CDT)

Agreed on splitting this thread, there are really 2 discussions going on.

I dont see your indefinite editorial deadlock. Unless you are refering to the total lack of people testing builds compared to people submitting builds. --Xeeron 07:56, 29 August 2006 (CDT)

While the argument for renaming the categories is seperate to the argument to change the processes we use to put builds into categories I would not say that they are entirely independent. The terminology we use undoubtedly influences the way in which people respond. I do think that you are right though, it doesn't make sense to be discussing these under the same thread. If we are in agreement we can move the discussion regarding the abolition of the voting process for builds to another heading. <LordBiro>/<Talk> 07:27, 29 August 2006 (CDT)

Generic resurrection skill?

A lot of builds suggest bringing a resurrection skill as the eighth slot, but many times the specific skill is not important. Should we have a generic skill that we can insert that implies "the best resurrection skill available to you, according to the situation"? --Spot 10:41, 29 August 2006 (CDT)

It isnt top of my priority list, but if someone were to make a nice picture, together with a short, descriptive name, I would not disagree. --Xeeron 11:58, 29 August 2006 (CDT)

Good idea. Now you just need to get LordBiro to summon us a nice little icon. Or did you have somehting else in mind? -- (talk) 11:55, 29 August 2006 (CDT)

Actually, why not just say that under the skill bar? :P — Rapta (talk|contribs) 11:58, 29 August 2006 (CDT)

But then you had to place a 'Optional' slot or choose between the res skills to put one in the bar. Unlike Honorable Sarah, I do think that optional and such changeable slots are good. I'd relly like to see this one as I would have a lot of uses for this one. -- (talk) 12:45, 29 August 2006 (CDT)

I don't have anything in mind artwise, and I totally lack artistic ability. :) --Spot 12:59, 29 August 2006 (CDT)

Don't like the idea of introducing a new icon that is not really a skill into a skill bar consisting only of either blanks or actual skills. --Ab.Er.Rant (msg Aberrant80) 19:53, 29 August 2006 (CDT)

I was thinking of something really simple and clear. The 'Optional' icon with a really small image in the middle is what I was thinking of. -- (talk) 20:00, 29 August 2006 (CDT)

For what it's worth I think having a generic res icon, probably pointing to Resurrect (action), is an excellent idea. --NieA7 06:22, 30 August 2006 (CDT)

Lively warriors, joy — Skuld 06:24, 30 August 2006 (CDT)

I'd go with a simple black ankh on a white background, or a black version of the phoenix guild emblem on a white background. -- Gordon Ecker 04:38, 31 August 2006 (CDT)

Here is my suggestion . I opted for a very light colour and only an outline to imply that it isn't a particular skill. The ankh implies monks and healing, which I think is good enough... but I do think that without text underneath it saying "Resurrect" or something then it wouldn't be easy to understand. Someone could think it meant generic self-heal, you know? <LordBiro>/<Talk> 04:59, 31 August 2006 (CDT)

That's a great one, but I think it should have the same black border as the optional slot and the other skills. (Desides, there aren't any elite res skills yet :D ) The text underneath should be something like 'Any resurrection'. -- (talk) 05:04, 31 August 2006 (CDT)

Unyielding Aura -- (Talk) (Cont) (Cool) 05:11, 31 August 2006 (CDT)

I agree with Gem - change it to a black border so it fits in better and I reckon we've got a winner. It should probably say "Resurrection Skill" or something similar underneath, to avoid confusion with Resurrect. --NieA7 05:07, 31 August 2006 (CDT)

I avoided using a black border because I don't think it should fit. It isn't a skill, and therefore I don't think it should have a black border. <LordBiro>/<Talk> 05:16, 31 August 2006 (CDT)

Optional isn't a skill either but that has a black border - we should be consistent, and of the two I think black looks much better than grey. --NieA7 05:20, 31 August 2006 (CDT)

I don't think optional should have a black border either, but that has the advantage of already being there :P The style I was going for was one of transluceny. Having a black border would kind of ruin that, but if there is consensus to change it to black then I'll gladly do it :) <LordBiro>/<Talk> 05:24, 31 August 2006 (CDT)

Ah consensus, always desired yet ever out of reach. Well, for what it's worth I think that optional and res should definitely have the same colour border. Black would be more consistent with other skills but grey would make them stand out as different fields, so I can see the argument for either. I guess on sober reflection I think optional should be changed too, just to really emphasise that it's not a single skill from the game. --NieA7 05:49, 31 August 2006 (CDT)

Seems like optional needs a change to grey. And we need to come up with a name for the new res icon. Needs to be both short and clear, so that it will not be confused with any actual skill. "Any resurrection skill"? --Xeeron 06:25, 31 August 2006 (CDT)

"Rez". gr3g 06:27, 31 August 2006 (CDT)

"Resurrection Skill" --NieA7 06:32, 31 August 2006 (CDT)

I really like "Rez", lol... <LordBiro>/<Talk> 06:47, 31 August 2006 (CDT)

Both icons with gray is fine with me. 'Any res' if you want it short, 'Any resurrection skil' if long is ok. I prefer a short one as some skill bars only have skills with short names anyway. The page linked to should explain that any skill causing resurrection is ok. -- (talk) 07:17, 31 August 2006 (CDT)

I don't mind but please make it lower case: if we're using generic resurrection skill, I would like "Generic resurrect", not "Generic Resurrect", thanks (GW:ULC and reduce confusion that it is an actual skill) — Skuld 07:20, 31 August 2006 (CDT)

Good point Skuld! <LordBiro>/<Talk> 08:59, 31 August 2006 (CDT)

In opposition to Skuld, i suggest it be named GENERIC RESSURECT SKILL!!!!!...

(This is a joke of the emergency Midnight system, Had this been a serious comment it would have been followed with the regular Midnight rant... I repeat, this was only a joke). In all seriousness though yes,GW:ULC. --Midnight08 09:22, 31 August 2006 (CDT)

Great icon! I like "Any resurrection skill" if long is okay, and "Any rez" or "Any res" if short. Even "Rez" is fine, if the user is confused, they'll click the image. Originally, I was thinking that it should redirect to the Resurrect (action) page, but now, I think it should go to a short page that explains what this is for (which references that page, of course). --Spot 09:57, 31 August 2006 (CDT)

The icon looks pretty good actually and grey is better than black for me too. How about putting a question mark inside optional so it wouldn't look so empty next to this any res icon? As for the text, "Any resurrect", "Any resurrection", or "Optional resurrection" would be fine. Drop the "skill" part, since optional doesn't have "Optional skill" either. --Ab.Er.Rant (msg Aberrant80) 19:56, 31 August 2006 (CDT)

I have uploaded my suggestion for the optional icon to . You can see how both of the icons would look on a skill bar atUser:LordBiro/Generic_Resurrect. <LordBiro>/<Talk> 05:43, 2 September 2006 (CDT)

I don't like this idea in general. I can see it now, our skill bars will be like {{skill bar|Generic Fire Damage skill|Generic Fire Damage skill|Generic Energy Management skill|Generic Glyph|Generic Attunement|Generic Resurrection Skill|Optional|Generic Healing Skill}} — Rapta (talk|contribs) 13:01, 2 September 2006 (CDT)

I don't share your concern Rapta. I'm sure you can agree that some builds require a form of resurrection skill, but not one specifically. It can depend entirely on the situation at hand. Equally there are some builds that only need 6 or 7 skills in order to be effective, the 8th being open to the style of play used by the player. Should we, then, avoid the use of optional skills in order to prevent someone from submitting a build with 8 optional skills? We already have a system in place for testing builds and approving them. I don't think this is a realistic concern. <LordBiro>/<Talk> 13:17, 2 September 2006 (CDT)

To be vetted a build must have an idea in it. We aren't reating more optional icons than the current optional and the generic res icon which is great to have too. Remember that a res is something that belongs to most builds, so it deserves a generic icon too as the exact res skill used is often unimportant. There aren't other skill types which are in most builds but don't need to be a specific skill. I don't have any concersn about this. And the icons are great, Biro! I suggest taking them into use. -- (talk) 17:56, 2 September 2006 (CDT)

Rapta, a quick response is that ANY build that has any member who is listed as Profession/Any will porbably have a generic res skill. Let's say the Urgoz trappers build with the Eles being E/Any. Those eles could go E/Me for echo and bring res sigs, or go E/Mo and bring Rebirth. --Karlos 17:10, 3 September 2006 (CDT)

I am just simply against the creation of any "Generic" skill. I really don't see any problem with simply putting in a Resurrection Signet in the build and placing in the Variants the possible other resurrection skill that can take its place. I just feel that there is no real need to basically "create" a skill for our skill bars. While it does save space, there just isn't an actual need to have such a generic image. And I stand by my initial point: You can basically create a generic skill for any skill, not just resurrection skills. I guess many do not share my PoV, but I am just stating that I am strongly against this creation of a skill for our skill bar, which should really consist of in-game skills, regardless of what the generic skill may represent. — Rapta (talk|contribs) 19:00, 5 September 2006 (CDT)

I actually voiced my concern over introducing an icon representing a non-actual-skill from the start. But since there are supporters for it, I can accept it but care must be taken to ensure that it is very clear that it is not an actual skill but a placeholder. Perhaps even going so far as to use a pattern on the border to differentiate from normal skill borders. --Ab.Er.Rant (msg Aberrant80) 20:03, 5 September 2006 (CDT)

Bump. If we can't get to a consensus, then lets vote. This has been taking too long. -- (talk) 05:25, 24 September 2006 (CDT)

Well, my opinion hasn't changed. I think that because of the availability of resurrection skills it makes sense to allow the player to pick whichever one is best for what they want to do. I do think it's important that this icon is different in style to the standard skill icons, and I think the grey border is suitable. Equally I think the optional icon should be changed to a grey border, and I posted my suggestion for a new optional icon above. I don't mind if this particular icon isn't used, I just think we should use a grey border to show that "optional" isn't a real skill. <LordBiro>/<Talk> 07:45, 24 September 2006 (CDT)

The icons suggested above are great. A generic res skill imho is a great idea as there are a LOT of res skills and all suit a different situation. We don't need to explain the uses of different res skills in each and every build page. -- (talk) 07:57, 24 September 2006 (CDT)

Seems to me more people said this was a good idea than a bad one but nothing much has happened. Is there anything specific holding us up on this one? --NieA7 07:14, 6 November 2006 (CST)

Well, the icons are there and ready for use, just noone seems to have used them so far. I guess in the end, in most situations there is one res that is better than the others (e.g. Rebirth in 99% of PvE). --Xeeron 07:39, 6 November 2006 (CST)

Well I knew about this discussion but I didn't know they were available to/approved for use. If these things can be used then they should probably be mentioned somewhere. Most people base their new builds on old ones I should imagine, so if these icons don't appear there they're unlikely to appear in the future. As for the Res one, I'd rather see an X/any build that uses a generic res than an X/Mo build solely for Rebirth. --NieA7 04:13, 8 November 2006 (CST)

Implementing the generic skill icons

So now we have the new optional skill icon and the new generic res skill icon. If no one objects, I will upload the gray bordered gray question mark with the same name as the current empty black bordered optional icon so that all current skill bars will use it. -- (talk) 05:56, 8 November 2006 (CST)

Perhaps unsurprisingly I am in favour :P <LordBiro>/<Talk> 20:01, 8 November 2006 (CST)

Sounds good to me. Where can we show off the generic res icon so that people will know it's available to use? --NieA7 03:40, 9 November 2006 (CST)

Sorry, didn't upload the icon as I really didn't like to wait for the wiki to load. -- (talk) 06:26, 17 November 2006 (CST)

Hehe, no problem Gem :) I had forgotten about it until Barek mentioned it! <LordBiro>/<Talk> 06:32, 17 November 2006 (CST)

Aaah, it feels so good to be contributing again AND communicating with old friends. I'll need to dome up with something really fun and usefull now. -- (talk) 06:40, 17 November 2006 (CST)

I wish that I had seen this discussion sooner. I'm actually against the new optional image, as I don't feel it addresses the complaints I've seen about the original optional image.

The primary two complaints that I see about the original optional skill icon were

1. It's too white, and stands out excessively in the tool bar. This new icon, while more stylised (and nicer looking) doesn't address this frequent objection. (I tried a negative of the image, but that seems too dark to me - something in between would be better).
2. Some users view it as a sign that the author had no clue what to include. While this group is against the use of the optional icon entirely (I feel it serves a purpose, so I agree with keeping one), I do feel that the use of a question mark is a mistake as it feeds more into the reading that the author didn't know what to put in the slot. A different symbol would be better.

On the generic resurrect icon - I like the concept, but would like to see it also darkened, and maybe even some color added to help visually differentiate it a bit more from the optional slot, as they are currently very similar.

As I said elsewhere, I'm not super active in the builds; but I do frequently see the comments in talk pages, and I feel that if we're going to produce new icons for these slots, then we should address the frequent objections at the same time. I had previously uploaded a screen capture of an empty skill slot. While I don't know if that's the ideal solution (likely not - it was just an idea), but it does at least address the first common objection, and doesn't worsen the situation with the second as this one does. --- Barek (talk • contribs) - 13:06, 17 November 2006 (CST)

Can we at least change the symbol to an asterisk? That symbol is more frequently used as a wild card. A question mark is just ... wrong. --- Barek (talk • contribs) - 17:59, 18 November 2006 (CST)

A darker colour would be okay. I personally like the question mark, but another symbol is okay to me too. -- (talk) 04:30, 19 November 2006 (CST)

I would prefer not to use a darker colour. I really think it should stand out in the skill bar. An optional skill is not a skill, and so it shouldn't have a black border. I made the border for the optional icon 50% black so that it would have a feeling of translucency.

As for the symbol on the optional icon, what would you prefer? I tried an asterisk, but it looks very similar to an assassin icon, and I didn't want to add any level of confusion there. A question mark is universally understood to mean something that is not certain.

Also, regarding the optional resurrection icon, I don't think we should add any colour. Pretty much every colour we could use is associated with a profession. I was tempted at first to make it blue, but in doing so that would associate it even more heavily with Monks. The neutral grey for both the optional slot and the generic resurrect is important, in my opinion.

I understand the concern that some users think that the author didn't know what to include, but I don't see how any icon would solve this. There is an argument that if you can't pick 8 skills for a build to use then it's not a proper build, and as far as I can see no icon would avoid this. <LordBiro>/<Talk> 05:41, 19 November 2006 (CST)

No such thing as a generic res

There is no such thing as a generic res. Rebirth/Sunspear sig for out of battle, res sig for in battle, chant/renew for hard res. All can and should be specified, generic will just force bad choices. — Skuld 13:41, 6 December 2006 (CST)

I disagree. Many builds deal with one specific task, and that task may or may not have an ideal res. If they do then yes, you should specify the resurrect skill. If not then I don't see any problem with using generic resurrect. <LordBiro>/<Talk> 13:45, 6 December 2006 (CST)

Note: a delete tag was posted at Generic resurrect - and I pointed the discussion over here. --- Barek (talk • contribs) - 23:43, 6 December 2006 (CST)

There is such a thing as a generic res. Sometimes it's a matter of reference and this is an easy way of saying 'a resurrection skill of your choice' as I may want to make that R/any build use Flesh of My Flesh for a faster resurrect that won't take all my energy instead of Rebirth which is best after a battle and not during. Other examples might include Renew Life vs Resurrection Chant as they are both in the same Healing Prayers line and they are used more on a level of preference than build function. Now IF the build calls for certain circumstances that may lead to one res being better than another then the Generic resurrect icon chould not be used (like how Lively Was Naomei with no ranks in Restoration will mean that anyone near any threat will be killed outright upon resurrection but Flesh of My Flesh will still give them 1/2 your health regardless of ranks in Restoration). If a build is intended to be used for RA then it's pretty obvious that a res signet is required but if the build is useable in RA and in general PvE then a Generic resurrect icon would be more viable to account for both situations. All this does is tell people a ressurect should be brought along whereas placing a specific resurrect in it's place tells people they should bring that specific one.-- Vallen Frostweaver 07:29, 7 December 2006 (CST)

I second the removal of the Generic Res "skill". There is no such thing in-game as a Generic Res. We have a skill pic for every skill, and optional represents an empty skill box. Definately should be no reason to add these "mythological" skills. Keep it direct, not with builds with Generic AoE skill|Generic Heal|Generic Speed Boost|Generic Slow Hex|Generic Energy Management Skill|Generic Resurrection Skill. — Rapta (talk|contribs) 16:20, 18 December 2006 (CST)

As was previously posted, there are no plans for other generic skills. The generic res is ment for use on builds which have a wide variety of uses. The wiki has builds which are suited for both PvP and PvE play, where the res skill choices are really different. In PvP you will mostly want a res sig, while in PvE the best res is usually a muliple use res. -- (talk) 16:40, 18 December 2006 (CST)

Which can be done with stating "For PvE, you may wish to replace this res with a different one such as ___". There's no reason that a generic skill should be created. In most situations, a Res sig is even the best choice in PvE, over the other resurrection skills. That, plus the fact there are so few builds that span both PvP and PvE builds, there's definately no reason there should be a "Generic Res". We discourage random, generic builds, so there shouldn't be generic skills either. — Rapta (talk|contribs) 17:05, 18 December 2006 (CST)

Okay, whatever. I'll stay out of the build policy and generic wiki build related discussions. Too many stubborn hard core players. -- (talk) 17:15, 18 December 2006 (CST)

It can, but why bother? Far easier to create a generic res icon, as was agreed and implemented less than a month ago. It works fine, nobody's going to create "generic nuke" icons - no need to get excited. It works well and is useful as it stands, and I don't think we should lose it. --NieA7 17:21, 18 December 2006 (CST)

Unprotect this page please

The protection reason is highly bogus. There is no reason to protect a S&F page when reversion is a matter of between two and three mouse clicks. Please use your admin tools lightly, people. gr3g 21:21, 31 August 2006 (CDT)

It's fine, just for a couple of days so the insisted build posting on this page slows down. Nothing to create a big fuss over. =P — Rapta (talk|contribs) 21:36, 31 August 2006 (CDT)

What that indicates is a deficiency in this page in pointing out where to post new builds. The users can be educated. Protection is too heavy handed. gr3g 21:42, 31 August 2006 (CDT)

What's the problem with protecting anyway? We don't need to act like Wikipedia in every single thing. We can have our own way to do things if it suits us. Protecting pages like this serves as a great tool to prevent the need of reverting and article over and over again. (I responded at the community portal too) -- (talk) 00:02, 1 September 2006 (CDT)

I agree that pages sometimes need to be clear what their about. However, if the page starts with "This article contains the necessary information on starting, expanding, and completing articles about builds." and has a name that says "Style and formatting/Builds", and the user still fails to get educated (as you put it), protecting a page is a simpler resolution than having to go to each user's talk page and pointedly add an explanation; which won't even work if the user doesn't bother reading it. Heavy-handed? It's not like this is a fact page or something. It's a page on guidelines and policies for this wiki, which logically, imho, should have restricted edits in the first place. --Ab.Er.Rant (msg Aberrant80) 00:49, 1 September 2006 (CDT)

gr3g, what changes would you make to clarify exactly what steps should be taken? <LordBiro>/<Talk> 04:16, 1 September 2006 (CDT)

I am quite surprised at the strong showing of support for this protection. I am not interested in brokering any changes I might want to make with an admin first because I believe this protection is unjustified. I find the expressed opinion that style guidelines "should have restricted edits in the first place" to be abhorrent. It has fatally worsened my already negative opinion of GuildWiki. I am sure I won't be missed. gr3g 04:53, 1 September 2006 (CDT)

gr3g, every builds category and build documentation page has had 3+ builds posted on it, some I believe upwards of 10! What do you suggest that would make people realise? — Skuld 04:40, 1 September 2006 (CDT)

I'm sorry that you feel that way gr3g. As far as I'm concerned it boils down to the question of how much time we should spend reverting articles. If you think that we don't do a good enough job of informing users that edits should not be carried out on this page then it would be helpful if you could assist us in trying to improve the wording used here. I would have no problem with unprotecting this page and keeping an eye on it for a while if you believed you could make such an improvement. <LordBiro>/<Talk> 05:26, 1 September 2006 (CDT)

gr3g, by having the pages unprotected, more people will post builds there. Not only is that quite damaging: A build posted in the untested build template messes up ALL untested build for as long as it takes to revert, it is also wasteful: The builds posted there might actually be very good, but they get reverted because the author posted them on the wrong page. Protection makes the author use the right page and thus protects his build from being reverted. --Xeeron 05:38, 1 September 2006 (CDT)

I just hate it when some people just spout off an opinion that try to change other people's opinions yet immediately leave the moment they encounter opposition. Abhorrent? Why? Because everyone should be able to edit guidelines and policies whenever they feel like it? There goes another opinion without any reasoning. I hope you come back and read all these responses. And it's still funny that you actually bothered to register despite having negative opinions on GuildWiki in the first place... --Ab.Er.Rant (msg Aberrant80) 09:57, 2 September 2006 (CDT)

I agree with gr3g, this page should not be protected. Place a clear message at the top of the article to not edit the page in order to make a build and show them how they can copy the code into a new article. --Karlos 07:20, 1 September 2006 (CDT)

I agree with the protection, i've seen this page get reverted countless times in the past month. By locking this page it forces the user to look for the correct place to post their build. A page like this is important for new players and if it gets changed consistantly or if a user thinks thats where he is supposed to post builds and then it dissapears it does more damage in the end.--Midnight08 08:11, 1 September 2006 (CDT)

I feel that on highly vandalised articles, protection should still only be used against un-registered accounts. Even then, I would prefer to see the template setup with a date to terminate the protection, like an expiry date of sorts.

I feel the main reason that this page gets edited is that it doesn't state how to create a new article. As a new wiki user, it's pretty self-evident how to modify articles, but not as intuitive how to create new ones. We have how to help articles; but in this case, I think the instructions should also be inserted here.

As it was, we had been seeing several builds inserted at template:untested-build. The reason was probably directly related to this article which astated "Begin the build article with {{untested-build}}." Users read this to mean to click on the link. I removed that link a couple days ago, but there's nothing clearly pointing people to how to create an article from scratch. --- Barek (talk • contribs) - 11:04, 1 September 2006 (CDT)

Gr3g came to the wiki, was immediately taking part in policy and such kind of stuff and then leaves when he is not winning. Hmmm.... Where have I seen this before? Ah! Now I remember! Stab... Wait, I didn't say anything. He/she wont ever return to the wiki. Right? -- (talk) 15:50, 1 September 2006 (CDT)

lol... why did you have to go and say a thing like that Gem? :P <LordBiro>/<Talk> 18:17, 1 September 2006 (CDT)

Because... I'm not sure actually. Maby because I'm always thinking of the Stabberpuppets when people like this come to the wiki. (Note that to me Stabber and her contributions are different than Stabberpuppets and the problems they caused, even if Stabber might not be a real person) Some of these people might be Stabberpuppets. ;P -- (talk) 05:20, 2 September 2006 (CDT)

Just looking at gr3g's logs, he only registered on the 28th, and the IP that he was using before that had only had 3 contributions. Presuming he's not a sock puppet I think it's pretty ridiculous to sign up, try to change our policies and then have a tantrum and leave because nothing has been done in only 3 days. I

As far as I can see he had only received a handful of replies on the matter, and none of them from an admin! I am dissapointed that gr3g hasn't stuck around, but in honesty I hope he doesn't come back. <LordBiro>/<Talk> 06:21, 2 September 2006 (CDT)

I think, when a page dont require further editting, it should be protected. Why would you want to edit a page that no longer needed editting? -- Cwingnam2000 22:07, 1 September 2006 (CDT)

Because it is not a good idea to protect everything that we think as perfect. There might be small things to correct. Protection is a tool to prevent massive amount of vandalism or a revert war. -- (talk) 05:20, 2 September 2006 (CDT)

---

Going back to the protection issue... I do not believe every effort has been taken to help users avoid the mistake. Instead of the big blue message that says this page is protected, put a big blue message that says "Please do not edit this page to make build articles, instead click HERE and do THIS and then THAT."

Xeeron, this is not a popularity vote, this is an issue of principle. We only protect pages as a last resort. --Karlos 05:55, 2 September 2006 (CDT)

Yeah Karlos, it should be made more apparent that this page should not be edited. I agree in principle that we should only use protection as a last resort In practice, protection is often the easy option, but not necessarily the best option.

I had hoped that since gr3g had pointed this out he would have some suggestions as to how to "fix" it, but instead it appears that he has left the wiki.

Cwingam, as Gem says, who is to say when an article is done? This isn't a newspaper or magazine where an editor can come along and say "ok, this article is finished". As admins we don't administrate content. <LordBiro>/<Talk> 06:13, 2 September 2006 (CDT)

Shush, when did I ever say this is a popularity vote? Issues of principle are fine, but you have to have the correct principles. "We protect pages as a last resort" is not a perfect principle, "We do everything to make this wiki the best possible for users" is. Barek changed the page, you can put up your big blue message, if it works great, I am not at all opposed to trying that, but if not, the best way to make this wiki usable is still protection. So dont talk about big blue messages, create them, obviously no non-administrator can. ;-) --Xeeron 06:23, 2 September 2006 (CDT)

While you edit it, please put in:

Give a descriptive name to your build. Prefix it with an abbreviated primary and secondary profession (for individual builds) or "Team" for team builds. Examples:

• R/N Touch Ranger
• Rt/any Ritual Lord
• Team - Ranger Spike

at the start, so people stop submitting X/Any (instead of X/any) builds. --Xeeron 06:42, 2 September 2006 (CDT)

gr3g has taken this away from the page, just to let you know guru_link. Damaging to the wiki I think, if anyone wants a word — Skuld 15:12, 2 September 2006 (CDT)

Reading the posts you've made so far Skuld, I think you shouldn't have gotten involved. While I'd say it is damaging to the wiki I would say that it's more due to your response than his. I think it would be best if that thread were left to dissapear now. <LordBiro>/<Talk> 17:25, 2 September 2006 (CDT)

Nice to see you took my advice... :P <LordBiro>/<Talk> 05:03, 3 September 2006 (CDT)

Well, I hate to join in discussions after they seem to be completed (and generally, I try to avoid discussions, since I typically seem to get an unfavorable reaction when I do so.) However, I see no problem with protecting a page like this. Yes, this is a Wiki, and one of the great things about wikis is that they're very much like free societies, where anyone can add information as they see fit. In a world of so little faith, a wiki is a place where people trust others to do the right thing and contribute good information. However, even in such a free society, there should be such things as rules and guidelines. There are many people who feel that the government should have very little power (coming from New Hampshire, believe me, I know what Libertarians believe in). However, even those who favor little government control can understand certain laws, such as laws against murder and burglary. In a society such as this, there are rules and guidelines too. This page serves to show newcomers how to make a build. Since this is a wiki, there are some who may feel that its better to design builds one way, while others may completely disagree. In order to make this site understandable, there needs to be continuity, and therefore specific ground rules should be made. This page helps establish those ground rules. Without protection, those who have differing views on how to effectively make build pages could change this page back and forth, and the newcomers who don't know how to design builds will be the ones who suffer. If someone wants to change this page for efficiency, let them discuss it here, so that changes will be minimal. Newcomers aren't going to be looking at the talk page to learn how to make a build. For the purpose of continuity, this page should be protected. All this, of course, is my humble opinion, feel free to disagree as much as you wish. VegJed 23:55, 2 September 2006 (CDT)

I think you have the wrong idea. This is protected because new users keep posting their builds here (see [1], [2], [3], [4] etc). It isn't a page that would be requiring a lot of amendments, and people aren't changing it back and forth for their own ideas — Skuld 05:10, 3 September 2006 (CDT)

I understand that newbies to this site have given more pressing reason to protect this page, its just that, IMHO, had that not been the case, I would have supported this page being protected anyways. It shows the formatting rules of the site, which should rarely be changed. VegJed 09:03, 3 September 2006 (CDT)

Quick recap of discussions

Since this page is seeing/has seen many simultanious discussions, I will do a quick recap here. So if you have something to add, do it now before I'll move it to archives please.

• Discussion and Vote on Nightfall builds. Result: Nightfall builds should be deleted. I will flag them soon.
• Discussion of moving untested builds out of the "normal" build categories. Unless there is new opposition, I will soon restart commenting out all categories from untested builds.
• Complaint about bad naming of "tested builds" category. Unless more support is given for a rename, I dont see a name change comming.
• Proposal for a new "generic res skill" icon, similar to the "optional" one in use in builds. Unless there is any critic, it will be implemented.
• Bid to unprotect this page. Seems to fail gathering support. --Xeeron 05:50, 1 September 2006 (CDT)

Proposed new builds policy

Check Guildwiki talk:Builds#Unified discussion on future builds policy for the current discussion on build policies. --Xeeron 06:50, 13 September 2006 (CDT)

Some fiddling

I was bored and wanted to see what I could do with ParserFunctions + StringFunctions. Check out the article linked on MYUSERNAME.nimh.net/wiki (please do not direct link it, I'm trying to avoid getting spidered). Ignore all the red links and missing templates, heh. You can't edit anything, but you can view the wikitext for any of the pages if you're so inclined.

In short, I hooked together the skill data templates to a template for use on build pages to show the description with values filled in based on the attribute ranks. A slightly longer description is on the talk page on my wiki.

To get the same kind of thing to work here might require changes we don't want to make. I'm unsure of if StringFunctions would be a potential performance problem. In particular, it would also mean even more pages using templates and we already have a problem with slowness when we edit high-use templates. My demo uses a certain template once for every skill in a build. So, while we have template:skill box used once for every skill (so several hundred uses) and template:skill box qr used essentially twice per skill (so about 1.5k uses), my template gets used eight times per build. We currently have at least 550 builds on the wiki, which would be 4440 uses right now... --Fyren 18:26, 8 September 2006 (CDT)

Implemented a toggle link through javascript. The whole thing isn't particularly pretty, though. "Toggle" is just sitting there and the two different views aren't similar stylistically, but I'm lazy. --Fyren 20:34, 13 September 2006 (CDT)

Also, this probably won't look like in IE, since I'm only testing in Firefox since there are no plans to use this here. --Fyren 20:38, 13 September 2006 (CDT)

Templates

Maybe we should implement a section for downloading templates for the skills and attribute points and equipment templates for PvP builds?

See: Skill Template, Equipment Template.

Authors and/or other contributors could put the templates up for download by hosting them on an independent storage site and make the download links available in the build page? I think it would be a good idea, but I'd like to get others' opinions on the matter. — Jyro X 08:50, 3 November 2006 (CST)

Download? What the hell are you talking about? A Skill template is a few simple text characters that one can copy-paste... There should be a part in the build template specifecly for putting a Skill and a Equip template. — Poki#3 06:08, 6 November 2006 (CST)

Build Stub vs. Untested Build

I think that these shouldn't both be listed in the example syntax. This is confusing a lot of newer and even older contributors and they're keeping both categories on the page when putting up their builds. A build shouldn't reach the "untested" category until it is completed. And only incomplete builds go in the build-stubs section. — Jyro X 13:25, 17 November 2006 (CST)

I agree with Jyro. By the way, I've written a short tutorial to handling builds. It's nothing big, but a it's something you can hand out to newbs and don't have to tell them the whole story over and over again. Linkage to said page. ~ Nilles (msg) 13:00, 21 November 2006 (CST)

category vs. template

I have a suggestion. Currently, to assign a specific build as being for farming, HA, GvG, etc, we add the category. The problem is that due to the Build namespace, you have to manually insert a pipe and the build's name after the category in order to get it to sort correctly in the category.
But, if we were to use a template instead, the template could be setup to automatically insert the pipe and build name. There are two advantages to this; first, the build will automatically be sorted correctly; and second, if the build gets moved/renamed, the template will automatically (overnight, not instantly) re-sort the build into the correct location for the new name on it. --- Barek (talk • contribs) - 18:32, 12 December 2006 (CST)

Great idea. -- (talk) 19:21, 12 December 2006 (CST)

Mmmm... template. (_:^(|) -- Vallen Frostweaver 07:54, 13 December 2006 (CST)

Skill Template Box

The S&F doesn't indicate the method to show the Skills Template for use by players. There are now three templates at Template:Skills-template, Template:Skilltemplate, and Template:Build template.
While it's the newest version, I'm promoting using the Template:Skills-template in builds, as it has the option to click on the skill template code to get it to automatically download. There is one known issue with it at this time; I'm hoping that Fyren can help resolve it. However, that issue hasn't caused any problems in testing. (edit: problem fixed - thanks Fyren!) --- Barek (talk • contribs) - 14:01, 16 December 2006 (CST)

I agree with Barek, on that we should use something with the downloading, however, is it really neccesarry to have the link to the download be the code itself? It just seems to me like the downloading should replace the copy+paste, not add to it. I was also thinking, that sense this build template almost always acompanys a Template:Skill bar and a Template:Attributes, it might be nice to combine the three? –Korolen 15:11, 16 December 2006 (CST)

I had just used the template as the link so that users had the option to either download or copy/paste; but something else could easilly be used instead (like the disk icon itself) ... but I wouldn't object to merging the template into the skill bar either. --- Barek (talk • contribs) - 15:23, 16 December 2006 (CST)

Would it be possible to compile the data for the skills template dynamicly? That way, you could just stick in the "build" template, which is a combination of the attributes, skills, and a download for an automaticly generated code. It would make it a lot easier, as you wouldn't have to figure out what the code is every time you change it, and all the builds on the site would be downloadable. –Korolen 15:34, 16 December 2006 (CST)

I suppose it could possibly be done, although it wouldn't be easy. But, to work within templates, it would require considerable rework of the templates that contain the related data, as well as updating every skill article and a new, fairly complex template to pull it all together. If someone wants to develop something in their user space or the sandbox, I would help testing - but I'm not sure who could be talked into taking on such a task. --- Barek (talk • contribs) - 16:00, 16 December 2006 (CST)

Doing it through templates would only lead to pain. It would have to be an extension. You don't want to try doing programming-like things, such as generating the template code from the skill/attribute info, with templates. --Fyren 16:03, 16 December 2006 (CST)

Well, one site has figured out the code [5] but they don't have their algorithm public, and figuring it out myself would just be a pain in the ***. However, I still like my idea of combining those three templates, dynamically generating the code or not. –Korolen 19:35, 16 December 2006 (CST)

No, all the information needed to create the template codes is known and public (the format of the code, the values for attributes and skills, and the encoding algorithm). It's just (possibly my personal hangup) that what we're doing with templates for builds and skills is bad. The skill templates are acting like a database with each template such as Template:Flare being a row and the skill box templates such as Template:Skill box ias being like views.

An extension could replace all that (with some effort) and improve both performance (not that it's an issue right now, but come campaign 5...) and functionality (spiffiness like JS popups in builds or replacing ranges in builds with actual values given the build's attribute ranks would become much easier). But, as far as I've been able to figure out, an extension would lose the "auto-update" ability of MW templates where editing, say, flare's template updates every QR page flare's on and also flare's skill page. I might be wrong, but it seems like it'd take a large effort make sure it works right so that changing a template doesn't mean a bunch of QR pages and builds don't end up out of date. But I'm rambling at this point, I think. --Fyren 22:43, 16 December 2006 (CST)

Sorry, I didn't realize that the template algorithms were public (I'm a horrible Googler). Could you give a link?

I'm not familiar with the technical details of Wikis... Would you program an extension in PHP? I have a rudimentary knowledge of PHP, but I'd like to learn it better anyway, so I'd be happy to help program a template generator (if it's in PHP) –Korolen 20:47, 18 December 2006 (CST)

This was posted way back when templates were first patched in (outside the beta, at least). Someone may have come up with a better writeup since then. Our Skill Template format isn't much better. --Fyren 20:58, 18 December 2006 (CST)

Wow, I didn't know we even had a page on the skill template format. Well, the skill template looks relatively easy to encode or decode; once again I'd be up to the challenge. –Korolen 22:59, 18 December 2006 (CST)

EDIT: In fact, it looks like Cheez has already done it in PHP. I didn't quite get what you were saying about things not updating with an extention... it seems like it should be rather easy to implement a version of his code? –Korolen 15:50, 20 December 2006 (CST)

Technically, the code for gwBBcode already accomplishes most of what has been discussed, and they at least had a spin-off version that works in MediaWiki. But there have been two problems; server overhead/bandwidth needed, and the update methodology to keep it in sync with the skill articles.

While all these are nice to have features if they can ever be fixed to require less system and network resources; for now I think converting the existing Skill Box Template to the version with the built-in download feature is the best option for now. --- Barek (talk • contribs) - 16:01, 20 December 2006 (CST)

stub AND untested... -sigh-

Ok, so it seems EVERY build that enters into the untested category as of lately is also stubbed a the same time. Can someone please remove {{untested-build}} from the copy/paste build template on the main page so that we don't keep getting dual untested/stubbed builds? Only reason I ask is because there is a <!--note--> on the page saying not to edit it so I am assuming it is an admin's preferred function.-- Vallen Frostweaver 15:18, 18 December 2006 (CST)

Ty very much Barek.-- Vallen Frostweaver 15:44, 18 December 2006 (CST)

Too much bashing

I realize this has been issued an incountable amount of times before and many of you have given up discussing (or arguing depending on what kind of person you are), but I still do believe there is way too much build-bashing going on. If you sum up all articles in the Tested builds-category (not counting the archived ones) you get 231 while in Unfavored builds-category you get 678. There simply can't be that many more builds that haven't the slightest of uses.

While looking around at the builds myself, I've seen literally all kinds of odd comments, including "bad rune choise" (IMO, not reason enough to unfavor a build). But it seems most of the unfavored-votees have specified "there are better builds for this" as reason, even if the build in question might even be with another primary profession. Well, sure, in most of the cases, that's most likely true cause there's always something better, but I personally thought we were only going to vote unfavored if the build wasn't usable at all. It's one thing if the build in question is for doing something that there are already tons of other builds meant for (like forge-running), but let's say I add a tank build with a mesmer primary (only an example). My biggest guess tells me that build would get bashed with the reason "mesmers are not tanks", and most without even trying the build, but IMHO everything is possible with the right skills, and as long as the build does what it should, it's a working one, and thus shouldn't be unfavored.

Guys/Girls, believe it or not, but there can be more than one build that does the same thing, and even if one of them would be better than the others, that's no reason to unfavor the others as long as they're working. Also, I'm not saying you should stop unfavoring builds (who would listen to me anyway?), I'm just begging you to please give it one extra thought and if there's only a slight change that would just make the build better, please go ahead and make that change instead. That's the nature of a wiki anyway.

Now, it's 4:37 am, so I've most likely missed something, but I believe you get my point. — Galil 22:39, 5 January 2007 (CST)

To me that sounds like "hey, let's have a bunch of bad builds moved to unfavored!". — Rapta (talk|contribs) 22:46, 5 January 2007 (CST)

Either your comment made just about no sense at all, or you mean tested and not unfavored. Anyway, that's not how I meant it. This is how I think (being entirely neutral on the matter since I have never written or voted on a build [with the exception of IWAY]): Reasons like "bad rune choise" has to go away cause they are really nothing more than a vote with a seriously bad reason. Comments like "you're not allowed to move this build back into untested since no admin has stroken the reason-less unfavored-votes" also has to go away GW:YOU. As any other wiki-user who couldn't start playing nightfall til recently (due to my time abroad), I like to be able to visit the wiki for builds for my heroes, and my own chars that take use of the new skills in nightfall. However, since no one wants to play a bad build, I check through the votes to find a build that does what I want it to, and has been favored by most. Many times, this is impossible (try finding a good PvE paragon support build that hasn't been nerfed recently), often due to reasons like the above about runes, or "there are better builds", or "not enough energy management" even though the usage-section fully explains how to gain energy, and many times it does work, or in PvP, even reasons like "a monk without channeling?!". All I'm saying is, people are too picky with builds when voting, almost like they're obsessed with having perfect builds and nothing else. One slight mistake, and the vote goes for unfavored, instead of fixing that one problem.

All, I'm really saying is, please think one more time before adding an unfavored vote and the poor reasons really have to stop. — Galil 23:09, 5 January 2007 (CST)