Effecting a single instance of a blueprint

[DoomBoxHero1 (DoomBoxHero)]

How do you effect one instance of a blueprint if you have multiples of the same blueprint in a level?
For example, I have a lock on system that when it locks on to the enemy it triggers a widget to overlap the enemy but it triggers on every enemy so they all have a widget overlayed on them.

[omicron0806]

So, You have ‘MainCharacter’ and ‘Enemy’ (instances of object enemy) right? Does enemy instance has some kind of interact widget?

For example. Red boxes are all of same Blueprint (class). But, let’s say OnOverlapEvent, only one shows InteractWidget, i.e. ‘E’… Is that something you’re going for?

[omicron0806]

I will insinuate that You have a global (world instantiated) widget, and probably instancing it on every class of ‘enemy’. If that’s the case I’d add ‘OverlapWidget’ to list of Components of ‘enemy’ class, set it’s visibility to false, and then when event is triggered (which should be just on the enemy you’re targeting), change visibility. That helps?

[DoomBoxHero1 (DoomBoxHero)]

I have a lock on mechanic that is a capsule component that checks if the actor has the tag “Enemy”. When the tag is valid it also checks a boolean related to the actor and triggers the widget to display.

[omicron0806]

Well, if all enemies have the ‘Enemy’ tag, it’s normal that the widget is showed on all of them. What about that other BOOL?

[DoomBoxHero1 (DoomBoxHero)]

Thats the problem. The boolean is just a check that ticks when the target is valid which triggers the widget to display. The problem is that its setting it as true in the BP_actor and reading as true for all of them. How would i make it only effect that individual enemy?

[omicron0806]

OK… If we’re to solve this a bit of information is needed… So, just one enemy_actor has ‘enemy’ tag?.. Where’s the boolean declared and what is it checking?
Seem to me like all of your enemy_players share some global variable… Which you’re checking.

[DoomBoxHero1 (DoomBoxHero)]

Picture 1
So this runs through the code for setting up the lock on running the sphere trace for objects. At the end is when the EnemyLocked (boolean) is set. This was made so I could set a true or false in the Enemy BP.

Picture 2
This is the enemy BP It’s just checking if that boolean is true or not to set that widget to appear or not. That’s where my problem is. I know just setting it that way is what’s causing the issue, I just don’t know how to fix it or to only specifically effect the enemy that’s actually targeted.

[omicron0806]

Well I’m not sure I quite understand all of this, but shouldn’t you just be checking if the hit_actor has tag? I mean… In this way, parsing that boolean to EnemyBP all of them get it as TRUE.

i. e. if the enemy is hit a. i. traced->set_true

[Everynone]

It would be the same setup as in here but instead of a timeline, you’d fire widget visibility events:

Moving an object by pointing another object at it

See if this helps with this particular bit. a standard forward camera trace: [image] You’d use an interface or inheritance if there are more types to handle, ofc. not sure how you want stuff to move, here it’s via a timeline: [image] which results in: the branches in the script prevent it from spamming since we’re tracing on Tick: Hopefully you can adapt it to your needs. It’s a setup similar to this one:

In a nutshell, store a reference to what you’re looking at, so you can still interact with it (disable it) when you’re no longer looking at it.

---

And here’s a more resource-conscious alternative:

How to get static mesh name and input it into widget

Since this can be done in too many ways, we’d need to know how you’re handling things at the moment in order to suggest something that fits right into your existing system. calling a bind variable assuming this is what you mean in the widget: [image] assuming we’re using an interface: [image] assuming we’re tracing and looking at stuff: [image] assuming actors carry names we predefine ourselves: [image] The end result here would produce: As you can see I had to assume a lo…

Since we need only 1 lock-on widget visible at the same time, move the same widget from one target to another. The player owns the widget and moves it to where it’s needed.

[DoomBoxHero1 (DoomBoxHero)]

Ok I’ll check it out thank you for your help!

[DoomBoxHero1 (DoomBoxHero)]

Thank you for taking the time and helping me out!

[DoomBoxHero1 (DoomBoxHero)]

Ok so this kind of thing will work for a system I already have built?

Unreal Engine Hack & Slash Tutorial Part 10 | Targeting System (DMC 5 Inspired)

This is the system my lock on is based on.

[Everynone]

It’s a common, generic and pretty agnostic approach. Both of them are.