No, it’s the opposite. My playable pawn has the collision sphere (for managing the distance), and my non playable object, with widget, detect the overlapping
You’re gonna want to have the collision sphere on the actual non-playable actor. It can be done the way you are doing it, but you’d need to break the hit result, use that to set a target (or most likely add a target to an array) and then work from that. You can use multispheretraceforobjects for the same thing.
Or, you could just add the collision sphere to the non-playable character and have that react to the player entering it. I prefer this, it makes it so much easier since you only ever have to check against a single actor (unless you have some reason for NPC interaction that triggers behavior, but even so there are better ways to do that).
I wanted the sphere on the player to be able to manage the distance at which the widget is displayed. And that requires only one sphere.
If I have to put the sphere on the actors, it will quickly become messy because I can have several hundred …
If the best solution is that, then I would do like that …
Well I understand what you’re trying to do. You want your player character to walk around with a sphere and activate stuff as he goes right? Well, for that you would be better off with a blueprint interface and a function in every non-playable character that receives the message from the interface function.
And what happens if you want to activate things at different ranges? Well, your player would need multiple spheres for that and you’d have to turn off the collision on one sphere and activate it for another and it just becomes very difficult from there.
Do that if you want, but I think you’ll have far more success with just having the spheres on the actual actors that fire events off the player entering them. This is the beauty of parent-child blueprints: You only have to add it once. Say you have a 100 different NPCs, they all do different things. Well, if you have a master npc blueprint you add the sphere and the collision detection there. And you never have to do it again if you make the NPCs child-classes of that blueprint.
I do not absolutely want to do that. But yes, that was my first thought, but I have no problem admitting that it may be the wrong way to go.
Regarding the distance, I just wanted to change the radius of the collision sphere, no need for multiple sphere.
I know the principle of parent / child, it was not in this sense that I said that, but, if I put the sphere on the actor, the engine will have hundreds to manage, instead of one in my first idea.
But I’m probably wrong. I will try the way you described in the first posts.
Sphere collisions are actually quite simple, there can be hundreds or thousands to manage, but that is only a problem if they are all fired at the same time. One by one it is not taxing.
Remember, you are sending info between blueprints with the first method here, that is more taxing than detecting a collision.
Yeah your right. I moved my collision to my non player actor, and now its work. I’m just little sad cause i cant manage display distance simply without check distance between all actor and player 