Best way to intercept input events for HUD if not using Slate?

We’re working on implementing some on-screen buttons via C++, and we’ve tentatively decided to not use Slate. What’s the best way to intercept mouse up/down events, to ensure that a left or right mouse-down does not get passed on to the game if the HUD intercepts it? I could try passing them through the PlayerController (and just call something directly on the HUD from there) but that seems like a hack; surely that can’t be the right way to do it.

For our understanding of what people like and don’t like about Rocket, can I ask why you are choosing not to use Slate when working in C++?

Are you using the HitBox click events system that we’ve already implemented (which is mostly intended for being able to do UI from blueprints until such a time that Slate can be exposed to blueprints)? If you are you’ll have noted that it doesn’t have a way of intercepting the input to the rest of the input handling system, perhaps it (and the actor/component clicking system) should optionally allow that. I will consider that further.

Philosophically the HUD class is really intended for displaying information for a given Player and not really for interacting. It is owned by the PlayerController and so is the PlayerInput handling, so no matter what you do here if you want to use AHUD for interacting it is going to involve in some ways intercepting the input.

If you want to make an interactive HUD system I think what you’re going to want to do is make your own PlayerController subclass, override InputKey, and in the case of the key being MouseButtonLeft (and Right if desired) route it to your HUD subclass, determine if it wants to handle it, and if so not call Super::InputKey.

Thanks, Marc –

The bottom line is that the documentation for Slate is very incomplete, and although I’ve spent quite a bit of time reading through the docs and looking at the examples that use it (such as the ShooterGame), I wasn’t able to prove to myself that using Slate was the right way to go, or that it would be any faster than doing it myself.

The “Slate Architecture” doc is nice but a bit more high-level than I need, while the “Slate Overview” section jumps right into a bunch of complex examples without giving a lot of context (specifically, where are all those different code blocks supposed to go? … and how does Slate interact with the rest of the system?)

EDIT: I’ve found Rama’s tutorials much more useful in this area. What I’d really like are a few sections to take me through: here’s how to create a simple on-screen indicator on the HUD; here’s how to extend that to accept mouse events, etc.

I wasn’t aware of the HitBox click events system until you mentioned it, and I’m not seeing anything about it in the documentation or the UDN.

If you want to make an interactive HUD system I think what
you’re going to want to do is

Thanks, yes – that’s what we’re trying to do. What we really want to do is make a whole UI system, including interactive components (on-screen buttons), non-interactive components (popups, indicators), and various other menu components on top of them.

I’d be happy to use Slate for that if it’s the right way to do it, but it sounds like what you’re saying is we’d be better served writing it ourselves.

Slate is certainly the intended UI system for UE4 and as such I would think in most cases the best choice. While there are definitely usability issues (particularly with blueprints being unable to access it) and learning curves for now it will be supported and continue to be improved, while writing your own is probably more work for you and likely going to result in maintenance issues.

I’ve flagged this post for the documentation team to try and encourage them to improve the documentation and I’d encourage you to ask as many questions as you need to try and work out any issues with getting the system working the way you want and help us understand what parts of the system are not clear and need better documentation.

I believe the StrategyGame sample game has some HUD elements built using slate if you want a resource to look at. There is a brief overview of it at https://rocket.unrealengine.com/docs/ue4/INT/Resources/SampleGames/StrategyGame/index.html#in-gamehud and then you can download the sample and look at the code.

OK, thanks, Marc. I will do that.

By the way Marc,

In case you’re curious why I am not using Slate,

I took one look at the c++ for it early on when I was just learning UE4 C++, in the shootergame example, and I just couldnt follow it at all :slight_smile:

I really think if you want to make Slate something everyone can get into, a Slate-maker GUI within the editor would be a HUGE help

I envision this as something that works like blueprints but is really something that generates Slate C++ code for people.

The unusual consideration here will be whether to force people to make every function they want to call from the Slate Maker Blueprintcallable or whether to somehow allow people to use any c++ function from the Slate Maker

I can’t see Slate becoming as popular as you want it to be without some sort of Editor GUI Slate Maker

If you take the time to do this

I bet people will looooooooove it

(me included)

having a base node class to create custom slate maker nodes would of course be awesome

Oh I know I could take the time to understand the c++, but that’s me and a minority of others who will go deep into the c++


I am just really wanting to convey that a GUI Slate Maker would be AWESOME


:slight_smile:

Rama

PS: oh and Marc, Thanks for all your awesome C++ help! You’ve helped me on many many occasions now with my project and my project shows the benefit of your help :slight_smile:

Yes, this would be fabulous – something like what Unity just released in version 4.3 would be awesome.

And I love the idea of being able to use Slate in C++, too, but right now the docs for Slate are in such a state that I’d recommend rewriting all of them from scratch.

Marc – Now that the latest beta has the “StrategyGame” example, we’ll take a look through that – that’s definitely a much more useful example to us, and I expect it should get us up and running with Slate in a hurry.

you could use GetMousePosition and check every tick if WasInputKeyPressed(EKeys::LeftMouseButton)

and then only process the LMB for gameplay if it is not within the bounds of your HUD elements.

You could run this check every tick in your playertick of your custom pc class :slight_smile:

here’s my tutorial with lots of code on creating a custom cursor, you could adapt the code to your current goal

http://forums.epicgames.com/threads/972861-Tutorial-Compile-C-for-UE4-Code-Samples-For-You-gt-gt-New-Get-Set-AnimBluePrint-Vars?p=31656285&viewfull=1#post31656285

#Intercepting

Again I am saying you are “intercepting” the mouse input by routing the input to the HUD or to the gameplay functions yourself based on whether the mouse position is calculated to be within the bounds of your HUD at the tick that the mouse down occurred.

I am presuming that you are processing the left mouse button press for gameplay within the c++

Let me know how this goes for you!

Rama

Thanks, Rama – loving your tutorials BTW; they’ve been a huge help to me.

I could do it that way, but it seems to me that polling in a separate part of the code like that, and then trying to pass some other messages to the other parts of the system to not intercept the event, and dealing with potential timing issues, just can’t be the right way to do it.

With input events like this, you really want to have some kind of a clean system where you pass it through a series of potential receivers for the event in order, and if any system says it wants it, it doesn’t get passed through to the others.

So I could certainly do that manually. Which seems to mean I’d need to get a pointer to my HUD class from inside my player controller, cast it to my derived class, and then call some bool MyCustomHUD::DidWantMouseEvent() method …

which is …

… a bit “messy,” to say the least. A player controller really shouldn’t know about a HUD.

Paul

Glad you like the tutorials :slight_smile:

It seems you are favoring having some third party code regulate what the player controller gets and what the HUD gets

but I think you’ll find that just actually enabling your core UE4 classes like HUD and player controller to communicate is how you will actually get your design features to manifest in code

To me the HUD is basically an extension of the player, and the closest thing to the player in the code is the player controller.

So in my view the HUD is really player controller part 2 :slight_smile:

Getting your player controller and HUD to communicate is really not hard and in my opinion really quite essential.

//Within pc class
AVictoryHUD* JoyHUD = Cast(GetHUD());

//within HUD class
AVictoryGamePlayerController* VictoryPC = 
		Cast(GetOwningPlayerController());

It’s just 1 line of code each, it’s not bad.


if you go for the idea of having some third party code that is not HUD or pc regulating what HUD and pc gets

well

then you have to write a class to handle that

or use the Game replication info class, or the game info

and so you will end up needing MORE references to custom classes, both HUD and player controller

and you still need to figure out a way to get the player input

which should probably be done through the player controller → player input anyways


#Player Controller gets the input

fundamentally the fact is you said you are giong for a non-slate method

so you need to get lots of input from the player’s keyboard and mouse and pass it to your hud

the best way to do that that I know of is to go to the source

player controller has player input and you can use WAsInputKeyPressed etc to get ANY key input you want.

If you see my video on my multiplayer chat system, I am tracking all the possible chat letters and symbols via my player controller class and passing it to the HUD :slight_smile:

In my opinion a third party manager would just make things even more complicated.

These are all my opinions of course, I’m not claiming it is the best or the only way

:slight_smile:

Rama

Right. That will certainly work; it’s just a question of the most elegant / natural way to do it, compared to all the other engines I’ve worked with.

Part of it is the assumption in Unreal that there is a “player” with a controller and a camera, and everything going through that controller. That tends to throw me for a loop, because we’re making more of a strategy game without any particular character or entity associated with the player.

Anyway, we’ll see if any of the Epic guys chime in and suggest a better way to do it, but I’ll go with your recommendation until then :slight_smile:

Paul