Yes, it has that same symbol with “Shotgun” next to it.
However, when I hover over it, the pop up says Child Actor Component so maybe that’s not the actual actor or if that at all?
That’s right. So drag it into the graph, and do ‘get child actor’ 
Oh wait okay. I apologize. I did it backwards. I didn’t pull from the variable itself that’s why. My mistake. I’ll test it once more.
1 Like
IT WORKED! I can shoot again upon pickup!
Thank you so much for your help! I really appreciate it.
1 Like
TAKE OFF!!! 
1 Like
Hello! Now that all of my ammo counters are functioning properly, thanks to you, I am running into another small issue where I am not sure how to make it so that only the specific set of counters will show based on what weapon is equipped. Each weapon has 2 fire modes so they have 2 counters each. So for example, the shotgun will have the shell counter and the freezing projectile counter. I had a few ideas but ran into some issues when doing so.
At the moment, all of the counters are visible on the HUD and I would like to only have the set specific to the currently equipped weapon visible. Thank you!
It’s looking good
I don’t really know how you have it setup, but it needs to be generalized.
Because you don’t know what kind of weapons you might make ( maybe one with 1 ammo type, one with 3 etc ) the weapon needs to carry the details of it’s ammo. Just like real life
So a weapon would hold all the ‘weapon dependent’ info. That would be, number of types of ammo, icons for the ammo, max amounts, timeouts before re-fire, and so on.
The most logical way to do that would be with a structure. Welcome to the thorny world of structures ( and arrays ).
Also, you need a generalized ammo status widget. It will receive the structure from the weapon, and make the display. And… you need to get the save game sorted out Otherwise the player ( and weapons ) have no way of knowing what was happening last time you were playing.
Sorry, it’s a lot, I know, but that’s a good way to do it.
Basically, the weapon makes it’s own widget when you pick it up, and gives it the structure. The weapon parent and widget are totally general, and the children are the things that contain the details.
It might also be good to learn about blueprint interfaces. Because they let you communicate without casting.
So because I have an array system setup for the weapon inventory, could I still setup a structure that includes Ammo Types, Icons, and all that and link it to my inventory array or would the whole thing have to be a structure?
I know that weapon systems can be setup with either arrays or structures, but can they be combined in certain ways? If so, how would that be done? Is this where an interface would come in handy? I know they are good in communicating between one another, but I’m not fully sure how they can be used in this situation.
Lots of questions, sorry.
And yeah, I’ll figure out the save game steps once I get the HUD working properly. May need your help with that, too, but we’ll see when we get there.
It’s looking pretty tidy, actually.
You can carry on like this with interfaces, actually, because you’re already using inheritance nicely.
If you want to do it this way, then you don’t need any structures, you can just use variables in the parent class.
Say for each gun, you have 4 arrays
icons
amount in gun
amount in mag
number of mags
Something like that. Then you can just use 4 arrays, one for each ammo type. And each time you want to change ammo types, you just move a universal index up by one. If it goes off the end, go back to 0.
You can totally do it like that. It’s just that some people don’t like lots of separate variables, and so they put it in a structure. And then have an array of that structure. It’s really the same thing.
In each weapon child, you just use those arrays to represent the gun that it stands for.
Sorry for the delayed reply.
So I have this base array setup so far in the parent weapon BP class. Now you said to have arrays in each of the child weapon classes but I got confused when I did that because I felt like I only would need one array in the parent class that the child classes will all inherit from somehow. I may not have set this up right either.
Anywho, I also have another thing now where if I was to do a universal index just like how the weapon swapping index is setup, well the weapons have two ammo types each that need to be displayed at the same time. With the index only selecting one input here in the array, I believe only one would show. Again, I may have just not set this up right either so do let me know if I have this wrong.
With each weapon having two ammo types each, is there a way I make it so that either the array has 2 inputs selected at a time if that is possible or make it so that the ammo counter widgets I have for each weapon are linked (maybe with an interface or just with variable references or something?) and hooked in this array and then I can switch the visibility with an index if that is possible? I believe with widgets, it’s not just as simple as set visibility on or off like the weapons, unless there is and I’m wrong about that too.
1 Like
Here’s how you figure out the child / parent thing.
Imagine writing all your weapons separately, one at a time.
After a while, you’d notice that you keep writing the same code, again and again. THAT’S the stuff you put in the parent. The only part that goes in the child, is the bit that doesn’t fit in the parent
What kind of ammo a gun fires, and if it has secondary or tertiary methods, is all child stuff, you see? You just can’t put it in the parent, because if you suddenly decide you want a gun that fires 20 kinds of ammo, you have to change the parent. And that’s nuts
I’m gonna show you both methods: multi-array and struct. We’re just going to talk about ammo types here.
Multi-array approach : ------------------------------------------------------------------
Parent
See I’ve got the data types, and basic firing routine here. But… there’s nothing in those arrays, and there’s nothing in the FireGun method.
In the child
( 20 bullets and 3 grenades )
and I override the fire method
And you could have another array of the ammo icons, blah blah etc… I only have the fire routine in my parent, because it’s simple. If you have all sorts of complex machine gun things going on, you might not implement anything in the parent, or you might override the fire method.
Structure approach: ---------------------------------------------------------------
Structure looks like this
And the parent code
Child code is the same, for this simple example.
So, maybe you can see, the structure approach is a very ‘neat’ idea, because you just have an array of everything you’re ever going to need. But, working with structs is messy.
In the multi-array approach, you just have a lot of arrays, and it’s up to you to remember which array does what, but the code is more simple.
Hope that makes some sense…
1 Like
Oh, okay yeah this makes waay more sense now. For some reason my brain just went straight to making an array in the code. I didn’t even consider variables as arrays. I understand what you mean now.
Thanks for taking the time to really go in depth with this for me. You are an absolute legend. I will be sure to credit you whenever the game is released 
I’ll give this code a shot tomorrow once I get home from work and let you know where we’re at from there.
1 Like
Okay, so I definitely feel like I’m in a much better spot now. There are still a couple of issues I ran into. But before that, I will show you all of what I have so far.
I had to tweak your example a bit to match what my setup was. So to start, I have two Interface events, one for the primary ammo types and one for the secondary ones as the two counters within the widget are independent of each other but have to be displayed at the same time for each weapon. I left the fire blank because each child BP already has their own unique firing setups within them. To accompany this, I have two Enums of the ammo types, two variables for the ammo amounts, and two “Current Ammo Types” variables. This allowed the primary and secondary types to stay separate, yet be linked together for the widget. I also still have the ammo checks in each of the child weapon BP to recieve the message from the ammo pickups and to clamp the values in a certain range. I think I set those up properly.
Here’s where I’m getting some issues though. So in the Ammo counter widget, I cast to the first person character and then to the weapon parent BP so that the info can get through. I then have the bindings for the counters and to change it’s color to red when it reaches 0. I think I either did something wrong in the Ammo Counter BP with the casting or something is not setup right with the inventory and get copy nodes (I figured I had to do that to include all the child actors, not just one). Or a big issue could be the fact that all the child actors are in the First Person Character BP. So I end up having multiple actors with child actor nodes that all have to attach to one input and I of course cant do that. For the INT message nodes, I made an array to connect all the actors together but I feel like that is another problem on it’s own.
The end result of this wasn’t too bad. The ammo counters did show values on the HUD when playing the game, but they we’re just set to 0 despite the ammo values I gave them in the child BP’s. Because of that, I couldn’t tell if they were switching (I didn’t implement the icons yet) but I would assume they were not. I also then got these error messages when ending the game, which is why I know the issue is somewhere in the Ammo Counter Widget or has something to do with it or with something linked to it.
It’s the common “Accessed none when trying to read…” errors. I tried using some Is Valid nodes in certain places but those didn’t seem to help much so there’s definitely something else wrong here.
It’s a lot, but I want you to see as much as possible so it’s a bit easier to see what could be wrong
A few things
-
Lots of casting can be avoided with interfaces. You can just send a message to the player and get info back. The player, in turn, can do an interface call on the weapon. But… I’ve never setup a detailed ammo system, what I’m thinking is, why not let the weapons make the widgets? Then you don’t have any communication problems.
-
You were talking about having a lot going on in the player. When you swap weapons, you should remove the child actor, and spawn a new one. The way, the player only every has to deal with one thing, the weapon. Initially, the player is empty, and can add the weapon component when they pick it up. That would deal with this problem
-
Consider making the weapon an actor rather than a component. Then there’s none of this child actor fiddle going on.
-
None errors and pretty easy to sort out. Click the last link in the error, it will take you to the offending node
First one, you’ve gone off the end of an array. Not sure about the second.
I definitely considered having the widgets just in the in the individual child BP’s at the very beginning, but didn’t get very far with that at the time because I didn’t know how to remove them from the viewport or hide them when I switched to a different weapon.
However, if there is a way to make that work, I can definitely go back to what I had before because the ammo did work. It’s just that all the counters were visible at once.
When you say make the weapon an actor, you mean just a regular old BP class for each of them right? I would agree that the child actors are quite a lot.
And actually now thinking about it, I’ve been having bad issues with my Niagara effects like the flamethrower and electricity beam where it flickers really bad or even just disappears at certain angles and it’s not because of fixed bounds and such. It may be because even though all the other weapons are hidden, they are still “there” and maybe they are interfering with the effects. It definitely could just be an issue with the current engine version as well, I have no idea.
So if I convert all them to their own BP Actors, how would I setup a weapon switch code that would actually destroy the actor and spawn the next or previous one in the available inventory? I would imagine it’s similar to what I have now but I don’t know for sure.
This is definitely my first time doing any of this as well, at least to this degree lol. But, it’s really good practice and your help has pushed me way further and it really motivates me to keep going. So again, thank you
This would not happen if you were dynamically adding the weapons.
No changes to the BPs, just the way they get added. Instead of adding a component, you can just spawn the weapon and attach it.
Like I say, one at a time… 
I don’t think you have to do anything, except change the code in the player.
Oh really? Well I suppose I’ll just give that a try then 
I guess that would be better for an inventory system too, where the player BP doesn’t have any weapons attached to start but once I run into a weapon pickup, it would spawn an actor in my player BP and it becomes available to use. Right? I feel like that’s a better way to look at it.
1 Like
To be clear, you have a widget problem, that you haven’t got to the bottom of.
But… if the guns manage their own widgets, I think you’re less likely to have this problem. It’s easier to control.
1 Like
Yeah it certainly makes sense. Like I said before, that was one of the first ideas I had but I didnt have as much knowledge at the time. I’ll definitely look more into it again because I think it’s a great idea and could make it less of a hassle.
1 Like
You make the widget from the weapon, which gives you a reference. When you’re going to destroy the weapon, you can just remove the widget first
1 Like