Template talk:Item infobox/Archive 1
If we had parser functions we could make this work for any item, consumable or not, and be able to add or remove sections at will. At the moment I'm thinking about adding a cost parameter, but not until the if function is working so that it can be omitted for use in Trophy or Quest item articles. Same with value, but that is more useful in than out at the moment. - BeXoR 14:47, 25 February 2007 (EST)
- Bexor - just checking, did you intentionally change the code to require "image=" if over-riding the image name? It looks correct that way (the old way could cause problems in some cases), but the "usage" section doesn't reference that extra variable yet. --- Barek (talk • contribs) - 20:47, 13 March 2007 (EDT)
- Yes, I added the note in the revision summary that I did so. Emily had edited the template because her images were larger than normal, but most of the images around are smaller than 100x100 so I did what we have on the other templates - the option to manually set the image and thus, the width. It has helped on the creature articles because most humans end up taking up a lot of space vertically with the default width. I will copy over the usage section from one of the other templates later, but it's not required, so it can wait til I've had sleep. - BeXoR 20:57, 13 March 2007 (EDT)
Nice job!
I just wanted to say that the new layout of the template looks great! Good job guys, you all rock =) --Emily Diehl 16:16, 16 March 2007 (EDT)
- Having just spend 5 minutes marvelling at this template after I was astonished to find the ecto picture on the ecto page, but no picture being called, I have to agree with Emily: This is indeed a great template! --Xeeron 10:44, 22 May 2007 (EDT)
Replacement Template
I've created a replacement item template that auto-types, auto-categorises and allows for salvage information over at User:Indecision/Template. You can also see examples of the template in use at User:Indecision/Sandbox. I was hoping to overwrite this current template with the new one which provides enhanced functionality, in line with the proposed formatting of items. Please let me know if you think there will be any problems with the proposed new template, otherwise I will go ahead and copy it over to here sometime next week (week ending 5th April, 2007). --Indecision 08:34, 29 March 2007 (EDT)
- I like it in principle, I have no idea looking at the code if it would work or not :) once people start throwing if statements in there I get lost! --Lemming64 08:38, 29 March 2007 (EDT)
- I agree that it should be replaced with Indecision's template. As salvage information for trophies and salvagable items are essential to users and an important part of why those items are in the game in the first place. — Gares 08:47, 29 March 2007 (EDT)
- I replaced that template and found something which does not work correctly: see Identification Kit - template screw up if type is set and autotyping is in progress. - MSorglos 04:29, 30 March 2007 (EDT)
- The type is doubling up when ever you type in something, unless it is automatic for things like alcohol which works ok. --Lemming64 08:52, 30 March 2007 (EDT)
- Can someone fix the million line breaks that are pushing content down the page. - BeXoR 12:33, 30 March 2007 (EDT)
- I seem to have partially fixed it, where type is defined manually there are now less line breaks, I am unsure of the origin but when you don't specify a type and it has to autotype then you get many more line breaks. --Lemming64 12:41, 30 March 2007 (EDT)
- Do it yourself Bexor, it's a wiki afterall? ;) Nah, just joking. It's a complicated template.. I just looked at the code and then turned away, so much to mess up if I start editing the code. - Anja Astor 12:49, 30 March 2007 (EDT)
- I went to sleep so there was no chance of that. :P - BeXoR 23:39, 30 March 2007 (EDT)
- Can someone fix the million line breaks that are pushing content down the page. - BeXoR 12:33, 30 March 2007 (EDT)
- The type is doubling up when ever you type in something, unless it is automatic for things like alcohol which works ok. --Lemming64 08:52, 30 March 2007 (EDT)
- I replaced that template and found something which does not work correctly: see Identification Kit - template screw up if type is set and autotyping is in progress. - MSorglos 04:29, 30 March 2007 (EDT)
- I agree that it should be replaced with Indecision's template. As salvage information for trophies and salvagable items are essential to users and an important part of why those items are in the game in the first place. — Gares 08:47, 29 March 2007 (EDT)
Intergration
for the sake of not having to go through and fix about 100 infoboxes I have made two small adjustments to the image parameter so it matches what we had before more closely. --Lemming64 09:02, 30 March 2007 (EDT)
Still broken
Superior Identification Kit - BeXoR 22:34, 31 March 2007 (EDT)
- dammit indecision you make it looks so easy :P --Lemming64 06:10, 2 April 2007 (EDT)
- Sorry, was away at the beach for the weekend, so this was the first chance I had to look at it. Found the double up problem, was something silly I had done earlier to try and split the auto-type code from the display, but didn't work the way I intended. It also looks like someone fixed the linebreak problem, which would have probably been added when I attempted to add wiki-comments and broke the sections of the table apart :(. Please let me know if there are any other problems that people have found. --Indecision 06:15, 2 April 2007 (EDT)
- I tried to fix the line break thing, I partially did, but there is still quite a few of them happening. --Lemming64 06:26, 2 April 2007 (EDT)
- Can you provide me with specific links? I've been searching but I can't find examples. Also what part of the box is breaking, the type area, or other areas? --Indecision 08:17, 2 April 2007 (EDT)
- No the box is fixed now, the only thing still broken was the double type but you fixed that. examples of the line break phenomenon: Champagne Popper, Red Iris Flower, Birthday Present --Lemming64 06:43, 2 April 2007 (EDT)
- Those links appear fine to me now, Aspectacle made some minor edits to the template shortly after I posted that may have fixed the problem, either that or it may be browser compatibility (I'm using firefox). --Indecision 08:17, 2 April 2007 (EDT)
- I am also using firefox, you may notice that the text for the main articles is shunted 5-10 lines down the page even though it is hugged right up to the template. It is still like this for me. I had a look in IE too and it is even worse. --Lemming64 08:19, 2 April 2007 (EDT)
- I misunderstood the problem, thought you were referring to line breaks within the infobox. I've managed to isolate the problem, which seems to be that the auto-categorisation was adding additional linebreaks. I've used display:none to stop the categorisation text from line breaking, and the categorisation should still work. --Indecision 09:55, 2 April 2007 (EDT)
- Working here now, that's great, I thought it might be something to do with with the auto-type/categorisation code as when you didn't use that there was less breaks. --Lemming64 10:17, 2 April 2007 (EDT)
- I misunderstood the problem, thought you were referring to line breaks within the infobox. I've managed to isolate the problem, which seems to be that the auto-categorisation was adding additional linebreaks. I've used display:none to stop the categorisation text from line breaking, and the categorisation should still work. --Indecision 09:55, 2 April 2007 (EDT)
- I am also using firefox, you may notice that the text for the main articles is shunted 5-10 lines down the page even though it is hugged right up to the template. It is still like this for me. I had a look in IE too and it is even worse. --Lemming64 08:19, 2 April 2007 (EDT)
- Those links appear fine to me now, Aspectacle made some minor edits to the template shortly after I posted that may have fixed the problem, either that or it may be browser compatibility (I'm using firefox). --Indecision 08:17, 2 April 2007 (EDT)
- No the box is fixed now, the only thing still broken was the double type but you fixed that. examples of the line break phenomenon: Champagne Popper, Red Iris Flower, Birthday Present --Lemming64 06:43, 2 April 2007 (EDT)
- Can you provide me with specific links? I've been searching but I can't find examples. Also what part of the box is breaking, the type area, or other areas? --Indecision 08:17, 2 April 2007 (EDT)
- I tried to fix the line break thing, I partially did, but there is still quite a few of them happening. --Lemming64 06:26, 2 April 2007 (EDT)
- Sorry, was away at the beach for the weekend, so this was the first chance I had to look at it. Found the double up problem, was something silly I had done earlier to try and split the auto-type code from the display, but didn't work the way I intended. It also looks like someone fixed the linebreak problem, which would have probably been added when I attempted to add wiki-comments and broke the sections of the table apart :(. Please let me know if there are any other problems that people have found. --Indecision 06:15, 2 April 2007 (EDT)
Optional parameters
After talking to Indecision I've learnt that if you leave the "gold" or "salvage" attributes blank they default to saying that the item cannot be sold and cannot be salvaged, respectively. I don't think this behaviour is ideal.
If I decide to start an article on an item but I don't know how much it costs, what value should I give the gold parameter? Leaving it blank will say "cannot be sold" which will no doubt mislead readers. Any other value would be incorrect. It would make most sense if I could leave it blank and have the line for gold omitted from the article.
I realise there are items that cannot be sold, such as quest items, but I think that these should be differentiated based on a separate parameter, such as "quest-item". LordBiro 09:26, 12 April 2007 (EDT)
- Just to clarify the exact behaviour of the infobox params in question atm is:
- value
- omitted then displays Value / Can't be sold
- blank then displays Value /
- common&raresalvage
- omitted then does not display the row.
- blank then does not display the row.
- value
- The way I see it at the moment is we could do following to this template:
- Set value to behave as a true optional parameter (i.e. same as common&rare salvage) with questitem setting it to display Can't be sold. This would remove the need for the bundle parameter (which just removes value anyway).
- Also, it would be a good idea (in my opinion at least) if we could expand and neaten Guild Wars Wiki:Formatting/Items, so that we know exactly what this infobox will be used for and how (in an ideal world :)). --Indecision 02:15, 13 April 2007 (EDT)
Template Tidying
I've tidied up the template a touch and made value an optional parameter. Feel free to alter/revert as needed. --Indecision 23:27, 13 April 2007 (EDT)
cost
perhaps there should be a cost parameter instead of a value parameter for items you can buy at a merchant for example salvage kits etc. --Lemming64 20:03, 22 April 2007 (EDT)
Categorization
Currently, the template is miscategorizing consumable various consumable items as [[category:kits|kits]]. --The preceding unsigned comment was added by User:Gordon Ecker .
- Originally, I thought that the uses parameter would only be Kits, to save people from putting uses = 1 in consumable items. As people seem to have started using it for consumables, I've removed the auto-categorisation by the uses parameter. Let me know if there are any other problems you find. --Indecision 01:05, 24 April 2007 (EDT)
I think this needs an autotype/auto-category for Monstrous Claw, along the lines of Monstrous Fang. --BramStoker 12:17, 5 May 2007 (EDT)
code = crap ?
between:
<!-- Start:Auto-typing Code --> <!-- End:Auto-typing Code -->
you have this code:
{{ #if: {{{alclevel|}}}|{{{type|[[Alcohol]]}}} | {{ #if: {{{questitem|}}}|{{{type|[[Quest item]]}}} | {{ #if: {{{collector|}}}|{{{type|[[Trophy]]}}} | {{ #if: {{{commonsalvage|}}}|{{{type|[[Salvage item]]}}} | {{ #if: {{{raresalvage|}}}|{{{type|[[Salvage item]]}}} | {{ #if: {{{uses|}}}|{{{type|[[Kit]]}}}|{{{type|Not specified}}} }}}}}}}}}}}}
it is absolutly the same like:
{{ #if: {{{alclevel|}}}|[[Alcohol]] | {{ #if: {{{questitem|}}}|[[Quest item]] | {{ #if: {{{collector|}}}|[[Trophy]] | {{ #if: {{{commonsalvage|}}}|[[Salvage item]] | {{ #if: {{{raresalvage|}}}|[[Salvage item]] | {{ #if: {{{uses|}}}|[[Kit]]|Not specified }}}}}}}}}}}}
u cant set a value to a parameter like that...look here and here. (Sandbox pls hurry :) )
i hope anyone can tell me where iam wrong. greetings --Flece 12:06, 9 May 2007 (EDT)
- Umm... Yeah. On your version, you got rid of the part where it sets the type parameter, which is why it's broken. The first version works, and that's a pretty major difference between the two of them =P They are not "absolutly the same." MisterPepe talk 12:08, 9 May 2007 (EDT)
- Do u see my testing in the last 2 links and have a look at the code ? i see no differenc --Flece 12:19, 9 May 2007 (EDT)
- Try calling it with the correct parameter (i.e. quest=Gwen's Cape) and you'll see the difference. MisterPepe talk 12:23, 9 May 2007 (EDT)
- (Edit conflict) I hope my second testing makes clear what this code produces: in original, if type is set, this type is displayed, ignoring autocategorisation. in your example, type is overridden by autocategorisation. - MSorglos 12:25, 9 May 2007 (EDT)
- Ok thx, now i see my mistake. u can override the type, but u cant use the value in the parameter "type" in another place in the template...but thats it what i want to try :( thx for helping me. greetings --Flece 12:36, 9 May 2007 (EDT)
- (Edit conflict) I hope my second testing makes clear what this code produces: in original, if type is set, this type is displayed, ignoring autocategorisation. in your example, type is overridden by autocategorisation. - MSorglos 12:25, 9 May 2007 (EDT)
- Try calling it with the correct parameter (i.e. quest=Gwen's Cape) and you'll see the difference. MisterPepe talk 12:23, 9 May 2007 (EDT)
- Do u see my testing in the last 2 links and have a look at the code ? i see no differenc --Flece 12:19, 9 May 2007 (EDT)
incorporating upgrade components
there's been some discussion here regarding the incorporation of runes and insignia (and inscriptions while they're at it b/c i want to start on those at some point) into the item infobox. the problem is that the code here is complicated enuf that the ppl discussing it are afraid of or apathetic about actually doing the incorporation. so if someone could help out and incorporate these items, it would be greatly appreciated. whoever can do this might want to consider incorporating weapon infoboxes also, so we can just have 1 generic item infobox. --VVong|BA 16:22, 26 June 2007 (UTC)
Salvage items
How should we distinguish stackable salvage items from salvage armor? -- Gordon Ecker 06:54, 4 July 2007 (UTC)
Quest item
Says "when the quest item parameter is left blank" - where's the quest item parameter? - BeX 06:19, 20 July 2007 (UTC)
- Nvm I just can't read.. :( - BeX 06:22, 20 July 2007 (UTC)
Auto-cat is stupid!
Why do we have to type the plural i.e. [[Bolt of Cloth|Bolts of Cloth]] or [[Tanned Hide Square]]s etc in order for the infobox to auto-categorize? Wouldn't it just make more sense to just use the shorthand of a material, so that there is no need for the distinction between singular and plural? Some salvage items only return one piece of material. - BeX 10:37, 24 September 2007 (UTC)
- I originally implemented it that way because it didn't seem to make sense in the singular, and to encourage a unified look over all item pages. There's probably a few ways to handle it: simply add extra code to the auto-cat for the singular and shorthand forms of materials (which will mean some pages will have the shorthand, and others the long), or change the formatting guide to use the short-handed form and update the auto-cat accordingly, or remove the auto-cat entirely :). Also, I should probably poke Biro into trying to fix the CSS based item infobox we looked at implementing, and split the auto-cat/auto-type into sub-templates in line with: User:Indecision/Sandbox/ItemInfobox and User:LordBiro/Item_infobox. --Indecision 11:02, 24 September 2007 (UTC)
- When I looked at the formatting it didn't say which form of the material to use, so neither is incorrect atm. I don't think singular or plural would be correct in 100% of cases, but shorthand would, because it is referring to a type or salvage result, if you can see the context there. - BeX 11:03, 24 September 2007 (UTC)
- Yep I can (by shorthand I take it you mean Cloth instead of Bolts of Cloth etc...), and I'd be happy to change it, but at the same time I'd like to get the CSS separated version working as well... and split the auto-cat functionality into another template, to cut down on the length of code currently in the item infobox. At the same time is there anything else you (or others for that matter), would like changed about the formatting guideline and/or the infobox itself? Might be a good idea to try and hit everything on the head at once. :). --Indecision 11:10, 24 September 2007 (UTC)
- I can't think of anything atm cause I'm braindead, but you should ask Anja, I'm sure she knows of something! - BeX 11:12, 24 September 2007 (UTC)
- Just to quickly check, I take it we'd be using the short-hands in use at Category:Contains_common_crafting_material and Category:Contains_rare_crafting_material? Cause I just made those up when I was sorting out the categories :). Also if we're going to overhaul it a bit, I suppose I could work on supporting multiple materials auto-categorisation at the same time. I'll drop a note on Anja's talk page as well. --Indecision 11:20, 24 September 2007 (UTC)
The only thing I can think about atm is that we were going to implement runes into the infobox also. You can see my proposal over here and the infobox change here. I'll take the time to look things over and see if there's something else that needs addressing, that I've forgotten :) - anja 12:52, 24 September 2007 (UTC)
- Polymock piece box needs to be merged also. - BeX 02:58, 26 September 2007 (UTC)
- With my recent *ahem* mistake on the npc infobox, I'm wondering whether it would actually be safer to split the infoboxes into more specific types, to reduce the impact of an edit on it. So if I have runes infobox separate from item infobox, a change to the rune infobox won't affect all the non-runes. Whereas if merged, one single edit specific to a particular type needlessly affects all of them. -- ab.er.rant 05:13, 26 September 2007 (UTC)
- I like the centralized templates for all topics - it means that there are fewer things you need to learn about, and after this I don't think too many further edits would need to be made. And with the recent suggestion to change the job queue it probably wont be a problem anyway. - BeX 06:04, 26 September 2007 (UTC)
- I like your proposed change Anja, mostly because it solves the problem of Disambiguation Hell!. --Lemming 09:01, 28 September 2007 (UTC)
- I like the centralized templates for all topics - it means that there are fewer things you need to learn about, and after this I don't think too many further edits would need to be made. And with the recent suggestion to change the job queue it probably wont be a problem anyway. - BeX 06:04, 26 September 2007 (UTC)
- We could just state a value range from 25-100 and have it explained in the rune article. Or maybe take on the guild wiki system with no individual pages at all :P - anja 11:22, 28 September 2007 (UTC)
So can we have some show of preference of either redirecting all those individual rune articles to Rune, or to keep the individual pages and use Anja's suggestion plus poke's suggestion for the value? -- ab.er.rant 15:12, 4 October 2007 (UTC)
- I would actually prefer them all redirecting to "Rune". There's so little to say about each rune. - anja 15:14, 4 October 2007 (UTC)
- It seems the decision to make them all individual articles in the first place never really had any discussion. However I would be happy to see the minor major sup forms combined, but I have grown to like having the articles. --Lemming 15:26, 4 October 2007 (UTC)
- I would like to see each rune type on it's own page but with one combined page for them (like Anja's example) poke | talk 16:48, 4 October 2007 (UTC)
- Ok, so we'll replaced the disambiguation pages with a combined rune page and make all the existing ones redirect to that one. So example, is all the "Ranger Rune of <ranger attr>" will all redirect to "[[Rune of <ranger attr>]]" instead. And only the combined rune page will have Category:Runes. I'm itching to get this resolved :) -- ab.er.rant 10:53, 5 October 2007 (UTC)
- I would like to see each rune type on it's own page but with one combined page for them (like Anja's example) poke | talk 16:48, 4 October 2007 (UTC)
- It seems the decision to make them all individual articles in the first place never really had any discussion. However I would be happy to see the minor major sup forms combined, but I have grown to like having the articles. --Lemming 15:26, 4 October 2007 (UTC)
Parameters
Can we have a "Stackable" parameter? Backsword
- Hmm. Weapons have their own infobox, so which unstackables do that leave? Backsword 14:04, 4 December 2007 (UTC)
insignia infobox
since the rune infobox was incorporated here, should the insignia infobox be incorporated also? --VVong|BA 16:34, 28 November 2007 (UTC)
- Probably. Major undertaking, so you might want to ask those involved in the rune project. Backsword 14:05, 4 December 2007 (UTC)
can u tell me where to look or who to bug? i tried Guild_Wars_Wiki:Projects/Runes and "rune" and "insignia" but all were blank... would bex be in charge of that?heh, all i had to do was read a couple sections above... =P. --VVong|BA 14:26, 4 December 2007 (UTC)
image icons and some other ideas.
Like in the armor template, i'd like to add images icons to this template. Besides the information about the invetory appearance, these items could also be used, like the skill icon template and the npc location template in one, to create an item icon template. Like this, we could add a list of item skins certain monsters can drop on their pages - neatly arranged like the skills. additionally, the template could also automatically add all these item skins into new cathegories like Category:Drops Fiery Dragon Sword. Like that, one would have an overview which monsters can drop the item skin wanted. :) —ZerphaThe Improver 14:45, 3 December 2007 (UTC)
- Are you suggesting this only for the rarer weapons? The list for the common weapons is going to be huge... -- ab.er.rant 23:45, 3 December 2007 (UTC)
- It will be especially useful for rare weapons. But we can all drag them out of gw.dat . they can be simply be saved as .pngs and uploaded as [Item Skin] Icon.png. i don't think that's a too big problem. it's a wiki, if an image is missing thats not uploaded yet, anyone may do so. :> All we actually need is to upload the pictures. If the template is programmed right, it will simply add every monster to the weapon's cathegory if one uses it. I could then also add a uniform template for the list of drops. At best like this:
==Items dropped== <!-- when applicable, list alphabetically with {{tl|Item Icon}}. --> ===[[Trophies]]=== <!-- list collectable drops here. --> * {{item icon|Stone Summit Emblem}} etc... ===[[Salvage Item]]s=== <!-- list salvagable drops here. --> * {{item icon|Stone Summit Armor}} etc... ===[[Crafting material]]s=== <!-- list dropped crafting materials here. --> * {{item icon|Bolt of Cloth}} etc... ===Item [[Skin]]s=== <!-- list dropped weapons skins here. --> * {{item icon|Summit Axe}} etc
- —ZerphaThe Improver 13:57, 4 December 2007 (UTC)
- Think this is a great idea. Both for utility and consistency. But it's a lot of work and I'd hate to see it left half done. Backsword 14:20, 4 December 2007 (UTC)
- Well, i could upload all pics i find in GW.dat when i've got nothing diffrent to do in the holidays. —ZerphaThe Improver 15:04, 4 December 2007 (UTC)
- But then please
Image:Name icon.png
instead ofIcon
poke | talk 15:05, 4 December 2007 (UTC)- well, i was intended to do so :) see above: "...[Item Skin] Icon.png...". That with "Image:" for sure. —ZerphaThe Improver 15:38, 4 December 2007 (UTC)
- He meant the "i" in icon, not the "i" in image. Use lower case where appropriate. So
Image:Name icon.png
, and also{{Item icon}}
, and "Salvage items", and "Item skins" :) -- ab.er.rant 05:34, 5 December 2007 (UTC)- lower case? ah ok. so it should always be used instead of capitals if not written big ingame? —ZerphaThe Improver 12:44, 5 December 2007 (UTC)
- The case crusade insists it should always be written in lowercase. Even if in uppercase ingame. Rule of thumb: there are no proper nouns in the game. Backsword 12:52, 5 December 2007 (UTC)
- lower case? ah ok. so it should always be used instead of capitals if not written big ingame? —ZerphaThe Improver 12:44, 5 December 2007 (UTC)
- He meant the "i" in icon, not the "i" in image. Use lower case where appropriate. So
- well, i was intended to do so :) see above: "...[Item Skin] Icon.png...". That with "Image:" for sure. —ZerphaThe Improver 15:38, 4 December 2007 (UTC)
- But then please
- Well, i could upload all pics i find in GW.dat when i've got nothing diffrent to do in the holidays. —ZerphaThe Improver 15:04, 4 December 2007 (UTC)
- Think this is a great idea. Both for utility and consistency. But it's a lot of work and I'd hate to see it left half done. Backsword 14:20, 4 December 2007 (UTC)
I just added an icon to Holy Vial (never saw this discussion). Do you think that would be sufficient, or does it need to be in the infobox? - anja 18:51, 13 December 2007 (UTC)
- Ah, here you answered :P (maybe you want to read my other response here. As I said, I'd advice to put it into the box, as (except for bundles) every Item has a corresponding icons. (non-weapon stuff like quest items already use item icons as their image atm. They could instead then also use their icon where the weapons will get it. it's another thing, but i also wanted to mention it as it'd suit in the scheme) —ZerphaThe Improver 00:44, 15 December 2007 (UTC)
AlcDur
Planing to remove this. We now know that this is not how al cohol works. Just causing misunderstandings and strife. Backsword 14:07, 4 December 2007 (UTC)
- that means, this "up-to-five-levels" theory that give 1 point every minute to the title if the level dropped from 3 to 2 or more, is wrong?? —ZerphaThe Improver 14:51, 4 December 2007 (UTC)
- As far as I understand you, no, that's exactly why it's wrong. Items have no inherrent duration, it's all about the total level. Backsword 15:16, 4 December 2007 (UTC)
- what i thought was: there are levels from 1 to 5. every minute, if you have got a level, it shrinks by one. if it shrinks from 5 to 4, from 4 to 3, or from 3 to 2, you will get 1 point towards the drunkard title. Common alcohol adds one level, but firewater adds 3 and old dwarven ale and eggnog add 5 levels. that means, you can start with an eggnog to get immediately to level 5, and then drink a flask of firewater every three minutes to get up to 5 again, or simply common alcohol every minute. —ZerphaThe Improver 15:29, 4 December 2007 (UTC)
- That's right, which is why intoxication duration is independent of specific items. Backsword 15:32, 4 December 2007 (UTC)
- (Edit conflict) wait! you're speaking of the dur all the time. x( yes sure, i never understood for what this line was for...this really only causes misunderstandings. how long it would last if you use only one of a certain type...you can think this yourself. i also agree to remove this. —ZerphaThe Improver 15:34, 4 December 2007 (UTC)
- what i thought was: there are levels from 1 to 5. every minute, if you have got a level, it shrinks by one. if it shrinks from 5 to 4, from 4 to 3, or from 3 to 2, you will get 1 point towards the drunkard title. Common alcohol adds one level, but firewater adds 3 and old dwarven ale and eggnog add 5 levels. that means, you can start with an eggnog to get immediately to level 5, and then drink a flask of firewater every three minutes to get up to 5 again, or simply common alcohol every minute. —ZerphaThe Improver 15:29, 4 December 2007 (UTC)
- As far as I understand you, no, that's exactly why it's wrong. Items have no inherrent duration, it's all about the total level. Backsword 15:16, 4 December 2007 (UTC)
Helper Templates
Just a quick change that I've been meaning to promote for a while which is the use of helper templates. These helper templates would handle the auto-typing and auto-categorisation code in a separate template, essentially converting this:
| <!-- Start:Auto-typing Code -->{{ #if: {{{alclevel|}}}|{{{type|[[Alcohol]]}}}
| {{ #if: {{{questitem|}}}|{{{type|[[Quest item]]}}}
| {{ #if: {{{collector|}}}|{{{type|[[Trophy]]}}}
| {{ #if: {{{commonsalvage|}}}|{{{type|[[Salvage item]]}}}
| {{ #if: {{{raresalvage|}}}|{{{type|[[Salvage item]]}}}
| {{ #if: {{{uses|}}}|{{{type|[[Kit]]}}}|{{{type|Not specified}}}
}}}}}}}}}}}}<!-- End:Auto-typing Code -->
To this:
| {{{type|{{ Item infobox autotype|a={{{alcohol|}}}|q={{{questitem|}}}|s={{{commonsalvage|}}}{{{raresalvage|}}}|u={{{uses|}}} }} }}}
My main concern with this is possible performance issues with nested templates. It may also be possible to accomplish something similar using the variables extension although I haven't explored this yet. This method is even more useful for the auto-categorising features of the item and weapon infoboxes as it removes large amounts of code from the main template. The method enables the main templates to be updated/edited without having to wade through the auto-type/cat code. It also allows these helper templates to be edited and updated separately, which should promote understanding of their function. In essence this is a move towards modularity.
Please let me know what you think.
--Indecision 16:04, 11 December 2007 (UTC)
- I plan to rework the categorizations of some infoboxes after I finished the Weapon stats template. I think the Variables Extension would work really good for auto-categorization issues but I still need to do some research on it. poke | talk 16:06, 11 December 2007 (UTC)
- Heh, I'm quite happy to leave the grunt work to you poke, I remember working on these when they were just starting out and that was frustrating enough :). Feel free to blame any unneeded complexity on me, or contact me on my user page if you want to ask a question (such as what the hell were you thinking? :) )--Indecision 16:16, 11 December 2007 (UTC).
strange appearance
i'm not sure what's going on, but whenever i attempt to view this template, in its current revision it appears to be vandalized. but when i view the diff page between my revision and aspectacle's, there's no difference. i also know the infobox is working b/c the item pages work. is anyone else seeing this? --VVong|BA 22:14, 14 December 2007 (UTC)
.png
Why .png images? Granted they are usually of better quality but also heaps larger in filesizes than a .jpg.
- Sorry, nevermind that... - nian 13:54, 1 February 2008 (UTC)
render image naming
Isn't the "render" suffix in the name redundant? The inventory icon uses a .png file, the render a .jpg file. So it should better be:
([[Image:{{PAGENAME}}.jpg|100px]]
(We already had a quite similar discussion on the Inventory icons project and ended up using the same names for both pics. (I also asked the same question on The Polymock piece infobox template talk)) —ZerphaThe Improver 13:09, 11 March 2008 (UTC)
- It doesn't really matter for the most part, but you are probably right. --Lemming 22:32, 11 March 2008 (UTC)
Miniatures
They are stackable? 0.ô Likely not. May i change the infobox for them? (Or anyone else that want to do this) —ZerphaThe Improver 17:00, 27 April 2008 (UTC)
- They aren't stackable that is certain. --Lemming 17:05, 27 April 2008 (UTC)
- I changed it now. But some minipets are displayed as stackable, though. The Miniature Hydra for example...but i suppose that's a wiki bug, because if i only push the preview button without changing anything, the Stackable parameter is set to "No" instead. —ZerphaThe Improver 17:46, 27 April 2008 (UTC)
- Or should we completely remove the Stackable parameter for miniatures instead? —ZerphaThe Improver 17:47, 27 April 2008 (UTC)
- That's just the job queue being slow. It'll refresh soon enough. -- Brains12 \ Talk 17:49, 27 April 2008 (UTC)
- Are you sure it's a cache problem? Miniature Raptor is still categorised as stackable. I think it's a logic bug. And once fixed, the stackable category needs to be documented like the other auto-categories. -- ab.er.rant 10:01, 29 April 2008 (UTC)
- I changed it now. But some minipets are displayed as stackable, though. The Miniature Hydra for example...but i suppose that's a wiki bug, because if i only push the preview button without changing anything, the Stackable parameter is set to "No" instead. —ZerphaThe Improver 17:46, 27 April 2008 (UTC)
Category:Stackable items
I noticed i forgot to change the category for unstackable items as well. What do you think would suit best as name for this category? Category:Unstackable items or Category:Not stackable items? —ZerphaThe Improver 16:48, 29 April 2008 (UTC)
- Well unstackable is not actually a word in the English language, so I think we should stay away from that. You could have Non stackable items --Lemming 16:55, 29 April 2008 (UTC)
- neologism ftw :P Wouldn't "Non-stackable" normally be written with a hyphen? (like Category:Non-collector trophies? (though this category has to be renamed anyways)) —ZerphaThe Improver 17:37, 29 April 2008 (UTC)
- I couldn't say for certain on the hyphen, my grammar is rubbish. --Lemming 18:24, 29 April 2008 (UTC)
- I don't like hyphen in words anyways, but we should rather do this than using my first proposal. (Yet i still don't think a negated wordform would be a great deal :P) —ZerphaThe Improver 20:23, 29 April 2008 (UTC)
- I think "not stackable" seems better than "non stackable", since "stackable" is an adjective, unlike "collector trophy" which is a noun. -- ab.er.rant 04:06, 30 April 2008 (UTC)
- Well, the prefix "non-" can also be used on nouns afaik, but if you think "not stackable" is better, you may change it if you want, i'd also prefer this name actually. —ZerphaThe Improver 19:06, 30 April 2008 (UTC)
- I think "not stackable" seems better than "non stackable", since "stackable" is an adjective, unlike "collector trophy" which is a noun. -- ab.er.rant 04:06, 30 April 2008 (UTC)
- I don't like hyphen in words anyways, but we should rather do this than using my first proposal. (Yet i still don't think a negated wordform would be a great deal :P) —ZerphaThe Improver 20:23, 29 April 2008 (UTC)
- I couldn't say for certain on the hyphen, my grammar is rubbish. --Lemming 18:24, 29 April 2008 (UTC)
- neologism ftw :P Wouldn't "Non-stackable" normally be written with a hyphen? (like Category:Non-collector trophies? (though this category has to be renamed anyways)) —ZerphaThe Improver 17:37, 29 April 2008 (UTC)
Reviving this discussion a little -- "Category:Not stackable items" doesn't really make sense. I preferred "non-stackable items", but seeing as you don't want that, how about "Category:Items that stack" and "Category:Items that don't stack"? Or whatever else sounds better than "not stackable items". (Sorry about the late response/revival, only just noticed now.) -- Brains12 \ Talk 20:09, 5 May 2008 (UTC)
- no problem. Well, i didn't dislike "Category:Non-stackable items that much. Yeah, i'm not a fan of hyphenated words, but I'd still prefer this name to "Category:Items that stack" or "Category:Items that don't stack", as i'd like to keep the word "stackable" in the categories, which describes this feature at best, and is most likely also the best known word. If you want to, you may create Category:Non-stackable items again and delete Category:Not stackable items, or you may want to wait for another proposal. —ZerphaThe Improver 20:16, 5 May 2008 (UTC)
- Well, "Non-collector trophies" (yes, it should be renamed too) doesn't really make much sense if you take it in an English context, and there's no elegant way of writing a proper term without making it unnecessarily long. Does "Not stackable" not make sense from an English point of view or does it not make from a GW point of view? We can properly explain what it means in the category page. Putting in a hyphen when the general convention is to avoid punctuation in names should really only be done when there's no workable alternative. -- ab.er.rant 17:19, 30 May 2008 (UTC)
- It doesn't make sense grammatically. The one that makes the most sense to me would be "Items that don't stack", but that would also require changing stackable items to "Items that stack". That's probably not consistent with other categories, but I don't think "Not stackable items" is best for this one. -- Brains12 \ talk 17:23, 30 May 2008 (UTC)
- The proper way to negate an adjective in English is with "Non-". "Not stackable" would be for a predicate adjective "X is not stackable" where one has a verb assigning the description to the object, and thus the "not" is used because it connects the verb and predicate adjective better due to flowing both ways ("is not stackable" and "is not stackable"). Since there's no verb in a category name, though, "non-" is preferred. (Aiiane - talk - contribs) 17:29, 30 May 2008 (UTC)
- Well, "Non-collector trophies" (yes, it should be renamed too) doesn't really make much sense if you take it in an English context, and there's no elegant way of writing a proper term without making it unnecessarily long. Does "Not stackable" not make sense from an English point of view or does it not make from a GW point of view? We can properly explain what it means in the category page. Putting in a hyphen when the general convention is to avoid punctuation in names should really only be done when there's no workable alternative. -- ab.er.rant 17:19, 30 May 2008 (UTC)
- You know, it would be simpler if we just forget about this "negating" category, since we don't really need it, kinda like a "non-salvage items". It's just a personal dislike for using hyphens in the category names unless I really have to. I don't really like "<profession>-related" categories either but no one raised a section to ask about them :) Just treat it like a weak oppose from a foggy mind (it's currently 2am here and I woke up at 6:30am). As Zerpha said, it's dragged on for a while so if someone "ninjas" it, I don't think I'd notice, heh. -- ab.er.rant 17:49, 30 May 2008 (UTC)
new template for bundles?
they aren't actully items, and have diffrent characteristics than all the actual item types. Creating a template for them is preferable i think. —ZerphaThe Improver 19:09, 30 April 2008 (UTC)
- I was thinking the same thing when I created the Charr Explosive page. For example, does the "stackable" property even apply to them as they must be carried? Mohnzh say what? 19:15, 30 April 2008 (UTC)
- yeah, that's one of several problems, as the rework for the render parameter adds their images twice, as their their default image file is .png, though it has to be changed to .jpg always as there aren't icons for these Bundles. Instead we could add special parameters for bundles, e.g. what effect a player gets while holding it, and what happens when dropping it. (Risky recently made a list of these unseen "bundle skillls", creating them comes conventient for those bundles.) —ZerphaThe Improver 19:22, 30 April 2008 (UTC)
- here it is. I added everything that crossed my mind when leaving through their category, the template should yet be ready for use on the bundle pages. —ZerphaThe Improver 20:37, 2 May 2008 (UTC)
- yeah, that's one of several problems, as the rework for the render parameter adds their images twice, as their their default image file is .png, though it has to be changed to .jpg always as there aren't icons for these Bundles. Instead we could add special parameters for bundles, e.g. what effect a player gets while holding it, and what happens when dropping it. (Risky recently made a list of these unseen "bundle skillls", creating them comes conventient for those bundles.) —ZerphaThe Improver 19:22, 30 April 2008 (UTC)
Stackable/Not Stackable
There are way too many exceptions to the rule that Salvage items are not stackable for this to be a workable autocategorization. At least not one that for whatever reason overrides any attempt to change it with the Stackable parameter. I'm not sure how to fix this, so can someone who does take a look please? this is one I was trying to get moved into Category:Stackable items that refused to budge no matter what I did.-- Wynthyst 06:13, 29 May 2008 (UTC)
- Tried to turn it a bit, and seems to work now. But as always, i must have screwed something somewhere, so better keep an eye on it for a while XD.--Fighterdoken 08:32, 29 May 2008 (UTC)
- Thanks Fighterdoken, the pages appear to be showing correctly now, but the category lists are still wrong. This may be a cache issue though, so I will just leave it until tomorrow.-- Wynthyst 08:36, 29 May 2008 (UTC)
- Yup, it's just a cache issue. Simply use the long url format with the &action=purge paramenter to check if they work as intended.--Fighterdoken 08:39, 29 May 2008 (UTC)
- Is stackable supposed to default to true for quest items? -- Gordon Ecker 23:08, 28 August 2008 (UTC)
- IMO the stackable parameter should default to unknown and put the item into a category such as "items with unconfirmed stackability", and items which aren't stackable should be categorized as "non-stackable items" rather than "not stackable items". -- Gordon Ecker (talk) 05:53, 16 November 2008 (UTC)
- Is stackable supposed to default to true for quest items? -- Gordon Ecker 23:08, 28 August 2008 (UTC)
- Yup, it's just a cache issue. Simply use the long url format with the &action=purge paramenter to check if they work as intended.--Fighterdoken 08:39, 29 May 2008 (UTC)
- Thanks Fighterdoken, the pages appear to be showing correctly now, but the category lists are still wrong. This may be a cache issue though, so I will just leave it until tomorrow.-- Wynthyst 08:36, 29 May 2008 (UTC)
Auto-categorizing miniatures by rarity
IMO we should auto-categorize miniatures by rarity. -- Gordon Ecker 23:35, 6 September 2008 (UTC)
- Good idea. The same could actually also be done for certain other item types. —ZerphaThe Improver 08:54, 7 September 2008 (UTC)
Rarity parameter
I wanted to suggest this proposal as long as the parameter is still new and not extensively used:
Blue or white items have, as we know, both the same rarity, since the game changes the font color of white weapons or salvage items into blue if they have any inherent mods or upgrades. But upgrades/common runes are always blue (likely for causing a specific effect) and quest items/common miniatures are always white.
Maybe we should have two values for them, to show both colors, e.g. "Common" for "1a" and "Common" for "1b". —ZerphaThe Improver 08:18, 7 September 2008 (UTC)
- Yes, there should be a way to show rarity:white, if we could call it that. Maybe we should call the parameters "white" "blue" "purple" "gold" "green" and "red" instead? - anja 10:20, 7 September 2008 (UTC)
- that could be a viable solution. though do you think it's adviceable to have three different descriptions for the same thing? 2 / uncommon / purple etc? it actually doesn't cause any problems, but should "common" then give the item a blue or a white appearance? we could add "common2" or something like that to complete your "new definition row" when we're going to "split" white and blue common items. —ZerphaThe Improver 10:33, 7 September 2008 (UTC)
- I would remove the "common" "uncommon" etc if we added white blue and those. Just have numbers and colors, white being 1 and blue being 2 and so on. - anja 10:43, 7 September 2008 (UTC)
- ok, these could be removed. but changing the numbers would cause problems. gordon already used it on the unique miniatures. 5 would change them into "rare" and they'd have to be tagged again. that's not urgently a reason, but as aforementioned, the game treats blue and white seemingly as the same rarity, and simply changes the item's color under certain circumstances. I don't actually try to force my opinion upon you, but i'd prefer having "1a" and "1b" instead for that reason. —ZerphaThe Improver 11:08, 7 September 2008 (UTC)
- I guess it is as random to have 1a and 1b as to have numbers at all. I don't really like them :P They don't tell me anything. But if we have colors also, I don't mind 1a and 1b :) - anja 11:10, 7 September 2008 (UTC)
- yeah, suppose you're right. I'll try to use the color words instead when defining the parameter on pages, other users can likely make better use of this as well. —ZerphaThe Improver 14:15, 7 September 2008 (UTC)
- I guess it is as random to have 1a and 1b as to have numbers at all. I don't really like them :P They don't tell me anything. But if we have colors also, I don't mind 1a and 1b :) - anja 11:10, 7 September 2008 (UTC)
- ok, these could be removed. but changing the numbers would cause problems. gordon already used it on the unique miniatures. 5 would change them into "rare" and they'd have to be tagged again. that's not urgently a reason, but as aforementioned, the game treats blue and white seemingly as the same rarity, and simply changes the item's color under certain circumstances. I don't actually try to force my opinion upon you, but i'd prefer having "1a" and "1b" instead for that reason. —ZerphaThe Improver 11:08, 7 September 2008 (UTC)
- I would remove the "common" "uncommon" etc if we added white blue and those. Just have numbers and colors, white being 1 and blue being 2 and so on. - anja 10:43, 7 September 2008 (UTC)
- that could be a viable solution. though do you think it's adviceable to have three different descriptions for the same thing? 2 / uncommon / purple etc? it actually doesn't cause any problems, but should "common" then give the item a blue or a white appearance? we could add "common2" or something like that to complete your "new definition row" when we're going to "split" white and blue common items. —ZerphaThe Improver 10:33, 7 September 2008 (UTC)
Auto-setting of the rarity parameter
Certain item types do usually, or even always, have the same item rarity, e.g. quest items or salvage items. We could add a switch to set them automatically to "common". —ZerphaThe Improver 08:57, 7 September 2008 (UTC)
- For Common/Rare crafting materials, this row should better completely be left out. Displaying "Rarity: Common" for rare crafting materials as they use white font is confusing; additionally they do not actually have that rarity. —ZerphaThe Improver 09:01, 7 September 2008 (UTC)
Festiveness & Sweetness
I move to change these terms to "Party Points" and "Sweet Points" as Festiveness is a vague term and in changing that, we should be consistent with Sweetness also. --JonTheMon 14:35, 12 September 2008 (UTC)
- Reasoning can be seen on Talk:Festive item. Misery 14:39, 12 September 2008 (UTC)
"Not stackable items" to "Non-stackable items"
A move proposal has been in place on the Category:Not stackable items since November 2008. Is anyone opposed to this change? It would require changing the last few lines of the template from "Not stackable" to "Non-stackable". I was going to change it (see the talk page for the category) then realised the original move proposal may have not been know to others so thought I would see what others thought before changing a template. So, Not stackable item or Non-stackable item? ~Celestia 08:00, 4 October 2009 (UTC)
- Well I've moved it now, so...ignore this part? :P ~Celestia 08:48, 10 October 2009 (UTC)
Drinks
Ok, do we want to document the level of the drink (1 or 5) or the amount of points given (1 or 3)? --JonTheMon 14:50, 4 March 2011 (UTC)
- In the infobox, only the points are meaningful to the at-a-glance view...unless you can find more than one person who is drinking to get drunk. (On the actual articles, we should be documenting both.) — Tennessee Ernie Ford (TEF) 16:12, 4 March 2011 (UTC)
- Of course there are people who drink just to get drunk, mostly for the synergies with some PvE skills. How about listing both?
- Drunkard Points: 3
- Intoxication Level: 5
- The template could be adjusted to print both rows based on the existing 'alclevel' parameter (alclevel=5 -> 3 points, alclevel=1 -> 1 point). Instant usefulness without adjusting a single article. Tub 16:34, 4 March 2011 (UTC)
- I don't quite like that, since it seems a bit heavy on space usage. I can see how explicitly saying both can be useful, but... Also, I don't know if i want to lock us into the 1->1 and 5->3. --JonTheMon 16:39, 4 March 2011 (UTC)
- Of course there are people who drink just to get drunk, mostly for the synergies with some PvE skills. How about listing both?
- See GWiki's current implementation (which will, I am sure undergo revisions) — Tennessee Ernie Ford (TEF) 16:58, 4 March 2011 (UTC)
- Ok, i'm gonna retract my space usage issue, since sweets just fill up their infobox and it hasn't been an issue. --JonTheMon 17:36, 4 March 2011 (UTC)