I’ve recently been trying to learn UE4’s Blueprints to make a prototype of a small game. It’s a puzzler in which you have to guide an actor to a goal volume by moving obstacles out of the way. The problem is I’ve fallen at the first hurdle.
I have a blueprint with a trigger volume acting as the goal who’s location I’m storing as a variable. I want the non playable character on the other side of the map to take that location and head towards it, with the idea that when I get one I can spawn multiple on the fly heading to different goals to make things more hectic. I’m very new to UE4 and have watched alot of videos on casting on youtube but they all either rely on the getting the player character (my pawn is not the player), tracing something very close or overlapping to be able to get a references of other actors.
It seems so basic, am I missing something? How do I get that variable shared to others? People online say I should avoid using the get all actors of class, but it’s the only way I’ve gotten it to work so far.
TLDR: I have a non controllable pawn that needs to take the goal location variable of a trigger volume BP on the other side of the map and I’m stumped.
You’re right about the performance cost of Get All Actors of Class node. But sometimes it is the best way to get what you want. It just needs to be used sparingly.
In this scenario, you could call it once at the start of the level from a class like Game State or Game Mode that can be accessed from anywhere and then store the goal location in them. Whenever an NPC requires its target location, it can use the Get Game State/Game Mode nodes to access the stored goal location variable instead of using the Get All Actors of Class every time
Check out video #25 and see if it gives you any ideas for how to create a reference to your trigger volume. If it already exists in the world as well as your pawn (neither is spawned) you can directly reference it by creating a variable of type “trigger volume” in the pawn BP and give it the reference to the actual trigger volume in the editor. The video should help clarify this process.
Alternatively, by your description it looks like you might be able to just have the trigger volume BP itself spawn the AI pawn and give it its location during spawning, then just place the AI very far away or wherever you like from the goal with the spawn actor transform pin. This way it will already know the location of the goal.
[USER=“1188480”]Nebula Games Inc[/USER] ’ approach of setting it at spawn seems like a better solution than retrieving the goal location from elsewhere. Unlike my previous solution, this removes the need to have the AI class depend on an external entity.
In addition, you can set the properties of the goal location variable to be Editable and Expose on spawn (check the Expose on Spawn section here: Blueprint Variables | Unreal Engine Documentation). As shown in the documentation, it will allow you to set a variable directly through the Spawn node.
[USER=“1188480”]Nebula Games Inc[/USER] @Stormrage256 Thankyou so much for your ideas. I’ll be honest some of what you’re saying is going over my head at the moment but I will watch and read those links you gave and see what I can come up.
The spawning method sounds perfect - ideally I want to have a stream of actors on screen spawning and moving to the goal then disappearing like a very basic crowd system. I assumed however I would need a spawn point BP and a goal point BP. If i were to make the spawn point also create the goal maybe that would be easier to get the data and actor references?
Just a quick note, scenarios like this are why UE4 is structured the way it is. Storing the goal’s location in the game state would allow infinite actors to reference it easily and efficiently. If the goal moves, there’s no requirement to get all the actors or do anything inefficient; rather, the actors who care about the goal’s location simply get it from the game state. I’d recommend this approach as it allows you to do much, much more without any unnecessary overhead (replicating a vector is no big deal). Example, a moving goal now becomes 100% doable with minimal work and overhead – simply reference the game state’s variable for this when needed, and all is well.
[USER=“145111”]One Mode Only[/USER] Hi, I usually work on small short term projects and quite often end up reusing gameplay systems from past projects in new ones. Under such circumstances, having reference to a game state or game mode within an otherwise independent entity like an AI or weapon class creates this scenario where almost the entire project gets ported over during migration due to references. So wouldn’t it be better to keep the AI classes decoupled from singleton classes like Game State?
It’s a trade-off you’ll have to take into consideration. Basically, you’ll trade efficiency for portability in that scenario, which is totally fine when done properly. In an actual game, however, portability shouldn’t really be a consideration. Selling on the marketplace… Well, often people are just starting with UE4 and would like a portable solution anyway (and frankly, they don’t understand the performance implications). It’s all based on your needs
My personal approach is to keep things as separated and de-coupled as possible. This scenario outlined by the OP, however, would be an exception to my normal paradigm. Any time multiple actors need the same information, I personally avoid getAllActors (and its variants) like the plague. Passing the location in on spawn is a great solution which allows decoupling, but does not allow a dynamic goal. Another scenario where requirements definitely dictate approach. Passing the goal object itself to the actor would also be a great solution, and allow just grabbing the location whenever necessary.
Hi [USER=“145111”]One Mode Only[/USER] thanks for your input there, really helpful to get some more under the hood info. Any chance you could just futher clarify and break down for a newbie what you mean in your last three sentances about passing the goal to the actor?
Oh definitely, sorry for the vague bit there. I just mean passing the actual goal actor itself into the other actors. Like mentioned above, having a variable which is set to expose on spawn, so when you instantiate these actors you can pass the variable directly into it.
So say your goal is a custom actor, MyGoalActor. Add a variable of the type MyGoalActor into your other actor, for the sake of example MySeekerActor. Then, set that variable to expose on spawn, and upon spawning MySeekerActor, you set the MyGoalActor variable to the one that exists inside the level. Then, whenever MySeekerActor needs the location (if it were ever to be dynamic / move), you just use the variable it has to get the actor’s location.
