Simplify Casting & Event-Dispatchers -- Match-Ease-of-Use-Of-Kismet-To-UE4

You can say that Interfaces are a own type just like BPs are. It only contains function definitions.
You can also store a Interface reference as a variable. You then only have access to the functions of the interface and don’t know anything of the actual type i.e. if it’s a Character or just an actor

Been trying to learn blueprints for 2 years now and still don’t understand any of it, and I have a math and learning disability :frowning:

I didn’t like interfaces because of the functions, but interfaces with events sound like they could be pretty useful. :cool: Then again you can do basically the same thing with event dispatchers anyway. In the end there’s lots of ways to do anything.

Interfaces/BPI feels a little like glue bolted on, or a wrapper etc to solve a problem.
Its reminiscent of a ‘message bus’ or something less reliable like UDP net traffic etc…
But it helps and it works and that’s all that matters… Cheers for sharing @Raildex_

If you only need the interface on actor classes, then you don’t need an interface. You need a component.

Eh, no.
Components encapsulate functionality. They will behave the same for every actor.

Interfaces (and also Event Dispatchers) have a common interface (the Event/Function) with different behaviour.

franktech wants to have the simplicity to not use casting and call functions without caring of the type. When using Components, you either need to cast your actor or check if the Actor has this component.

One intentional change from Kismet was using more strongly typed object references. The problem in Kismet is that you can try any Action on any Object, but you had no idea if it would actually work! Does ‘Toggle’ on my WeaponFactory do anything? I guess I’ll just have to try it! With stronger types, we try to only offer relevant functions. When you drag off a LightComponent, you should only get relevant functions, which should make the thing you are looking for easier to find. Remember that there are a LOT more functions exposed in Blueprints than there ever were in Kismet :slight_smile:

@JamesG [MENTION=8]Alexander Paschall[/MENTION] [MENTION=14973]Chance Ivey[/MENTION]

But here’s the thing, the official BP docs are so poor that you have to just try things anyway.
Epic minimally explain the inputs / outputs / prerequisites of BP nodes, not helpful!

Physics-Node-Tooltip-Alert: ‘Better to use Add Torque / Add Impulse’… Why? Nothing in docs!
Or SetPLVelocity compared with Add-Force / Add-Impulse / Add-Torque. Detail real differences!

So I just find myself trying things… And Casts / Event-Dispatchers only slow things down more.
(But thankfully, while it feels hacky, Interfaces help: No-Casts, Minimal Bindings, Return-Values).

You could still ‘key off’ the Node name, not the particular dragged variable PIN (in the BP ‘All Actions’ func finder).
Plus if the initial characters you type are wrong you get nothing back anyway. (It needs ‘Expand All funcs’ option).
i.e. Dragging GetGameUserSettings-Return-Value and typing ‘parse user settings’ / ‘break settings’ returns nothing!
So you have to really know what you’re looking for, and realize that each setting here is actually its own function!

Yes thankfully! If you wanted to stick with Kismet before you had to over-hack ‘Get-Property’.
By any chance can we ask about Epic’s broad plans and vision for the future of Blueprints
Will BP be easier, or will it beefed up so that its more capable making C++ far less necessary???
(Whatever you choose please don’t let it rot like Kismet / UDK, after a time no further additions)!

The only problem I see with blueprint communication is that the actual documentation is very weak, but that’s generally an issue that I have with the engine.

For a beginner, it becomes very clear once they watch the video on the topic. Unfortunately, it has to be found first and is two hours long.

In fact, I feel like finding how references/interactions between objects are structured might be one of the hardest thing for a beginner in any object-oriented environment. I can do it now in Unreal, but my attempt at Unity had me at a complete loss because it worked completely differently there.

Just personal study notes to self, but placing them here in case its of help to someone else.
There are 3 principle forms of communication between blueprints. They all have Pros / Cons:

#1. Direct Communication
One-to-one inter-links or one BP directly referring to another, and in turn that BP referring back.
So a kind of Bi-referential or two-way communication going on, using fixed actor references etc.

