InputActionReference enabled, but nothing occurs

This is a test script I am trying to use as a base for a much larger and more complicated system (a rhythm-based mode for my game).

I have created 4 public InputActionReferences and have assigned them in editor – all looks well there. I have enabled them, and am simply trying to have it output to the console when one of the actions is performed. That’s it.

As of yet, I have gotten absolutely no feedback from these InputActionReferences. I have boiled the gist of my code up to this point down to the following, and I am wondering – what am I doing wrong? Have I missed some step? I have tried a variety of things, but either nothing has changed from this level, or fatal errors have resulted. The reality is: I really just want a reference to the button presses in the particular action map I care about, not just the button press in general. This feels like a very simple way to complete that objective, but, I really am at a loss for why it doesn’t throw anything. Perhaps something different would complete that goal better? That’d also be valuable feedback.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.InputSystem;

public class TestForInputAction : MonoBehaviour
{
    public InputActionReference NoteButton1;
    public InputActionReference NoteButton2;
    public InputActionReference NoteButton3;
    public InputActionReference NoteButton4;

    private void Awake()
    {
        /*
         * It hasn't mattered whether or not I use the "ToInputAction()" or just "action". They both seemingly do the same thing, in this case.
         * Which is to say...they both have equally not worked, save for simply enabling them.
         */
        NoteButton1.ToInputAction().Enable();
        NoteButton2.ToInputAction().Enable();
        NoteButton3.action.Enable();
        NoteButton4.action.Enable();

        NoteButton1.ToInputAction().performed += ctx => OnNoteButton("1");
        NoteButton2.ToInputAction().performed += ctx => OnNoteButton("2");
        NoteButton3.action.performed += ctx => OnNoteButton("3");
        NoteButton4.action.performed += ctx => OnNoteButton("4");
    }

    private void OnNoteButton(string p)
    {
        Debug.Log("What was pressed: " + p);
    }
}

I really would like this to work, and I have found seldom little to help beyond a year-old forum post with a similar issue, but enabling it somehow worked for them, and not for me.

BTW, For some context…I am able to make these button presses do things in my movement script, for example. But that requires me create an instance of my InputActionAsset (called PlayerController, in my context), and to call directly to the action map and action I want like so:

_playerController.FirstActionMap.LightAttackButton.started += ctx => Attack();
But, for this particular use case, I don’t want to have to create a whole new instance of my InputActionAsset – it wouldn’t make much sense. I just want the reference to the action itself to see if it is being pressed.

I haven’t use “InputActionReference” before, so this is new territory for me.

This code works:

using UnityEngine;
using UnityEngine.InputSystem;

public class Reporter : MonoBehaviour
{
    public InputActionReference iar;

    private void Start()
    {
        iar.action.Enable();
        iar.action.performed += c => Debug.Log("iar");
    }
}

I had areadly set up an InputActionAsset with a map, action, and binding (the left mouse button, to be specific). In the editor, I clicked on the bullseye to the right of the field exposed for my iar variable, then selected the map/action I wanted.

How did you set the value of your InputActionReference?

If you open the InputActionAsset in the Project window, you can also drag and drop the actions from there into the matching field

7005191--828233--upload_2021-4-4_11-59-48.png

7005191--828239--upload_2021-4-4_12-0-52.png

That is also how I set them, yes. I think the only difference between your code and mine is that you placed your enable and performed code within Start(). Everything about our processes is the same, down to assigning them via the editor. Will test here tonight and see if my code could be better served by placing it in Start() rather than Awake().

I also just copied your code exactly and it runs fine. Not to insult your intelligence, but are you sure you have added this script to an active GameObject in your scene? I make that mistake all the time…

I noticed that about Start/Awake too, so I changed mine to Awake and it still ran, as does your code now that I have copied it exactly.

Hm. That is very odd. In answer to your question, yes I have it attached to an active game object in my scene. In that case, I don’t know what would be the problem…I do have logic tied to those controls via my main PlayerCharacterInput script, perhaps I can’t have both? That seems strange though, I don’t know why it wouldn’t be working, then. I would guess then that it might be due to the fact I have that test script attached to the same game object as my other logic – my player. I’ll try disabling my other script that uses those controls and see if that is causing some amount of issue. I could certainly see that being the case.

If you suspect anything else is interacting in a bad way, I’d suggest opening a new project entirely and adding just the code you have posted here. Assuming that runs for you as it did for me, then you can start adding stuff until it breaks. But make it run first! The actual reason it isn’t running may be hard to find, so having two projects (one where it runs and one where it doesn’t) will let you sort of converge them to a point where they are almost identical, with only a slight change left that converts the one that works into the one that doesn’t.

I call this the “moose in Alaska” technique, based on an article I have never been able to find again, but that I remember reading around 1980. The author suggested using a form of binary partitioning to find bugs. If the bug were a moose and the program were Alaska, you could find the bug/moose by successively dividing the program/Alaska into halves. Generally, you’ll know which half the moose is in, after which, you divide that half again. Keep doing this until the space left is small enough that you can see the moose just standing there. It’s not very elegant, but it gets the job done and we don’t get style points for how we find our bugs.