Thats not possible. There are two ways that may solve this issue though first you could try using loops. Second you could modify the varible types. Both depend on the context however so i would need to see more of your script to better help.
Hello. I’m making my armour system and I’d like to know how to do what the title says, if it’s possible. I need to do it like this because I can only put the BP Base Armour into the Armour Info variable
once and I have 6 pieces of armour. Thanks for any help.
Just from the looks of this minimal bit of script I think you might want to be using “parent-child” hierarchy for your armor pieces. If each piece of armor is going to have common “variables” stored in a struct you want to manipulate while remaining under the umbrella of “base armor”. This way you cast once to the “parent class” the object reference would become a “variable reference” of the parent class so any child would fulfill the criteria of the “object pin” and the output pin of the cast would be the specific armor type you fed in as the input object variable ref. Then you could pull “armor info” out of any child with a single cast node. Otherwise as ThompsonN13 said, you would need to loop through all your armor pieces and check which is the one you collected or whatever.
As ThompsonN13 said it’s hard to offer much help with that little bit of info so I will offer a different approach to get this without casting directly and perhaps it will give you some ideas on how to proceed.
If you use an interface (something I feel like I’m spruiking a lot lately…) you can pass the information from that blueprint to another without needing to cast to it.
For this example, I’m making a few assumptions from what I can see from your images so it may not fit your problem perfectly but you should be able to hopefully make it fit, or at least take some ideas from it. I’m assuming each of those is a child blueprint component and that BP_BaseArmour is the parent class.
The first thing you want to do is create a new blueprint interface and create a function in it with a return value of your armour info struct.
Then you need to add that interface to your BP_BaseArmour by going to Class Settings->Interfaces->Add->Your Interface. Any children that this blueprint has will automatically inherit that interface as well.
This will give you an interface function that you can then add your struct to and any time this is called it will pull the instance of that variable associated with that specific blueprint.
To call the actual interface function, you can then use your component, get the child blueprint reference and be able to call the interface function without having to directly cast to it and you will get your struct for that specific piece of armour.
Thanks for the replies and sorry for not including more of my BP. I thought/hoped there’d be a way to just connect them all to the single object reference lol.
Basically, I have a base armour and base weapon that I create childs of to make more weapons and armour. (I’m using the system in Titanic Games’ RPG tutorial). All armours and weapons have the exact same variables.
I’ve set up an attribute system for my character, and all the attributes start at 0. The different weapons and armour that gets equipped increase those attributes, as shown in the more detailed BP below. Atm I’m basically replicating what you see in the BP below a further 9 times, to get the head item, torso item, feet item, left arm item etc and it’s taking it’s toll as it’s on the tick (hence the 0.4 delay).
Hope this is a better explanation. Again thanks for ur help. I’ll look into the interface idea to see if that helps.
Yeah haha. Well, what you see in the BP x9 more times lol. I did try connecting to Event Begin play, but the attributes didn’t update when I put the armour and weapons on. I’m still pretty new to BPs, but with the tick, the attributes updated, so I assumed the attributes needed to be updated fast so they register when you equip them? Sounds like there’s a better way though >.<
I’d like to think we are. I’m not even in any programming discipline, I do medicine but I taught myself a good amount of Unreal blueprints in a year and remembered how frustrating a lot of it was when it didn’t have to be. I posted a few questions here, none got even a comment let alone an answer! So now that I feel slightly experienced using blueprints I figured I’d give back to the community and help people as best I can.
This is running on tick?!!? Why?? Why would you need to update player attributes every 0.4 seconds?! What exactly is this armor system you have here??
Oh no, no, no…haha this is terrible for performance! haha You need a function that will run this ONCE when you change armor or whatever, you call the function and it runs this code, updates everything and stops. You are having the processor check every 0.4 sec if anything in all your armor changed, EVERY 0.4 seconds…that’s insane haha luckily it is just a lot of math looks like so the computer is pretty good at handling that but still man, this is crazy I didn’t expect that! Yea we need to rework this for sure. Event begin play only executes ONCE thats why it wasn’t “updating” because once you “begin play” it sets the armor variables and after that does nothing. So a function would be much better suited to handle all of this, or at the very least a “custom event” you call on pick up or change out of armor
A super quick fix for this would be to
- Create a function call it what you like “Update Armor” (you can do this on the left hand menu panel in whatever blueprint you are running this now should see “function” click the “+” next to it and it brings you into the function editor)
- Cut this entire code from here and paste into the function
- Hook up the function execution pin to the sequence input where you currently have the delay going
- Connect the “Cast to BP_Base Weapon” to the 0 output of the sequence (you will need this reference) and then connect it to the other “Cast to BP Base Armor”
- Wherever you are “picking up” armor, the end of that execution pathway should then “call” this function we just created, so drag off the last output wire in that sequence and type “Call” and search for this function name you made in step 1
- You may have to cast to whatever BP this function is in if it is not the same as the one where you are scripting the “pick up” logic but that is a minor thing
I am sure there are ways to optimize this further but that would be the quickest, just cut/paste this into a function and call it. Hope that helps. Good luck!
dude no just no. on so many levels.
ok so im assuming that your just trying to add together all the stats from your weapons and armor. theres no need to repeat this process for every piece of armor and there is really no reason to be doing it on tick either. first lets leverage logic to simplify the process here. each piece of armor should inherit from a base actor that defines all the basic variables (it has a variable of the type of your struct). below the base armor you can have children such as chest piece, boots, gloves, etc that all will inherit from the base armor so you can cast to that if need be or to simplify this set all the armor pieces variables to the type of the base piece (this is what i did in the picture. my base armor is just called armor). make all the armor pieces into an array and use a for each loop. the for each loop will run its script once for each item in the array. so as you can see in the below picture it gets the struct from the armor and adds it to a struct of the same type on my character then sets the values. easy to do and you dont need to copy the script a ton of times.
now as youve already noticed doing all this on tick is very cpu intensive. to combat this make a custom event and only call it when you need to update the stats. for example call the event when the game starts to initialize the stats, then only call the event again when a piece of armor is changed. with fewer nodes and not a ton happening on tick you will see your performance come way up.
haha pretty much my reaction too. its actually worse though since things ran every tick is every frame so itd happen way more than just 0.4 sec its more like 15-120 times per second.
Haha I was shocked too, but the OP did manage to squeeze in a “delay” of 0.4 sec before the sequence, that’s what I was referring to. But it’s pretty bad either way. Oh well, that’s what this place is for…living and learning.
o yea didnt notice the delay through all that. yup this is the place to learn to do things better. well at least i hope we are helping people haha
Hi 
I tried doing it both ways suggested. Both result in the engine freezing for a few seconds whenever I equip an item. In the BP below, “Update Stats” is where I put both solutions, 1 active at a time obviously.
And for some reason, I get no data in Thompsons way (and lots of errors, pic below), even with the engine freeze when I equip. Nebulas way, I get the data, but the freezing gets more intense with each item equipped.
The 1st pic is Nebulas way, if I did it correctly. It’s pretty much the same as the BP pic above, except in the pic above, i forgot to make it so all the variables add up into one, so it was resetting the variable instead of accumulating. It now accumulates and looks like a jellyfish, sort of.
Nope… this looks worse than what you had before. The BP_Stuff3 image which you said was my way I don’t even know how that is working! It doesn’t look like the function is even hooked up to the sequence…is it? I don’t see a white wire from the purple function to the sequence node. BP_Stuff2 which is the interface call image I believe, I can’t even follow that logic, it looks like you threw about 3 different ideas together into one. And finally that image for “update stats”, you shouldn’t be looping through each inventory item and setting the values if you are picking up armor pieces individually. Only the piece you pick up should need to update itself. I will try and post a solution later today but this is crazy mess I’m not surprised the engine freezes when it has to run this code. But no worries, the solution is pretty straightforward.