Difficulties spawning/respawning - not sure why

Hi all, happy new year! :slight_smile:

I’m having some trouble trying to spawn a player in a very noddy little game I have here. I think what I have is kinda working, but the log is stating that it could spawn the player because of a collision at 0,0,0. That’s fine, I understand that, but what I’m struggling with is why it is trying to use 0,0,0 when I’m trying to get it to use the PlayerStart, which is at 0,0,100.

To explain a little further…

I have created a “master” map which is empty. When it starts a ui widget is loaded to display the main menu. Initially, you could see both the player and the ui widgets I’d added to the viewport which was really irritating. I spent far too much time trying to work out how “not” to show these, and in the end discovered that if I just destroy the actor for the player, the ui widgets go to, leaving a clean/tidy menu system.

I will confess to not being overly familiar with the maps/modes/ui stuff at the moment and struggle enormously with the barren/sparse ui documentation.

From the menu, when you then click play, the blueprint then uses “load stream level” to load in the “level1” sub level. there’s obviously no longer a player, because I destroyed them, so the plan was to just respawn the player, at which point I assumed the ui widgets would all re-appear and off we go.

I am really struggling with which nodes I need to do this… I am currently using “GetPlayerController” to then “FindPlayerStart”, then “GetActorTransform” before hooking that into a “SpawnActor”, selecting my player’s pawn, and finally using a “Possess”. I did also see that the GameMode has a “RestartPlayer” but the outcome of both approaches seems to be the same, e.g. the error about the collision at 0,0,0.

I’ve run a few Print nodes off of the initial process and the transform location for the GetPlayerStart is coming back as 0,0,0 which I think is the source of the issue. It feels as if this is just a default value that is being returned when it fails to find the actual player start, but I don’t know why it would be failing.

I note that I’ve not used the “Incoming Name” property, I have no idea what this is for. Feels like there is some kind of mapping missing between the player and playerstart, yet before I did the “destroy actor” thing to make the menu appear correctly, everything ran as it should, the player just spawned in the right place and everything was ok.

I’m losing sooo much time on this and going round and round in circles with OLD forum posts and OLD tutorials and sparse UE4 documentation, I’m a bit lost :frowning:

If anyone could spare a few moments to help I would be very grateful, if you have an example of nodes you could pop up in a screenshot of how you do it that might help.

Thanks in advance and happy new year :slight_smile:

  • Always make sure the Spawn node is set to spawn anyway ignore collisions by default, otherwise you end up chasing ghosts. Never used FindPlayerStart. Rarely use PlayerStart(s) except for trivial tests. Its safer to use notes / invisible / collision-less meshes or some other inconsequential actor and Tag them in the level. Then use Get All actors With Tag node, to get an array of actors, from which you can get locations to pass to the Spawn node. That way you can control the entire process and debug it explicitly. Otherwise controlling which single-player / local multiplayer / online multiplayer locations players spawn at is often chaos!

  • You’re asking for a whole world of hurt using Level Streaming so early on imo… Its broken in multiplayer right now for starters. Its necessary for optimization, but this should come later. Get a prototype working first. You have no idea how many gotchas streaming brings. One of the most common questions on here is how to solve the problem of spawning a player when the level hasn’t even loaded yet… But if you’re doing this for some other reason, then make it clearer. Remember you can package a sub-level as a blueprint too if you want to spawn things in / out dynamically. That way, similar to manual spawning, you get to keep total control and can debug it all…

  • Killing the player to hide a widget? Alarm bells… If its not to appear until later, look at timers or a key / button press or a 1000 other solutions, but not this! Agree that UMG / UI is tricky. Dissecting working solutions and customizing them to your liking is far faster than starting from a blank page…

  • Agree, the BP / UMG docs vary from awful to not good. Most are auto-generated from C++ source, but don’t contain the actual C++ comments, which are valuable. If you’re relying on BP docs to grow your game, you will likely fail and give up! Epic realize this and are working on a solution circa UE5. Meantime, Its better to take apart working projects found in the Marketplace / Community-Tools (fastest most productive option if you can work that way)…Or watch Tutorials (slow going for learning BP / UMG, frequently out of date or overrated)…

Hi @ClavosTech, thank you for the reply, really appreciated.

I should probably try to explain in more detail, but I’m concerned it will create a very long and confusing post, I’ll give it a whirl.

Regarding killing the player for the menu - I started off with an empty level, I set the default pawn in the game mode to the BP that I have for my player. In the level’s BP I added a UI widget for the main menu. When run, you could see the player pawn through the main menu UI, e.g. behind the buttons you could see the 3D model. In addition, because the player’s own hud (another UI widget I’d created with health/ammo etc) had been added to the player pawn, this also showed with the main menu.

I think I understand the problem, but at this stage I do not know really how to resolve it. I believe the problem is that the GameMode is loading in a tonne of actors into the level that I don’t really want, or at least, not at this stage for a simple level that should just be displaying a menu. In my previous experience with Unity creating a main menu was fairly simple, and the main difference was that I didn’t have all of the other GameObjects in the scene, just the ones I had chosen.

