Ran into a weird scope issue today. The reason I think it’s odd is that I’m pulling three variables from an object - two INTs and a NAME variable - and the NAME variable is being updated fine. I’m getting out of scope errors on the two INT variables though (Current Stack Size and Max Stack Size).
Any thoughts on why only some variables would be in scope, when they’re all being called the same way, from the same place?
The Objects in the array have names, but do they inherently have values? Wouldn’t you store those values in Int Arrays and then line the indexes up so that Index 4 of Int Array has the correct value for Index 4 of the Object array?
What makes sense to me right now is that a name is a value, same as an int. I had to create the name value and set it in the BaseItem blueprint, which is the exact same thing I did with the ints.
In this context, I’m currently understanding the term Object to mean a container (of sorts) that holds data, like names and values. Because of this thought process, your suggestion sounds like I’d be making an array of ints for an object that always has one int (i.e. I won’t ever have multiple Max Stack ints for the same object).
I needed an array to hold the objects, and each object holds the individual data that I need. I could be wrong, but it doesn’t make sense to me that I’d need an array to hold data that’s already being held inside the Object. I should be able to just call on it on a per-object basis, which is what I’m attempting to do with the for loop.
But please correct me if I’m wrong. I’m not a guru at blueprint (or code logic).
When I pull from the array object, it allows me to get the variable…
I think(which may not be exactly right) that you might be better just use a regular native class(like an Actor or Object array) to store your reference.
It might be sort of bug of blueprint compiler that it forgot to cast to your BaseItem_C, or maybe you need to actually cast to your actual item class before you access your item.
So, try create a interface for your BaseItem class and then use interface function to return value instead of directly get the variable value.
Then all the get happened with in BaseItem’s class scope, and could possibly avoid any compiler/blueprint bug that Epic hasn’t fix yet.
If above does not fix your problem, you should post a bug report on answer hub.
@penguin - if he followed my tutorial on the other thread about this inventory correctly, this is part of a function called after BASEITEM has already been cast to. I have no issues with it on my side and can’t make it throw out of scope errors.
@ - I would suggest going back through my tutorial on the other thread to make sure you didn’t miss something small that is causing this issue.
