What causes the “Invalid set index on base Nil” error in Godot?

The script assigned a property on a variable that is null — an @onready node path that did not resolve, a freed node, or a function that returned nothing being used as an object.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix “Invalid set index (on base: 'Nil')” in Godot

Quick answer: Identify which variable on that line is Nil, fix why it is null (wrong node path, freed instance, missing return), and guard assignments that can legitimately race scene setup.

The set twin of Godot's most famous error: you wrote thing.property = value and thing was Nil. The debugger names the line, so the job is naming the Nil. Here is the routine.

How to fix it

1. Break on the line and inspect

Run with the debugger, let it pause on the error, and check the Locals panel — the variable that shows <null> is your culprit.

2. Check the node path and timing

For @onready var hp_bar = get_node("UI/HPBar"), a renamed or moved node yields Nil. Use the editor's drag-to-script or %UniqueName paths to survive refactors.

3. Watch for freed instances

A node freed with queue_free() becomes invalid — check is_instance_valid(thing) before late assignments from signals or timers.

4. Return values explicitly

A GDScript function with no return yields Nil; assigning through its result sets on Nil one line later.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Godot error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The errors you never hear about are the ones quietly costing you players. Visibility turns them into a worklist.