In trying to remove them I found that if I set the World Settings to use GameModeBase, I could display a menu without any problems, but then when the level loading (from clicking my Play button on the UI menu), the player pawn was no longer there - presumably because I was now using GameModeBase rather than my previously configured GameMode.

The most recent approach, for which I now feel somewhat tied in to as I only have another two weeks on this project before it needs to be handed in, was to create an empty level, named Master. I added a sub-level called Level1 which is the first playable level. Master currently uses a process of showing/hiding UI widgets to the screen for the various menu options for the UI. Thet GameMode issue was still the same, so, I used DestroyActor to get rid of the player, by doing so, the players own widgets (health/ammo) also disappeared. I had assumed that then simply spawning the player when Level1 was loaded would pop the player back in and all would be good.

The process of respawning was fairly horrific to be honest, and I can only assume this was because there was nothing tying the default PlayerStart (which was used successfully when just using the original GameMode) to my respawning. As such, the default player pawn was spawned at 0,0,0, have way through the floor of my level, which then threw errors about the spawning/collisions I mentioned previously.

The solution to this was to just add my BP for the player into Level1, knowing full well I’d have to do this on every level which would kinda suck, and then “possess” it when the level had loaded. This caused a little cascade of other issues as I had so many things assuming that the player would already be in the level.

I have had enormous frustrations over the execution of things. I had assumed that a construction script would be executed and completed before any BeginPlay events, but there seems to be no control over which things execute in which order at the BeginPlay level, and again, limited documentation on this. I have now had to throw an event when the player is possessed so that I can then tell other things “Ok, the game has started, created your references” - this feels ridiculous being that the engine itself is already doing this through BeginPlay, so I really shouldn’t need to do this.

This has been a project for college (mature student), the main aim was to recreate the “mechanics” from an example project, because of the limited amount of time we had, I didn’t really have time to look at other example projects to try and dissect and find out how things have been done, most of the research has been carried out searching the web, looking at articles, documentation or the odd youtube video. Each time I’ve turned to the documentation I’ve felt disappointed, a simple “usage example” on each page would go a long way to being useful!

Can I just ask, from a “high level”, if you were just creating a simple game, with a menu, and a single level with a player moving around and shooting within it - what approach would you take to creating the menus and loading the first playable level? I don’t need the “nodes”, just a description of the steps you’d take for example.

I had used just “OpenLevel” originally, but then things like playing the games music stopped because it was playing via the previous level (with the menu), the Master level approach above at least gets around that by adding in another level into the current one, or at least, I think that’s how its working.

Rob, I think with a few key bits of information and corrections on where you are experiencing frustrations you’d be well on your way. But before working through the problem I wanted to ask why do you even need a menu in the first place?

Edit - I worked on some stuff for you hope it helps:

I recommend for now putting aside your project and reviewing the platformer game sample on how it solves the problem. I’d then go back and fix your menu and work on the separate mechanics replication problem you made reference to. After you’ve gotten through all of the required work on the project you can go back and try to unfix your original problem as a lesson, but my current assumption is that you’re solving the wrong set of problems because of how you started off - hope that makes sense. I’ll make an effort to respond to any replies, GL with 2 more week >)o.0)> :slight_smile:

Hi @oldhighscore, thanks for the reply and the links, I’ll check them out in a sec…

The menu was for the usual Start, Options, Quit menu system. Start to play the game, loading the first playable level. Quit closing the game (appreciate mobile devices have other considerations around this, but this was just for a Windows platform), and Options for providing the ability to, enable music/sound effects volume changes and saving of player preferences.

In the same way, I wanted to have a separate UI/scene/level (call it as you will etc), for the game over conditions, player win / player lose - these then have options such as “Play Again” / “Main Menu” / “Quit”.

Hope the above explains what I was aiming to achieve. Will check out these links now - thank you :slight_smile:

Rob I literally edited in the same minute you posted, just wanted to make sure you saw the final edit can you confirm?

Hi again, thanks again and for the update.

The first link I had seen before, although I’m still not overly “getting it”…

From what I can see, a lot of that happens before there’s a “node” I can use, e.g. the light blue vertical column at the bottom. It also suggests that BeginPlay occurs before GameMode doesn’t it? And with regards to the red column on the right, the “create delegates” step for example, does that relate to the use of Event Dispatchers or is this something “behind the scenes” rather than something I can interact with. This is what I find challenging with this image as I don’t see how it directly relates to Blueprint.

If I point you to a similar image which Unity provided, which I think explains a similar process;

That I find a lot easier to understand, as the steps kinda tally up with the code you could right, e.g. the functions you could call. There’s also quite a bit more text to help explain. I’ve tried to find something similar for Unreal to help me understand/learn but haven’t found anything, so not entirely sure if this “is it” or if its something else.

