Diablo Wiki

Crossover banner.jpg
Diablo wiki on Fandom


Diablo Wiki

Item models

Do the 3d models actually add benefit on the non-weapon item pages? Given the size of the viewer, and the very generic nature of the models (take the crafting plans as an example), will players actually gain any benefit from having them there? I personally don't believe so, and would like to see them removed. --Wynthyst 22:51, 7 October 2011 (UTC)

Probably not. The armor pages could theoretically get the same benefit, but they seem to be very generic and the same across armor tiers. But I agree, plans, objects etc. really serve no purpose for a viewer.--PhrozenDragon 00:36, 8 October 2011 (UTC)
I've been systematically removing the model numbers from the generic armor images. I will get rid of the plans and stuff as well. --Wynthyst 02:14, 8 October 2011 (UTC)
I come across a few broken 3d models in the weapons section as well. Should i start removing the ones that are broken? --Zhuge 21:20, 19 October 2011 (UTC)
Yes. -- Wynthyst User Wynthyst sig icon.png talk 04:59, 20 October 2011 (UTC)

Creating redirect pages for attuned skills

This would simply be:

#redirect [[parent_skill_name]]

as I understand it from Zhuge's explanation. I wrote and ran a script for it this morning and lo and behold, there are conflicts. Good thing I had the script not blindly overwrite pages. For example the Demon Hunter actually has two attuned skills called "Backup Plan" (Preparation + Alabaster rune, Evasive Fire + Obsidian rune)... my advice would be to come up with some naming convention that consistently avoids these problems. So here's a list of pages that need disambiguation edits or some resolution due to there already existing spells with the same names from Followers, other classes, item names, outdated information, duplicate spell names, etc...:

(37 conflicts)

Withering Fire
Thunder Ball
Screaming Skull
Backup Plan
Focused Mind
Rolling Thunder
Chain Lightning
Static Charge
Circle of Life
Deep Freeze
Slow Time
My best guess is that there will be some resolution of this issue as the game progresses in Development, or that a solution will present itself as more datamining is done. -- Wynthyst User Wynthyst sig icon.png talk 18:13, 18 October 2011 (UTC)

Quest page links

We need to determine where/how to get links to the quest pages that Apoc has been slaving over accessible from the main page. -- Wynthyst User Wynthyst sig icon.png talk 05:50, 19 October 2011 (UTC)

Looking at the Diablo II main page, would it make sense to just add another portal window "Quests" in our Diablo_III_Wiki? We would also need a general explanation page for D3 quests as well. --Apoc 06:02, 19 October 2011 (UTC)
Both sound good :D -- Wynthyst User Wynthyst sig icon.png talk 06:08, 19 October 2011 (UTC)
The six icons were originally chosen and formatted based on a minimum screen width of 1024px, which is the same as DiabloFans and indeed all curse sites that use a similar layout. Adding another image will widen the main page and force it to scroll for users with smaller screens.--PhrozenDragon 16:35, 19 October 2011 (UTC)
Well, the point is that somehow the Quest pages have to be accessible from the main page, so whatever you feel is the best way to to that Phrozen, it needs to be done. -- Wynthyst User Wynthyst sig icon.png talk 16:38, 19 October 2011 (UTC)
A quest link is of course an excellent idea, though it requires a general page to be created first. I'll reorganize the link box so we can fit the quests there for now though. And if it turns out we want to put quests as an image further down the road we'll just have to decide whether it's more important than say locations.--PhrozenDragon 16:44, 19 October 2011 (UTC)
While I understand the aesthetics behind the 4 portal images, the simple fact is that the information that's available isn't just those 4 things. I would like you to consider other options, such as possibly creating a second row of images (possibly below the line of large links... or some other way to expand the amount of information that is directly accessible from the main page. -- Wynthyst User Wynthyst sig icon.png talk 18:53, 19 October 2011 (UTC)

Item display template on weapon/armor list pages

It seems there are two fields, ID and item level which are not needed for visual viewing. Should we hide these from the display lists? --Zhuge 18:00, 19 October 2011 (UTC)

What's your reasoning on this? If it's a matter of interest I agree the id can be omitted but the ilvl is still important to mf'ing and treasure theorycrafting. If it's an issue of space then you could tuck the ilvl into the require level field with some CSS mouseover magic. --Apoc 18:34, 19 October 2011 (UTC)
Agreed bout the ID one but the item level was confusing atm --Zhuge 18:38, 19 October 2011 (UTC)
Um, the item ID has already been hidden though it should be left in place for future usage, and if the item level is available, it should be included. It's clearly marked as being different from the required level, so I don't see a problem. -- Wynthyst User Wynthyst sig icon.png talk 18:51, 19 October 2011 (UTC)
Actually, wowhead has been doing this for years with millions of users pretty much the same as our table with the exception they have it labeled "Requires level" instead of "Required level". I don't think it's confusing as long as it's properly labeled. --Apoc 18:56, 19 October 2011 (UTC)

Magic and Rare Items

On the item pages, how are magic and rare items going to be maintained once the game goes live? For example, there are going to be literally hundreds of magic and rare axes. Is the plan to create a page for each of them? I'm assuming if that's the case something different will need to happen with the nav boxes otherwise they will become unwieldy. If we are going to maintain a prefix suffix list instead and not list every item, then what purpose does the magic and rare sections of each item page serve? Are they only for the crafted items? If so we should probably denote those sections as crafted only. -Talkerst 18:25, 24 October 2011 (UTC)

As far as the magic and rare items go, these are only the crafted items. There are too many affix combos to put on the wiki. --Zhuge 18:27, 24 October 2011 (UTC)
Yes they are for crafted only, listing all combinations of magic and rare items is both pointless and nigh impossible to boot. I agree though that labeling them as crafted somehow is probably a good idea--PhrozenDragon 20:58, 24 October 2011 (UTC)

Featured Article and mainpage focus

I believe we should further discuss the usage and implementation of the Featured Article section on the main page, as well as some additional items that deserve main page attention. Regarding the featured article, I have started a discussion here. As for new items for the main page, Talk:Diablo III Wiki -- Wynthyst User Wynthyst sig icon.png talk 04:52, 28 October 2011 (UTC)

Monster pages and templates

Working example: Risen. There's not a whole lot of stats on each NPC, other than we know if they are hostile, their class type, and what levels they are in each difficulty. Based on observations, we can determine their abilities and location in the game. Ideally the level info belongs in the Data: namespace but since it varies by level and looks better paired with the location information I placed it into tables with Template:D3 NPC Location. --Apoc 03:37, 29 October 2011 (UTC)

Very nice. Do you mean however that the monster levels varies depending on where it spawns (similar to D2)? If so we might just have to wait until the game is released to get more detailed information on how those levels vary and where that information is best placed.--PhrozenDragon 13:13, 29 October 2011 (UTC)


The DPS calculation is rather complex and is currently used in two places. I've created a template that can be used to centralize the calculation so that changes to it won't have to be rippled through multiple files (currently Infobox_Item and Item_List). You can view the template in my Sandbox and see how it is used in Sandbox3. Unless there are objections I'll add it to Template:Infobox_Item and Template:Item_List.

While on the subject of DPS, is there any desire to color code item's DPS based on their elemental adds? I.E. DPS would be listed in blue for items with +cold damage. I think this could be useful when looking at item lists and can be easily added into the new DPS template I mentioned above. -Talkerst 18:29, 9 November 2011 (UTC)

You have to just be careful with colors since colors are already being used to designate rarity of an item, and if colors are too similar, they can become confusing. I would suggest we retain how this is displayed by Blizzard, which is currently without any additional color. -- Wynthyst User Wynthyst sig icon.png talk 18:56, 9 November 2011 (UTC)
Except Blizzard puts a nice little colored graphic around their elemental items. I like that but it's a little too complicated for the wiki. Was thinking colored DPS could serve the same function. Though I do agree that it could be confusing at first given that all the colors are used for other things elsewhere. Maybe some other way, like a little fire/ice/etc. icon next to the DPS? -Talkerst 19:32, 9 November 2011 (UTC)
HAHAHA! I really have to laugh at what you find complicated... -- Wynthyst User Wynthyst sig icon.png talk 22:58, 9 November 2011 (UTC)

Continued work on the categorization tree

I have spent the past couple days expanding and cleaning up the Category:Diablo III Skills tree. The tree is now organized as follows:

  • Barbarian Skills
    • Barbarian Active Skills
      • Fury Generator Skills
      • Fury Spender Skills
      • Situational Skills
    • Barbarian Passive Skills

  • Demon Hunter Skills
    • Demon Hunter Active Skills
      • Discipline Skills
      • Discipline Spender Skills
      • Hatred Generator Skills
      • Hatred Spender Skills
      • Offense Skills
    • Demon Hunter Passive Skills

  • Diablo III Follower Skills
    • Enchantress Skills
    • Scoundrel Skills
    • Templar Skills

  • Monk Skills
    • Monk Active Skills
      • Mantra Skills
      • Spirit Generator Skills
      • Spirit Spender Skills
      • Combo Skills (in the works, still working on the actual mechanics)
    • Monk Passive Skills

  • Witch Doctor Skills
    • Witch Doctor Active Skills
      • Mana Spender Skills
      • Physical Realm Skills
      • Spirit Realm Skills
      • Support Skills
    • Witch Doctor Passive Skills

  • Wizard Skills
    • Wizard Active Skills
      • Arcane Power Spender Skills
      • Armor Spells
      • Offensive Skills
      • Signature Skills
      • Utility Skills
    • Wizard Passive Skills

What other category separations would be helpful, that can be easily identified using the variables available on Template:D3 Skill? -- Wynthyst User Wynthyst sig icon.png talk 07:14, 10 November 2011 (UTC)

I'm not sure there are any more useful ways to categorize the skills based on that. We have level requirement (kind of pointless), resource cost(not really transferablle easily and not very useful) and cooldowns. --PhrozenDragon 20:34, 10 November 2011 (UTC)

Template Documentation

Currently our templates have minimal documentation at best. I'm going to try and update them to correct this. I was looking at implementing a document system similar to wikipedia and minecraft-wiki. You can see my first attempt in my Sandbox4. To get an idea how the documentation works you can view its documentation at User:Talkerst/Sandbox. The links in their don't exist yet because I have everything sitting in my sandboxes as apposed to their rightful locations. I also haven't crated nodoc and baddoc pages but those will come.

The big things I could use help/suggestions on is the look of documentation. Currently I'm sticking with the existing color scheme. Though, I don't know all the exact colors so I had to guess. If someone could point me to where they are stored I can make everything match up exactly or be a variation of what we are already using. We also have the option to go with a light background for the documents and have all the text be dark. This would require more work but isn't that hard. If there is a strong demand for a light background I'll do a mock-up. Also, the icon wikipedia uses doesn't work well with our dark scheme but we can always create a new one.

I also used headings in my example which produces a table of contents. It looks like wikipedia just uses enlarged text for the sections so this eliminates the TOC. Not sure which is better or if it's just a matter of taste. Though I think we should pick one and enforce it across all template documentation. -Talkerst 17:16, 11 November 2011 (UTC)

Looking very good Talkerst, I knew you'd do a good job with this.
  • Colors can be found in the style guide at the bottom. Though perhaps the help documentation should use a different color set, otherwise it might clash when we put templates inside the documentation. See http://en.wikipedia.org/wiki/Template:Navbox to see what I mean, the navboxes would look rather weird there if the background was also blue.
  • The text should saty the same, for uniformity's sake across the wiki, so the background color should conform to that.
  • On the topic of the style guide, check the entires on category and header names and the use of capital letters.
  • The icon I guess we could just recolor.
  • Wikipedia includes the magic word __NOTOC__, which removes the table of contents from a page. You can see all of them here: http://en.wikipedia.org/wiki/Help:Magic_words
  • Also remember that linebreaks get transcluded with the template, so any <noinclude> tags would have to be appened right after a template rather than on a new line. --PhrozenDragon 18:18, 11 November 2011 (UTC)
  • I updated the colors but I don't know what the sandy color is that header text uses. I think we should use that for the word 'Documentation' but since I didn't know the value I just used the one for crafted items. I dropped an infobox into my example and it looks fine to me. It's because we use a near black as the background in infoboxes. Let me know if you feel differently.
  • I can look into recoloring the icon into some shade of red this weekend. Might be cool to give the circular part little diablo horns but that's beyond my skill level. Might be too kitschy too.
  • I was mistaken, wikipedia does use headers and has TOC's in their documentation. Maybe minecraft-wiki didn't or the page I saw didn't. I think having the TOC's is fine.
  • In general line-breaks get transcluded but I thought blank lines at the end of a file didn't count. Only if they appear in-between stuff. Since the noinclude will get removed it will look like a blank end of line to the parser so it will just ignore it. That wording came straight from minecraft-wiki's so I'd be surprised if it caused bad behavior. -Talkerst 19:22, 11 November 2011 (UTC)
I would seriously prefer you avoid multiple template page documentation and would prefer you go more with the type of documentation found on the Official Guild Wars Wiki, where it's just included directly on the template page. -- Wynthyst User Wynthyst sig icon.png talk 19:45, 11 November 2011 (UTC)
Can you give the reasons for your preference? I'm sure both systems have their merits, though I haven't used either one of them enough to know. I'm prototyping the sub-page doc system because that is the one that was recommend to me by Phrozen. -Talkerst 19:59, 11 November 2011 (UTC)
This seems like a good system in practice, but it introduces some overhead. Who's going to update all the templates to use this method now? In addition, we will need to teach users how to follow this practice and also enforce it (if it is that important). Have those issues been addressed? --Apoc 20:07, 11 November 2011 (UTC)
Well, since I'm going to be looking at all the templates for places where they need documentation it wouldn't add any time to drop the new system into place. It also looks like you can create a /doc redirect to point people to the instructions for creating the document pages. Thus if we amend the style guide to say every template page should include <noinclude>{{/doc}}</noinclude> as the last line it should leave a breadcrumb to show new editors how to create the doc pages. At least that appears to be how the system works on other sites. -Talkerst 20:16, 11 November 2011 (UTC)
I have two words that I've been preaching to you since you started editing Talkerst, and you just aren't getting it.... OVER COMPLICATED. There is absolutely zero benefit to making this so complicated. Simply type out the instructions on how to use the template within <noinclude> tags directly on the template page. Simple. No need for instructions on how to create and use documentation, just simple usage documentation that any average wiki user can easily understand including a preformatted "copy this and paste it on the page you want to use it on" example, along with any specifics for variable usage. We have SO much other work to do here, and you are spending all your time on these complicated, need a manual to begin to understand templates. Just stick to the KISS (Keep It Simple Stupid) theory and things will be just fine. -- Wynthyst User Wynthyst sig icon.png talk 20:29, 11 November 2011 (UTC)
I asked Talkerst to look into how we could improve our template documentation in the wiki to make it more appealing and standardized, and I suggested looking at wikipedia and minecraftwiki to see how they'd handled it. The intended goal is to make all the templates we have in the wiki more easily accessible to all users.
The reason for having a /doc page in other wikis seems to be to allow the documentation to be edited by regular users while the template itself is protected. This is perhaps not necessary in our wiki, so moving the documentation to a template page itself should present no problem for the purpose of the documentation. It also seems as if this structure Talkerst has come up with can easily just be placed on the actual template page, thus allowing for easy copy-pasting of a pre-formatted structure to aid new visitors.
As for the colors, the header color is the one currently specified as Link Color#D49E43. Links no longer use that color however, so the information is out of data. --PhrozenDragon 17:09, 12 November 2011 (UTC)
I'm sorry if my reaction seems over the top, I felt the exact same way when it was simply "implemented" on the Minecraft wiki (without any notification or discussion, one second it wasn't there, the other it was on more than half the templates). I find it cumbersome, and so much more complicated than necessary. Very few of our templates need to be protected, unlike on Wikipedia, where they are dealing with thousands of templates, and hundreds of thousands of active editors, so the dual layer documentation just becomes another added step. I just want everyone to remember what the purpose of documentation is, make it easy for any user to understand how to use these tools we've created to make editing easier. EASY being the operative word. In my mind, EASY = SIMPLE. There are so many things we are working on here, with more coming every day, and a very limited number of people to do them (right now), I don't want to see any of us bogged down in needless complication. -- Wynthyst User Wynthyst sig icon.png talk 17:48, 12 November 2011 (UTC)
It looks like we've settled on a unified page approach. With that out of the way there were a couple things that I liked about wikipedia's documentation that aren't sub-page dependent. I wanted to see if there would be any benefit of doing any of the following:
  • I like the look and feel of User:Talkerst/Sandbox4 quite a bit better than Template:Weapon_DPS. Is visually differentiating documentation from normal pages useful?
  • nodoc and baddoc seem like useful abilities. It makes it easy for users to flag something that needs updating even if they are not comfortable performing the updates. Would something like this be useful here?
I can envision a stupidly simple template that would allow us to do either one or both of the above while sticking to the unified page system. That is if the above are considered useful for the general audience. -Talkerst 14:37, 14 November 2011 (UTC)
Both of those ideas are good to implement. The first provides an instant visual que that it is a help page, and it shoudl be easy to associate with how it looks on other wikis. The second is more useful in theory, as I don't think it's going to receive all that much use in the wiki, at least not at present. One could argue that without functions like these existing it's hard to know whether they're useful, so I'd say implement it and see how it works. --PhrozenDragon 23:26, 14 November 2011 (UTC)
Created a hybridized system that I think gives the best of both worlds. User:Talkerst/Documentation_Demo. Let me know what you think. The last thing to do would be choose colors for baddoc and nodoc. Normally they move the background towards red but that's a little harder to do on our red oriented site. I'll come up with something either way though I'm open to suggestions. Though honestly I don't care about the color that much, what I am more interested in is that it will drop them into categories so we can easily see which templates need doc updates. Unless I hear complaints in the next day or so I'm going to start rolling out with this system. -Talkerst 20:42, 15 November 2011 (UTC)
The Wikipedia images are not necessary, they add little benefit since you can barely see the pink one on the red background. -- Wynthyst User Wynthyst sig icon.png talk 11:31, 17 November 2011 (UTC)
Sorry for the late reply, it does seems good. The change in color doesn't seem to be a huge deal, perhaps just a text notice or similar could serve a similar function. --PhrozenDragon 21:44, 18 November 2011 (UTC)

Doc Rollout

I've started rolling out the new system. My plan is to first mark all templates that have no documentation. This will add them to Category:Templates with no documentation to make them easy to find for anyone who wants to create some for them. Personally I feel almost all templates should have some level of documentation but I can understand if very simple ones have none. I've attached nodoc to pretty much everything without something in it so we probably should decide how simple it needs to be before no documentation is necessary.

After I've marked all the nodoc's I'll start work on updating the documentation to use the new format and fill in holes where I can. For complicated ones that I don't fully understand and are incomplete, I'll mark them with the baddoc. This adds them to the Category:Templates with bad documentation category so others can easily find and update them. If people feel 'bad' is a user unfriendly term for incomplete documentation let me know and we can come up with a different descriptor. -Talkerst 15:34, 2 December 2011 (UTC)

Looks good. I updated the target categories to align with the Style Guide however. Bad seems like a good word, though perhaps Incomplete would be more descriptive?
Strictly speaking I think all templates should have a template description. The simplest template I can think of is Template:*, and that one could at least have a sentence explaining that the sole purpose of the template is to make lists with bullets look more cleaner in the code. How else is one to know that it isn't used for wiki-code sheenigans like Template:!? --PhrozenDragon 16:57, 2 December 2011 (UTC)
I had another thought. Many templats, such as Template:Locations, are really just variations of Template:Navbox2. We should probably just include a link in that documentation to say something along the lines of "This template is based on Template:Navbox2, and all documentation pertaining to this template will be located there." It doesn't make much sense to include identical descriptions for all navboxes and infoboxes that are just variations of two templates. --PhrozenDragon 16:36, 4 December 2011 (UTC)

