Hi, I’m trying to create multiple interactable objects that you mouse over them and a list of interactions appears (max of 4 options), but of course the options text and interactions are different for each object, and on top of that, options can change over time, depending on some factor or game progress.
What I have so far is a parent actor “Interactable Object” and child actors which are mostly just different meshes, but the parent handles all the blueprint, including spawning the widget and populating it with the input options.
the way it works right now isn’t optimal for dynamic options, since I’m basically hard coding each option onto exposed parameters. so my 1st question is what would be a better way to approach this?
I also don’t have a proper solution to actually do the interactions. I suppose interfaces would work best, but each button from my widget has an “on clicked” event and I’m not sure where to go from that, so my 2nd question would be how to proper make the interaction events.
Put all possible (required) code/behaviors in parent class. Then either feed data from some text format file like CSV, or from database.
Some tut about data tables:
Create child class only for handling looks (or sets of parameters that you expose to editor). If you put separate pieces of code in child object you are basically back to square one: you end with almost similar code in many different child classes. This works in text based code like C++ or python etc, but its nightmare to maintain in those bloated cthulu like blueprint source files.
Make enum variable in parent class that describes class of objects etc. Then execute different construction script based on that enum, read variabes from that CSV.
This way you have all code in single blueprint actor. And all data in single CSV file.
IMO easiest for maintenance and editing all those actors.
I see @Nawrot 's answer above. Maybe you want to use tables.
My preference would to drop a wardrobe in the level, and set the possible options in an instance editable array.
When the player walks up, the wardrobe uses the parent code to make the widget list.
I think you’re stuck with using the widget itself at that point, but the button can call the BPI on the wardrobe when it is pressed. You can the text associated with the button to the BPI, then the wardrobe knows what to do.
This way, you have a totally generic widget and blueprint actor.
Yeah I think my problem is mostly how to handle the interaction.
for example, let’s say there’s only one interaction per object.
my “main” interactable object actor has all the code for calling the widget, and the child actors have no code to say what’s being interacted with, they only have exposed variables with the interaction names and their own names. so when the player steps in next to the object, the widget with the options shows up, and I can click an “interact” option, but I don’t even know how to associate that with a specific event.
I’m thinking I’ll have to add code to the child actors to send their own reference to the widget? But then I’m thinking it’s not helping much having a parent actor with all the code
I thought you have problem with how to setup multiple blueprint actors with lots of data and options and you are not sure yet what it would be. But you need actor code first, and done in way that allows easiest maintenance later.
So ideas for all that (in random order):
yes keeping all options in array is the way to go, however use enums there instead of string or tags.
you can make empty (no visuals, just code) blueprint actor as base, so it is always same class everything needs to communicate with. Then you add widget component and blueprint actor component (that keeps all visuals).
create custom umg widgets, and add them to actor “master widget”
same “trick” like for blueprint actor and components may be done for widgets. You create that “master” widget that is always of same class, then you populate it with custom widgets, and since they always sit on master you do not have problems with casting to different types, and master can have hardcoded code for reference, casting and all that to owning blueprint actor.
So create something like inheritance without actually creating different classes of blueprints:
parent that is always same class
actor components that may be different classes, but they always cast to parent that is always same class
same for widgets, container widget that is always same class, and spawned on blueprint actor
child widgets that all are custom widgets, but they always spawned on top of same widget class
And then you can populate all that from data tables
I did all of that. Now when I click an option from the interaction widget, my parent (master) interactable actor receives an event call with an integer ID of which of the (up to) 4 interactions was clicked like this:
so what I (probably) want to do is to check which child interactable actor is this one (a self-get display name should do it) and then compare with a list of all interactable actors from an enum? I’m not really sure how to proceed. This is what I have:
