TickReplay: critical but stable

[dotnet]

1.
There is a strange condition in the @BuySellPressure builtin indicator:
if (CurrentBar < activeBar) return;
It looks like an internal bug fix, maybe this should not be in the user code area?

2.
While the Tick replay is played in the indicator, there is no visual clue, and the process can takes minutes. At last the usual "loading.." message could be visible until the calculation finished.

3.
It is too hard to access TickReplay currently. I would suggest a "IsTickReplayRequired" switch in the indicator, which would provide tickreplay for the indicator without manually enable that feature in options+data series.

4.
Tick replay is still not working with strategies. (for example SampleMaCrossover)
It drops an "A hosted indicator tried to load additional data. All data must first loaded by the hosting NinjaScript in its configure state." error, and crash/hang ninjatrader.

[NinjaTrader_Jesse]

Hello,

Thank you for the questions and comments.

The if (CurrentBar < activeBar) return; would be expected in this file, this is part of the logic for the indicator. A lot of scripts in NinjaTrader require CurrentBar checks to perform correctly. Often you will see this when you reference prior data that would not yet be loaded on bar 0.

For your second question, can you provide more details on where specifically you see this? Is this in live data with Tick Replay enabled? With more information on specifically where you see this and what indicator and actions were used will help in finding an answer.

Currently the only way to access tick replay would be to turn the feature on for the scripts to use, I can submit this as a feature suggestion to development.

For the final question, I tried applying the SampleMACrossover with TickReplay enabled but did not see the error you mentioned. Could you provide the steps you used to create the error you had mentioned? For any error reporting please provide all steps taken to produce the error and any supporting items such as sample scripts if needed.

I look forward to being of further assistance.

[dotnet]

tickreplay

Hello Jesse,

Regarding point 1.:
Not sure if this is documented and going by the book, or this is a bugfix forgotten in the code,but this is how TickReplay-ed scripts run:

First the tickreplay cycle run , replay bar 1, replay bar 2, replay bar 3..., when this is finished, there is a second cycle, onbarclose bar 1,onbarclose bar 2, onbarclose bar 3...
The "if (CurrentBar < activeBar) return;" filter out the second cycle. I would suggest to document the second cycle, because it is not expected. I wasted a lot of time until I noticed that second onbarclose cycle, which basically deleted the data gathered in the tickreplay cycle.

Point 2.:
When tickreplayed indicator added to the chart, almost instantly the control given back to the chart, nothing indicate something is calculating in the background, the user might close the chart, or refresh the chart, or add new indicators - before the tickreplayed indicator finish. (all of these can easily trigger a crash) Ninjatrader somehow should indicate indicators that are still in progress.

3. That would be great, thanks.

4. Tested with win7 and win8.1, both with eu and us time zone.
ES 12-15 chart 30 min,cqg connection,10 days loaded, tickreplay enabled, default samplemacrossover added to the chart and started from the control panel. The error: "A hosted indicator tried to load additional data.." .

Interesting: When the strategy started with non tickreplay chart - it is possible to enable the tick replay, and there is no error message or crash. So it is possible to switch to tickreplay after the strategy started, but it is not possible to start the strategy on chart where tickreplay enabled from the start.

[Ricam]

Should the CurrentBar less than activeBar test be applied in ANY indicator that could run in tick replay (in other words, every indicator), or just in those that have added non primary Data Series? When there are added Data Series, should the test also be done for each of them, in addition to the primary Data Series?

While the Tick replay is played in the indicator, there is no visual clue, and the process can takes minutes. At last the usual "loading.." message could be visible until the calculation finished.

How about a popup progress bar? For now a crude hacker solution is to print something from an indicator to the output window while it loads, keeping track of the ratio of CurrentBar to ToBar.

It is too hard to access TickReplay currently. I would suggest a "IsTickReplayRequired" switch in the indicator, which would provide tickreplay for the indicator without manually enable that feature in options+data series.

For now a test for IsTickReplays can be coded into anindicator so that it can print a message or display something on the screen, and maybe adjust its program flow... not the best solution but it's a start.

