What kind of systems have you used to buffer player control inputs?
Ie. Player Presses Y to throw a granade. While the animation is playing, he wont be able to shoot. But when the animation is close to being finished, the controls should be registered into a buffer, as what happens now, is that if player presses A to shoot a bit too early, this results in player character not shooting at all. Which feels clunky controls. Instead, the key press should be buffered for a while and keep in hold until the player can perform his next action again.
Hello,
I am not sure about the best way to implement it in blueprint / I would try to save it in a variable with a timer before deleta thenand check if variable is empty or not when it is ok to play again but not sure it ould work fine.
Anyway, i ve seen in marketplace a plugin: input buffer basic that i think you would try.
Thanks, I might check the plugin or try some things myself first. Buffering controls is an important thing in most games though. The better the animations get, the more important its to have buffering, or the game will look and feel sluggish.
I don’t think you’ll be able to get away from having to either get a plugin or create some custom nodes. It also depends on what kind of buffer system you want (do you need to buffer several inputs or just one or two?). I’m not really a programmer, but a bit of thought with my own custom nodes led me to create this example:
I tend to work in character states. My example character has Idle state, Attacking state, and Charge Atk state. In the Idle state, my character has two button inputs; pressing Tri will put my character in the Charge Atk state and pressing X will put my character in the Attacking state. For brevity of the example, the Attacking state only has simple logic in it to return the character to the Idle state 1 second after entering the attacking state. I should mention that the way the InputAxis’s are set up in the Idle state grant a lot of versatility; if you hold X as the character enters the Idle state, it will immediately re-enter the Attacking state. The Axis Neutralizer connected to InputAxis Tri can nullify this behavior (holding Tri as the character enters the Idle state will not do anything until you let go of Tri).
The Charge Atk state has a bit more complicated logic. Upon entering the state, it sets a Buffer State variable to Idle. 3 seconds after entering the state, it sets the character state to the buffer state (i.e. if nothing happens, the character just goes back to idle). But in the 2.5 to 3.0 second window after entering the state, the player can press the X button to set the Buffer State variable to Attacking, which will send the character state to that new state upon leaving the Charge Atk state.
This is a really really awkward way of implementing an input buffer system, but it does offer a lot of versatility. It also requires the implementation of a few custom nodes. I’ve talked about these custom nodes before over here if you’re interested:
It’s an option, but depending on your application, it may not be what you’re looking for.
Thanks, that looks something like what I have, but seems actually more simple than my weirdish delta-time counters for every action input. I will have to adjust a bit since my control scheme is totally different, but I can try parts of there.
No problem.
I’ve made a few improvements to some of my nodes and created a relatively simple method of buffering single button inputs:
The HoldUntil node works similar to a HoldGate node (it will allow execution pulses to go from Input to Output only if it is receiving execution pulses into the Release port) but is able to “hold” an execution pulse for a set amount of time. In this case, when the Squ button is pressed, the branch is opened, a single execution pulse passes the OnFlowStart node and gets trapped in the HoldUntil node for 0.1 seconds. If an execution pulse is not sent to the Release terminal within that time, the pulse held by the node disappears. If it does receive an execution pulse, the held pulse is released, thereby setting the Air State to Air Slam.
For your setup, you could set the Release pulse to be conditional on returning to an idle state and replace the Set node with whatever nodes you need to fire your gun.
The HoldUntil node has some rather convoluted logic, but it works somehow:
I should mention that all my custom nodes require the C++ programming of a custom node (which I call CustomRDelay). The coding is different depending on what Unreal version you’re working with and some of these nodes may have buggy behavior on older versions of Unreal.