This lets me assign the classes I want but I can’t actually edit their values, all I’m left with once I assign a UMorpheme child is the dropdown:
Is there any way I can change this, and expose the values of each UMorpheme after it’s assigned to itemEffects? Without that the elegance of the whole system falls apart, because it’s no longer possible to do stuff like generate dozens of different food and drink items by giving Consumables different values for each piece of food.
Ooh okay, that makes sense… so is the only way to get away with what I’m proposing to literally spawn hundreds of components on the inventory manager and edit them once they’re instanced?
So to clarify, you’re suggesting that each category of item effect would be an instantiated, spawned-in-the-world actor Blueprint? Because that’s what I’m using this weirdness to avoid in the first place: ideally, I’d like to ensure that items only ever exist as a single integer reference to a database/array entry whose properties I can tune for each individual item.
The intended workflow with TSubclassOf is that you make a base class, then make BP Classes derived from that and use the BP Class Defaults to set the , well, defaults. So if this is for items oyu would have a base item class, then blueprint classes for say a gun or a bow or whatever. None of the above are Instances, just Classes.
Yep, as others have said, if you want to store an array of classes, you need to create a blueprint for every variation of values that you need. This will work fine, but it is a little annoying to have to create a blueprint every time when all you’re doing is changing a value or two. There is another way to do this that lets you edit values inline, but you will then be storing an array of instances rather than classes in each object.
And also add the EditInlineNew specifier to the UCLASS(…) declaration for your UMorpheme class. Then in the editor you’ll be able to select a UMorpheme-derived class from the dropdown, and then edit its properties in place.
Be careful with this though. Because this is instancing the objects, you may end up with unintended results. If your outer class/blueprint (the one which has the TArray property in it) is itself going to be instantiated multiple times, then each object will have its own array, and each element will contain its own instance of UMorpheme. More often than not, this will be what you want, but if the UMorpheme is just a specification and its values won’t change at runtime, then you end up with unnecessary duplication of objects. In that case I’d go with the blueprinting method instead.
U can change default object of that class, but for that u need to write ur own editor module and create ur own widgets for that, try to google “unreal engine details panel customization”, it’s eiser than u think, but u need to read something about slate and IPropertyHandle.