AlgoLiftAlgoLiftGuide

Set Variable Node

The Set Variable node writes a value into one of your strategy's variables when a condition is true. Its clock (once a bar, or on every trade), where a variable starts, how long the value lasts, and the one job it does best.

NodeBy AlgoLiftUpdated 6 min read
On this page 7How it worksWriting when a trade opensExample: never buy above your last entrySettingsUse something else whenWhen it doesn't behaveGoing further

Some rules need a fact no indicator holds, like the price you last bought at. The Set Variable node is how a strategy writes a fact like that down. You create a variable, and whenever the node's condition is true, it stores a new value there for a Get Variable to read later.

Takes
A condition, and the value to store
Gives
Nothing on the canvas. It writes into a variable
Reach for it
Remembering something about your last trade after it's gone

How it works

Variables live in the Variables section of the node panel. Click Create Variable, give it a name and a type (Numeric or Boolean), and it's ready. (Time variables are retired: time rules belong to the Time Window and Time Since.) Drop a Set Variable on the canvas, pick the variable from its dropdown, and wire in two things: a Condition that says when to write, and a New Value that says what. The value has to match the type. A Numeric variable takes a number, a Boolean one takes a condition, and the builder refuses a mismatch.

When it writes is the node's clock, the same two clocks a Crossover has:

  • Bar close checks the condition once when each bar closes, and writes at most once a bar. A counter built as "the variable plus 1" counts bars. New Set Variable nodes start on Bar close, and they count the bars of the strategy's primary series.
  • Intrabar checks the condition on every trade print while it holds, and writes every time. Give it a condition that holds for a whole 5-minute bar and it writes on every print of that bar, which on a busy ES bar runs into the thousands. For storing a price that's harmless, because the last write wins. For counting, it counts prints, not bars. A Set Variable saved before the clock existed runs this way, exactly as it always did.

Once a value is written, it stays. A variable doesn't reset when a trade opens or closes, and it doesn't reset at a new session. It changes when a Set Variable writes to it, and only then.

Where a variable starts is its Initial Value, set where you create it. Left empty, a Numeric variable starts at 0 and a Boolean one at false. The one twist is the monthly split: with Parallel on in the run settings, which is the default, each month of history runs on its own, and every month starts your variables over from their Initial Values. With Parallel off, values carry from one month into the next. So a strategy whose variables carry across months can give different results in the two modes, by design. Turn Parallel off when a value has to carry.

Writing when a trade opens

Wire an Entry's output (the same output that feeds the Trade node) into the Condition, and the node behaves differently. Whatever its clock, it writes once, when that Entry fills, and the node shows At the fill where the clock was. This is the job Set Variable does best: keeping a fact about the last trade after the trade itself has closed.

Example: never buy above your last entry

Say you buy oversold dips on ES 5m, with RSI(14) under 30 as the signal. On a bad day it keeps firing all the way down, and each new long lands right next to the last one. You'd rather every new long be at least 5 points cheaper than the one before.

Create a Numeric variable named lastEntry with an Initial Value of 0, and treat 0 as "no entry yet". Then:

  1. Add a Set Variable for lastEntry. Wire the Entry's output into its Condition and a Current Price into its New Value. Each time a long fills, lastEntry holds the price it was taken at.
  2. Read lastEntry with a Get Variable and compare it with a Constant of 0 using Equal. That's true before the first trade.
  3. Read it again, subtract 5 with a Math node, and check that Current Price is Less Than the result.
  4. OR steps 2 and 3 in a Logic node, AND that with the RSI condition, and wire it into the Entry.

One honest caveat: with Parallel on, lastEntry goes back to its Initial Value of 0 at the start of each month, so the ladder starts fresh every month.

Settings

Variable
The variable it writes. Create variables in the Variables section of the node panel. If the variable is deleted, the node says so.
Writes
Default Intrabar
Bar close (new nodes) checks the condition once when each bar closes; Intrabar checks it on every trade print. A node saved with no clock runs Intrabar. Wired from an Entry, it writes at the fill instead, and shows At the fill.
Bars
The series whose bar closes Bar close counts: the primary series unless another is set.

Use something else when

Count how often a condition held
Its Count and Count in last outputs count bars, judged at each bar close, since a reset or over a window.
Since
Remember a value from the bar a condition held
The high of the bar where two averages crossed, for example. It's computed over history, so a month boundary doesn't wipe it.
Capture
A pattern with steps, like the second attempt
States, transitions and the values each step keeps, in one node. A pair of variables can't hold a pattern like this.
State Machine
The open trade's entry price or stop
While a trade is open, the Trade Variable reads its entry price, stop, target and more, with nothing to store.
Trade Variable

When it doesn't behave

My counter climbs into the thousands

The node is on the Intrabar clock, so a counter built as "New Value = the variable plus 1" adds one on every trade print while its condition holds. Set its clock to Bar close and it adds one per bar. If what you're counting is how often a condition held, Since does it in one node: Count gives the bars since a reset, and Count in last gives them over a window, with no month boundary in the way.

It forgets everything at the start of each month

That's Parallel at work. Each month of history runs separately, and each one starts the variables over from their Initial Values. Turn Parallel off in the run settings to carry them across, at the cost of a slower run.

The builder won't let me wire the variable into a Crossover

A variable only exists while the engine steps through the data, one print at a time. A Crossover, Since, Capture, a State Machine and the modifiers all need values that can be worked out over the whole history first, so they refuse it. Compare the variable with a Comparison instead.

“Type Mismatch” on the node

A Numeric variable is being fed a condition, or a Boolean one a number. Change the variable's type in the Variables section, or wire the other kind of value into New Value.

Going further

When a Get Variable and a Set Variable for the same variable aren't wired to each other, nothing says which of them runs first within a moment, so a rule can see the old value or the new one. Build so the answer doesn't matter. The pattern in the example does exactly that: it writes at a fill and reads on later bars. And if you catch yourself wiring two or three variables that switch each other on and off, that's a pattern with states, which is the State Machine's job.

Or ask the copilot

Next: Get Variable