Hi all,
Not sure what the issue is as this suddenly just stopped working.
The process:
UMG Weapon Selection → Defines Data Table index → Fires event that spawns Actor from Blueprint Class in DT Row and Attaches to the actor.
After some troubleshooting, I have found that everything executes correctly when fired from the BeginPlay event. But when firing from a Blueprint Interface Event the weapon does not spawn.
This works:
This does not work:
I do not know why the above does not work as the print string does indeed fire and
this wasn’t always the case as this was fired from the Interface event just fine before.
any suggestions?
Hey @anonymous_user_3cf2ac1c! My first thought was this is probably related to data table shenanigans, but we have to rule everything else out here. The only true functional difference between BeginPlay and triggering it any time after that is the timing in which it’s fired. That said, let’s do a couple of further tests. I see you set up that cast, any way you could pop a print after the cast to verify it was successful (we’re sure it was but still), then a breakpoint on the GetGunData node afterwards?
On your game instance, are we sure the data table is updating correctly/pulling correctly?
1 Like
Hi and thanks for the help!
So after some troubleshooting I have a better understanding of the issue. The sequence was executing correctly, but what I found was that it was no longer attaching to the gun to the Actor that I had dragged into the level but to the PlayerStart actor only? It hasnt done this before and both actors use the same BluePrint Class so I dont understand why this has developed.
Actor 1 was dragged in and I have been using it as a model with no problems since this development.
Actor 2 is the PlayerStart location.
Before Start:
Starting game and choosing weapon
Actor 2 (Player Start location) had been sitting off camera somewhere and Actor 1 is what is used when the Menu is exited and other level loads, so the gun is missing. Again it is really perplexing because They both use the same Class BP and is set as the default pawn so why does Actor 1 no longer get a gun anymore? Cant say if Actor 2 was receiving a gun as again it was off camera.
Thanks Again!
Ahhhh that is weird, I see where it attaches is a variable called Mesh, if you’re anything like me that’s probably dragged out from the hierarchy itself right? It should apply to both if that’s the case, unless where mesh is defined you snagged the player controller 0 or something, the player start actor always steals that over actors in scene.
Mesh has dragged out hierarchy so it should apply to both, right… Ill be more than happy to send you my project if you want to look around it yourself. Because this just seemingly developed on its own and I am a noob developer.
Hrm, don’t know, that probably is against our security on my teams side, but I will be looking into this a bit more. Probably just need to look through the structure a bit. Is this going to be multiplayer?
I cant imagine anymore then a simple Co-Op? Let me know if you want screenshots of the whole process, its not too complicated.
I’m replicating things on my side to test and yeah that’d be great to see the rest of your construction, though it probably lies in what we see above, can’t hurt to have more information!
Edit: For a moment I thought it could be that you have it set to stay at relative to where it spawned, but if it spawned 0,0,0 of it’s parent instantiation it should remain on whoever the mesh is.
Here’s a question, are both characters receiving the message to do this? I’m thinking the only one getting it is the new one, otherwise it would work fine for the other, in my tests that’s been the case.
Thanks so much for sticking with me on this.
Im not sure how to specify only a single entity of class spawn to uttilize the BP. I havent messed with instances at all and this seemingly happened on its own.
Something I did that was a little fishy was delete the savegame file from the EXPLORER content browser on the desktop while Unreal was open (to check its functionality).
I looked over the savegame area numerous times in my troubleshooting but didnt see anything that would cause these problems.
Let me layout the process:
Bread and Butter: Data (Game Instance)
UMG Weapon Selection & Calling interface (Widget):
Spawning Weapon & Calling to savegame (Player Actor BP, would you recommend putting this elsewhere? Say Gamemode?
(The step was a bit more complicated with a simple check to see if the savegame existed after the print string and before the actor destruction, removed during troubleshooting)
Savegame (Also GameInstance)
Apologies for any very obvious errors as these snapshots are from a recovery of when the engine crashed, but it looks as intended to me.
Again thank you for your help !
Actually this is quite good across the board, just a couple of questions to get a better grasp on the inner workings here and also refocus on our issue. (I work lots of threads so I sometimes refocus, also catching up people to the thread in one quick move).
So issue initially was that the gun wasn’t spawning, but we realized that it is indeed spawning, but on the character from player start and only them, and now we’re trying to ascertain where you need to change things to make sure it spawns on both instances so you can continue working on the model in the menu/viewport, but the player itself can be disabled off to the side right?
So I think I see where the defining moment is. So we knew that somewhere in the system, it only points at player 0, which the player start will always generate as in priority over even actors in scene even if they are the same.
So I’m thinking the reference passed through that interface points back to the player as shown there, but this only references player 0, and the pawn that spawns from player start is always going to be 0 because they always auto possess. This means that whenever this is used, it will only effect the pawn you are to be controlling right then and there.
Now onto solutions, there’s a million ways to do it but most of them are either hacky or will require structural changes. I’ll go for some recommendations for structural changes.
-
Have a separate (likely child) class for the menu guy, and just have a reference to her as a mannequin directly to mimic each thing that happens to the player. This isn’t as clean, but this gets the job done relatively quickly.
-
While doing this, is probably also really easy. Basically doing a for loop and attaching guns to all actors of this class BUT if you do multiplayer you’d have to rework it. (you still have to rework it as is using player 0 though so not a bad trade off)
I think 2 seems to be the best here and should work out of the box. Doesn’t mess with UI or anything. Only downside is if you wanna change the guns on it you’ll have to loop whatever you do to change the gun on that character as well.
Thank you for the compliment, means alot for a first project!
Ok interesting, Ill take another look at where else I have uttilized "get player charcter " as ideally id like to have this working as before rather than new implementations.
If I cant Ill work on reworking on according to your suggestions over the weekend.
Another solution I thought of: I could just use the player start model as the menu model since the gun does spawn on it. Im just worried that this issue will present itself again in a multiplayer environment later down the line, and resolving it then could be terrible.
Ill provide an update. Thank you!
This was originally cast to “BP_Player” instead of casting to directly the interface and I was still having the problem. I used this in an attempt to troubleshoot and left it in as it seemed like the proper move and fired all the same.
Will include in future troubleshooting:
Took a look back at an older verison where I was using an event dispatcher and I didn’t want to be casting to the widget using the Event tick so this is why I decided to use an Interface.
Ive decided to just use the Player Start model for the time being.
Thank you so much for your help !! Ill probably have to use your solutions for multiplayer. Again! Thank you!
All good, and yeah you got it! If you’re going to do multiplayer then you will need to change out every instance of getting the original player. But for the most part you had everything all together, just needed a little direction. Excited to see where this project goes!