The most direct! Easily understood, but it requires good understanding / use of Casting, plus pre-planning.
Also knowledge of built-in functions that grant access to other BP’s: GetOwningPawn / GetGameMode etc.

References to other blueprints must actually be explicitly stored somewhere, in an array or in many vars…
This approach with lots of interconnected BP’s will probably become hard work to maintain and may break!
Lots of initial Casting! But using generic arrays of heavily used BP types reduces workload and re-casting.

#2 . Dispatchers
Far easier to understand than Interfaces. A few minutes and you’re up and running with the right tutorials.
They are one-to-many in design. In that one Call from the Caller will automatically invoke many Callees etc.
So you don’t need to keep an array of hard fixed references to get access to all the dependent Callees etc.

Event Dispatchers seem far more limiting than Interfaces. They don’t seem to return values for starters etc.
They also seem more work to maintain and overall clutter your Blueprints more, making them harder to read.
They also encourage bad use or inconsistent use of naming making reading other devs work more confusing…

#3 Interfaces
Probably the least work to get set-up. Simple and fast, and probably also the least work to maintain or change.
Interface functions can return values too, so its not fire & forget / hope something actually executed correctly.
A single Interface allows for communication across many different functions which saves on the set-up time etc.

Probably the least immediately obvious as to what’s going on when you watch a tutorial for the first time etc.
The reason is its all quite abstract, because you are creating ‘ghost’ procedures without any implementation…
Communication as per Direct-Communication is 1 to 1. However its quite easy to get a list of participants etc.
Loops needed to communicate with all Callees, but feels easier to manage vs ED’s which bring name confusion!

Honestly @franktech, most of your complaints are quite silly. You’re complaining that what is effectively programming with a coat of paint is adhering to programming principles. What you’re suggesting would be the death of Blueprint as all the error checking it’d have to do under the surface just for the convenience of you not having to drop a cast node in your graph would make it borderline unusable.

In your post above, again, you complain about casting with direct references and the fact that you require “many variables”… It’s not uncommon for projects to have objects with more than 50 variables so I am not sure what “many” means in this context. Just look at the number of settings in the post-process volume.

In your second point you complain that event dispatchers have no return values, but please tell me - how could they have return values? You said so yourself, they’re a one-to-many relation. How could you have return values in that case? For every call of the function the dispatcher would receive as many return statements as there are listeners. It also means that each dispatch would need to have info about the dispatcher embedded into it so that receivers know who to return data to. If you desperately need this, you can add a “Caller” variable to your dispatcher, and have your listeners call a function on your caller with your “return” data.

Lastly, you have a beef with interfaces because they’re… interfaces really. Yes, they’re the most abstract of the bunch and it takes a bit for newcomers to figure them out, but they’ve been around in programming for ages, literally, with little change.

Honestly, everything that you listed above has workarounds and / or enforces good practices. The communication between dispatchers and listeners should be one-way as that makes the relationship clear and you don’t have to follow as many loose threads to figure out the flow of execution. You said it yourself - direct variables require pre-planning, which is a fabulous thing to enforce.

All in all, it all feels very superficial and trivial.

I’d rather hear that from official channels! But know this I don’t want to break anything, ok???
I’m just wondering if its possible to add another type: ‘Super-Object’, that bypasses the rules.
Like the ease of a Macro language which Kismet is. And its just a question, no censoring here!

Please re-read the post DamirH! These are just personal study observations about getting the most out of each one.
They are not COMPLAINTS! They are just a cheat sheet about using it. Maybe I shouldn’t have posted it? But I did!

Understood. But again this was just an operational reminder or note about using them.
So that next time I’m picking from one of the three, I’ll recall what the limitations are…

Again no beef, just personal study notes dude! It was actually meant to be a push to others learning this…
If I in turn hadn’t gotten encouragement to try Interfaces I might have felt it too flaky and switched off.
And that would have been a big mistake because I like them the most out of the three, so best all round!
Why? Unlike ED, Binding isn’t done in-graph so they don’t clutter the Graph as much and naming is simpler.

