Each LootScript compiler and runtime message starts with a code like LS2008. The code is stable across versions and independent of the UI language, so it’s convenient to search by it. This page lists every code the terminal can show, with the message text, the cause and how to fix it.

Messages appear in Russian when the terminal interface is Russian; for any other language they appear in English. First — the most common errors, then runtime errors and a complete table.

Where errors are visible

At compile time. The Editor compiles the script on each typing pause. Findings appear in the “Problems” tab at the bottom of the Editor: code, text and position in the form “Line 6:6”. Double‑clicking a line moves the cursor to the error location. The Editor header shows the result: “ok · 12 ms”, “warnings: 2” or “errors: 1”.

At runtime. A script that compiles cleanly can still stop on a bar: operation budget exhausted, an index went out of bounds, unknown symbol, etc. Then the “Output” tab will show a line like “Script stopped: LS6004: …”, and the same reason appears in the Strategy Tester. Other scripts, panels and the terminal continue to run.

Diagnostics have three levels:

How codes are organised

Common compile errors

LS1009 — missing script declaration

“No script declaration — start with indicator("Name")”. The first statement in the file must be indicator(...), strategy(...) or library(...). The same error appears if the declaration exists but something is written above it. Comments and the #version 1 directive do not interfere.

// Так нельзя: объявление не первое
len = input.int(14, "Длина")
indicator("RSI")

indicator("RSI")
len = input.int(14, "Длина")

A second declaration in the same file gives LS1008: a script may have only one.

LS2002 — unknown name

“Unknown name ‘…’ — check spelling or declare it earlier.” Most often a typo or a function without its namespace: indicator functions live in ta, math in math, colors in color.

avg = sma(close, 20)

avg = ta.sma(close, 20)

The same error occurs if you read a variable before the line where it’s declared. The full list of names is in the Function reference.

LS2008 — comparison with na

“Comparison with na is always false — use na(x)”. Any comparison with na, including == and !=, yields false, so the compiler rejects such expressions.

x = ta.sma(close, 50)
plot(x == na ? close : x)

x = ta.sma(close, 50)
plot(na(x) ? close : x)

The shorter equivalent is plot(x ?? close).

LS2014 — value changes bar-to-bar where a constant is required

“‘…’ in ‘…’ requires a value at least as strong as input, but a series was given — use input.*(…) or a literal.” A window length for ta.* must be known before the first bar. A length chosen by a per-bar condition is not acceptable.

len = close > open ? 10 : 20
avg = ta.sma(close, len)

Compute both options and choose the result, not the length:

fast = ta.sma(close, 10)
slow = ta.sma(close, 20)
avg  = close > open ? fast : slow

If the length must be user‑selectable, take it from input.int(...).

LS3004 — ta.* call depends on a variable from a branch

“Argument ‘…’ cannot be computed outside the branch — move the ta.* call to the top level.” ta.* functions remember past bars, so the compiler treats them as computed on every bar even if written inside an if. If the argument is declared only inside the branch, on other bars it simply doesn’t exist.

var float avgBody = na
if close > open {
    body = close - open
    avgBody := ta.sma(body, 10)
}

body    = close - open
avgBody = ta.sma(body, 10)

LS2017, LS2007, LS1006 — strings, conditions and chained comparisons

These three errors share a cause: LootScript does not coerce types implicitly.

LS2018 and LS2019 — name already taken

“‘…’ already declared in this scope” (LS2018) — you declared the variable a second time with =. To change a value use :=.

level = high
level := low

“‘…’ shadows a built‑in name — choose another” (LS2019) — a variable, function or type was named the same as a built‑in series or function: close, time, hour, volume. Rename it: startHour instead of hour. Using namespace names like color or position for variables is allowed.

LS2004 and LS2005 — call arguments

“‘…’ expects … argument(s), but … were given” (LS2004) and “‘…’ has no parameter ‘…’” (LS2005). Check the call against the signature in the Function reference: parameter names must be written exactly as shown.

plot(close, colour = color.red)

plot(close, color = color.red)

LS3011 and LS5011 — strategies

“strategy.* is available only in strategy(…)” (LS3011): orders and position state exist only for a script declared with strategy(...). Replace indicator("…") with strategy("…").

“Strategy reads ‘…’: book and tape have no history, a backtest would be fictional” (LS5011): a strategy is tested on history, but book.* and tape.* have no history — they are na on past bars.

strategy("Book imbalance")
if book.imbalance(10) > 0.5 {
    strategy.entry("L", strategy.long)
}

For historical order book data there’s the depth namespace: where the order book is recorded it gives values on each bar.

strategy("Book imbalance")
if depth.imbalance(1.0) > 0.5 {
    strategy.entry("L", strategy.long)
}

LS5000–LS5006 — repainting warnings

These warnings do not stop the script. They say the line on history will look different from what was seen live:

• LS5001 — a value that exists only on the live bar reaches output (barstate.isrealtime, barstate.isnew).
• LS5000 — a varip value reaches output: it accumulates live‑bar ticks that don’t exist on history.
• LS5006 — book.* or tape.* reach output: the series is empty on history.
• LS5003 — higher timeframe value from request.security without [1]: the unclosed bar will repaint.
• LS5002 — lookahead = true in request.security: the script sees the future on history.
• LS5005 — math.random or timenow reaches output: two runs give different lines.

If that’s intended — e.g. the indicator is meant only for live trading — the warning can be left.

LS3016 — a setting accepted and does nothing

This is a notice, not an error. It appears in scripts ported from other platforms: the parameter exists for compatibility but has no effect in the terminal. The message’s second part explains why.

Runtime errors

A runtime error stops the script on the bar where it occurred. The text appears in the “Output” tab as “Script stopped: LS6004: …”.

LS6004 and LS6005 — script runs too long

“Script exhausted its operation budget on the bar — simplify the loop” (LS6004) and “Script exceeded the time limit for a pass” (LS6005). Each bar has a budget of 2,000,000 operations. Time is limited too: the whole historical pass — 2 seconds, one live‑bar tick — 20 ms. Almost always the cause is a loop that doesn’t terminate or iterates over too much data per bar.

var int n = 0
i = 0
while i < 10 {
    n := n + 1
}

var int n = 0
i = 0
while i < 10 {
    n := n + 1
    i := i + 1
}

LS6002 and LS5004 — reading the future

A history index x[n] cannot be negative: close[-1] would mean the next bar. If a negative number is written literally, the compiler rejects it immediately (LS5004). If it comes from a calculation, the script stops with “Negative history offset — cannot read the future” (LS6002). An index larger than the amount of loaded bars is not an error — it yields na.

LS6001, LS6007, LS6019 — collections and objects

• LS6001 “Index … out of bounds” — array.get, array.set or matrix.get past the size. Check array.size(a) before access.
• LS6007 “Access to an empty object (na)” — a collection was declared but not created: var array<float> a = na, then a.push(x). Create it with array.new<float>().
• LS6019 “Drawing object already deleted or evicted by the ceiling — create it anew”. At most 500 objects of one kind live simultaneously; the oldest is evicted. Raise the ceiling via maxLinesCount, maxLabelsCount or maxBoxesCount in the declaration or reuse the object via set_*.

LS6017 and LS6018 — symbol and timeframe in request.security

“Symbol ‘…’ unknown — check the format ‘VENUE:SYMBOL’ or set ignore_invalid_symbol = true” (LS6017) and “Timeframe ‘…’ not parsed — expected ‘5’, ‘60’, ‘4h’, ‘1D’, ‘1W’” (LS6018). With ignore_invalid_symbol = true an unknown symbol yields na instead of stopping.

Execution limits

When there’s no error, but there’s no value

Many situations that would crash in other languages give na in LootScript — a gap on the chart, not a stop:

• arithmetic with na yields na: close - x with empty x is empty;
• x[n] deeper than the start of history — na;
• integer division by zero — na; floating division by zero does not stop the script;
• book.*, tape.* and screener.* on historical bars — na;
• footprint clusters, delta, open interest and order book history — na on bars where data is absent. Check cluster.available, delta.available and the neighbouring flags;
• ta.* on the first bars while the window fills — na.

na is never drawn as zero on the chart: the line is interrupted. To substitute a value use nz(x), x ?? fallback or fixnan(x).

All codes

LS0001–LS0009 and LS0999 — text reading

LS1000–LS1012 — parsing

LS2000–LS2030 — types and names

LS3000–LS3033 — program semantics

LS4000–LS4009 — compilation limits

LS5000–LS5013 — repainting and tester

LS6000–LS6036 — execution

Next