I’ve only dabbled with Unreal and C++ a tiny amount in the passed via an online course, so everything is Blueprint focused at the moment, which, coming from a C# background I find a bit challenging as I find it kinda obfuscates whats going on because I cant see the actual code. (separate issue).

The second link however looks like it will be really useful, and I agree with your suggestion, for now what I have is “kinda” working, there are no errors, it just feels a bit of a mess and that I am probably recreating functionality that is already present (somewhere). Changing things now would be detrimental from a time perspective, so I’m going to finish the last few features and wrap it up, but as you suggest, I’ll then work through that example and then see if there’s a penny dropping/eureka moment where things become a little more clear and I’m able to see where I went wrong.

I couldn’t help but notice that the page linked first talks about “slate” (not sure what that is yet), mentions it can be used for tools and in-game UI, and at the same time suggests if you want to create in-game ui to use UMG - which is what I’ve been using (to my knowledge). That’s a bit confusing/odd, as it isn’t overly clear which should be used. Any thoughts on that?

The slate thing mentions about using a PlatformerGameMode which then provides a level with a menu system built in, kinda what I was trying from the outset…

Thanks again for the reply and info :slight_smile:

Here is perhaps a better way to conceptualize what you are creating.


You can see the actual unreal source code even if you are using blueprints. I find looking at the unreal source code can be a better resource than their documentation, which as you stated with your lovely reference to Unity as a perfect example of what the Unreal documentation is missing at the moment.

For my curiosity I did this for the game mode base and I now have a rough idea of how the world is created and it’s first actors are spawned. From here I can continue down the execution path and so on. So I’m going to agree again on the documentation bit, but having access to the source code is helpful for those who can navigate it.

Plenty of thoughts -_-

Your welcome for the info, glad I can aid in anyway, this helps me too :slight_smile:

Thanks again, the diagram is handy as it also gives me an indication of whether I am storing things in the right place. My course hasn’t covered things like GameMode / GameState and so on in a huge amount of detail yet (year 1 of a 2 year course, so hopefully more to come). Possibly the closest to a “best practice” I have yet to find! :slight_smile:

Sorry, when I asked if you had any thoughts, I didn’t mean on the confusion regarding the documentation, I meant whether to look at the ui slate stuff or the umg?

I know, but I also don’t really know myself. I’m still learning too!

According to the docs I just read >

So I think you should look at one or the other, or both, or neither depending on what you are trying to accomplish. Try using both at least once and try to start thinking what use cases would be better implemented in one over the other.

Knowing where not to look is just as useful knowing where to look. o.0

I come from a web programming background so I relate Slate to being a browser with the power of a desktop and UMG as what compromises the game experience I might be after, say the speedometer in a racing game or a crumpled old map in some battle royale clone. It might not be ideal to use the Slate UI framework for the dashboard in my Jet spacecraft but I’m certain it’s possible. Another best practice you are after ~-~

young padawan ~-~

Guess I’ll take a look in a couple of weeks when this project is done and dusted…

“young”… chuckle… I’m 45 this year… young at heart I guess… the image of baby yoda is quite apt though, big welling up eyes is pretty much how Unreal has made me feel! :smiley:

Thanks for your time and replies and thoughts, very much appreciated :slight_smile:

Lots of walls of text for a Saturday :p… Slate, WTF? Ignore the docs! Instead study projects by devs listed here. Regarding the framework @RobMeade, you can cut it down to just 1 or 2 classes → Character (or Pawn) + Gamemode… Everything else is optional during prototyping in single-player (often multiplayer too). Player-Controller is important, but it can be ignored for now if it contains no code (just understand that it underpins cameras / inputs / spawning / UI etc). See this + this.

Hey @ClavosTech, thanks for the reply and the links, I will check them out.

Regarding “cut it down”, most of these things are appearing by default though with the default GameMode… I really didn’t want a level full of “clutter”, or at least, would prefer my own clutter… but it all comes with the GameMode… in order to cut it down, presumably I’d need to define my own?

Thanks again for the links :slight_smile:

Not sure how to reply but I’ll try… For some devs, the huge amount of small assets in UE4, split into small files across many folders is distracting. So before getting to work, they want to tidy all that up, fix the org, and place everything into better named more sensible hierarchies… The danger is, sometimes in doing so they break the entire project (its a common problem). My suggestion is, try to just go with the flow of the framework for now, and accept that Custom-Gamemode or not, UE4 is going to create default classes anyway (watch the Outliner window during PIE).

So try to focus on ‘utility’ for now. Ask yourself: Is the project doing interesting things that holds your interest and is fun (even if the org feels like chaos)… Basically if you can chill, then you’ll keep progressing, which is what you want. Looking for an analogy here, its like cleaning your home. But you can’t start unless everything is organized perfectly into drawers / boxes. So in the end, you never actually start, just keep putting it off… UE4 is messy, simple as that. But if the ideas you’re working on feel like they have utility you may get past that. Then later ‘get cleaning’ etc. :slight_smile: