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

One of the things I really miss about UDK and Kismet etc, is the brutal absolute simplicity…
Like just having to use the same one Object type to hold any object-value from the engine.
Or having identical events in duplicate places, or calling procedures To / From anywhere etc.
You can’t do any of that in BP, not even ‘hook’ the same Custom-Event from several places…

In UE4, You can create an Actor or an Object and use it to store any spawned Blueprint etc.
But once you try and access its Methods / Custom-Events / Variables (Public or not) → Fail…
So could Epic add a Super-Object-Type that works like Kismet? If not, why / what will break?

Same goes for Event-Dispatchers, as they often require some pretty tricky set-ups at times etc.
Because ultimately the Caller and Callee both need to know a lot about each other in advance.
Plus, it can be confusing to read another devs code due to all the variation in names & naming!

What if:
…Event-Dispatcher Binding was implied / automatic / hidden / assumed on every Custom-Event?

What if:
…‘Callee’ Binding / registration was generic and not type-cast or specific to any Calling/Caller BP?

What if:
…UE4 added a Super-Object-Type to cast silently in the background to match Kismet’s simplicity?

Event-Dispatchers & Casting both stem from C++. Is their existence essential for BP Inheritance?
If so ok, but know this, they’re both invasive & unhelpful at the worst of times vs ease of Kismet.
There’s cases of ‘Casting’ failing silent in so many threads on here and none of this is going away.
And sure while Event-Dispatchers do work if plumbed right, they’re the least well explained topic…
Both will continue to trip up lots of developers whose games don’t benefit from Inheritance / OOP…
To aid UE4 adoption Blueprints should be easy & accessible to anyone but Casting/ED are barriers!

I am not a programmer per se, but I think everything is fine as-is with casting/dispatchers right now. At first I couldn’t wrap my head around it, but then I simply watched/read training materials and applied the core principles in practice.

If you had to start over again tomorrow on a blank new project, would that view still hold? :slight_smile:

Sure when you have a clear structure in place: gameplay / characters / weapons all setup etc…
But when you don’t when you’re improv’ing or when you’re a novice then I don’t think its easy.
I think the simplicity that Kismet brought to the table as regards game-making has been lost.

As a techguy developer I get why both are there, but I think more could be done to simplify BP.
Here’s two recent posts, look at how complicated certain things are made that don’t need to be.
Epic should push to make Blueprints as easy as possible because so much isn’t exposed anyway…

Casting it’s not barrier, it limitation needed to keep code clean, fast and understandable. Yes, Kismet was easy to use. And also easy to make a mess and kill performance.
BP architecture forces you to design a lot better code. Implementing what you ask would require more operations performed during compilation or runtime. If ever possible, BP it’s still child of C++.

Case 1) If I know I gonna need some functions from my class, I store references as “MyClass_C”.
Case 2) I store references as Actor usually if I need native Actor functions here.
Case 3) Sometimes I store references as Actor and I still cast object to specific class, but… likely there are only 2-3 possible classes which are referenced by this variable. It’s easy to cast it and perform different chain of actions.

Think how you gonna use variable when defining its type. It’s really no hassle when you get used to it.

Look at what you wrote though, it clearly shows experience and planning etc.
To me that just confirms Casting / Event-Dispatchers are barriers to newbies…

But I’m not making a case to change the current set-up, better don’t break it.
I’m just asking a question if its possible to add optional layer to simplify things?

We know the Epic guys aren’t on the forums as much as they were a year ago.
Makes me think maybe they’re strategizing on the next shinny, or Unreal 5 etc.
Just a gut feeling after the roadmap was overhauled. If so get requests in now. :slight_smile:

That’s good. At least they will learn, and we don’t have to deal with questions “why this mess does not work/is so slow” whle trying to untangle web mess of kismet.

You often see a lot of the same Kismet mess on here…
My pet hate is people not using variables in loops etc.

I don’t see how event dispatchers are hard to understand. The only strange thing is that you need to untick context sensitive when trying to bind to an event dispatcher from some unrelated BP.

You said that the caller and callee need to know about each other but that isn’t true, you only need a reference for one of them. So if you put them somewhere where you can always get a reference to them (like in the player controller by Get Player Controller) they’re super easy to use.

Like the identical events in duplicate places thing you said, put an event dispatcher in a custom player controller, assign it to an event, in other BPs call the event dispatcher using Get Player Controller - Cast to CustomPlayerController (right click to make it a pure cast). Clearly not impossible. :stuck_out_tongue:

Overall, it makes sense that Epic really are busy formulating the next 5 year plan or so.
So I’d like to see BP get easier or become more capable (more stuff get exposed) etc…
Rather than having it stay the same way or get stuck in a dead-end like Kismet before.

Well hard to understand for newbies / Artists maybe etc.
And tricky to work around / plan for all BP dependencies.

But when you register the Bind you need to know what other BP’s will call there.
If lots of other classes are going to need to phone-home there’s Duplicate code!
Then lets not forget Casts in all of this, which are maybe the greater headache.
Plus there may be Parameters also too in all of these Event-Dispatchers etc etc.

But I’d still like to be able to call Events on any BP…
And like to go back to working with one Object type!

Or up the complexity of BP and make it all worthwhile etc.
Don’t fancy C++ again and there’s no Kismet Get Property…:slight_smile:

Everything is hard for newbies. That doesn’t mean we have to sacrifice workflow efficiency to help new people. Especially now because there’s a 2 hour video explaining blueprint communication anyway.

What other BPs will call there is mostly irrelevant. You’re probably going to have some idea but you can add more BPs after the fact if you want and you don’t have to change anything. I don’t see how casts are a headache either. You’ve got some kind of object but you want to make sure it’s the right one.

It’s like you’re making a phone call, I call your house and someone picks up so I know it’s a human…class. “Are you franktech?” “Yes!” and the cast succeeds. Or “Are you franktech?” “No, I’m a burglar.” and the cast fails. And I should probably call the police. Anyway in UE4 that’s how it works, you start by getting some general object type and narrow it down to the thing you want by casting.

You can call events on other BPs by casting to them first and then if the cast succeeds trigger the event.

That’s how you get there - work your way up and plan your projects from the ground up.

To answer your previous question, if I had to start from scratch, I’d have no problems with casting. After all, I started from scratch with my current project to begin with and I didn’t have prior UE4 experience.

BPs are basic OOP (I don’t know about Kismet, I haven’t worked with UDK)
and I don’t understand what exactly the problem is. Do you want that when a BP has an Event “Event_A” and another BP has an “Event_A”, too that you can call “Event_A” without any casting?
That’s what interfaces are for. Calling Interface Functions do not care about the underlying BP only that it implements this function. The Interface Call will fail silently if it does not implement this Function.
And UE automatically provides the function calls if you create an interface which can be called on every BP.

Just querying if it would be possible to build a layer over BP, that would simplify it closer to Kismet :

  1. No casting, just one object type…

  2. Custom-Events get called whichever BP they reside, purely on a name-match basis…

Interesting! This is possible using BP alone?
If so, can you detail the steps … Cheers!

Overall, asking this now because I’m curious if plans for BP will make it simpler / more complex.
It could suit me also if BP became more complex, because then C++ might be almost optional.
(My C++ is rusty / Not a fan! Don’t know if I ever was. But it was the only viable option once)…

Looks interesting… Although I’m not clear at all on the restrictions etc.
Interface functions are custom events and can have timers and delays.
Or they’re just functions? Sounds like the latter but the doc isn’t clear!

Ok, they’re like an abstract layer / empty procedure / definition.
Must have a look at these and contrast with Event-Dispatchers.
But it doesn’t look like there’s any restrictions. Cheers for the tip…

Functions without a return type are Events.

You first create an Interface and let multiple BPs implement this interface via the Class Settings.
The Function/Event of the Interface will then be automatically in the Blueprint.

If you want to call this Interface Function/Event, simply use the Interface Message Call. Notice: You don’t have to cast it. you can have a Actor Reference but you can still call this function/event.
If the Reference type does not implement this interface, it will fail silently (With return types you have to be cautious, because they will be None for references and 0 for integral types)

Here’s an example just now of how BP can seem very inaccessible at times:

Cheers @Raildex_