Input focus could not be acquired since the buffer is full (16) (SOLVED)

Questions
#1

I’ve got the message

WARNING:GAMEOBJECT: Input focus could not be acquired since the buffer is full (16).

How can I enlarge the buffer for gameobjects? I need at least 24

"Match Pairs" game : how should I handle click on all cards?
#2

Why not have a manager which handles input for all game objects?

1 Like
#3

I believe this has been discussed here before, but I can’t find the post now (I could be wrong and maybe it’s something we discussed here at work). In any case, it is currently not possible to increase the number of things that can have input focus at the same time. The reason for this is to some extent to highlight a bad design decision (sorry!). Just as @Pkeod suggested I think it would make more sense to have a central receiver of input and let that receiver decide if and to whom to pass on input. This design with a central input handler also makes things such as temporarily disabling input so much easier (one place instead of 24).

1 Like
#4

Good idea! :thumbsup: It requires me to rewrite a main code though…

#5

Done. Works well! :nerd:

1 Like
#6

Sorry to necro this topic, but I’m getting close to 16 in one of my projects and wonder how an input manager should be structured.

In a previous project, I did have a centralised input manager because I wasn’t comfortable with on_input(). I’ve now got used to using on_input() and find it works very well, except I’m now getting close to 16 scripts with focus!

My previous project’s input manager required me to check for input in update(). This was clunky, had unintended consequences, and I imagine it’s not as performant as using on_input().

How is everyone else doing it?

#7

I think having 16 input controllers at once is quite a lot to be honest.
In general, I would have 2-3 at most at the same time. E.g.:

  • Main game menu

    • Sub menu / dialog

    • In game (player controller)

      • Pause menu
1 Like
#8

I have some temporarily focused scripts (e.g. to allow my intro logo to be skipped) and some scripts that won’t make it to release (imgui debug, godmode).

Not counting those, I currently have:

  1. Collection manager (to pass down to proxies)
  2. Gameover screen
  3. Main menu
  4. Character select
  5. Meta-progression upgrade screen
  6. Another meta-progression upgrade screen
  7. A third one…
  8. Pause screen
  9. Player controls
  10. Levelup screen
  11. Input utility script (what I use to do rebindable keys and detect whether we’re using gamepad or mouse+keyboard)
  12. Keyboard shortcut utility script (for things like Alt+F4)

So I’m not quite at 16 in the end but for a more complicated game I could see it happening. If it gets tight I could combine some things, for example input utility and keyboard shortcut utility, but I feel that would introduce a loss of clarity in what each script does.

I’ve worked at moving away from large scripts, and I am finding it enjoyable working with smaller modular scripts (e.g. my flow main menu → character select → level select would now be 3 GUI scripts rather than one big one). It seems you suggest that fewer scripts are the way to go, which would be disappointing to me!

1 Like
#9

Sure, but I wouldn’t have them all active at the same time?
Same as you’re not displaying all the screens all at once.

1 Like
#10

You know, that’s a good point. I agree it would rarely make sense to have 16 scripts actively taking input. I could see there being a handful at the same time (e.g. a player + a pause listener + a few utilities like the keyboard shortcut thing I mentioned).

So rather than managing input centrally, I would make sure to manage input focus. I don’t know if disabling a GUI releases input focus, but if it doesn’t, that would be a trivial thing to implement and would ensure we’d never be close to 16 at the same time. For example if my gameover GUI is not active I could just ensure the input focus is released.

Guess I was worrying a bit prematurely :slight_smile:

3 Likes
#11

My input controller reads the hashes and sends them almost straight on using msg.post() to the scripts that need them. It was one of the quickest things I’ve ever programmed and it always worked perfectly - it was really easy to convert the on_input functions I had previously written into on_message functions.

my method overcomes this limitation and has allowed me to design exactly as badly I wanted :rofl::rofl:

4 Likes