Right now easy there tiger! There’s always a bigger dog around the corner to take a bite out of you!.. :stuck_out_tongue:
But lets get down to it! I get how it seems trivial to you. I’ve walked your shoes, I get it believe me.
Once you know BP, C++ and your way around the Engine, its easy to look down on others who don’t…

But there is a point here…

Don’t recall you from the UDK days so assuming you didn’t use it. But this thread stems from there / echoes back to there…
Requesting that BP was made easier or more comprehensive replacing the need for C++ for most games isn’t a bad request.
If it was more comprehensive many more devs could avoid C++ and it if was easier it would just be another macro language…
But right now its neither imo. At least in Unity C#, there’s one language devs stick with throughout the entire game process.
But I’m getting somewhat tired of seeing so many subtle limitations of BP that can really affect your game, its disconcerting.
But jumping fully over to C++ doesn’t appeal. Not because I don’t know it, but because I will never be as productive with it!

I don’t expect any change arising out of this thread, however a discussion would be nice, it might provide some useful insight.
How? I’d like to know what Epic thinks about this area, and what they plan for the future for Blueprints overall in general etc.
Is BP ever going to fully converge with C++, or will it always be a crippled cousin. Plus ideally I’d like to know that sooner, ok?

One thing that killed UDK, was how feature frozen it became, and how even bugs were just left by the roadside eventually etc.
I wouldn’t want that to happen to BP too, with the only remaining mantra: ‘well you can always go & fix the UE4 source dude’!
Because that’s not really that helpful… As I, like many others want to focus on making games- not being an engine developer!

But they do develop blueprints further. There are new possibilities with every release. Not too much, but it’s not forgotten.
Also it’s very easy for programmers to expose a lot of functionality to blueprints. One of the reason is the BP it’s tied to C++. And that’s why adding any “Super-Object concept” is bad. It would make simple things not the simple, clean and readable code not that readable. It’s not possible to introduce huge change like “Super-Object concept” to programming/scripting language without affecting every UE4 project in development. And what for? So not experienced user would spend a few less days on learning blueprints?

And JamesG already replied :slight_smile:
He explained philosophy behind blueprints. And he said nothing about changing overall blueprint design or adding anything it. Clearly Epic devs don’t plan anything like that. There’s no need for any changes and that what we’re explaining here. I hope we explain it well :slight_smile:

Yes, blueprint needs some planning. Exactly as any other tool. Maya or Max are complex and difficult for beginners. It takes some time to learn basics. And such tool always requires planning, even for simple mesh. Painting in Photoshop also requires planning.
Of course you could write code or create illustration without planning. And you would end up with a mess. It would more difficult for you to resume work on this code or illustration.

Blueprint doesn’t need simplification or adding “newbie” mode. I’m “fluent” in blueprints, but still I’m very slow in material editor. It’s just because I didn’t really learn how shaders work. So I won’t request “making it simpler for non-artists” :wink:

We would just need global variables, that can be access from anywhere (level-blueprint, blueprint, widget…).

That’s what your GameInstance is for.
Global Variables are evil though if you want to debug them.

How about expanding BP then, rapidly in a massive exposing of C++ functionality to BP?
In order to make the added complexity of learning ‘Blueprints versus Kismet’ more worthwhile etc.
As you said new Nodes are just drip fed to us, and long delays leaves developers very frustrated:




A massive addition to Blueprints would help clear up some of the ambiguity regarding its true capabilities.
i.e. What are the limits on games that can be made with BP before devs get flung out to C++???
Its the type of question that comes up regularly from Unity devs. They know BP doesn’t go far enough!

They think BP doesn’t go far enough. What exactly are you missing from blueprints?

Lots of stuff related to Multiplayer, native not plugin. Can list threads if you want…
But for now, Steam example above. Physics, Split-screen helpers, Adv-Networking.
You’re happy enough with what’s in BP then, what kinds of games do you work on?

Steam is a bad example because it already works in BP. The other stuff is too general. If you want to give feedback on what should be exposed to BP you should link from the actual API.
For example: FQuat | Unreal Engine Documentation

Regarding creating a Super-Object-Type I came across this… Looks interesting…

But then, like in some sort of Hindu karma coincidence I also came across this:slight_smile: