@Sangemdoko ... Thanks that helps clear it up in my mind too.... !
In the demo we use an array. You are allowed to have [empty, empty, myAttachment, myOtherAttachement, empty]. Now if you want to order your attachments I think that comes with the logic of the UI. You can take the slot array within the item, order it and then display it. You could even apply that order change to the item.
But for this specific use case, you could have two arrays: item[] and index[], where your index can be of type int, enum, etc...
We don't support dictionaries as attributes (our serializer won't serialize it), if you find a good use case though we may look into supporting it.
But for this specific use case, you could have two arrays: item[] and index[], where your index can be of type int, enum, etc...
//Pseudo code untested
[Serialiazable]
public struct MySlotStruct{
public int usableSlots;
public Item slotOne;
public Item slotTwo;
public Item slotThree;
public Item slotFour;
public Item slotFive;
}
@Haytam95
Thank you for your insight on this. I'll keep it in mind and I'll discuss with Justin to see if he can add dictionary serialization in the shared serializer.
I'm not sure we are talking about the same sockets here. I was talking about items within other items such as enchantment scrolls or magical gems that you add to your weapon.
If I understand correctly you are talking about character inventory sockets? as in headgear, armor, pants, footgear, etc.. for character equipement?
If that's the case then this is part of the ItemCollections. You can extend the ItemCollection class so that it suit your exact needs. As mentioned before you can have multiple ItemCollection in an inventory each can work differently.
I think I'll make some generic ItemCollection which could be used as-is or extended. Some generic use cases could be:
and maybe others.
- for limited space (max amount 99)
- dictionary like collection use for character equipments mainly (i.e 1 armor, 1 weapon, 2 accessories, etc..)
- custom sized stack ItemCollection where you can split items in different sized stacks, instead of one stack per item
If you were indeed talking about item sockets as in items within items, then I think it should also be possible. I want to make the ItemCollections serializable and if so nothing prevents you from using an ItemCollection as an attribute for your item.
You could also technically use an Attribute<MySlotsStruct> if you know in advance all the possible keys of your dictionary. Usually you'll have up to five slots, of course that depends on the game. But something around those lines could be a potential solution:
C#://Pseudo code untested [Serialiazable] public struct MySlotStruct{ public int usableSlots; public Item slotOne; public Item slotTwo; public Item slotThree; public Item slotFour; public Item slotFive; }
It really depends on your game. But the point is that there are no restrictions, you should be able to use any types as attributes as long as it's serializable by our serialization class. We'll continue working on our shared serialization class so that it can serialize many types of objects.
I hope that clears any doubts you had on this matter.
As mentioned before you can have multiple ItemCollection in an inventory each can work differently.
@Sangemdoko , I don't mind the wait... Sure it will be well worth it. But do keep posting any old clip, snippet or update here as often as you can as it will keep we paying punters from getting twitchy!Hi @Dragonflame I'm sorry but the Inventory System was never planned for this year. We are working extensively on the asset and we hope to release it sometime Q1-Q2 2020. That could change at any time though, we will only release the asset once we believe it is ready.
To give you an indication of our progress, I am currently refactoring the core components and changing some functionality to make it easier to understand and use while making it more performant.
Apart from refactoring, there are four big things that will take a lot of time:
I know its a long wait but hopefully, it will be worth it.
- A new demo scene built from the ground up which can showcase all the best features of the asset. The demo scene I showed in the posts will be scrapped completely, so expect something different. We are about to start working on this new demo very soon though, I'm quite excited about it.
- The Editor window needs a revamp. It's functional but the layout is inconsistent with the rest of the Opsive library. So it will be remade at some point.
- The Opsive UCC integration, It was made clear that a majority of the people want the integration at launch, or at least soon after. We've just thrown some ideas around with Justin but we haven't come up with a concrete plan just yet.
- Documentation and videos. I've been writing bits and pieces for the documentation, but putting everything in one document and making it easy to understand takes time. And of course the videos are the same. I assume that we could make most of the videos after the release.