You only want a moving average to appear when a checkbox is on, so putting plot() inside an if statement seems natural. Then Pine says it cannot use plot in local scope. The error is a design rule, not a missing option. The Pine Editor on TradingView is deliberately strict, which is useful once you know what it is protecting you from, but not very comforting when you need one line fixed now.
Pine needs to know the chart’s plot declarations consistently as it compiles the script. An if block is local scope because it may run conditionally. Rather than creating and deleting plots from inside that block, you define the plot once in global scope and use a series value to control whether it draws on a given bar.
What this error actually means
Global scope is the top-level body of the script. Local scope is code nested under if, for, while, switch, or a user-defined function. Many visual-output functions, including plot, must be declared globally so Pine can establish their settings and output structure predictably across the full dataset.
This is related to Pine’s per-bar execution model. The value passed to plot can change on every bar, including to na, but the plot call itself remains a stable top-level declaration. That distinction gives you conditional visibility without asking the compiler to create a different chart structure inside a branch.
The code pattern that causes it
The temptation comes from ordinary programming languages, where a drawing call inside a condition is normal. In Pine, the correct pattern is to calculate the condition in any appropriate scope and then use the conditional operator in a single global plot call.
//@version=6
indicator("Local scope plot", overlay = true)
showAverage = input.bool(true, "Show average")
average = ta.sma(close, 20)
if showAverage
plot(average, "Average", color.blue)The input and average are fine. The plot call is nested beneath if showAverage, so it is in local scope. Moving the condition into the plot value preserves the user-visible behavior while meeting the compiler’s requirement.
The smallest useful fix
//@version=6
indicator("Local scope plot", overlay = true)
showAverage = input.bool(true, "Show average")
average = ta.sma(close, 20)
plot(showAverage ? average : na, "Average", color.blue)The call now exists globally. When showAverage is true, Pine plots average. When it is false, it plots na, which hides the line without changing the plot declaration. The same approach works for conditional shapes and colors, although each output function has its own supported arguments.
Do not confuse plotting with creating labels or lines. Some drawing-object functions can be called in local scope, subject to their own limits, because they create objects rather than stable plot declarations. Check the function documentation before applying this pattern blindly. For plots, histograms, and many visual series outputs, conditional values are the usual answer.
How to diagnose it without guessing
When you see a local-scope error, identify the outermost if, loop, function, or switch containing the call. Move only the output declaration to global scope. Keep the calculation where it belongs, then pass its result through a ternary expression or a conditional color. That preserves separation between logic and display.
Declare your plots together near the end of an indicator. Compute conditions and series values above them. This layout makes output constraints obvious, keeps the chart layer readable, and reduces the chance that a later feature wraps a plot in a local branch.
Apply the same idea to shapes and conditional color
The global-declaration pattern scales beyond a moving average. A plotshape call can stay in global scope while its first argument is the condition that controls visibility. A plot can stay global while its color argument changes between a color and na. In both cases, Pine has one stable output declaration and a series value that decides what appears on each bar.
Do not assume every visual function follows exactly the same rule. Plot-family functions are declarations of chart output, while labels, lines, boxes, and tables create drawing objects with their own limits and lifecycle rules. Before moving a drawing call, read its reference page and consider object-count limits. The right design depends on whether you need a stable series plot or discrete annotations.
Build conditional visuals from stable declarations
A reliable indicator layout has three layers. Inputs define what the user can configure. Calculations produce series values and conditions. Global output declarations decide how those series appear. With that structure, a checkbox does not wrap a plot in an if block. It changes the series passed into the already-declared plot. This makes it clear which code controls meaning and which code controls visibility.
For example, a buy marker can use plotshape(showSignals and longCondition, style = shape.triangleup, location = location.belowbar). The call remains global, while the boolean series becomes false when the user hides signals. A conditional plot color works similarly: plot(average, color = showAverage ? color.blue : na). The value still exists, but Pine does not draw the configured color when the toggle is off.
This design also improves debugging. If a visual is missing, you can inspect the condition and the series independently. First plot or log the calculated value, then inspect the visibility condition, then inspect the output declaration. That is much easier than untangling one large local block that mixes math, state changes, and drawing calls. Stable outputs are not only a compiler requirement. They are a maintainability pattern.
Choose the right visual primitive before you write the condition
Use a plot when the value exists on every bar as a series, even if you sometimes hide it with na. A moving average, band, oscillator, or threshold line belongs in this category. Use plotshape or plotchar when you want a marker only on bars where a condition is true. That distinction helps you choose the argument that controls visibility without trying to create the output from inside an if block.
Use labels and lines when you need an object with a specific location, text, or lifecycle. They can be created conditionally, but they introduce a different responsibility: managing how many objects are created and whether old objects should be retained, updated, or deleted. A label on every bar is not a substitute for a plotshape. It can exhaust drawing limits and make the chart unreadable even when the source compiles.
Conditional colors are often clearer than turning a plot on and off. For example, a single average can be blue when a trend filter is true and gray when it is false. The series remains visible, so you can inspect the calculation, while the color communicates the state. This is a display decision, not a reason to move the calculation into local scope.
When a visual still does not appear after the scope fix, check the value and condition separately. A correct global plot of na will draw nothing. A correct plotshape with a condition that is always false will also draw nothing. Add a temporary plot or log message for the intermediate condition, verify it on a known bar, and then remove that debugging output once you understand the path.
Keep the global output section ordered consistently, especially when an indicator has several plots, fills, shapes, and alert conditions. Put the matching calculations near each output and use titles that identify their role on the chart. This makes a later local-scope repair safer because you can see which declaration belongs to which series. It also prevents a visual toggle from accidentally hiding the wrong plot when two values have similar names.
The same layout helps when you later add alerts. Reuse the existing named condition for an alertcondition declaration instead of duplicating its logic in a separate local block. One source of truth for the condition keeps what you see on the chart and what the script reports aligned.
Separate display changes from calculation changes
A general chat response may solve this error by rebuilding the indicator around a different structure. That can work, but it makes it hard to tell whether the calculation changed along with the display. For a local-scope error, the safest patch moves only the output declaration and preserves the condition and series value that already express your logic.
PineScripter’s line-level editing and Code Changes diff are useful when the repair should be that contained. Its in-app lint flow can surface the local-scope finding, while retrieved Pine documentation helps the model choose a valid plot pattern. Review the changed output line and validate the visual result in the Pine Editor before keeping it.
For the underlying language rule, consult TradingView documentation on plots. Related reading: the broader compile-error guide, the Pine execution model, runtime debugging patterns.
A practical checklist before you paste again
Find the nested plot call, keep the calculation intact, define plot once at the top level, and return na when the condition should hide it. Recompile before changing colors, line styles, or unrelated strategy logic.
The local-scope rule is easier once you separate what to calculate from what to display. Pine lets the series change every bar. It simply asks the plot declaration to remain stable.
Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.