Why can't uobjects spawn actors?

Development Programming & Scripting
1

I’m creating a spell system. My spells, which are UObjects, are in charge of keeping the spell data - like cast speed and the next time it’s able to cast - but they’re also in charge of executing what the actual spell does - like creating actors. For example, there would be a spell called “Spell_Fireball” which creates an “A_Fireball”. Pretty standard, right?

The problem is that I can’t create actors from UObjects. At least, not in blueprints. This is a problem because, well, my spells now cannot interact with the world. I’m forced to either make my spells actors, which sounds awful in so many ways, or couple them with an actor which can create actors. Both sound like extreme code smells, so I’m not sure what exactly to do.

If someone can shed some light on why it’s like this, and how to do it differently without the two ways I’ve already mentioned, I would be very grateful. Not to mention UObjects are not replicated by default, so doing this in a replicated environment will give its own headaches, but one problem at a time!

2

UObjects dont have a World Context. In C++ you can simply overwrite GetWorld() and telling it where to get UWorld from (many can exist at once) and everything will work like in a regular BP.

If you can´t do C++ than simply pass some Blueprint along that does the Spawning for you and returns the Spawned Object.

3

Thanks for responding, but your suggestion isn’t working for me. Where is your first picture located at? Because when I try to do that I get the error “Wrong class to spawn in.” Is that the “Construct object from class” node in the UObject? It also calls for a pawn class to be the instigator.

4

Its Construct Object from Class in any regular AActor based BP. You gotta create your UObject at some point right :stuck_out_tongue_winking_eye: you can also Construct object from within a UObject if needed. Just remember you got to keep the UObject refferenced somewhere in a Property or they get Garbage Collected (Can´t survive on their own basicly)

5

But I can’t use the “spawn actor from class” node in a UObject - even if it’s branching off of an actor that can. It’s literally impossible to make it appear in the event graph. If I copy and paste it, an error appears. I can bring up the “Construct object from class” node in an UObject but when I choose an actor for the class an error says “Wrong class to spawn in”.

Can you show the graph where you spawn an actor in an UObject graph using a reference to an actor?

6

“The problem is that I can’t create actors from UObjects. At least, not in blueprints. This is a problem because, well, my spells now cannot interact with the world.”

The chief difference between AActors and UObjects is that AActors can interact with the world and UObjects cannot. This makes UObjects significantly lighter than AActors, which is their advantage.

Nachtmahr is on the right track; you will need to give your spells access to an AActor that can do the spawning for you. But as I read the example provided, you’re trying to spawn that intermediate AActor BP from your spell UObject, which you can’t do (if you could spawn AActors you wouldn’t need the intermediary).

Hard coupling your spells with a specific actor class is probably not the best way to do this; then you’d need all AActors that use your spells to have access to that specific AActor class, or be a child of that AActor class. What will probably be your best bet is an interface that your spells can use to trigger a spawn from an outside AActor.

When casting a spell that requires a spawn, you can require an AActor that implements the interface to be passed in to the spell as the SpawningActor.

When the spell is cast, if the SpawningActor isn’t available within your UObject the spell will fail silently; so you’ll want to verify the passed AActor implements the interface before continuing execution (DoesImplementInterface). With the interface verified, the spell UObject can call a method defined in the interface from the given AActor.

Define a “SpawnSpellEffect” method in your interface (use whatever name you like); you will need to pass in the class to spawn as an argument, and probably want to pass in a location, and maybe some other parameters - that’s up to you. I’d suggest having the SpawnSpellEffect method return the newly spawned AActor, that way your spell can continue manipulating it as necessary.

Any AActor (or object) that casts a spell will need to be able to pass in a valid SpawningActor (which could be itself).

Any AActor you want to be used as a SpawningActor would need to implement your interface, and define the corresponding method(s). Each of your SpawningActor(s) can also define their own ruleset for success and failure of spawning spells.

7

Yes thats why I told you to have the Spawning Process outside of your UObject. Your UObject just holds a refference to a Actor and tells him to Spawn something. The Spawning Part itself is inside the Actor and not in the UObject.

A simple Function that returns the Spawned Object refference back to the UObject. (You can add the inputs you need like Class, location, Texture to use whatever ;P)

If you want to Spawn Actors inside a UObject you have to provide the World Context via C++

8

To be Honest thats the strangest approach I ever heard :smiley:

Why would you use Interfaces at all? If you need a easy to Access Object that does the Spawning there are planty to choose from like GameMode, GameInstance, PlayerController, etc. A Interface you use if you dont care at all how the Function executes but in this case you definitly care and want a specific Spawning Process to choose from. The Ruleset should be on the UObject. I dont see any reasson letting a external thing decide when or even if it can Spawn. Thats something you do way before the Spawn call.

A smarter approach would be to have a Spell casting Component that also creates and Holds the effect Objects and servers as a Bridge between Object and Caster (owner of the Component, that can be any Actor). And as it happens to be its also a good Candidate for World Context aswell as Target for a Incoming Effect.

Anyway what I wanted to tell Asusralis in a Nutshell. UWorld does not know about UObject and UObjects dont know anything about UWorld unless a Context exists they Communicate trough.

9

An interface is used to allow different objects to use the same function definition with multiple implementations on other objects. I’m not saying use an interface just to spawn the object, but use an interface to implement the spawn.

“A Interface you use if you dont care at all how the Function executes but in this case you definitly care and want a specific Spawning Process to choose from.”

Not necessarily.

“The Ruleset should be on the UObject. I dont see any reasson letting a external thing decide when or even if it can Spawn. Thats something you do way before the Spawn call.”

The spell may have a ruleset for when it can cast, but the casting object also may have a ruleset. Using an interface allows more flexibility in the long run, and an easier way to allow multiple AActor types to cast the same spells.

Just off the top off my head, you could have a Wand item (AActor) that has a recharge time between spells, or has a limit on the number of spawned elements it can track at a single time. You may have a Wizard character than can only perform one summon spell per day, but multiple summon spells. Each summon spell won’t know that the Wizard has used its summon spell for the day, but the Wizard will.

This seems like a pretty standard way to use an interface.

It may be better to have a separate method that determines if the spawn can be performed (e.g. CanSpawnSpellEffect), in addition to the SpawnSpellEffect method that actually performs the spawn.

10

Your “spawn effect” method doesn’t know what class should be spawned.

This is partially why I suggest building an interface. You can create a function definition and then any actor can implement it, rather than having to know the specific method available within each actor.