How do I limit the number of spawned actors to just one?

Hi,

I’m wondering how I can spawn only one instance of a Blueprint at a time, ie. when a second instance of the same blueprint is spawned, the previous instance will be automatically destroyed.

For reference I’m spawning the blueprint from a radial menu as demonstrated below:

Thanks!
Miley

There are several possible solutions but I personally would add this logic to my gamemode which than makes sure that there is only one.

1 Like
  • You can add a reference to a variable and check it before spawning.
  • You get check for all actors of class before spawning: if > 0, another actor exists.
1 Like

I’m wondering how I can spawn only one instance of a Blueprint at a time, ie. when a second instance of the same blueprint is spawned, the previous instance will be automatically destroyed.

As above, it would be close to something along the lines of:

3 Likes

Thanks for the reply. Unfortunately the actor doesn’t get destroyed. I’ve duplicated what you made though just wondering if I’ve got it right.

I’ve set the variable (New Var 1 in your example) to be the actor itself, is this correct?

Thanks again, Miley.

If that variable holds a reference to the actor, it should get destroyed. Is the other actor created here or some other way?

Or are you also referring to this actor?

Apologies for the low resolution images, the help is much appreciated.

There’s only one actor (campfire 1) which is being referenced by both the variable and the spawn actor node. Is this what you mean or am I missing something?

Asking since you have logic to spawn two actors of different classes.

Just wanted to make it clear that for this to work, the actor has to be spawned from this event or a copy of the reference already stored in this variable:

Ah I see, sorry I should’ve clarified. The second actor being spawned is assigned to another slot in the radial menu (which is based on an integer value). Unless I’m mistaken, the spawn campfire logic is self contained and is not referenced anywhere else, neither does the logic for the ‘spawn actor 1’ overlap with ‘spawn actor 2’.

If we put Print String here:

Does it print?

You have to hold the reference to the campfire outside of the campfire itself, else it would be a selfdestruction , potentially.

The best place to hold this kind of things is the GameMode or even better the GameState class of the game.

The GameState normally has all current information of your current game and is even replicated in the network. The GameMode is the manager of your game and provides important game functionality, like spawning your campfire.

So the (imho) correct thing would be:

  • PlayerController calls the “PleaseCreateCampfire” method on the GameMode
  • GameMode checks in GameState if there is already a Campfire reference
  • If yes the GameMode destroys the reference and creates a new one
1 Like

It does, it returns “Hello”

Oh, is the whole thing in the campfire actor?

The logic is held in a widget, not within the actor’s event graph, if that’s what you mean.

Ah ok. Than I got it wrong.
None the less you shouldn’t combine important game logic in things like the graphical user interface (like umg).

Always try to structure your logic by splitting things like GUI, logic , graphics, input,… from each other. You will have a much easier life later on.

1 Like

Thanks for the answer, much appreciated. I’ll give it a shot.

Edit: Ah thanks for the heads up regarding compartmenting the logic, a great shout.

Just noticed that what you suggested does work, however only when the character doesn’t move.

The spawn location is based on the player’s location and when the character doesn’t move, only one instance is called. However moving even slightly will call a new blueprint without deleting the old one.

It’s been a while since I looked under the hood of the Spawn Actor from Class node - specifically the behaviour of the collision override.

Can’t recall if Default still equals Ignore collison but try setting it to Always Spawn (or smth named like that). I’m thinking that the char movement component’s capsule’s collison handling may interfere here somehow.

Although it does sound like grasping at straws.

1 Like

Right I see, this took a different direction than I was expecting haha thanks for all the help, I’ll keep messing around and report back if I fix it. Thanks again!

1 Like

You can always disable collison on the campfire completely. At least you’ll immediately know if that’s the culprit.