[NinjaTrader_DaveI]

Should the CurrentBar less than activeBar test be applied in ANY indicator that could run in tick replay (in other words, every indicator), or just in those that have added non primary Data Series?

The CurrentBar < activeBar check appears to relate more to the accumulation of Buys and Sells specifically for the BuySellVolume and BuySellPressure indicators, and is not related to Tick Replay. This check is primarily in place to reset the "buys" and "sells" variables when needed, to start accumulating again for the next bar. The NinjaTrader 7 versions of these indicators used the same syntax to accomplish this goal, as well.

This is different than the most common type of CurrentBar check, which, as Jesse mentioned, is generally put in place to ensure that you are not looking back too far in a collection on earlier bars in a series.

[NinjaTrader_DaveI]

Regarding point 1.:
Not sure if this is documented and going by the book, or this is a bugfix forgotten in the code,but this is how TickReplay-ed scripts run:

First the tickreplay cycle run , replay bar 1, replay bar 2, replay bar 3..., when this is finished, there is a second cycle, onbarclose bar 1,onbarclose bar 2, onbarclose bar 3...
The "if (CurrentBar < activeBar) return;" filter out the second cycle.

I'd like to understand what you are seeing more clearly on this particular issue. Can you share a sample script that clearly shows this in action? Unless you are adding a secondary data series to your script, it would not be expected to see multiple OnBarUpdate() calls for each bar.

Thank you.

[dotnet]

Dave, see the onbar section:

if (CurrentBar < activeBar) return;
if (CurrentBar != activeBar)
{
...
activeBar = CurrentBar;
}


Normally the currentbar smaller activebar condition should never hit,
whoever wrote this was aware there are another onbar cycle(s), which trash the calculation, he filtered those with the if (CurrentBar < activeBar) return; condition.

To answer for Ricam: Yes, this filter needed for every tickreplay indicator, otherwise the extra onbar cycles ruin the calculation.

[dotnet]

Here is a CurrentBar print from the @BuySellPressure indicator, this is a single run.

[dotnet]

.. and this is the modified @BuySellPressure, which created the print.

[NinjaTrader_DaveI]

Thank you for sharing the script. I'm not seeing the same output on my end with the sample code. Perhaps there is something in my setup that is different than yours. Here is what I am using to test:

• 1 Minute ZB 12-15 chart
• Tick Replay Enabled
• 1 Day to Load
• Apply modified BuySellPressure indicator

With these steps, I'm seeing one Print for each bar, in sequence. I'm not seeing any of the overlap you are seeing. Your output actually appears to be looping through every bar up to the current bar, on each new bar. Are you certain there is not another script running a loop through all bars enabled somewhere else, or something similar occurring?

[dotnet]

Dave, add a few indicators to the same chart : SMA, and a BarTimer for example.
Let me know if you found the programmer, and the explanation of the if (CurrentBar < activeBar) return; line, that is the fix of those onbar disortions, that you can see on the attached print log.

Thanks,
Dotnet

[NinjaTrader_DaveI]

I'm still seeing the same results after adding those additional indicators. Take a look at post #2 and #5 on this thread for an explanation of that particular CurrentBar check.

[Ricam]

Dave, are you doing this when trying to duplicate the problem?

From Post 3:

Interesting: When the strategy started with non tickreplay chart - it is possible to enable the tick replay, and there is no error message or crash. So it is possible to switch to tickreplay after the strategy started, but it is not possible to start the strategy on chart where tickreplay enabled from the start.

I don't see any downside to the actifveBar < CurrentBar check so am putting it into all of my new indicator code.

[dotnet]

Here is the pressure indicator with bartimer.
The print upgraded to show a serial number of the onbar calls.

I still suggest to document the
if (CurrentBar < activeBar) return;
with big red font if possible..

[palinuro]

dotnet, thanks so much for posting this - I'd spent days trying to figure out why my tick replay indicators were behaving erratically, and this solved the problem in all of them.

Regarding resetting values in the NT natvie indicators, isn't Currentbar != activeBar used for that?. Whoever coded CurrentBar < activeBar was checking for something else.