Player equipment/armor

[halvors]

In many voxel-based games, player equipment/armor exist (e.g. chestplate, helmet, leggings, boots).

This equipment differ from game to game, but are not supported in Nova yet.

I think this should be implemented as a plugin to core. And at least implemented in the NovaWrapper-MC.

Or should this be implemented in the Minecraft plugin instead?

[halvors]

@calclavia Any suggestions/opinions on this? I know that you will be needing this for the Hazmat Suit in EDX sooner or later :+1:

[shadowfacts]

I don't think it makes sense to have armor be it's own plugin, however it does make sense to include it in the Minecraft plugin MC armor differs enough from other games' equipment.

[Ecu]

I think this should be a Nova and not MC specific plugin. What it should essentially let you do is render an model attached to the player, and that's it. Statistic modification would be implemented by the armor itself.

[gjgfuj]

And have the item be registered to fit in slot e.g. "head"

On Mon, 8 Jun 2015 8:25 am Ecu notifications@github.com wrote:

I think this should be a Nova and not MC specific plugin. What it should essentially let you do is render an model attached to the player, and that's it. Statistic modification would be implemented by the armor itself.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109807886 .

[Ecu]

Actually gjgfuj, that's something that is game-specific. I don't think Nova should specifically register set slots, unless a list of slots is fed by the game-specific wrapper. You cannot always assume every game will have the same type of inventory slots (or same number).

Hell, you cannot even assume the same slots will exist with a few mods existing. TCon adds equipment slots, ThaumCraft adds equipment slots, etc. I think the best you can do is handle that yourself in your armor based on if it was put into a slot or not.

[gjgfuj]

This is why I say we have string names for slots. So an item would return a list of slots that it could fit in, e.g. "ring", "head", "chest", and then they'd only get in there if they match one of the strings. Because equipment slots aren't just wear this in any slot.

On Mon, 8 Jun 2015 11:25 am Ecu notifications@github.com wrote:

Actually gjgfuj, that's something that is game-specific. I don't think Nova should specifically register set slots, unless a list of slots is fed by the game-specific wrapper. You cannot always assume every game will have the same type of inventory slots (or same number).

Hell, you cannot even assume the same slots will exist with a few mods existing. TCon adds equipment slots, ThaumCraft adds equipment slots, etc. I think the best you can do is handle that yourself in your armor based on if it was put into a slot or not.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109820950 .

[Ecu]

Yeah. Basically like this (pardon if it repeats anything).

Have wrapper provide a list of "equipment" slots that are part of a second player inventory list that are used for equipable items/blocks. When creating an equipable item/block, you provide a list of slots, which would be stored to the item/block.

I'm not sure how these would be used to actually restrict things though. Since UIs actually determine if you putting an item in a slot, I'd only assume the list would just be able to be used by said UI to determine if something could go in that slot.

In which case, perhaps this should just be handled by a UI.. then again though, how would you handle this via Vanilla UIs?

[gjgfuj]

In Minecraft, the GUI asks the item if its valid. Therefore, in the wrapped item, it'd read the slots, and determine if the slot its being inserted to maps to any of the names provided.

On Mon, 8 Jun 2015 1:04 pm Ecu notifications@github.com wrote:

Yeah. Basically like this (pardon if it repeats anything).

Have wrapper provide a list of "equipment" slots that are part of a second player inventory list that are used for equipable items/blocks. When creating an equipable item/block, you provide a list of slots, which would be stored to the item/block.

I'm not sure how these would be used to actually restrict things though. Since UIs actually determine if you putting an item in a slot, I'd only assume the list would just be able to be used by said UI to determine if something could go in that slot.

In which case, perhaps this should just be handled by a UI.. then again though, how would you handle this via Vanilla UIs?

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109846798 .

[gjgfuj]

Also, I wouldn't have the wrapper provide anything to the item. Instead, the item says "I can be equipped on "head"" which the wrapper would then say, oh, that means you're a helmet. You can fit in this slot.

On Mon, 8 Jun 2015 1:19 pm Sandra Nicole gjgfujb@gmail.com wrote:

In Minecraft, the GUI asks the item if its valid. Therefore, in the wrapped item, it'd read the slots, and determine if the slot its being inserted to maps to any of the names provided.

On Mon, 8 Jun 2015 1:04 pm Ecu notifications@github.com wrote:

Yeah. Basically like this (pardon if it repeats anything).

Have wrapper provide a list of "equipment" slots that are part of a second player inventory list that are used for equipable items/blocks. When creating an equipable item/block, you provide a list of slots, which would be stored to the item/block.

I'm not sure how these would be used to actually restrict things though. Since UIs actually determine if you putting an item in a slot, I'd only assume the list would just be able to be used by said UI to determine if something could go in that slot.

In which case, perhaps this should just be handled by a UI.. then again though, how would you handle this via Vanilla UIs?

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109846798 .

[shadowfacts]

This all sounds good, but I think using an enum would be better than using a string.

– Shadowfacts

On Jun 7, 2015, at 9:56 PM, Sandra notifications@github.com wrote:

This is why I say we have string names for slots. So an item would return a list of slots that it could fit in, e.g. "ring", "head", "chest", and then they'd only get in there if they match one of the strings. Because equipment slots aren't just wear this in any slot.

On Mon, 8 Jun 2015 11:25 am Ecu notifications@github.com wrote:

Actually gjgfuj, that's something that is game-specific. I don't think Nova should specifically register set slots, unless a list of slots is fed by the game-specific wrapper. You cannot always assume every game will have the same type of inventory slots (or same number).

Hell, you cannot even assume the same slots will exist with a few mods existing. TCon adds equipment slots, ThaumCraft adds equipment slots, etc. I think the best you can do is handle that yourself in your armor based on if it was put into a slot or not.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109820950 .

— Reply to this email directly or view it on GitHub.

[Ecu]

Not sure about that. As, how do you know what slots exist and what slot would be appropriate for your item? Say one game has "head" and another has "helmet" and "cosmetic helmet"? Hell, I dunno how we'd implement an equipment system that would allow cosmetic armor and statistic armor being separate things.

[gjgfuj]

1. wrappers would use standardized names for the slots. 2. you can have multiple slots.

On Mon, 8 Jun 2015 at 13:29 Ecu notifications@github.com wrote:

Not sure about that. As, how do you know what slots exist and what slot would be appropriate for your item? Say one game has "head" and another has "helmet" and "cosmetic helmet"? Hell, I dunno how we'd implement an equipment system that would allow cosmetic armor and statistic armor being separate things.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109849483 .

[gjgfuj]

And an enum wouldn't work, as it'd be game specific.

On Mon, 8 Jun 2015 at 13:49 Sandra Nicole gjgfujb@gmail.com wrote:

1. wrappers would use standardized names for the slots. 2. you can have multiple slots.

On Mon, 8 Jun 2015 at 13:29 Ecu notifications@github.com wrote:

Not sure about that. As, how do you know what slots exist and what slot would be appropriate for your item? Say one game has "head" and another has "helmet" and "cosmetic helmet"? Hell, I dunno how we'd implement an equipment system that would allow cosmetic armor and statistic armor being separate things.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109849483 .

[gjgfuj]

I mean, sure, we can have somewhere to retrieve a list of slots. The item would also have an onEquipped(slot) callback, so it knows /what/ slot to put it in.

On Mon, 8 Jun 2015 at 13:50 Sandra Nicole gjgfujb@gmail.com wrote:

And an enum wouldn't work, as it'd be game specific.

On Mon, 8 Jun 2015 at 13:49 Sandra Nicole gjgfujb@gmail.com wrote:

1. wrappers would use standardized names for the slots. 2. you can have multiple slots.

On Mon, 8 Jun 2015 at 13:29 Ecu notifications@github.com wrote:

Not sure about that. As, how do you know what slots exist and what slot would be appropriate for your item? Say one game has "head" and another has "helmet" and "cosmetic helmet"? Hell, I dunno how we'd implement an equipment system that would allow cosmetic armor and statistic armor being separate things.

— Reply to this email directly or view it on GitHub https://github.com/NOVA-Team/NOVA-Core/issues/105#issuecomment-109849483 .

[Ecu]

Wrappers could not use a standard naming scheme if there are fundamentally different equipment variations. Especially when a mod may wish to actually add slots. Heck, what happens if a mod wants to change the player's form, disabling some slots?

[Kubuxu]

Enum would work. You specify by Enum what type it is like: helmet, glasses, shoes and so on and ie. MC will fit glasses and helmet into one slot. Slots with fitting types can also be provided so armor can be balanced depending on game.

[gjgfuj]

But... Enums wouldn't be extensible. As without changing the type, enums wouldn't work at all. We can have a class with string constants for common things. But we can't have an enum, as we can't add more slots to the Enum.

[gjgfuj]

The rest of those things, yes. but we can't use an enum. The amount of different equipment variations we can get....

[Caellian]

Why wouldn't there be an enum just for convenience containing strings and a map of strings to inventory slots. Both would be inside core and wrapper would fill the map with values, this system would also add flexibility for mods to add their own slots and wrapper would make sure that all of the values inside of the enum would be put somewhere. That way if we have 'hand' and 'fingers', wrapper would bind them to same slot if one doesn't exist, and of course, mods would be able to rebind slots if they want.

[Ecu]

Caellian,

Because an enum cannot be manipulated once created. You want a list/array, not enum. If mod authors are to be allowed to make their own slots and not have it be pre-determined by the wrapper only, that's what would be needed.

[Caellian]

I am aware how enums work, thank you. Using an array in this case for anything is probably the worst thing possible to do considering you would want an extensible, easy-to-use system.

I suggested using an enum just for convenience. This way, new programmers wouldn't need to search for a list of possible strings online - an enum would contain them. What I suggested is:

• Using a map linking strings to slots in game.
• A wrapper would fill that map with values.
• Mod would access slots by using something like: Slots.slotMap.get(SlotsEnum.HEAD.getStringValue()). An alternative without enum would look something like this: Slots.slotMap.get("head").

I don't know how to make it any simpler than that. Enum is just for convenience, system is based on a map (String -> Slot).

[Caellian]

Also, inventories should be consisted of Slot<?> objects instead of using id's. Minecraft is probably the only game using id's and arrays instead of objects for slots. Transition would be easy and it would be easier to use inventories later.

That way, you could just pass around slots instead of whole inventory.

[ghost]

You could cover supported strings in the docs. And since you have only 4 vanilla types ("helmet", "chest", "leggins" and "boots" fe) there will be not much confusion. This might work just as OreDictionary.

[ghost]

And slots from other mods (like Baubles fe) should be explicitly covered in their docs

[Caellian]

@anti344 In case a string changes, it would require all of the mods to update. Using string enums is just more convenient. I don't see a problem, you could still use a regular string. EDIT: Updated previous comment, I derped out.

[ghost]

Thats why you wouldn't change string. You could change enum just as easily. And where is custom equipment slots? How would you do it then? And if some game don't have leggins, what would your enum do?

[ghost]

Oh wait, i get this. You want to collect most popular strings(like vanilla ones and some common from big mod collections) and turn them into enums? And make it accept both enums and custom strings? Then maybe, i dont know

[Caellian]

@anti344 Yes. Enum would just contain a bunch of strings - some used, some not (depending on game). You don't HAVE to use enums, but you can use them to make your life easy and enum names wouldn't change, but their values would. That way, when changing thier values, you wouldn't need to update every mod because enums would act as a layer of abstraction.

[RX14]

I would say that it's better to use a string. Other than that the core idea sounds good.

[Caellian]

@RX14 You would use strings. Gist further explaining what I suggested: https://gist.github.com/Caellian/0ce7dc90806f90fea93b

Also, what I did in the example with horse helmet was just to show that strings should be prefixed with their inventory. Those enums would/should be located as public inside of inventories.

[RX14]

@Caellian I understand your reasoning, but i don't think it's worth it