29 replies to this topic

[felinoel]

 

About the Type issue, what if we were to add a Subtype?

{{Infobox/Item
|mod = ic2x
|type = Item
|subtype = Resource
|stack = 64
}}

That could make everyone happy but it just doesn't seem needed to me.

Instead of calling it a subtype we could call it a... classification? idk...

[RZR0]

About the Type issue, what if we were to add a Subtype?

{{Infobox/Item
|mod = ic2x
|type = Item
|subtype = Resource
|stack = 64
}}

http://ftbforums.org...6-item-subtype/

 

@dgelessus - we're not obsessing LoL

I am

[felinoel]

http://ftbforums.org...6-item-subtype/

Ohhhhhhh THIS is what that thread was about? My previous statement that Item, Block, Liquid, etc is unneeded still stands.

For THAT matter, what are Adventure Backpacks? Items or blocks? They open from the inventory or from the chest slot AND can be placed in the world like a chest.

[dgelessus]

About the Type issue, what if we were to add a Subtype?

{{Infobox/Item
|mod = ic2x
|type = Item
|subtype = Resource
|stack = 64
}}

Then we could just leave type as it is, but make the infobox's default type always visible. I don't see the reason for that though. Are there item types where the difference between block and item is not clear?

Another solution would be to set the standard to "in this Wiki we use Default Key Binds" since most articles already use 'Right-Click'... as Felinoel pointed out

Open any large modpack and look at the number of conflicting keybindings. Somehow I don't think that's a good idea.

[JC_the_Techie]

I meant "Vanilla" defaults, but ya Dgelessus is sure right about that what a mess!

 

Which bring another aspect, Mod bindings don't have a name per say so we have no choice but to use the key binding in those cases, for example "To equip a Backpack to it's hidden slot, press '[Left] Shift+B' and 'B' to quickly access it" so in that context, to be consistent it is better to use Right-click and Shift+ as well...

[dgelessus]

If the key bindings don't appear in Minecraft's Controls list and cannot be customized elsewhere (like NEI, which has its own options) then we need to use the real key names of course.

[RZR0]

Then we could just leave type as it is, but make the infobox's default type always visible. I don't see the reason for that though. Are there item types where the difference between block and item is not clear?

The only way I see this working out is that if the specified type does not equal Item or Block, it shows it as for example "Item (Potion)" or "Block (Fluid)" with the 'subtype' linking to the appropriate category? (+ perhaps it automatically adding the category for that)... I dunno.

 

So far I've worked around this issue by having templates such as Infobox/Row/Food and Infobox/Row/Armor to add rows to the Infobox templates for those specific item types and register them to the appropriate categories.

[dgelessus]

So far I've worked around this issue by having templates such as Infobox/Row/Food and Infobox/Row/Armor to add rows to the Infobox templates for those specific item types and register them to the appropriate categories.

Well... why not make the infobox automatically add categories based on type?

 

Also I still don't understand why it is important to have a type and a subtype, when the type is always the same as the infobox default. As in, how is it more useful to write |type=Item |subtype=Armor and see "Item (Armor)" as the type, instead of just |type=Armor and displaying "Armor"? Is there any armor that is a block? Or in a more general sense, is there any item subtype that could be a block or an item (and where the difference is important)?

[RZR0]

Well... why not make the infobox automatically add categories based on type?

You didn't seem to be into the idea before?

[dgelessus]

You didn't seem to be into the idea before?

Because pluralizing the types is not that easy IIRC... though I guess that could be handled by a template/module that knows all the special cases where the plural is something other than singular .. "s".