I Struggled With Blueprint Interfaces for Years!! (Unreal Engine 5)
Вставка
- Опубліковано 26 кві 2024
- I will admit that I struggled with blueprint interfaces for years! It took me years to understand why decoupling was so important to interactive media. Using these core programming principles, you will be able to change functionality without worrying if you will break other classes. #blueprint interfaces are so powerful and one of my favorite tools to use in Unreal Engine!
:) Comment below and let me know what videos you would like to see! Thank you!
Subscribe and begin learning with us today!
Email: brandon[(at)]glasshandstudios[(dot)]com
www.glasshandstudios.com
Facebook: / brandon.clem. .
Glass Hand Facebook: / glasshandfil. .
Instagram: @thebranclem
Glass Hand Instagram: @glasshandstudios
Twitter: @thebranclem
#ue5 #unrealengine
0:00 - 2:30 Intro to Decoupling
2:31 - 3:13 Definition of Interfaces
3:14 - 4:06 Reference Viewer
4:07 - 4:47 Create Blueprint Interface
4:48 - 5:40 Input Mapping
5:41 - 9:40 Implement Interface & Action Mapping
9:41 - 12:22 Implementing Interact Event
12:23 - 14:45 Target Object
14:46 - 16:16 Checking Our Work
16:17 - 16:48 Like and subscribe! :) - Фільми й анімація
Thank you for checking this video out! In the next video I will talk about event dispatchers! Cheers guys!
I feel like Event Dispatchers are less functional than BP Interfaces. But I'm a complete rookie.
I was wondering if an Interface would be good for a HUD, or a menu? I need something that will allow me to press on an icon on a drop down menu, and that will save a variable to the character and load the end of the map. Is the interface able to send a value to a different actor or blueprint's variable like that??
"Unfortunately" this wasn't new to me, I use interfaces alot. But seeing you enjoying yourself for learning this and the way you explain it to ppl is awesome, you're awesome. Thumbs up!
The problem with this is that you implemented the "interact" event in both the switch AND the hidden door, this means that in case the overlap event of the player's capsule fires (might happen) while standing on top of the hidden door, the player can press E and the door would open without the need for the player to interact with the switch.
The correct way of doing this is implementing another function in the blueprint interface that handles "indirect" interactions so you can send the "interact" message from the player's blueprint to the switch's blueprint "interact event" which then fires off and send the "indirect interact" message from the switch blueprint to the hidden door's blueprint "indirect interact" event.
Doing this you completely avoid the "bug" I described earlier. I hope this might help.
Hey Bruno thank you so much for taking the time to comment! Yes this makes a ton of sense. I'm definitely going to start implementing solutions like this in my projects. I appreciate the advice! Cheers :)
So basically the player character ONLY talks to the button, which then relays the signal to the door, rather than the player character talking to BOTH at once?
@@Baleur In short yes. If you use the same functionality in both door and switch, the character's capsule component might clip through the door (so the overlap event is triggered) and if the player is fast enough he might open it without the need to "press" the switch. It's basically a bug that might happen.
@@brunoverde2769 What about in scenarios where the Player is trying to BPI communicate interacting with ONE specific blueprint object, but TWO of the SAME blueprint objects are within Player's collision?
How does UE know which specific blueprint object they wish to interact with, lets say for instance the most recent object to enter Player's collision?
@@pibetry If you use the method shown in the video, only the first stored overlapped actor will receive the BPI message since the loop will break with the first stored overlapped actor that has a BPI implemented.
If you want to make the player interact with only one SPECIFIC object out of many others (let's call them actors from now on) you need to "write" specific code that tells the engine how to handle that.
In your specific case about handling the most recent overlapped actor, it's quite simple to do: inside the loop you just need to use a branch that checks if the current array index is equal to 1 and if it's true fire the BPI message.
Note that this is a very specific case and it will work ONLY if the player is currently overlapping two actors.
If the player is overlapping more than two actors then you need to first get the length of the overlapped actors array, subract 1, check if the array index is equal to that resulting number and then fire the BPI message.
Note that I don't actually know if the "overlapping actors" array stores the actors in the correct order but I assume it does hence what I wrote up here.
If you want to really make sure to get the most recent overlapped actor you need to use a variable that overrides everytime the player overlaps an actor (make sure to use checks here, for example check if the overlapped actor has a BPI so the code is permormance friendly) and then fire the BPI message to that stored actor.
Quite hard to explain here on the comments but in reality it's quite easy to do.
The most simple way is to add the interface "Interact" to all interactable objects, then fire a linetrace from the camera view of the player and check if it is hitting an interactable object, if it is then call the interact function from the interface (it does all the things you want the objects has to do calling every time the same function)
While line trace works, personally I feel it's pretty clunky unless you're doing a first person point and click game. Having all the options pop up when you enter a collision feels more intuitive.
I'm moving my first steps in Unreal(Blueprints) - and I'd say this sounds more like it should be done.
Coming from Unity - you simply cast a line (with a certain distance and params) -> you loop through all the actors in the line, and stop at the first one handling the event.
Probably the door should have a different interface.
And if I have different types of interactivity. For example, a door, a lever, or just a static mesh that needs to be lifted. How can I best implement this?
Just started learning UE5 and was making action blueprints for every interaction. This has saved me from so many future headaches and streamlined my game logic.
That's so awesome to hear!! Thank you for sharing this great news. Cheer!
Thank you i have been strugling with this for months, watching many tutorials and never really grasped the concept until I found your tutorial and it all came into place the best explanation out there by a mile.💯
Oh wow that's so awesome to hear!! Thank you 😊 cheers!
I really appreciate the approach you take in this video. It felt more like a lesson or class, which was 100% what I was looking for. You explained why you were doing each part precisely at a normal pace.
Thank you so much for this video, subbed!
Hey Corey thank you so much for watching the video and leaving this comment. I'm excited to keep learning together. Cheers :)
Man. Like you I struggled with this. Watched a lot of tutorials before yours, but yours is the one that put me over the top. Thanks!
hehe I thought I replied to this comment earlier in the week ;) Glad to hear the video helped! Cheers!
Great tutorial. I just want to let it be known that having that "does implement interface" step is usually unnecessary. It was used here to basically tell the ForEach loop that it's found the first instance of something you can interact with to then be able to break the loop.
You can just call the "Interact" message function, and it won't do anything with any actors that don't implement the interface, which is one of the most powerful things about using Interfaces. Again that branch check was just to check that we ran into the first instance of an actor that implements the interface. If, for example you wanted to loop through all the interactable actors within the overlapped actor, you just need to stick a pin straight into the "Interact" message and it will trigger the interact function on every actor that has an interact function and skip the ones that don't with zero bugs or erroring out due to unexplained references and whatnot.
Also, an alternative to using interfaces is to use components. So you could create and actor component called "InteractableComponent" that you can attach to your interactable actors. And then create a delegate "Interact" in that component so you can implement it in the Actors (this is what for example box collisions do when you implement the OnBeginOverlap delegate). And to call the method interact you just call Actor->GetComponentByClass("InteractableComponent")->Interact().
The advantage of using components is that you could have a default implementation as well and you can abstract logic in it. For example, you could have an enhanced input action in the interactable component so you could also implement the input handling logic there. The biggest disadvantage is that delegates don't support methods with return values, so interfaces are useful for those cases.
Personally, i find interfaces an antipattern due to how often are abused. They're very useful when used to remove dependencies between modules (i.e ItemModule from InventoryModule, QuestModule from InventoryModule/ItemModule, etc). But when overused to isolate single Actors within a module (module as in collection of objects that perform a single purpose), they make things harder to debug and maintain.
Thank you for your in depth comments, Kevin. I have really enjoyed reading them! Yes, honestly using actor components makes sense to me because of the single use principle :) it also reminds me a lot of how I would create prefabs in unity and I really like that way of scripting functionality. I hope to make a video on this soon, and I hope you can check it out. Thank you and cheers!
Interface IS abstraction while component is inheritance. Generaly speaking modern code style is in favour of interfaces then superclasses. I am not very strong in BP but in any C language your statement will be exact opposite
@@freezerain Yeah, I should have been more specific. Interfaces in BP are an epic workaround and doesn't work the same as interfaces in C languages, they're very limited in what they can do and, in BP, you couldn't even reference only the interface part of an object so implementing the Liskov substitution principle was/is not possible (I think it's now possible using TScriptInterface). IMO the way to look for the "best" way to code in Unreal is to look at how the Lyra project does it. They use a combination of components and interfaces depending on what they're trying to achieve.
The SOLID coding principles are good practice to make code testable and maintainable. However sometimes the abstractions become a performance problem and you have to break your principles to get uselfull code. They called principles not rules for a reason ;)
@@GlassHandFilms could you make another video to reference the component method? would be interesting!
In Blueprint you actually don't have to check if an actor implements an interface before sending an interface message. You can just send the message, and if the actor doesn't implement the interface the message will just be ignored.
In C++ you do have to cast the actor to the interface class to check if the interface is implemented.
And for hard references: a problem that you didn't mention that everybody should be aware of is that, beyond just getting a massive tangle of dependencies that will make making changes to your game extremely difficult, when you use a hard reference in a blueprint it actually loads the referenced class into memory. So even if the referenced class isn't in the world yet (i.e. you have a game manager class that references unique objects in every level), those classes will be taking up RAM for the entire game session. And if THOSE classes contain hard references those objects will be loaded too, and if those classes reference... etc. This could potentially lead to your entire game getting loaded into memory at once.
You are correct I did fail to mention this! Thank you very much for writing this comment!! This will indeed help many others! Cheers!
The question is. Once you're aware of this, how do you identify what makes these hard references and view all the dependencies all the way down the chain?
I'm curious what the overhead of sending the message through a blueprint is as well. If C++ requires you to cast the actor and blueprints are built on C++, that'd mean within the send message process it has to do this anyways, it's just more convenient.
I'm fairly new to unreal, as I mostly worked with unity but the send message features there were often costly and best avoided as a general good practice.
Awesome mate! Thanks for making this - really took me a year to understand these concepts. Blown away truly! Big thanks! Keep making more
My pleasure, thank you for watching!
Absolutely fantastic!!! Thank you for this. This is the kind of super high value content we like to share with our students.
Thank you, sir! It's a true story and I hope others enjoy using this technique haha cheers!!
God, it's about time people start teaching new devs this workflow. So many tutorials are like "Now open the level blueprint" and it's just a completely unrealistic way to build a game. Nice video. Subbed.
Have you discovered event dispatchers yet? ; )
Hey Michael! Thank you for the kind words! Awesome channel btw :) I subbed to you as well! My next video I want to make is about event dispatchers and why to use them. Keeping with a similar format. Cheers man!
@@GlassHandFilms Thanks! Can't wait to catch the next video!
probably because working in the level BP is easy to understand when just starting out
@@commoncure3335 I mean, it depends. I'd argue that finding out that the level editor doesn't really work in any modular workflows and having to redo all that work the right way is a lot harder than just learning it the right way, the first time.
I think they need to be teaching better.
Thank you! I've been watching so many Unreal tutorials and so few of them focus on good programming practices for scalability.
Being able to pull apart your assets and have some decoupling is so important! Unfortunately so many of us learn this too late, including me haha glad you enjoyed the video!!
I'm so happy I took the time to listen to this. Super useful for a casual user like me.
Thank you, Jamie. Super happy to hear this! Cheers!!
This is the type of breakdown I've been trying to find! I've been struggling with understanding how to properly use both blueprints and interfaces with the constant tweaks I add to evolving systems.
Thank you Sir! This really was a clear way of understanding a very convoluted/complex concept.
I am so happy to hear that it helped you! Cheers :)
This made Blueprints not only much more simple to me, but also has the benefit of perf. Awesome video thank you!
Amazing! Thank you for checking it out! Cheers :)
We usually use the able suffix for interfaces like Interact
Interactable, Deletable, Archivable, etc.
I really like this! I'm going to try and start using this in my projects as well. Thank you!
This is good stuff man seriously this is textbook material much luv for dropping dis gang 👏🏾
Awesome man I'm glad you enjoyed it!! Hope to post more soon! Cheers!
ah yes this makes so much sense, I started ue recently and thank I'm finding right videos at right time !!!!!!! Thanks for making it!
Amazing!! Thank you for checking it out 😁 cheers!!
Great video! I'm starting with UE and I'm finding it very interesting yet very difficult since programming is not my thing, but I think what you are showing here will help later on the road. Thanks for sharing this so people don't have to suffer with similar issues!
Thank you!! That's exactly what I wanted to do with this video. I wanted to guide your creative thinking and allow for a more modular approach. Thank you for sharing your thoughts and I wish you the best as you continue on your coding journey!!
Wow! I always thought interfaces were a last resort for when I improperly structured my classes, but this really opens my eyes.
Thank you. You managed what none of the other videos have been able to explain. Others were able to explain the how in using them but not the why. I'm a veteran in C# but learning blueprints (before I swap to full C++) and I couldn't quite work out why casting would be expensive.
Your use of the Reference Viewer made it finally click. Liked and subscribed.
Great video because not only did you show how to use interfaces you explained why. Thank you!
Thank you, Gabe. I appreciate the comment greatly! I hope we can continue to learn together. Cheers man!
Thanks for explaining it in such detail!
You're welcome! It's super powerful and I hope you use it in your projects! Cheers
Awesome vid, really helped me understand this a lot.
Thanks!
so awesome! Thank you for checking it out! Cheers :)
Excellent job, Thank you for sharing 👍
Thank you so much! I really appreciate it 😊
I just subbed because this is one of the most useful videos I've seen so far for Unreal.
So awesome! Thank you for checking it out!!
Thank you ❤so much for sharing your experience
You are most welcome 🤗 thank you for watching 😌🙏
Coming from Unity and it's script components I was lost in Unreal trying to figure out how to make an interface. This video is SO helpful. Thank you very much!
I'd love to see you make more Unreal tutorial content and you're very engaging and clear. Subscribing in case you do in the future.
Hey there! Thank you so much for leaving a comment and reaching out!! I will definitely make more content in the future. I try to balance my day job, small business, and UA-cam 😁 but always here if you have questions! Cheers!
You're coming into my feed at just the right time. I have a bunch of hard references I replaced. :)
That's so awesome to hear! It's a great feeling decoupling classes in the reference viewer :) cheers!!
This is so cool! thanks for this explanation!
Thank you for checking it out!! Cheers :)
This is awesome. Thanks Bro!😎
my pleasure! glad you enjoyed it :) Cheers!!
Appreciate the info! I have been looking to learn these kinds of optimization and more advanced best practices for game dev.
Great Tutorial, really helpful, thanks for sharing, I liked and subscribed!
Interfaces becomes more useful for larger modularized solutions if used correctly. They do add some additional complexity due to an extra abstraction layer though so good to not overuse. Mainly useful for behaviors like this example and when building pluggable frameworks for other developers.
cant imagine how much time you just saved me, thank you x a million!
amazing!! super happy to hear this, thank you for sharing. Cheers!
You are a very positive person, thanks for the course
This is exactly what I needed. Thank you very much
That's awesome to hear! Thank you :) cheers!
fantastic video! It helped me out big time
I come from a pretty extensive background in Unity and it's pretty funny that you mention the coupled workflow of working in Unity that so many tutorials showcase. I unfortunately do find my self with a project some time down the road where several systems just depend too much on referencing each other and it creates such a pain when you want to create new levels and then the number of singleton classes become way too much. I mean, I may be getting ahead of myself, perhaps you'll mention singletons are the way to go for decoupling, but i'll find out as I dig into your video here.
It'll be great learning Unreal and getting a proper workflow down correctly from the beginning :)
Definitely glad to have come across this early on. Connecting blueprints was becoming a tedious habit of mine.
I totally feel you on interfaces. I even made a tutorial for using Interfaces based on someone else's tutorial that I saw, but I didn't actually understand what I was learning or teaching :P
Your video is great because you explain in really simple terms what the interface is actually doing :)
Thank you for the comment! 🙂 I use interfaces all the time, probably too much haha cheers!
Very nicely explained.
Thank you very much and thank you for watching ☺️
Wow, that’s awesome!
Although knowing about BPI existence I was never aware of this referencing dependency, that’s very important and like you said when it comes to scaling your Project that surely makes things a looooot easier!
Thank you for this video, awesome work! 🎉
Thank you very much for the comment and happy to hear you enjoyed the video!! Cheers :)
Thankyou for this! Very easy to understand for a beginner :D
Amazing, thank you
Extremely useful!!
Thank you for the comment ❤️
@2:14-2:24 Literally where I've ended up... When there is a mess of actors combined with other game mechanics, character blueprints and player controller, all intertwined it gets really messed up. I appreciate you taking the time to put this together
I hope this has helped! Thank you so much for checking it out! Cheers :)
@@GlassHandFilms I'll be real with you man, I've spent way too many hours trying to nail down this BP Interface thing with my player controller... Can't get the interface to carry the value to the pawn blueprint, doesn't give me a message just an event call... I'll get there eventually, with folks like you who post this stuff so an engineer with a taste for games can make a damn cool physic based game. Stay tuned lol
@@GlassHandFilms 2 days later and I am a champion of Blueprint Interfaces... not even joking. I appreciate you.
@@MBAalrightgames this is amazing to hear! I'm super happy you were able to unlock the potential of blueprint interfaces! Cheers :D
great video, thanks. also a quick tip, i noticed when you a adding the input mapping (04:48) you choose the key in the dropdown menu, you can also click in the keyboard icon to the left of the dropdown and press the key you want :) i found myself sometimes searching for a specific key and not finding it and this helped me a lot. And it works for controller buttons too!
Thank you for checking it out and for the quick tip! I really appreciate it! Cheers!
My only extension of this (besides the bug fix mentioned below) would be to make the target actor variable an array, and implement the code to fire Interact for any objects within that array. This way you can have a switch that talks to multiple objects at once.
awesome! yes this would work super well. Thank you for the comment! Cheers!
Thank you! 😊
Thank you for checking it out, Patrik
These Interfaces are amazing!!!
When i found out they were a thing
I got soo intriged
Oh man finally someone who actually explained it. Thank you very much, this was really helpful and I'm glad youtube has brought me here.
Oh wow thank you! That's so cool to hear! I hope to continue to share more content soon. Cheers!
I will watch this. I use BPI, but each time it is eerie to get what I want working
Great video! Thank you so much!
Thank you for checking it out!
Thank you for checking it out!
Thx you so much!
Thank you for watching ☺️
Thank you so much for this video. While I didn't think I needed to know this; this is exactly what I needed for my project I am working on. Which is a Vtuber/DM NPC puppeteering tool that is not leaning into simplified/anime trope assets, Unreal makes that very possible with their metahuman and vast resource library versus Unity.
I needed agnostic blueprints/functions so that the end user could interject their own assets to be used and can call on them with ease via keypresses while avoiding me just using massive and constant index references which can threaten it all if a component somehow gets activated ahead of schedule. Your instructions helped me decouple hard references, making it much easier for the end user to adapt it to their needs or conditions I did not think of. (My end goal is to have a compiled thing like VSeeFace/VMagicMirror and a plugin+sample scene for advanced users to change it to their needs.)
Thank you for sharing your project and experience!! So awesome! Please let me know how it's going. Sounds like a very useful tool. So happy you found this video helpful! Cheers :)
@@GlassHandFilms Thank you.
Great video. Easy to follow you. 😎👍
Thank you so much for the comment! Glad you enjoyed it! Cheers!!
you are "da bomb" i absolutely needed this shit with the current project im working on. tysm bro
Great to hear!!! Thank you for checking it out :) cheers!!
Great video. I was having an issue implementing an interface, and this helped me better understand it. Though one part I needed to figure out was what was a const function and why I had that checked on my interface function. Unchecked that and worked great.
Thank you so much!
Thank you for watching! Cheers!
I didn't know Taylor from PKA had an unreal engine channel! Sweet!
I had to do some googling but yeah we do look alike 🤣
Can you make a distance check to the switch instead of a volume and still keep it decoupled?
Thank you!
Thank you for checking it out! Cheers man!
I came here to learn blueprint interfaces.
I left knowing how to create a reroute node by double-clicking the wire.
Thanks!
😂 thank you for checking out the video! Always happy to help when I can! Cheers!!
I will be on my way, tidying up some of my blueprints… 😂
12:00 instead compile and save, you can do both "simultaneously", beside button compile there are 3 points, chuse "save on compile" "on success only" in this way when you press compile it will save automatically
Thanks, awesome video, but why did you add implemented interfaces in character BP?
I've been taking a class with UE5 for almost 3 months now and the Blueprint stuff with the nodes is the most difficult for me to learn. But I'm optimistic about getting better with it.
You da man, as a greenhorn I love these videos!
awesome! I hope they jumpstart your journey into blueprints. Cheers :)
Also your player can interact with the switch even if theyre facing the other.
Here's a solution, in the switch after you check if player is inside the trigger box, call the function find look at rotation between player capsule and switch mesh, then get forward vector from that rotation and project on to (0,0,1) plan (horizontal plan) then normalize the result, this will give you the forward vector of the rotation between player and switch projected on the ground and with length of 1 unreal units.
Then use dot product between player/Camera forward vector and the vector we found earlier, check if the dot is greater than 0.8 for example, and then send out the message to the door.
The quote is "Tight integration and loose coupling" ;)
I also came from artist background, though I could say art & management. I only have some basic programming studied in the course to know about the basics, and one of them is OOP(object oriented programming). Past recent years people are yelling about DOD(data oriented design), I tried to study(self-taught) but it's quite hard to understand since I don't know much about the framework and stuffs.
When I play around in UE4 with blueprints, I followed tutorials and none of them could answer my questions or rather there is no solutions for my problems. Therefore I implemented my own solutions instead, and that's when I noticed about interfaces. With the experiences I gained by working on my own projects I finally put all those lessons I learned into practice, then I finally understood DOD. It's not about the framework and language syntax, it's about how you put things together to achieve a certain result. Obviously if you just implement hardcoded stuffs you'd see the results right away, but they're inflexible. That's when I started to optimize my project and learned about struct and event driven style code.
Unreal mostly consisted of event driven nodes, that's why it's important to embrace the coding style(scripting just to differentiate between typing and build nodes). With the project became more complicate and the scope became bigger than just a game jam project, data became more relevant to the project. That's when struct came into play. Now you're playing with event driven, interfaces, and struct. It's already DOD without you ever try to be one, just by only trying to optimize the project more.
About coupling(or dependencies), don't afraid to still use them especially when the specific blueprint is already the dead end of the grand scheme. No matter how hard you wanted to avoid coupling, the lower hierarchy of your data structure would always depends on the higher ones. Because those lower blueprints must take all the data from the upper levels in order to be functional.
tbh the foundation of my project might be a bit too big for the scale of the game I'm making, when I think about it everything is much similar to how AAA projects would do because the scalability and the independent on higher hierarchy blueprints. Yeah, it took me about 2 months to work on them(though it's actually 1 month since the first month I just hardcoded stuffs and optimized them the following month).
Nice video :)
This proof that has some basics in some scripting language is very helpful when using blueprints.
Try to learn something about c# (even with not-so-funny Unity) to just learn how Abstract classes work, how Interfaces work, Delegates, Events, Inheritance, etc.
Then will be much easier to organize everything in UE5 and more of these "light bulb over your head" (eureka) moments will come :)
Good one, much appreciated : )
Thank you for checking it out! Cheers!
Very informative, thank you. I just started learning this year. Can this interact bpi be set up as a variable? Like to use as a throttle to an engine?
nice and useful, thanks. just a tip: "contains" node is considerably faster than "for each loop" maybe it helps in your case as well
I used to use bp-intefaces, but ur method is more universal and parametric, cool
Good vid, thx! :-)
Thank you for explaining everything. This has been very helpful!
Will it be ok if you can show us as well how to create model or be able to influence geometry in Unreal Engine 5? I know there is a bunch of programs that I can do that, but I don't wanna use other programs if I know unreal engine 5 has now the capacity to influence geometry and eventually create models from scratch. Bceause all I see with so many tutorials that I watched, they just get assets from the store, and I wanted something more in depth, not just dragging already made objects into your scene.
Thank you so much!
Hey there! Thank you so much for watching the video and reaching out through a comment :) yes! I would love to make a video over this topic! I do have some videos on blender you could check out if you are interested, but staying in engine is super powerful! I will try and make a video soon. Cheers!
@@GlassHandFilms Thank you so much! I am looking forward in seeing the video 👍🏻
Thank you for this video, can you also make a video or point me to a tutorial that talks about using variables more? for more interactive examples?
Thank you SO MUCH for this! It expanded my mind on exactly what I had been thinking about but didn't know how to do. Followed along and everything worked out except for one part (which is no fault of yours or the tutorial): the action input mapping section (5:00 minutes in); those options are now deprecated (I'm in 5.2). I did not try to see if those options still worked. Instead I found another video showing how to use the updated action mappings.
I hope it's ok to post a link to another video showing how to use the new action mappings (it helped me complete this tutorial because of engine changes between versions; and this tutorial is so great). If there is a better way to share this (or if this is already posted in the comments (I couldn't find any reference)) without a link I will. But maybe it will help someone else who runs into this.
Again thanks for the tutorial.
Here's a link to how to use the non-deprecated input action mappings: ua-cam.com/video/nXJuXUxQfa8/v-deo.html
ahhhh, lost but gonna keep watching till I understand.
Definitely try this out for yourself in a small test project! Once you get the hang of it, I'm sure you will using it a lot 😁
thank you very much
You're welcome! :)
I have a problem where because my door has collision box (for other reasons) the player can also walk up to the door itself and press 'E' and it works, obviously I only want the button to do this but I want to keep a collision box. Is there a way to specify that only the button can cause the interaction?
Awesome!
Thank you, Fred!
Nice tutorial bro!
Interfaces are just a collection of custom functions declarations that can be attached to an actor.
As you said, when you use Interfaces, you don't have to cast anything, because Interfaces don't care about their owner's class.
There's a design pattern called "Observer" that's a Talker-Listener relation. Where the Talkers send updates and Listeners receive those messages and reimplement the InterfaceFunction.
In this example I'd do it a bit different... I'd use the "BPI_Interface" for Triggers and other Interfaces for flows.
Save "GetAllActorsWithInterface" as a variable, do a ForEachLoop on that variable and call the function you need on each element. When completed, empty the variable to save memory.
You'll have a lot of Interfaces, but it'll be completely modular, automatic and without inheritance.
Just remember: Interfaces are for listeners.
Hey there Joaquin thank you for the well thought out comment. I appreciate your time in writing this. Cheers!!
Thank you.
Thank you for checking it out 🙂
You just deserved much more thab "just" over 300k subbers.
Hi, thank you for the content. I would instead of "Get Player pawn" (BP_Switch) "Get Controller" and than "Get Controlled Pawn". So now in a Multiplayer Game, all Players can open the Door and not just the Player with index 0. You can also make an Input at the BPI and send the information from the everyone how want to use the Switch.
Great video. But the interface function/message for the door should have a different name. Right now, I think you could press E if your capsule overlaps the door and have it open. To be really advanced, put your button blueprint into an actor component. Then you can have interactions on any actor (ie. any button, switch, etc. automatically becomes interactable just by adding the component and setting the target).
I love this idea! Thank you for sharing! I've been abusing actor components a lot lately! I did a small video about them but hope to post more soon
Interesting. Thank you. I’m a JavaScript developer but my knowledge doesn’t transfer to blueprints very easily unfortunately. This helps.
Hey Jameson! I'm not a developer, definitely an artist background with an interest in programming. I do know that this is a very useful solution for JavaScript. Thank you for checking out the video and sharing! Cheers!
awesome !!!!
The thumbnail to this video was one of the first about Unreal I ever saw. I remember thinking "what the hell is this dude talking about", so excited to have learned enough that this is something that comes up for me when searching! :D
Hahaha thank you! I know the thumbnail is cringe, but it really did take me forever to learn interfaces and take advantage of them :) cheers!
I have never related to something as much as I related to that thumbnail lol... This was a really great tutorial, thank you so much! I was wondering if maybe you have a tutorial on sending over variable values via blueprint interfaces, because I really struggle with doing so without hard references and there really aren't any good tutorials on the topic. :)
You showed me this at 29! Thank you
I hope you found it informative! Cheers!
Two questions please.
1. How would I go about a situation where I have a whole bunch of different interactable objects: doors that open, switches that turn on the light, actors that you can grab etc. Should I have a separate interface for each of these cases and then in my character loop though all of the actors and check if they implement each of the interfaces?
2. How would I go about having 3 switches that turn on 3 different lamps? How would you tie a switch to a certain lamp (I'm currently using tags for that, which is kinda frustrating)?
For anyone who would like to learn more - read about SOLID principles. Those are general principles of designing software, applicable to anything that you can program in any way possible, but I didn't hear someone speaking much about it in game development.
It might be tricky to understand at first, but if you manage to do so - you'll be on another level in how extensible and clean your projects are :)
This interface stuff is something that comes from those principles and is just one thing to make it all better!
thank you
Thank you for checking it out :) Cheers!
concepts finally line up in my brain and...well, who knows? Maybe I'll be able to make sotNice tutorialng now.