The concept of “needs” is something I won’t implement. E.g. my build uses Stonehide Kuba’s of Dranghoul but I could say that you don’t really need “of Dranghoul” and you could replace it with “of Readiness” for a small drop in performance. That’s a relatively easy example.
So any kind of such a system will use strict “has” rather than “needs” if I’m to implement it.
Initially yes, that was the purpose of g-tag system. Moreover, I think before it was a 100% subjective system when it was up to buildmaker to decide how he feels about gear dependability, on a scale of 1 to 5. My guess is at some point people started to demand for guidelines or even clear rules, and that’s how we ended up with a system that no longer fullfills it’s purpose.
The whole (mi) tag idea is just to keep some people happy. I don’t feel strongly about it, but it would keep the only thing related to g-tags people cared about. It’s also easy to implement.
Eisprincessin started tagging build threads based on sets used, and while I love it I’d rather not implement it in Compendium. Part of the reason is people want to type less stuff, not more.
It doesn’t answer the question whether something is hard to obtain or not, and it would still need to be explained. Initially g-tag system was designed to relieve the reader from research on what’s easy to get and what isn’t - because they could just check the g-tag and say “ah-hah, it’s g3 so should be average”. Here’s the quote from Compendium V (last vanilla):
g# : The build is dependent on specific gear with a value ranging from 1-5. The higher the number, the more gear dependent it is.
And that’s it.
Basically yes, that’s how it is. The only benefit of your idea is that people won’t have to open your thread and/or your GT link to know what kind of gear they will find inside. That’s not a bad thing, but I think allowing a tweet-sized description just for that would be an overkill.
Probably, but not necessary. Standartization is needed for using search, if description is to be read by human rather than search engine then the free form is possible.
I think this build is a one of a kind extreme, which doesn’t really justify the split of (mi) into subcategories.
I mean I don’t really see the difference between a build with one double rare MI and three double rare MIs, so I’m not sold on this.
Poll time. Do you think a (no-mi) tag for current (g3) builds would make more sense rather than (mi) for current (g4) and (g5)?
- (no-mi) for current (g3)
- (mi) for current (g4)&(g5)
0 voters