This is a backup copy of the discussion page in preperation for the 'True Build Ratings' proposal policy that states discussion pages will be wiped before voting proceds. Shireen 05:01, 12 May 2007 (CEST)

General Discussion/First Reactions Edit

I like the idea, really not a bad way to go. Needs some cleaning and additional small things but it sure a nice start :) GCardinal 19:08, 6 May 2007 (CEST)

A system like this would be completely subjective. The effectiveness of any build anywhere would depend primarily upon your opponent. Not only are the criteria totally subjective, but the ratings would be uninformative as well. Firstly, the numbers themselves could be confusing, i.e. what distinguishes a 4 from a 5 in ability to resist counters? (Btw, a counter to a build what will neutralize it. If any build can resist or circumvent that factor, it is not a counter) Secondly, it will distort the effectiveness of builds that are known to be good or bad. Take just about any GvG warrior build. It's only heal would likely be Healsig (poor self-survivability). It would likely have no Hex removal, and likely no condition removal (high team dependence). No hex or condition removal = difficulty "resisting counters." E-mgmt could arguably be inapplicable, because of a warrior's adrenaline. Taking these factors into consideration, the build might be judged unuseful to the team. As easily as that, you can portray a great and well-known build to be a disaster under this system. Lastly, having to rely on that "Test 1st Plz" policy pretty much puts the icing on the cake. That requirement is not only impossible to enforce, but it will also create an enormous backup of horrible builds that people will have to test to unfavor. I would never waste my time doing that. I can telly you right now that an all-Signet gimmick build will be ineffective, I shouldn't have to test it first. Over at GWiki, that "Testing Optional" policy wasn't enacted by a cabal of evil admins up to no good. It was put in place to maintain efficiency and a higher standard of quality than otherwise would have applied. - Kowal Krowman (talkcontribs) 19:28, 6 May 2007 (CEST)

Too many factors to judge fairly... and in pve, what if a build has a lot of enchants, and some area's have no enchant removal but other's do. Just my thought's. --Ranger-icon-smallfrvwfr2 (talk)(contributions) 20:20, 6 May 2007 (CEST)

The concept of whether a build is generally "good" or not is inheirantly abstract, we don't need to hold a ruler up to it. --Rollerzerris <!--Zerris--> 23:28, 6 May 2007 (CEST)
Re: My attempt to bring a Gate of Madness team into Foundry. Again re: My latest attempt at DNKP... using a team based off of our Hell's Precipice experience. -- Armond WarbladeArmond sig image{{sysop}} 22:52, 7 May 2007 (CEST)

But a measuring stick would greately help with the allready existing problems of how we fairly judge existing builds. I just realized where I got the idea for this and it may help if we take a look at their system to get some ideas. The following is one of those anime-music video sites run by a guy named Phade. Their community is completely opinion based and they rate each others videos and their system seems to work pretty well for them. Perhaps we could take the concept (not necessarily the exact procedure) and adapt it to out needs. Http://

The pre-set categories and numerical values are whats gonna make or break this policy (IMOP). We just need to discuss and figure out what's reasonable. And we can put together a guide to the voting section to better understand what it means to put a '10' or a '6' or a '3' into a particular voting field.
For example. If we were to put an 'Overall' or build quality category, the range would be from 1-10, 1 being lowest 10 being highest and we could do a quick chart like:
  • 1 - The build is completely rediculous, Example: 6 Skills - 2 Assassin, 2 Monk, AND 2 Warrior??? FTW! (Delete Candidates)
  • 2 - The build is simply broken or lacks an elite (Most noob or beginer builds people try to make)
  • 3 - The Build is functional but makes poor skill selections and is very difficult to use (Like an Ether Lord e-denial build)
  • 4 - The Build is functional, but only in very specific situations and is not reliable. (Pacifism Monk)
  • 5 - The Build Works, but there are much better examples of its type allready out there. (Like the default ZB sujested by the primer articles)
  • 6 - The Build works well, but is hurting in a minor area such as condition removal or e-management (Faster Caster Monk)
  • 7 - This build is solid and would be a good example of it's type. (RC Prot for HA)
  • 8 - This build works very well and can even accomplish a few things that isnt in it's designed scope.
  • 9 - A prime example of what a build of this type should be. (Stanced LoD Infuser)
  • 10 - The Uber 3llt version of the build. Will incite a massive nerfing backlash by Anet! (Like boon prot, back int he day when it worked)
Thats an idea, and we could do a chart for each category type we create. Just an idea to perhaps put some of this in perspective. Shireen 14:39, 7 May 2007 (CEST)
Then, a person can glance at a build to find if it does what he/she needs the build to do. Also a person can look in the unfavored section and see what needs to be fixed on a build. Although i could see people abusing it and using it to decide how to make their own votes. Eronth 21:10, 7 May 2007 (CEST)
I like this option, it's simple, it provides room for discussion, and though people might not like being a '4', there are many useful builds that are specific for a reason. I do think this system is best for PvP builds and perhaps another categorical system is better for PvE. -- 22:27, 7 May 2007 (CEST)

For the record, Mo/E SoA Sliver was the most awesome solo bosskiller ever and got nerfed by ANet - and it had no elite. Elites are handy, but in many cases aren't as useful as one might think. Solo builds and (let's be honest now...) many casual assassins play without elite. And it's spelled l33t. -- Armond WarbladeArmond sig image{{sysop}} 22:52, 7 May 2007 (CEST)

This is just too slow. nice idea but to much work to vote.--Coloneh 23:03, 8 May 2007 (CEST)

Yeah I agree. The concept is good but it would only work if we had some way of restricting the amount of builds submitted. The submissions will come in faster than they can be voted on. Its also makes voting a bit overwhelming and might discourage people from voting, which would compound the problem of too many builds not enough votes even further. -- BrianG 01:04, 9 May 2007 (CEST)
Also, a problem i run into often is i find (lets just say) a good assassin build. but all the votes on it are "bad". then u read teh reasoning and find out that its bad because theres another warrior build that does better... i dont play a warrior so i dont use warrior builds, so we deffinently need to be able to say "if you have a warrior, try running this!". I understand different classes are different skills, but sometimes an assassin would like a good raw power build that doesnt get put down for being inferior to a warriors. dunno, maybe this would be the job of the "buildmasters" or whatever they were called in earlier pages. Eronth 01:11, 9 May 2007 (CEST)

Let me kick this around in the old brain housing group to see if I can streamline the process into something a bit more managable... I guess I am a bit to detail orented. Shireen 02:29, 9 May 2007 (CEST)
Added a more detailed description of how the voting process would function mechanically in the scripting section at the bottom. Shireen 19:42, 11 May 2007 (CEST)

Clearly inferior buildsEdit

A build is clearly inferior to another build if it performs less adequately under all circumstances than a comparable build. This means that the inferior build would always be worse than the other build in ways such as (but not limited to) energy management, survivability, micromanagement, vulnerabilities, and adaptability to unforeseen circumstances. These are only a few things taken into account; this policy will not try to define all the properties that make a build work better than another. The responsibility to make the decision of whether one build is superior or inferior to another will eventually fall upon the shoulders of the admin who decides whether or not to delete it. This admin will, of course, take into account the votes of the testers and look at the builds in question.

Straight from PvX:WELL with bold and italics. Again, good idea, would be nice to implement, but there's no way we can say all the things that make a build own/suck, or when which ones apply, without major headaches. -- Armond WarbladeArmond sig image{{sysop}} 22:52, 7 May 2007 (CEST)

That policy does not try to determine what makes a build better than one another, but that still leaves the option to create another policy that would try to assist in the quantification of builds. Shireen 21:44, 9 May 2007 (CEST)

Added the note that anything recieving an overall category of 5 or less is subject to PX:Well Shireen 05:30, 11 May 2007 (CEST)

Subtype Listing Edit

Okay, there are a lot of people here who say they like the idea, but don't think it could work. I put on the front page that this policy is not filled out enough yet to warrent a vote yet. It is not fleshed out enough to really get it going. So I am going to ask for help. And if we can flesh it out to a reasonable point, we could then give it a trial period in the builds section, making the rating sytem completely optional for a few months. After the trial period we vote to see if this is a good policy or not.

I really think this kind of thing is doable, and once people get used to it, it won't slow voting down one bit. It is CHANGE and people tend to be weary of major changes.

Though right now I need help with identifying build categories and subtype attributes to help flesh it out. The only one I've listed on the front page is in my field of expertiese (Heal/Prot monks). But we need to expand the list so we can start getting an idea of just how big this sucker is going to get.

The beauty of the system would be that despite the many subtypes, they all use universal types of attributes (Such as damage output, or Degen Output, or something similar)

Subtype Ideas:

  • KD Melee
  • Condition Melee
  • Pressure Melee (IW mesmers would fit in here)
  • Trap Ranger
  • Condition Ranger
  • Spirit Rt
  • Spiker (be it Ranger, Rit, Ele, or Necro)
  • Interrupters
  • Shutdown Builds (E-denial/Diversion/Movement Redux/Hex stackers/Ranger Spirit Users etc.)
  • Protection Monks
  • Healing monks
  • Farmers
  • Runners
  • Support characters (most paragons, ward eles, etc.)

etc. etc. Please feel free to expand this list as you see it. Shireen 22:31, 9 May 2007 (CEST)

You have a bunch of different types of interrupters. Merged them and split healing and prot monks (as they're two completely different play styles). Also, added support characters and put all spikers in one category. -- Armond WarbladeArmond sig image{{sysop}} 16:55, 10 May 2007 (CEST)
Clarified shutdown builds to broaden it's scope outside of mesmers. Im going to start working on the master sub-attribute list and hopefully figure out which subtypes get what subattributes by default. Shireen 01:56, 11 May 2007 (CEST)

Baseline for 1-10 system Edit

I outlined the 'overall' build attribute as an example of what can be accomplished. Here is a basic 'template' that can be used or adapted to create the sub attributes. My opinion is that a build must have a minimum rating of 3 or 4 in a sub atribute to warrent it's presence on the rating table. That means if people vote a rating (on average) below 3 or 4 then that attribute is considered to small to be of significance and does not go on the table. The only exception to that would probably be for 'support builds' who often to mass reaching but very minor effects that can assist in the big theme of things.

Basic 1-10 Template
  • 1: Insignificant: Has no inate ability what so-ever. Does not warrant posting.
  • 2: Partial: Has a minor ability to enhance an external source to a minor degree, but is otherwise useless.
  • 3: Weak: Has a minor ability applied to 1 target or has a short term, mid level ability appliable only to self.
  • 4: Minor: Has a minor ability appliable to 2-4 targets or has a short term, high level/ mid level mid term, appliable to self or 1 target. (Or is extemely easy to counter)
  • 5: Works: Will work: Has a mid level/ short term ability appliable to 2-4 targets, or short term high level/short term ability applied to self or 1-2 targets. (Or is reasonably easy to counter)
  • 6: Aptitude: Has a strong aptitude Ability is Mid level/Mid Term appliable to 2-4 targets or is a mid level/long term ability appliable to 1-2 targets or is a high level/short term ability appliable that is mildly difficult to remove. (Could be countered)
  • 7: Strong: Is a good example of what can be achived in this area. (significant individual thread) (Could be countered)
  • 8: Superior: Is a prime example of what can be achived in this area. Very High individual threat (Difficult to counter)
  • 9: Elite: Is a strong effect that cannot be countered and plays a serious role in this area, warranting ganking by the entire opposing team. (Nearly impossible to overcome)
  • 10: Nerf Alert: It's broken and has reached 'god mode' in this area. A-net should be nerfing it soon.

Okay, it is really rough and hard to read, but it's a starting point to use when designing the sub-attribute types. As allways feel free to jump in and mix things up. Which would be a good policy: Minimum 3 or minimum 4? Shireen 05:08, 11 May 2007 (CEST)

Example of Voting Edit

To give a visual refrence, I am going to take one of my favorite builds that was unfavored back on Guildwiki as a safe example of what this could look like. This is not meant for approval/disaproval of the build itself.

<pvxbig> [build prof=mesme/monk fastca=12+1+2 inspir=2 protec=12 healin=2][zealous benediction][reversal of fortune][dismiss condition][guardian][shielding hands][remove hex][inspired hex][resurrection chant][/build] </pvxbig>

Gear would be FC/FR Wand and focus for prot. 500 health, 50 energy. (moot point)

This build is meant to be used in RA, with it's Fast Casting and hex removal this is a difficult monk to shut down.

-This would be on the discussion page-

:Votes Favored: 1 - Votes Unfavored: 0
: Attributes: [Hover-boxes would appear when mouse is put over attribute or number, with an explination of what they mean]
:|           Core Attribs:                 |     Monk Atribs                   |    Additional    | Create your vote (link)
:| OvA | EAM | Sur | MiM | Vul | Adp | Sus | HxR | CdR | DaP | SpC | Hea | Utl |                  | Show Breakdown of votes (link)
:|  4  |  7  |  6  |  3  |  7  |  6  |  5  |  8  |  6  |  5  |  7  |  5  |  5  |                  | 
= Rate-a-build -FC RA Monk== (This would be an extension of the table above)

Please test and vote on new builds. Testing is encouraged but not required.


  1. It works but is difficult to use -Shireen


  1. No votes recieved

And then down at the bottom of the page all you would see is

-= Voting section (Place your voting template codes here) =

  • Shireen has voted on November 11, 1775.


The abbrivations translated - In the finished product you could do hover overs...

Ova = Overall
EAM = Energy/Adrenal Management,
Sur = Survivability
MiM = Micromanagement (Ease of use) (Recieved a low score due to the dificulty of use)
Vul = Vulnerability (Recieved a 7 for being difficult to shut down using standard anti-caster tactics)
Adp = Adaptability
Sus = Sustainment
HxR = Hex Removal
CdR = Condition Removal
DaP = Damage Prevention
SpC = Spike Counter
Hea = Healing
Utl = Utility

Quality control Edit

Please make sure that this policy has all things required to pass quality control. Please read PvXwiki:Voting on Vetting Policy.

I've cleaned up the front page and put this policy into a holding pattern. There are a lot of people saying it's a good idea but won't work. Untill it can be refined enough (Hopefully it will naturally evolve through the thread's discussion) I would not recomend this policy (created by me) to be submitted for voting Shireen 21:43, 9 May 2007 (CEST)


Make sure that your policy meets all of above requirements or it will NOT become a candidate and people will NOT vote for it.

  • How new builds will be posted.
  • How new builds will get into actual vetting procedure. (short)
  • How discussion and voting/vetting will be done.
  • How re-voting will be done. (short)
  • How deletion of builds will be done. (short)
  • How builds will be organized. (optional)
  • How it will affect existing builds. (short)
  • If policy needs mediawiki extension, who will make it? (short)
  • Plan on how to make a script (if needed).

GCardinal 22:01, 10 May 2007 (CEST)

Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.