Suggestions for the 'proper' way to scale up a weapon system...

Development Programming & Scripting Blueprint
1

Hey guys, I could use some experienced input here… my head is swimming with too many options.

I’ve been developing a 3rd person shooter game for the last 6 months and currently have a single rifle weapon working exactly how I want it to. Now, I’m trying to go back and scale up my BPs so that the player can swap out different rifles. My problem is that, right now, this weapon (WeaponChild_Rifle_BP, a child of BaseWeapon) is a Child Actor Component of MyCharacter BP and my initial plan was to simply create duplicates of WeaponChild_Rifle_BP for each of the ~15 types of rifles I’d have in the game, setting the ~30 variables (WeaponName, SkeletalMesh, ReloadSounds, BaseDamageValues, HeadshotModifier, etc) uniquely for each, and calling each weapon BP as needed. However, now that I’m getting into it, it doesn’t seem that it’s actually possible to change the Child Actor Class BP on the fly, as I once assumed it would be.

So, what’s the proper way to go about this?

To me, for both cleanliness and efficiency reasons, it *seems *to make sense to create a child BP of WeaponChild_Rifle_BP for each rifle that I’ll have in the game. That way, every rifle is a contained unit and will be nice and organized. Great, right? If so, though, how would I reference all of the currently equipped child rifle’s variables from that parent BP?

Apologies if this is confusing… it is for me too!

Thanks

2

Yes keeping the rifles as their own independent blueprints that are children of the main rifle is definitely the way to go.

You can reference the child actor properties and parent properties directly in pretty much the same way you would access any other blueprint.

3

Hey ZoltanJr, thanks for the response. That’s great to hear I’m not crazy… well, not about this, at least.

Are you suggesting to leave all of my event graph in the parent rifle BP and then simply cast down to each specific child rifle blueprint, using a switch and pulling back all of the child variables so that I can set the 30 or so main rifle BP variables?

4

Hrmm… ok, I might be crazy after all. It seems that trying to cast ‘down’ to the child is a big bad no-no. I’m getting a dirty BP that won’t compile and doesn’t give an error. So if casting down is out, I’m back to square one… :confused:

5

if the ~30 variables are all located in the parent can’t you just set them in the defaults of the children? Or is there a reason you have to set them at runtime?

6

Absolutely - that’s the goal. But then how do I tell the parent BP [which is a child actor component of the MyCharacter BP] which child to ‘become’?

7

Ok… quick update, it seems I *can *cast down to the child blueprints and it’s working but the parent BP remains dirty [without giving an error] even after I compile it. When I PIE, though, I get the following error:

CompileError.gif

Then I found this topic on answerhub: Unresolved compile Error (while there is no Error) - Blueprint - Epic Developer Community Forums

where Ben Halliday says:

…so it technically works and the parent/child dependency seems to be what’s causing the dirty compiling but, certainly, I can’t be the first person to discover this? I have to be doing something backwards. Right???

8

Out of curiosity, I opened a copy of my project in 4.8P4 and it runs beautifully. I had to tweak a few cast nodes that are now unnecessary, but no longer getting any compilation issues by casting down to the child blueprints. My next step will be figuring out how to pull each of these 30 variables into a struct so I can pull them into my parent BP cleanly.

I’m still open to hearing comments on this methodology. It’s working but if there’s a better way, I’m all ears.