Input Audit — Godot 4 input action audit

Finds the action names that do not exist, and the actions a controller — or a keyboard — can never press.

---

if Input.is_action_just_pressed("jmup"):
    double_jump()

That line compiles, runs, and does nothing, for ever.

Why nothing tells you

An action name that is not in the input map is not an error in Godot. Input.is_action_just_pressed() returns false and prints nothing — at build time, and at run time. There is no warning, no red line in the editor, no message in the console. The double jump is simply gone, and the only symptom is a feature nobody remembers to test.

The same silence covers the rest of the input map. An action with nothing bound to it. An action bound only to a mouse, in a game that ships on a console. Two actions on one key, so one press fires both. A stick with a deadzone of 0, which reads as held for ever on any controller with drift.

Input Audit reads the input map out of your project file, reads every place your code and your scenes name an action, and puts the two lists next to each other.

What it reports

• Action name that does not exist — with the file, the line, and the real name it is one or two letters away from
• Action with nothing bound to it — in the map, with an empty event list
• Action no key or gamepad can trigger — bound only to a mouse or a touch
• No gamepad binding — a controller cannot trigger it
• No key bound — a keyboard cannot trigger it
• One press fires two actions — the same physical key or button on two actions
• Extreme gamepad deadzone — below 0.01, which never releases on a drifting stick, or above 0.9, which ignores almost the whole travel
• Action nothing uses — in the map, and never used as input anywhere in the project

Nine findings, not a hundred and forty-two

Every project's settings contain the engine's own ui_* actions whether the project ever touched them or not — about ninety of them, most keyboard-only, many sharing keys with each other. A tool that reports those hands you a hundred and forty-two findings, of which nine are yours, and you read none of them.

Input Audit reads which names your project.godot actually declares and leaves the engine's alone. A ui_ action you did override is yours again, and is checked like anything else. Both numbers above are measured on the bundled demo, not estimated.

Where it reads from, and why it matters

The input map comes from ProjectSettings — your project.godot as the editor has it, never from the InputMap singleton. Inside an editor those two are not the same thing: every enabled plugin has already called InputMap.add_action(), so the singleton holds names your project does not have. Which names are yours is read out of the [input] section of project.godot itself, so the engine's defaults and anything a plugin wrote into the settings at runtime are left alone; an unsaved change to an action your file already declares is audited as it stands, because that is what a save would ship, while an action you have added this session and not saved yet is not in the file and so is not yours yet.

Read the singleton instead and two things go wrong at once. Actions another plugin added get reported as actions nothing uses — and a name you misspelled is reported as fine whenever some plugin happens to have added a matching one. The test suite adds an action to the live InputMap and requires that it does not reach the report, and the editor stage repeats that inside a real running editor.

Output

The dock, and — from their own two buttons — a Markdown report and JSON with a versioned schema so a build server can fail on it. Six tick boxes cover the eight checks, so a keyboard-only or pad-only project can switch off the pair it has decided not to care about.

Two of the eight are failures — a name that does not exist, and an action with nothing bound at all — because both mean something in the game cannot be done. The other six are warnings, a pointer-only action included: on a touch game that is the design, not a fault.

What it will not tell you

Only names written as literals are checked. A remapping screen that builds the action name from a table is counted and reported as a number — "1 call site builds the action name at runtime" — never guessed at, and while there is one, every "Action nothing uses" line says so. Actions your code creates with InputMap.add_action() are recognised, so they are never called misspelled, but nothing here can say whether they end up bound sensibly.

An action property counts as a use and is never called a typo. e.action = "fire" on an InputEventAction you build in code, and the inspector value of an @export var action on a node in a scene, both name an action the way a call does — but an ordinary resource of your own can have a property of that name too. Both are read, counted and reported as a number: the names they carry are never reported as unused, and never reported as names that do not exist.

The engine's own ui_* actions are not checked unless your project declares them. .gd, .tscn and .tres are read — C#, GDExtension and binary .scn scenes are not, and folders carrying a .gdignore, folders that are links, and anything whose name starts with a . are skipped. Other plugins in addons/ are read so their uses count, but a name only they mention is never reported as your typo. Two actions bound to the same key, one by keycode and one by physical keycode, are not reported as a clash: they are not the same stored binding.

Anything that stopped the run covering the whole project is said out loud — a file or folder that would not open, a depth or folder limit, an action whose stored events could not be read. The JSON's complete goes false and the Markdown leads with it. A partial run is never reported as clean.

A clean report is still not a certification. It means the project as it stands had none of the faults it looks for. Play the game with a controller and nothing else plugged in, then with a keyboard and nothing else plugged in.

In the download

The addon, a demo project with one of every fault planted in it, the full README, and the licence.

How it was built

The code and this page were written with AI, directed by a person. Every claim above is checked by an automated suite that runs on Godot 4.4, 4.5, 4.6 and 4.7, and by pressing the dock's own button inside a real editor on each of them — the report quoted in the README comes out of that suite rather than being typed by hand.

Requirements

Tested on Godot 4.4, 4.5, 4.6 and 4.7. No C#, no build step, no external tools. One purchase, unlimited projects, commercial use included.