Why is Sphere Collider Component not Blueprintable?

[jwatte]

I want to build a re-usable “interactable trigger volume” component. Ideally, I add this component to an actor of any kind, and that actor shows up with a “Press F to Do The Thing” in my GUI whenever it overlaps the pawn. The interface between this component and the interacted actor is a simple Event Dispatcher.

Unfortunately, I can’t build this helper as a Blueprint. I tried a SceneComponent, but those don’t allow me to add additional sub-components.

I tried deriving from Sphere Collider Component (and just put all the logic in this derived component) but that’s not Blueprintable, so I can’t (without using C++.)

I can maybe get there using sub-Actor attachment instead, but that feels like a bad way to go; if I want to highlight the actual-object being interacted for example, I’d have to somehow follow the actor chain, which ends up making using different patterns in different circumstances harder, and creates more unnecessary levels of abstraction that can go wrong.

[ConradG]

Hi jwatte,

I’m trying to understand the use of this interactable trigger volume. It is meant to be re-usable whenever a Press command is called.

Would it be simpler to instead use a SphereOverlapActors or Components? And then define the logic in the GUI that calls this trigger (as far as I’m understanding)?

[jwatte]

I already have the GUI bit, and the command bit. I’m trying to factor out common functionality.

Currently, if I have some mechanism that can be interacted – door to close, chest to open, TV to turn off – I need to add an overlap volume in each of those objects, and set it to only overlap pawns, and then check that it’s a player, not an NPC, before it tells the player controller that the interaction is available. This code to “begin overlap, make sure it’s a player, tell it interaction is available, and when the interaction comes in, actually trigger the mechanism, and don’t let it be re-triggered until it’s done” has to be duplicated in each blueprint.

It would be possible to have a totally generic sphere trigger component, that did all of those bits, except for the “actually trigger the mechanism” bit. That could be an Event Dispatcher in the overlap component, tied to an Event within the mechanism.

Thus, here’s what I want to be able to do:

1. Start with a working mechanism blueprint and create a child class of it
2. Add this interactable-overlap-volume component to the child class and put it in the right relative spot to the main mechanism
3. Configure the interaction name (a variable value) and bind the “do the thing” event dispatcher to the function that starts doing the thing

Presto! Ready interactable object in three clicks.

Currently, I have to add a sphere-overlap component in step two, and then configure it for the right kinds of overlaps, and then do the logic to register/unregister with the Interactor, in each object that I need to make interactable, because there are no Blueprintable components that have actual collider/overlap geometry. If the Sphere Collider component was Blueprintable, I could easily make a subclass of this, that contains the logic once, and add this subclassed-component to the mechanisms that I want to make interactable.

I could pretty easily do this in C++, but I don’t want to go that way in this project. It just seems like such a weird blind spot in the actor entity component system – why are the colliders not blueprintable?

[ConradG]

Thanks for the taking the time to explain your idea. I think I get what you’re after; while the player is close enough (overlapping) a certain mechanism, allow the mechanism to be interacted with, correct?

Would it be a better route to use blueprint interfaces, where the Interact event comes from the player controller? That way you could assign the interface to whichever actors can be interacted only. In your case, the parent class which all the children will inherit.

Your interactable mechanism blueprints would still need a collider and it could detect whether or not the player is overlapping them like you have.

Something like this, called in the Player Controller. Sends out a general signal to all receivers. In the interface, the “Interacted” function has an Interactor input which is the player’s pawn.

Here is the line trace. It’s by channel. Your mechanism overlap component would need to block Visibility traces. Obviously doesn’t need to be line based. (This example was for a third person game so it depended on player facing direction, but you could use a sphere trace by channel instead or whatever.)

Below is the receiver’s event (not the player controller, but the mechanism in your case). The receiver needs to have the blueprint interface (BPI) added to it’s Class Settings section. From there you can write whatever code per type of object or whatever you want. Then there is no talking back and forth, but listening instead. This is an example of door logic. If the door is locked, it won’t do anything. If it is not locked, it casts the Interactor to the specific character or pawn class.

Then a check for some additional requirements - must be overlapping AND the door must not be animating (I’m calling animations on the door directly - no timelines - opted for skeletal mesh animation instead). From there you can call whatever logic you want for the specific type of “thing” that it is and what it should do.

Just to reiterate one note, the overlap sphere collision is the idea you have in mind. The overlap sphere would need to Overlap Pawn objects and Block Visibility channels.

And just for good measure, you wanted to tell the player that they could interact with whatever they are overlapping so…

You may not need to talk to your character class. I forget why I did it this way exactly, but I think it was for replication reasons. Either way, “Update Current Interact Text” is an event dispatcher which the character owned in this case (it could be in your GUI class, but you need a reference to it).

Here is the binding of the event dispatcher in the UI class. Again, getting the player’s character/pawn in order to know it. The player pawn has the event dispatcher, but nothing happens with it in the pawn class. It just passes along the event from the Receiver to the UI so that some Text can be drawn on screen (the Overlap Text in the Receiver class in this case - which is “Open Door” so the player knows they are close enough to do something).

Hope this helps even if it’s not exactly what you’re after!

[jwatte]

Thanks for the blueprint screen shots. Unfortunately, they don’t really help with what I’m doing. My interaction design works well the way it is.

Your interactable mechanism blueprints would still need a collider

Yup! And I want to make adding that collider easier. Also, I use overlap, not ray trace, for Reasons.

Currently, I have an interaction helper that does most of the work, but each mechanism that needs to be made interactable, has to add its own sphere (or other trigger,) and wire up the “begin overlap” and “end overlap” to the helper object. This adds three actions: Add trigger, bind event, bind event. If I could make my helper itself also be/contain the trigger, then I would reduce the complexity by those three steps. It’s not actually a big deal, but I found it annoying that the collider (trigger) components aren’t Blueprintable, and I don’t understand why that’s the case. Maybe that’s more of a C++ question.

This is the interface for an interactable:

This is the interface for an interactor:

The interactor may get multiple interaction possibilities, so it needs to sort and choose somehow; that’s fine. There’s really only one interactor for me, my NPCs don’t interact with things. (Although at some point they might have to pull a lever or something.) Also, the interactor is responsible for telling the HUD to “Press F to Do The Thing” while it has an active available interactable. But, specifically, having the interactable be responsible for telling the player when it’s available, rather than the player scanning for interactables, makes a thing choosing to hide itself easier! For example, an already-looted chest might decide to not tell the interactable about itself.

An interactable is responsible for telling all nearby interactors that they are available. Here is one place the helper comes in handy. as the interactable can just call into this helper. Theoretically, the thing that’s the interactor COULD be an actor, or COULD be a component, so testing both is helpful. Note that this helper implements the Interactable interface, so the thing (chest, door, terminal, etc) doesn’t need to:

(Those events are what the interactable actor itself needs to call, as well as bind itself to DoTheThing.)

Configuring those events on the bottom, and adding that Trigger sphere component, could be avoided if the Interaction Helper (LootHelper component here) was based off a trigger volume compnent, which I can’t do, because the Sphere Collider component isn’t marked Blueprintable.

So … why isn’t it?