I’m building out my game’s inventory system and I’m just at the point where I have the widget that comes up when you look at an item (strictly speaking, it will come up any time you look at something you can interact with). Finally figured out how to make it appear and disappear when you are and are not looking at something, but it’s throwing this message in the logs:
Blueprint Runtime Error: “Accessed None trying to read property Hit Actor Interactive”. Node: Destroy Widget Graph: EventGraph Function: Execute Ubergraph Inventory System Blueprint: InventorySystem
Since it’s working as intended, it seems… fine? But it will sure make trying to find other error messages hard because it generates this one every tick
Ideally, this needs fixing, otherwise it will make you miss other errors due to spam.
You will need to validate the bottom Branch as well. While the interface itself could not care less about the reference, the Get Component by Class will generate errors when attempting to evaluate a null ref.
Okay, that solved it, but I’ve got a new problem: I created a second item blueprint and gave it the NameTag component, but it doesn’t show up when I look at it. It’s still only the first item I created that makes the nametag pop up. Any ideas where that’s happening?
I expect that any time I hit something with the interactive channel, that item should be set as the HitActorInteractive variable, and then its nametag widget will be the one that is made visible.
Yes; I figured it out: I had two different mesh components and the one that actually had a mesh assigned to it didn’t have the channel activated.
Last question: I’m going to have components attached to stuff to handle various subsystems (one for picking up items, one for dialogue, opening doors, etc.) and they’ll all be activated with the same input: would a good way to do this be to have nesting branch statements that check whether the target is an item, NPC, door, etc., with each True branch leading to its own interface that in turn messages the corresponding subsystem?
Nesting branching is almost never the right choice.
If you can use some kind of event binding or some interface, and make that automatically dispatch the right action, that would be much easier to maintain, and would keep the code more contained where it makes sense.
One major benefit of using interfaces is avoiding cascading branches. We send a generic Inspect message. What Inspect means is determined by the function implementation in the actor.
The actor can then propagate the message to the desired component, if it has one.
when you Inspect:
– NPC: pop up a widget tag name
– Rock: nothing happens
– Door: internally, the door checks if it has a Keypad component, if so → show it and ask the player to punch in the code. If the door actor found not component, the door opens itself.
Unless you have a very specific system in mind, we should be sending messages to actors instead. And looking up comps should be the Hit Actor’s job:
Generally speaking, yes. That’s the usual scenario. The player pressess a key, we either trace or overlap and send messages to actors who interpret them. Each does its own thing.
But you may want a setup where you send messages to components directly instead. Lets say you have a broken down car with 4 doors comps, and a trunk comp to loot. You want to only interact with components of the car, the vehicle itself useless. Traces and overlaps can return hit components, too.
