What's the common way of checking actor validity before input?

[Rawalanche]

Hi,

I have this game where I control pawn from player controller through a reference, and relaying the input indirectly, as the player will be able to control multiple pawns at a time. There are some other level elements that rely on a reference to this pawn. The pawn can be destroyed, and at that point, the reference becomes invalid and message log throws error. So I have added validity checks where appropriate.

I do the validity check every tick. It appears however, that the input is processed prior to every tick, so if I send an input to an invalid actor, I still get one or two errors before validity check through the tick actually catches it.

I am sure people deal with these trivialities on daily basis, so I wonder what is the most common way to handle this?
I thought of adding the validity check on the InputAxis event, but my intuition tells me that using a random axis event in a player controller to do validity checks for an actor many objects in the scene rely on is a bit awkward solution. Also, I don’t know what the order of the InputAxis events is, so to ensure the check works, I’d have to do it twice on both axes, and doing two validity checks each frame feels like a waste.

Thanks in advance.

[Demeese]

[Screenshot - c667b2bce76d2531b40050d43f0baaad - Gyazo

This is the node!](Screenshot - c667b2bce76d2531b40050d43f0baaad - Gyazo)

[Demeese]

Are you doing your input through the controller? In my opinion a better practice would be to use input on the pawn itself. I think this is how Epic wants us to do it as well. If you do it this way, the controlled pawn will always be valid while the input axis are firing!

[Rawalanche]

@Demeese

https://gyazo.com/c667b2bce76d2531b40050d43f0baaad.png

[Screenshot - c667b2bce76d2531b40050d43f0baaad - Gyazo

This is the node!](Screenshot - c667b2bce76d2531b40050d43f0baaad - Gyazo)

Yes, I get that. I think it’s the same as what I already have on my blueprint, except I am using isValid function that outputs bool which goes into branch. That is not my question. My question is that I have to do that validity check before InputAxis event happens, and InputAxis event happens before tick. My concerns are that doing it on InputAxis event is just not a right thing to do, so I was wondering if there is a “more right way”

Regarding the controller, yes I am using player controller and forwarding the input to pawn. That’s necessary here, because in my game, player will be able to control multiple different units and swap between them. That means I want to have input logic on one central place (player controller) and then use those input events and values to to different things on different types of units On top of that, only one pawn can receive input at a time, so this is kind of workaround for that.

[Raildex]

@Rawalanche

Regarding the controller, yes I am using player controller and forwarding the input to pawn. That’s necessary here, because in my game, player will be able to control multiple different units and swap between them. That means I want to have input logic on one central place (player controller) and then use those input events and values to to different things on different types of units On top of that, only one pawn can receive input at a time, so this is kind of workaround for that.

The Input System in Unreal takes this into account. You don’t have to put your input into the controller. you can implement the AxisEvents and ActionEvents directly in your Pawns.

[Demeese]

@Rawalanche

My concerns are that doing it on InputAxis event is just not a right thing to do, so I was wondering if there is a “more right way”

There isn’t really a more “right way” to check validity of an actor. Using the IsValid macro node on the input instead of setting the bool on tick will get rid of the errors its throwing you because, yes, the input fires before the tick. Doing just that will already save you some time, because right now your setting the bool every tick, then checking the bool on 3 input nodes.

@Rawalanche

Regarding the controller, yes I am using player controller and forwarding the input to pawn. That’s necessary here, because in my game, player will be able to control multiple different units and swap between them. That means I want to have input logic on one central place (player controller) and then use those input events and values to to different things on different types of units On top of that, only one pawn can receive input at a time, so this is kind of workaround for that.

I understand what you’re trying to do, and I also thought before that having all input in the controller was the easier way. However, Epic has taken care of that for us in the framework. So to answer to the “right way” is more of a misuse of the game framework.

From an epic developer:

@JamesG

I think you may be getting confused by the name ‘PlayerController’, sorry about that! This is not where the movement logic lives. A ‘controller’ represents a ‘will’ in the game that can ‘possess’ a pawn to control it. A controller could be an AI or a real player, hence the terms AIController and PlayerController. This doc gives an overview of our architecture: https://docs.unrealengine.com/latest/INT/Programming/Gameplay/Framework/index.html

To get a basic game up and running, you only really need the Pawn class. It’s the Pawn class that handles the input and moves itself around. Character is a special type of Pawn which includes ‘walking’ movement logic, and is used as the basis for templates like the side-scroller. You only really need to create your own PlayerController to handle logic outside of the Pawn, things like bringing up a mid-game menu for example. Our Character class is quite flexible, there are some great tutorials and example out there of extending it to add dodge, climbing etc. In 4.2 we made it even easier to do things like double jump, and we’ll be releasing a video tutorial to cover that.

[Rawalanche]

Well, here is my dilemma:

My game is kind of Cannon Fodder style. RTS style view with camera smooth following the units from aerial view. For me, the easiest solution with least workarounds was for the Player Camera pawn to be the pawn that’s possessed by the player controller. It appears that Unreal prefers the camera player is viewing the level through to be component of the pawn that is actually possessed. If it was the other way around, and the possessed pawn was the actual unit I am controlling, then each unit would have to have their own RTS style camera duplicated, and if I was switching between the units, it’d be tricky to make camera slowly lerp from one unit to another.

This way, with possessed pawn being the floating camera view (which Epic suggest in their docs), I can not directly possess any other pawns.

And I was unable to find a way for non-possessed pawn to receive any input directly, I’ve even made this thread about it:
https://forums.unrealengine.com/deve…e-pawn-at-once
…and later solved the issue using the workaround I just described.

So then there were only two places I could put the movement logic inside of. In the floating camera pawn that players controls to see the game level, or the player controller, which would then pass the inputs to both the camera, as well as the multiple controlled units depending on which one is active. Latter option seemed like more appropriate place to do so.

I still have some input events directly in the possessed floating camera pawn, but only those that will concern only the camera movement intself. Those inputs which concern indirectly controlled units are in the player controller, and being sent to whatever the active unit variable is. That way if the active unit is for example a Tank, then horizontal axis can be interpreted as steering while vertical one as throttle, where as if the active unit is just a soldier, the axes can directly define walking directions.

With all the being said, I am still a beginner, so if there is a better way to do it, I’ll be thankful to learn it. This was the best one I was able to figure out so far

[Rawalanche]

@Demeese

There isn’t really a more “right way” to check validity of an actor. Using the IsValid macro node on the input instead of setting the bool on tick will get rid of the errors its throwing you because, yes, the input fires before the tick. Doing just that will already save you some time, because right now your setting the bool every tick, then checking the bool on 3 input nodes.

This is where I am a bit confused. AFAIK when it comes to Axis event, their execution pins are pretty much equivalent of the Tick, since they fire every frame. So doing the check on both of the axis events (since I don’t know the order they’re executed in) instead of Tick would mean I am now doing the check two times every frame. I am sure overhead for that is tiny, but I guess I have a certain intuition that tells me that is not a right way to go about it. That’s what I meant by the right way.

Although I think I’ve came up with the solution. I don’t really need to check the validity I think, especially each frame. I just have to set the boolean to drive the checks with to true once the unit is spawned, and then to false once the unit is destroyed. I think actor destruction is usually done at the end of frame, after other logic ran, so if it flips the bool then, then once new frame starts, the inputs will already have correct bool value and won’t fire to trigger the logic referencing the destroyed actor

[Demeese]

It’s typical in an RTS to have the controlled units as AI. Your camera controller just feeds them information based on your selections and clicks.

[Rawalanche]

@Demeese

It’s typical in an RTS to have the controlled units as AI. Your camera controller just feeds them information based on your selections and clicks.

Yes, sorry for the confusion. I mentioned RTS just in terms of how the view of the game is handled. The units themselves are controlled quite directly. In example case of a tank, WASD to move and mouse cursor position to aim the turret. So no indirect, AI based control. But at the same time, there will be more than one unit and player will be able to swap between them using some key.

- YouTube

[Demeese]

Ok, I see. So just to make sure, you’re technically still only controlling one tank at a time right? or do multiple tanks follow your input command at the same time?

If it’s still only one tank we’re controlling at a time, then it’s possible to use the framework as intended while switching between them, and even switching back out to your camera pawn.

Now, if you want multiple tanks to be following your input at the same time, then this is something that you’ll just have to come up with an implementation for. Then we come back to your original question–

Checking validity every frame on each of the input is not expensive. The way your doing that with the bool, or replacing it with the macro node is the only way it’ll stop it from throwing you errors.

[Rawalanche]

@Demeese

Ok, I see. So just to make sure, you’re technically still only controlling one tank at a time right? or do multiple tanks follow your input command at the same time?

If it’s still only one tank we’re controlling at a time, then it’s possible to use the framework as intended while switching between them, and even switching back out to your camera pawn.

Now, if you want multiple tanks to be following your input at the same time, then this is something that you’ll just have to come up with an implementation for. Then we come back to your original question–

Checking validity every frame on each of the input is not expensive. The way your doing that with the bool, or replacing it with the macro node is the only way it’ll stop it from throwing you errors.

Yes, only one tank/unit at a time. I will see if the spawn/destroy based notification causes any of the errors to still pop up, and if it does, I’ll revert to checking on every axis event. Thanks for taking the time to answer my stupid questions

[Demeese]

@Rawalanche

Yes, only one tank/unit at a time.

Ok, then in this case you WILL actually be able to have movement input on your pawn. You’d have your PlayerController initially possessing your camera pawn. This camera pawn will allow you to click and select a tank (or however you’d like selection to be), then tell your controller to unpossess the camera pawn and possess a tank pawn. There are nodes that allow you to create a smooth transition between view targets.

You can then later unpossess a tank and move back in to your camera pawn, or just go directly to another tank. Your camera pawn will remain floating there for you, so as an example, OnUnpossessTank->SetCameraPawnLocation->PossessCameraPawn.

[Rawalanche]

@Demeese

Ok, then in this case you WILL actually be able to have movement input on your pawn. You’d have your PlayerController initially possessing your camera pawn. This camera pawn will allow you to click and select a tank (or however you’d like selection to be), then tell your controller to unpossess the camera pawn and possess a tank pawn. There are nodes that allow you to create a smooth transition between view targets.

You can then later unpossess a tank and move back in to your camera pawn, or just go directly to another tank. Your camera pawn will remain floating there for you, so as an example, OnUnpossessTank->SetCameraPawnLocation->PossessCameraPawn.

I supposed I could do that, but at this point, I am not sure I’d gain much compared to the current workaround. I could be actually swapping the possession of the pawns instead assigning them as an actor reference variable to which the input gets sent, but that would mean that my camera logic now needs to live and be synchronized in every pawn I could theoretically possess, and so would the actual input mappings.

Right now, in case I decide to change or extend camera functionality, there’s only one place to look at, camera pawn. I don’t really need to care about managing view targets, as the camera will never change or die, just move around. On top of that, if I decided to change the input bindings, again, there’s only one place to go to, my player controller. Individual units just implement an interface to decide how to interpret the input, not what the actual input is. I think that offers a bit more flexibility Especially in the example of tank vs soldier I’ve mentioned above.

Thank you again for the help though