I am having a problem with one of my Blueprint Interfaces. I have a MainMenuItem BP that uses an interface with a couple functions that a MainMenu BP, which acts like a manager, operates on. I recently added a SetOpactiy(float Alpha) function to my BP interface and it is not getting called when I fire the Interface Message. The weird part is all the other functions within my interface work fine.
I remember having an issue where I think I received a crash and following that is when this occurred. I saw another thread where someone reported this but it seems as though a proper solution/fix was never determined. Here was the link (https://answers.unrealengine.com/questions/74088/reports-of-failed-import-function-interface-incorr.html). But I have the same issue now whenever I enter my map, I get this and then it never fires. I have tried completely deleting this function and it’s associations but after re-creating it, it didn’t resolve this issue and now after loading the map for the first time today to work on this, I am greeted with the following error in the Log Window…
Error Failed import: Function /Game/Core/Interfaces/MainMenuItemInterface.MainMenuItemInterface_C:Set Opacity in /Game/Core/Blueprints/MainMenuItem
UPDATE: Okay, it didn’t fire because of a mistake I made. I was sending in the ChildActorComponent and forgetting to call Get Child Actor prior to calling an interface message on it. So it works, but I’m still getting these errors when going to the level for the first time. It appears to be a false error since it is working but let me know what you need from me to help you solve this in case this is being reported falsely. Thanks again!
I am trying to avoid doing a lot of casting to my custom BPs as that can induce circular dependencies. And I do understand what interfaces are meant for but using them to avoid doing direct casting saves a lot of potential issues in Blueprints.
“Interfaces are not made for communication, they are for relating unrelated classes which has same function”
That isn’t necessarily true, actually it’s quite the opposite. The definition of an interface is the following…
“In computing, an interface is a shared boundary across which two separate components of a computer system exchange information”. It’s absolutely meant for communication and why it exists in the first place.
Now yes they can be used to group a set of unrelated types to make the same set of calls to but there importance is to be able to communicate with a set of unrelated types. In BPs they are also used for communication hence “Interface Messages”. To avoid the circular dependencies that I mentioned, that is how I am now using them unless they are native types and I am able to communicate with them fine through that protocol.
You are aware that you can call functions from other objects directly without need of interfaces? Because it sounds that you forcing yourself to use them
Since you got MainMenuItem class (Blueprint is class same as C++ class) which you could spawn from MainMenu manager and contain in some array right? if you keep MainMenuItem object in MainMenuItem varable array you don’t need interfaces, because you can call functions of class MainMenuItem with variable as a target.
Interfaces are not made for communication, they are for relating unrelated classes which has same function
But ask yourself, do you need to communicate with unrelated classes? Do you plan to use anything else then MainMenuItems to your MainMenu code?
As for casting you doing it just once to throw MainMenuItems to array, after that you don’t really need to use it, as long as all use functions and events of main base class
I worked with UnrealScript and i never need to use interfaces and same goes with C++ in UE4, but for some reason in UE4 regardless blueprint using the same virtual machine as UnrealScript there strange oppression about interfaces as it’s a main way of communication between classes.
I know what interface is, to relate unrelated classes that in class hierarchy with same functionality. Thing is i never needed to do them, because i didn’t need to relate unrelated class to store them i same variable. I also don’t see need for it in your SceneElement example, because i can make all scene elements inherit from SceneElement class, not to mention this way i can apply common functionality as well relative classes may be different and create whole tree of objects, same as all objects on UE4 are relative to Actor class and all Components are are relative to ActorComponent class. Same case with your MainMenuItem, you got base class and then childs of that class… why you need interface here if they are related and you can hold them in single variable and call functions/events declared in base class?,
This obsessive use of interfaces is strange to me, because it does not fit patterns i see in entire UObject envriament, which blueprints are part of (look Class Viewer).
“But ask yourself, do you need to communicate with unrelated classes? Do you plan to use anything else then MainMenuItems to your MainMenu code?”
I very likely will as I’ll be opening up that system to be able to be used in other areas any will need the generic access to those types when I do.
“As for casting you doing it just once to throw MainMenuItems to array, after that you don’t really need to use it, as long as all use functions and events of main base class”
Actually you wouldn’t need to cast an object just to add one to an array if that’s what you meant. If I did want to make my array let’s say of the type ‘MainMenuItem’, then I wouldn’t need to do any casting whatsoever. But in regards to my array, I want to keep it more generic for actors and handle them differently depending on types. The interface is to bring that common functionality together for types with the same function calls but aren’t directly related.
“I worked with UnrealScript and i never need to use interfaces and same goes with C++ in UE4, but for some reason in UE4 regardless blueprint using the same virtual machine as UnrealScript there strange oppression about interfaces as it’s a main way of communication between classes.”
I didn’t understand that last bit about the virtual machine and strange oppression but in regards to interfaces in general, they are a very powerful programming tool. Definitely a little more limited in BPs than in C++ but there are many great cases for using an interface. Let me give you an example… (I’ll post another comment because of character restrictions but then I want to bring the focus of this thread back to the issue)
Let’s say I was writing my own graphics engine and I had a series of objects that were part of the current scene to be rendered. Let’s say common functionality between those classes are functions like (Initialize, Load, Unload, Update, Render) but maybe each has different functionality or purposes but we want to store them all within an array to be looped over for updating/rendering/etc and let’s say I will call that generic interface “ISceneElement”.
I can store an array of ISceneElements that maybe are much different in functionality but have those common calls and just iterate over them calling those common functions. If you haven’t yet used interfaces as a programmer, you should check them out. If you also spend a lot of time in code compared to BPs you may find instances where they allow you to do things you couldn’t before or more efficiently. Hope this helps
But not to derail this thread because I do want to discuss with the guys over at Epic the issue in further detail and help resolve it, but I have had many problems in the past with BPs having dependencies and my project is at a stage where I can’t afford any more issues with those and interfaces help keep that at bay. But check those out and I’m sure you’ll find them handy.
No offense but this thread is getting off track. This doesn’t relate to the original post in regards to the error that the editor has thrown so going back and forth on this on why interfaces are important for me to use isn’t going to help if you can’t understand it. You can argue the uses of base-classes over interfaces but you are ignoring why I am opting to communicate through interfaces rather than the actual type which is to avoid dependencies against those original types when using non-native types that were originally composed in Blueprints.
I also don’t understand what you mean about the obsessive use compared to patterns in the UObject? That doesn’t make any sense or is really relevant to solving my problem.
But if you are confused as to why the developers at Epic have interfaces in the first place, you should reach out to them and I’m sure then can answer that question for you.
Ok i wanted to propose alternative by avoiding using interface, but ok whatever if you don’t want to ;p you right we bloated this thread.
As for UObject, it’s object management system in UE4, and names come from base class which most UE4 classes inherent from them including all blueprints. If you look on API reference, you will see how typical UE4 class in UObject tree is structured:
Also i’m not confused why Epic has interfaces in first place, as i said i understand what the are and why they are in UE4, for me strange is why people use interfaces so much frequently even in relative class communication where other UE4 classes rarely use them and rather use references in variables. Also you can to watch this to see how i understand classes in UE4:
, I am going to take my time to respond to you this once more and try to make this a constructive post. I understand you are a beginner to programming and there is nothing wrong with that at all and I appreciate you coming onto this thread to attempt to help me, I really do and I do anyone.
Trust me, you will definitely learn over time the value to using interfaces and as I posted above, you can reach out to Epic and ask them why they are even an asset type within the engine if you want to know more or are confused. Epic is very responsive and will take the time to fill you in. But that wasn’t the point of this thread, it was to solve the error I am seeing.
I have been a programmer for quite a while and I do understand the value of base classes and nowhere did I say in this thread that I wasn’t using them as I am constantly throughout my code. But I am at a very critical stage in my project where native types/interfaces are avoiding what are called circular-dependencies between other Blueprints that are composed completely within the editor.
This is explained in the documentation and you can read about it there but if you have multiple BPs relying on each other and you are doing a lot of “casting” (ie. ‘Cast To MyActor’), then then engine can run into major issues potentially. It has happened to me and it can get nasty. I personally cant afford any more of these issues so I’ve started switching over to use interfaces in those cases to communicate with those functions from another BP. But if you have classes that are purely C++, then you can cast to them all day long without an issue. You can do a search here on the forums and you will find people primarily use interfaces to avoid those same issues.
I hope that could make a little more sense about things. Good luck with everything and if you ever have any questions that I can help answer, feel free to reach out to me on the forums.
