There is nothing to install
Pine compiles and runs inside TradingView. There is no SDK, no toolchain, and no local runtime — the Pine Editor opens below the chart [1], and scripts you write and save are kept "on TradingView's servers" [1].
This is the structural difference from MetaTrader, where MetaEditor compiles to a file that a terminal on your machine then runs. If you have come from there, the instinct to look for an install step is the first thing to drop — the MQL5 environment is what that side actually requires.
Three different things get called "running a script"
They live in different places, and conflating them is what produces "it works on my chart but not on yours":
| Thing | Where it lives | What it does |
|---|---|---|
| saved | your account, on TradingView's servers [1] | the source exists and you can open it again |
| added to chart | this chart's layout | the script actually executes and produces output |
| configured | this chart's script settings | the input values this instance runs with |
Saving is not adding. The documentation is explicit about this for a working copy of a built-in:
Because the working copy is a different version of the script, you need to use the Editor's "Add to chart" button to add that new copy to the chart. [1]
So a script can be saved and produce nothing, because no instance of it is on a chart.
Editing a built-in requires a copy first
Built-in scripts are read-only. To modify one you press "Create a working copy" [1], which gives you a separate script — yours, editable, and not the one already on your chart. The original keeps running until you add the copy.
This catches people mid-debug: you edit, you see no change, and the reason is that the chart is still showing the original.
The trap that costs the most time
Your input values are not in the file.
The Inputs tab changes "the settings which the script's author has decided to make editable" [1] — and those choices belong to this instance on this chart, not to the source. Which means:
- sending somebody your Pine file does not send your settings
- re-adding the script to a chart starts from the declared defaults again
- two charts running the same script can produce different results, legitimately
If a result matters, record the input values next to it. This is the same reproducibility problem as the account plan deciding how much history your backtest sees — see running and maintaining a strategy.
The other settings tabs
Style configures the script's visuals, and Visibility configures which timeframes the script appears on [1]. Neither changes what the script computes, which makes them safe to experiment with — unlike Inputs, where moving a number changes your results without changing your code.
The first two minutes after adding it
A script on the chart is not yet a script you can trust. Five checks, ordered so that the ones which invalidate everything else come first.
1. Confirm it is a strategy
Look at the declaration. strategy( gives you the Strategy Tester panel and an
emulated account; indicator( gives you neither, no matter what the script is
called. Why that line decides everything else is in
what a TradingView strategy is.
2. Check the chart type — this is the one people skip
TradingView states plainly that non-standard chart types produce unrealistic results by default, and that standard charts should be used for realistic backtesting [4].
If you attached your strategy to a Heikin Ashi or Renko chart, the equity curve you are looking at cannot be reproduced with real fills. It is not slightly optimistic; it is not a backtest. Check this second, because it invalidates everything after it.
3. Confirm the timeframe matches what the strategy was built for
A strategy designed on 15-minute bars behaves differently on 1-hour bars — same code, different data, different everything. Generated exports often carry a comment naming the intended timeframe; if yours does, match it before reading any result.
4. Read the declaration for costs
commission_type, commission_value and slippage. If they are absent, the
report describes a market that charges nothing to trade, and the numbers are
not comparable to anything real. The values and the two that get misread are in
the cost parameters.
5. Verify the inputs actually do something
Open Inputs, move one threshold to an extreme, and confirm the trade count changes.
This sounds redundant and is not. An input that is declared but never referenced in the logic produces a control that moves and does nothing — the threshold is compiled in as a literal instead. There is no way to tell by looking at the settings panel, and a user tuning such a strategy is tuning nothing.
Then, before you believe any of it
Open the List of Trades, pick three trades, and find them on the chart. Does each fill price fall inside that bar's high-low range? That single check catches future leak, a non-standard chart and a misread tick size at once — the full audit is in reading the Strategy Tester.
Re-run steps 4 and 5 after every re-export
A fresh export rewrites the declaration. Costs you set by hand do not survive it, and neither does anything you changed in the source. This is the same reason the maintenance routine is short but not optional — see running and maintaining a strategy.
Tactix AI — Studio vs Guide
Tactix AI is AlfaTactix’s product assistant brand (open Tactix AI).
- Tactix Studio turns a one-sentence strategy description into a draft across Timeframe, Signals, Filters, and Risk in the visual Strategy Builder. You review and edit every field before Code Generator writes MQL5 or Pine Script.
- Tactix Guide explains the step you are on — what to fill, what a control means, or how to phrase a rule — without dumping untested source code.
That is form-first automation: the LLM never replaces Code Generator, and you keep plan limits and real-time validation.