Guide walkthrough

Start reading here

This is the main article body, where the page shifts from summary cards into the actual workflow and decision-making notes.

On this page

Define the mismatch before changing the code

Take two timestamped screenshots and write down the exact value that differs. Compare the same instrument and contract month, bar type and interval, trading-hours template, data source, time zone, indicator settings, and Calculate mode. A chart configuration mismatch can look exactly like a code defect.

  • For futures, verify the contract month and whether either chart is using a continuous contract.
  • Match regular versus extended trading hours and any custom session template.
  • Record whether the wrong value appears during the forming bar, after bar close, or only after reload.

Check Calculate mode and intrabar assumptions

Calculate.OnBarClose, Calculate.OnEachTick, and Calculate.OnPriceChange do not produce the same update sequence. An indicator generated around bar-close assumptions can appear to lag in real time, while an intrabar indicator can show temporary values that disappear after the bar closes. Historical processing also does not automatically recreate every tick that arrived live.

  • Use OnBarClose when only completed-bar values should matter.
  • Use OnEachTick only when the calculation and state updates are designed for repeated calls on the same bar.
  • Treat OnPriceChange carefully when unchanged prices with new volume still matter.
  • Use Tick Replay or Playback only when the test actually requires an intrabar event sequence.

Audit bar indexing and first-tick state

Real-time divergence often starts when code updates a running total more than once on the current bar or reads the wrong series index. Check every use of series[0], series[1], CurrentBar, and IsFirstTickOfBar. Decide which values should update once per bar and which should update on every event.

  • Do not add the full current-bar volume repeatedly if the code expects only the change since the prior tick.
  • Confirm that previous-bar references use [1] only after enough bars are loaded.
  • Reset per-bar state on the first tick of the bar when using an intrabar Calculate mode.

Verify multi-series routing and session resets

For scripts that call AddDataSeries, OnBarUpdate runs for more than one series. Guard the intended logic with BarsInProgress checks, confirm CurrentBars has enough data for every series, and verify which series controls session resets. An unguarded secondary-series update can double-count values or reset them at a different time.

  • State which BarsInProgress value owns plots and user-visible calculations.
  • Check CurrentBars for each required series before indexing it.
  • Use the intended series and trading-hours template when detecting a new session.
  • Confirm time-zone assumptions when the reset appears one hour or one session off.

Reproduce the first divergent bar in Playback

Run a short Playback window that includes the first known mismatch. Add temporary timestamped output for BarsInProgress, CurrentBar, state transitions, input values, and the plotted result. The goal is not a huge log; it is the first event where expected and actual state separate.

  • Start shortly before the mismatch instead of replaying an entire week.
  • Compare the value during the live-forming bar and again after the bar closes.
  • Reload the chart afterward and note whether the historical result changes.
  • Remove or disable diagnostic output after the issue is verified.

Escalate with a reproducible case, not only a screenshot

A programmer can review the issue faster when the report includes source, NT8 version, chart configuration, Calculate setting, a short Playback window, and the first expected-versus-actual value. Escalate when the script mixes Tick Replay, several data series, custom sessions, vendor dependencies, or state you cannot explain after a reload.

  • Keep the AI-generated original and your edited copy separate.
  • Include a minimal chart template only after removing account or personal information.
  • Define the acceptance test: the exact bar, expected value, and update timing that must match.

Best next reads

These pages pick up the questions most readers usually have next, so you do not have to back out and start a fresh search.

Updated May 31, 2026

Fix A Broken NinjaTrader Indicator

A practical guide to diagnosing broken NinjaTrader indicators, including import errors, compile failures, missing plots, duplicate names, and when a source-level repair is the realistic next step.

Updated Apr 23, 2026

How To Test An Indicator In Market Replay

A practical guide to testing trading indicators in market replay without giving them perfect hindsight, false confidence, or credit for decisions they did not really help with.

Frequently asked questions

Why does my NinjaTrader indicator change after I reload the chart?

The live calculation may have used intrabar events that historical processing did not reconstruct, or the script may be updating persistent state differently during real time. Compare Calculate mode, Tick Replay requirements, and per-bar state handling.

Does a real-time value change mean the indicator repaints?

Not always. Values on a forming bar can legitimately change as new ticks arrive. Repainting is a concern when previously completed signals or values change in a way the documented calculation does not justify.

What is the fastest way to debug an AI-generated NT8 indicator?

Match the chart configuration, identify the first divergent bar, replay a short window, and log only the state and inputs needed to explain that bar. Avoid another full rewrite until the mismatch is classified.