Hi, I’ve been working on an Item system, which relies on interfaces. I have a macro that wraps extracting an Item Interface reference from an Actor, which works just fine. Well, until I started on the Inventory, used an array of Item Interfaces and wanted to remove an existing item: it didn’t get removed.
After some debugging I’ve boiled it down to the cause being the Select in my macro so far, and made an as short example as I could.
For now I’ve applied a quick fix where I call ToObject and cast back to the interface before doing array operations and it’s working just fine, although an ugly hack.
Steps to reproduce:
- Create an interface and implement it in a class
- Create an array of the interface
- Add an item that’s gone through a Select
- Try to find/remove it, and it’ll fail.
Note:
Oddly enough it doesn’t seem to fail in all cases, here are 2 similar flows (ignore the warning), one which fails and the other succeeds.
Hi Cookies.io,
Can you clarify a bit for me?
- What are you trying to accomplish exactly with the interfaces?
- What is your macro looking for specifically?
- Is this a custom macro or one already implemented in the editor?
The reason I am confused is that interfaces are designed to communicate between blueprints and typically don’t need to be turned into variables, I don’t fully understand why you are creating an array of interfaces for them or what the end goal you are trying to accomplish is. Perhaps with some clarification I can get a better understanding of what is occurring and why.
As you said, it’s for communication between blueprints. However, in my case I was making a rather dynamic Item system, I want to reduce the coupling between individual classes. I have interfaces meant to be listening to changes to items/inventories, which would also be added to arrays (and thus would be prone to the same issue). I couldn’t do it through event dispatchers as I wanted to be able to use whichever base class I wanted, and to try things either side-by-side or mix-and-match.
At least while I was working on it, or to keep it so things wouldn’t be too locked down.
By using interfaces I could try out a lot of the ideas I had, without having to make modifications to other blueprints. Which also meant I had to make interface (array) variables, as I wouldn’t have a specific class to choose.
The macro is a custom one I made to be able to get either the Actor or it’s Item Component, depending on which way the setup was, and return that as the item interface. Basically a way to be able to either implement the Item interface on the actor, or make it an Item by adding a component.
This project is mainly to try and see possible limitations with blueprints for fun, but I just find this issue with interfaces and arrays really odd. Especially seeing what should be referencing the exact same thing, fails a find in an array which makes things like an Inventory a pain to make when the items are stored as interfaces to avoid casting/component scanning every time they’re needed.
Unfortunately this is not what interfaces are intended to do and will probably continue to cause errors in the long run. You are currently utilizing interfaces as if they were similar to actor components, but this is not how they work. Interfaces are meant simply as a call between blueprints to run specific functionality if other blueprints contain the interface as well. By using the interface as a variable, it breaks the entire process. Instead, try using actor components in place of the interfaces, these are modular and can be attached quickly to any actor blueprint, which make them ideal for things such as inventory/items.
Alright, thanks. I’ll just voice my final thoughts on this.
I’ll start by making clear that I wasn’t using interfaces as though they were Actor Components, I used them to not lock my other classes needing references to them being forced to be changed wherever I wanted to try out new things, so I could try my ideas out either side by side, or mixing them together. I also prefer type-safety and generally dislike casting, so I didn’t want to make my variables Objects to be able to store both Actors and Actor Components, when i knew they shared interface.
While this may not be the intended way to use interfaces, it just feels odd. The references should ideally be the same, since they’re referencing the same instance, yet they’re not equal (as proved by the find). Logically, I find that nonsense.
All other languages I’ve worked with would’ve been just fine with what I’ve made, I know that Blueprint is not necessarily like other languages, but still.
That’s all I have to say for now. On a last note, I’ve chosen which way I wish to go now, so I can start removing my interfaces, but I still think the behavior of interfaces are odd and could use at least some clarification.
