Intermediate

LUA debugging step by step

Find where expected and actual behavior become different, then fix the smallest cause.

Chapter goal: Find where expected and actual behavior become different, then fix the smallest cause.

Simple explanation

Debugging is detective work. You compare what you expected with what happened, then find the first place where the values became different.

In LUA, this chapter is about testing one assumption at a time instead of guessing. Start with the idea above. Then connect each symbol to a value or action in the example.

Do not try to remember every symbol. First ask what data the program has, what it does with that data, and what result it creates. Technical words become easier when you connect them to those three questions.

Why this topic is important

Developers spend a large part of their work understanding unexpected behavior. A calm process is faster than random edits. In LUA, the syntax may look different from other languages, but the thinking skill transfers: name the data, choose the right operation, and make the next step obvious.

When to use it

Debug when output is wrong, a screen does not update, data is missing, or an error message appears.

Example code

local function totalPrice(prices)
  local total = 0
  for _, price in ipairs(prices) do
    print("adding price:", price) -- debug trace
    total = total + price
  end
  return total
end

print("result:", totalPrice({10, 20, 5}))

Line-by-line explanation

local function totalPrice(prices) — This defines a reusable function. Its name describes the job that other code can call.
local total = 0 — This stores or updates total. The value on the right is worked out first, then saved under that name.
for _, price in ipairs(prices) do — This starts a loop. The program repeats the following block for each item or while the condition remains true.
print("adding price:", price) -- debug trace — This is the visible output line. It shows the final value after the earlier work is complete.
total = total + price — This stores or updates total. The value on the right is worked out first, then saved under that name.
end — This line supports one focused piece of application logic. Read it together with the block directly around it.
return total — This sends a result back to the code that called the function. Returning is different from printing.
end — This line supports one focused piece of application logic. Read it together with the block directly around it.
print("result:", totalPrice({10, 20, 5})) — This is the visible output line. It shows the final value after the earlier work is complete.

What the output means

adding price: 10
adding price: 20
adding price: 5
result: 35

The output is evidence that the program followed the instructions. If your result is different, read from the first line and write down how each value changes. That is debugging, not failure.

Mistake example

local function totalPrice(prices)
  local total = nil -- several lines are changed before the original cause is identified
  for _, price in ipairs(prices) do
    print("adding price:", price) -- debug trace
    total = total + price
  end
  return total
end

print("result:", totalPrice({10, 20, 5}))

This version intentionally shows how several lines are changed before the original cause is identified. The changed assignment stores a missing value, or a required line is removed, so later code cannot complete its job safely.

Fixed version

local function totalPrice(prices)
  local total = 0
  for _, price in ipairs(prices) do
    print("adding price:", price) -- debug trace
    total = total + price
  end
  return total
end

print("result:", totalPrice({10, 20, 5}))

The corrected version restores the real value or required operation. It fixes the chapter-specific problem: several lines are changed before the original cause is identified.

Common mistakes

Changing several lines before testing again.
Ignoring the first useful error message.
Fixing the symptom while leaving the cause.

Warning: Change one part at a time. If you change many lines together, it becomes harder to learn which change caused the result.

Real use cases

Trace a wrong total.
Inspect an API response.
Find why a button callback did not run.

Practice exercise

Introduce one intentional bug, then find it using print or log statements.
Change only one line at a time while re-testing after each change.
Write down the exact moment the expected and actual results diverged.

Tip: If the exercise feels too large, complete only steps 1 to 3. Small working code teaches more than a large unfinished project.

Mini quiz

Match the term to its meaning: "root cause" versus "symptom".
Find the bug: given a wrong total, which single line would you check first?
Explain a real scenario: a teammate says "it just doesn't work" — what is the first question you ask them?

How to read AI-generated code

Do not copy AI code first. Read it like a detective. Find the data, follow the changes, and locate the final output. Ask AI to explain a line only after you have made your own guess.

What data goes in?
What values are stored?
What calculation or decision happens?
What is printed, displayed, saved, or returned?
What can go wrong?
Can you rename one value and still explain the code?

RedM safety check

RegisterCommand creates a named command. Its callback receives source (who triggered it) and args (the words after the command). Client code handles the local player's screen and input. Server code owns trusted game state. Never trust prices, rewards, permissions, or item counts sent by a client; check them again on the server.

Before you move on

I can explain this topic in my own words.
I can read the small example without AI.
I can change the example and predict the new result.
I can find and fix one simple mistake.
I can name one real project that uses this idea.

Next topic

Next, learn files, JSON, and local data. Before opening it, explain this chapter out loud in under one minute.

Open the interactive lesson →

← LUA basic project LUA files, JSON, and local data →