Embedded Header at the Beginning of a List

Currently most long or multi-segmented lists do not use an embedded header at the beginning of each segment list in order to separate itself into a category or section such as Diablo 3 Weapons.
However there are pages in which there is a header already directly embedded into the beginning of a list segment such as Axe Affixes and Any of the class pages.

Now the reason I'm bringing this up is because even though the embedded header is more of a hassle to code in (1-4 lines of code usually) it really gives the table/list a professional look and makes the headers stand out more.
This also leaves a situation in what to do if the new way of doing headers with lists is implemented in that should only Diablo 3 pages and up be change almost signifying the modernization of the pages and the new game.

Now to provide an example and a direct correlation between the two styles; I have set up two multi-segmented lists showing both of these styles in use Embedded Headers and Normal Headers using my demo of the Formula lists.

I'll now leave this to be discussed as I'm interested on others opinions or views on this matter. Ebonmourn 03:01, 6 January 2012 (UTC)

As far as I understand it, what you feel is missing is that the current template for recipe lists doesn't include a header at the very top that covers the entire list? In the current format I have two concerns about this.
Right now using the list template is just about as easy as it gets, you just enter the name of whatever you want listed and it pops up, and adding a header is sraightforward use of basic == Header == wikicode.
The second concern is that we'll start to include headers into templates, which means that page structure will not be decided on the actual page, but on a template somewhere. In this one istance it's not a big problem, but it sets a precedent where we might end up with countless headers and templates.
I understand what you're getting at with the aesthetic appeal, but I don't believe including html headers into the template is a preferable path to take.--PhrozenDragon 00:04, 7 January 2012 (UTC)
Does embedding the header into the table permit the auto-compilation of the Table of Contents at the top of the page? The use of "== Header ==" also allows linking (/pagename#header). --Apoc 02:15, 7 January 2012 (UTC)
No, I think he's talking about having the red box w/centered text for the "category" headings rather than just plain lvl 3 headings. If you look at his example, that's what I'm seeing. I'm not sure I really care, the embedded headers need a little tweaking to look quite right imo. Either style serves the purpose it's intended to, to build the TOC, so it's more of an aesthetics issue. -- Wynthyst User Wynthyst sig icon.png talk 05:03, 7 January 2012 (UTC)
Yes, it is more of an aesthetics issue and I can also see how it could cause problems when pulling the table in from when it is a template with the layout already being decided on another page.
I just added a spacing line at the end of each table/list on the Normal Header page.. and it does makes it look more appealing and make it easier to read the header --Ebonmourn 06:15, 7 January 2012 (UTC)
Despite my hesitation over the future precedents this might create, I can agree that it's a more visually pleasing solution. As long as it's incorporated into the current template easily, preferably in the same template, I think we can try this out.
If you feel comfortable doing that modification yourself, I suggest you mess around with it in the sandbox and try it out. If not, I can incorporate it next week when I'll have more time to devote to this. --PhrozenDragon 22:47, 12 January 2012 (UTC)

Discussion about how to handle Recipes and their sub areas

Just to throw some numbers out, there are currently 159 Plans, 16 Designs, 241 Formulas... 416 total that are just from tombs/books the player has to get.
There are 142 Blacksmith Training, 36 Jeweler Training, 149 Mystic Training... that is 327 total recipes that are learned from training that the Craftsmen already have.

  • Should there be a separate/modified Item-display/Data-entry template for Recipes?
Yes, the item that they make works fine with the current setup/template (at least with the blacksmiths). However in the current templates there does not seem to be a field for:
  • Crafting materials they take
  • What level the craftsman has to be to learn it
  • How much gold does it take to craft the item
  • If its from a Plan/Design/Formula
  • If it can be learned from the trainer and so on.

Yes most of these ideas of what fields each type of recipe would need were taken from Blizzards site as I have yet to play the game/beta myself.

  • Blacksmith Recipes have an actual item so the display needs to support normal item quality like Name, Item quality, Required Level, Item Type, Slot, Materials, Cost to make, Blacksmith Level, and the source.
Less important is the Damage, Durability, Item Stats. Note: The Required level is the level to wear the item not make it.
  • Jeweler Recipes require Name, Materials, Cost to make, Jeweler Level, Source.
Less important to the items it makes are Stack Size, Stats, Required Level, Item type which is 'Gem'.
  • Mystic Recipes require Name, Materials, Cost to make, Mystic Level, Source, and Effect/stats it adds.
Less important would be Item type the enhancement effects.
Any thoughts on how to handle the item type that the Mystic Recipes make.. basically that it doesn't make an item it makes a Enchant effect that applies to the item.

Bringing this up as I'm not sure this has been discussed yet.--Ebonmourn 12:15, 10 January 2012 (UTC)

I don't quite understand what you're saying, do you mean that there should be two kinds of recipe pages? One for the recipe, and one for the item the recipe creates? --PhrozenDragon 23:05, 12 January 2012 (UTC)
Well... I suppose that is part of it. Like for example WoW.. you have the item 'Formula:Enchant Minor Brutality' which has all the mats, gold, profession level requirement on it (plus the 'item' stats) and then you have the actual spell/effect/item of 'Enchant Minor Brutality' which has all relevant data for the effect/item if that makes sense. Also there are only like maybe 20 (I didn't actually count its a guess) different enhancements with 5-7 variations. EX. Minor Brutality is always a +10-30% to Critical Hit Damage while Super Brutality is always + 55-57% to Critical Hit Damage both of these can be applied to 1Hs, 2Hs, Wands, and Bows.
The main point was that the current template for the data:items/ and the item list does not provide relevant information for the recipes only information that is relevant to the actual item.. basically there is no field for when your making a data page for recipes to enter in the level the craftsman needs to be or the amount of materials it uses to craft the item. which by the way formulas take dust from salvaging runes, 2-4 dust per enhancement
Last two notes Enhancements/Formulas are basically an extra affix and the hounding on the Formulas over the designs and plans is mainly due to the other two actually produce items while formulas produce an effect
If my point is still confusing please ask me to clarify and I'll try my best to.--Ebonmourn 14:21, 13 January 2012 (UTC)
Ok I see what you mean, but this does not require a new template, just expanding on the current item template. IF you take a look at Template:Item Display you will see a complete list of all stats that can be added to an item that uses either Template:Infobox Item or Template:Item List. If we want to we can add material costs, salvage materials etc. to the necessary templates and the existing List template, which you've been using, will work as intended. --PhrozenDragon 18:37, 15 January 2012 (UTC)
That would be awesome if you could do that when ever you have the time as I'm not quite comfortable messing around with the templates for item list or item display. As far as I understand if the stat can be added to the item being displayed then it has to follow the same order as the template such as Item Defense being listed before Item Durability. Also when it currently displays the recipes in the lists I have put together, it has the Source being '?' and the Req Lvl and Item Lvl are sort of irelevent is there a way to get them to not show, Source showing 'Crafted', or do they just show by default due to lack of other things to display? Ohh.. if I wanted to start adding new data pages for the items but don't know their item id# what is I to do? is it possible to leave it blank? granted a pain to go back and fix. --Ebonmourn 13:37, 30 January 2012 (UTC)
1: No the order the stats are listed in on that page have no bearing on in what order they appear on the actual, that can be changed. 2: They mostly show by default. "?" is automatically displayed unless a source (such as Blacksmith or Drop) has been specified. 3: Don't worry about the item ID, just put a "?" mark there instead for now. --PhrozenDragon 20:58, 31 January 2012 (UTC)

NPC Models

Some models are still buggy and missing parts. I don't feel that its providing much benefit and the broken models actually hurt the page appearance. Can we shelf this feature until it receives an update? --Apoc 18:12, 24 May 2012 (UTC)

I have no problem shelving the buggy ones, but I wouldn't expect it to get any updates. -- Wynthyst User Wynthyst sig icon.png talk 19:05, 24 May 2012 (UTC)

Strategy guides

Regarding strategy guides, I think we can probably setup a section for dedicated guides for "how-to" (level a class, farm items/gold/xp). For everything else we should just let people add suggestions to the appropriate item or monster page. Having a good how-to-write a guide page would also help. --Apoc 03:25, 29 May 2012 (UTC)

Citing Sources

I've been reading through a lot of the lore pages recently and updating their information and sources, and I came across the < ref > tag with something I hadn't seen in it before--this { { Booksource | Book name | Page number } } construct. Are there other "source" types, like if I wanted to cite in-game chat text or in-game books?

I also found myself citing books in the Diablo Archive--obviously, it's a compilation of books and not a book, itself, so should I be using the book I'm quoting from inside the archive with the archive page numbers? Unfortunately, I don't have the individual books contained in the old archive, only the Sin War books and MotS. --Magistrate 04:12, 2 June 2012 (UTC)

In-game chat doesn't need to be cited because almost everything in this wiki is dedicated to material in-game (assumed primary source). To cite online material that is off-site, just use <ref></ref> wrapped around the url. There are no other special citation methods that I'm aware of. I think it would be best to try to be as specific as possible when citing, so if you can use the individual book it's better - if not, probably not a big deal. (good to see your edits again - welcome back) --Apoc 06:10, 2 June 2012 (UTC)
Just to clarify on the sourcing part, the Booksource template hasn't included the Diablo Archive until now, but the material is identical to the other books, so I will include it in the template for future use. --PhrozenDragon 20:17, 4 June 2012 (UTC)
Oh, okay. Thanks for all the help, fellas :D --Magistrate 02:39, 5 June 2012 (UTC)

Alternate Platforms

  Before I embark on any indepth or meaningful endeavor on Diablo Wiki, I harbor some questions. After perusing a few topics, I am compelled to ask if Diablo Wiki is strictly dedicated to the PC version of Diablo III? I currently play the console version. In addition, I notice no referencing to Reaper of Souls or Rise of the Necromancer installments. 
  My knowledge and experience regarding console play of Diablo III, remains quite extensive. Henceforth, making this an honour and privilege to contribute, should console play content, discussions, strategies and other pertinents hold vacancy here. 
  An uncontrollable urge to share this knowledge, compelled me to join the Diablo Wiki community. However, I may have easily overlooked any content for console play that dwells here. If content for the console offering resides on the Wiki, can someone please direct me to that particular domain of the Wiki? Thank you.

Is it time for crossover to Fandom?

Hello everyone. I've been deliberately putting this off for a while, putting up the claim button to see if anyone would be interested in taking up a community admin role on their own initiative, but that hasn't happened yet. And so we're in an awkward spot, since there is next-to-no active editing community to speak of anymore. The wiki does still get a lot of views, but, in particular, the lack of community activity re: Diablo IV is not a promising sign for this wiki's future.

And since Gamepedia and Fandom have joined forces some time ago, the hour has come 'round at last that we open a discussion on crossover. How this would work is that this wiki would be archived. This means it would be placed in a read-only state, remaining available for readers, but there would be prominent messages referring visitors to the more active Diablo Wiki on Fandom. The [Battlefield 1 Wiki is an example of a Gamepedia that has already been archived.

I need to stress that crossover is voluntary. We won't be doing this unless there is widespread agreement in the community, and there is no timetable set for this currently. We're are just testing the waters at this point, so please add your opinion on this question here. OOeyes (talk) 22:01, 2 February 2020 (UTC)

It's been several months since this was proposed, and there have been no objections. The wiki remains largely empty of new edits. Therefore, we will be archiving this wiki as explained above by November 1st. You'll still be able to read all the pages, but not edit them. Visitors will see a banner pointing them to the Fandom wiki. If you have last-minute concerns to bring up, please do so here before that date! Mira Laime (talk) 16:54, 21 October 2020 (UTC)