Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Coding Multi Time Frame (MTF) Indicators with NinjaTrader
Please, do not use the VisualSMA for that purpose in VisualMode. You need to set it to StrategyMode (all other modes are repainting). Once set to StrategyMode you can decide whether it should plot an arrow or not.
Can you help answer these questions from other members on NexusFi?
Now you have me a bit more confused...the slope of the VisualSMA matches the same SMA(Typical,1) on the 8 and 10 ranges charts...but the CrossingArrowsMTF says they don't and that's why it doesn't plot an arrow?
If I set the VisualSMA in StrategyMode they are mostly horizontal and rarely they go down at the same time....and the CrossingArrowsMTF draws an arrow where they are flat.
The esteemed vegasfoster and I have written an indicator adapted from the StochCycle indicator that currently works on 6R, 12R, 24R time frames. I want to be able to use it for tick charts and time charts as well as range, preferably based on the current chart bar type. NT Support says they won't (a) tell me how to access the current chart bar type and (b) they only support hard coding even though some NT users have conditionally coded to test and conditionally set the bar period but "I'm on my own". In other words, I would have to have a distinct indicator for each bar type... (back to the 50's in programming style?)
protected override void Initialize()
{
Add(PeriodType.Range, addBarPeriod1); //I WANT TO MAKE THIS TICK OR TIME-BASED CONDITIONALLY
Add(PeriodType.Range, addBarPeriod2); // DITTO
}
Is there a way to get and test the current charts BarsPeriod.Id value?
I doubt the following is correct, but just to show you what I'm trying to do.
if (BarsPeriod.Id == "Range") Add(PeriodType.Range, addBarPeriod1);
else if (BarsPeriod.Id == "Tick") Add(PeriodType.Tick, addBarPeriod1);
else if (BarsPeriod.Id == "Minute") Add(PeriodType.Minute, addBarPeriod1);
else <blah blah blah>;
An example of the syntax for determining the type of chart that is in the main price panel can be found in the GomRecorderIndicator.
After you type the period character after PeriodType, the Intellisense® code editor will helpfully give you a dropdown list of the valid values that you can select from.
braulio, ive kinda read into what you are doing here but not following 100%. are you trying to replace the visualSMA indie with arrows of the crosses or are you saying that the visualSMA indie is off?
dont believe anything you hear and only half of what you see
If the VisualSMA is horizontal, this simply means that no new 8-range bar has been completed, so the indicator sticks with the value of the prior 8-range bar.
The confusion about the slope occurs, because there are two bar series. The slope relative to the 8-range bar series it not the same as the slope relative to the 4-range bar series. The VisualSMA would show the slope relative to the 4-range bars, which is often flat in StrategyMode. What you need is the slope of the 8-range bars. Or better, you just want to check whether the Typical[0] was greater or smaller than Typical[1] on the 8-range bars.
You cannot get the slope from the 8-range bars by using the VisualSMA.
So the first conclusion I draw from your quote is that I cannot trust the slope of the VisualSMA indicator.
Based on the CrossingArrowsMTF I wrote the attached indicator to try and better understand what's going on and here's what I found (please correct me if I'm wrong) :
It basically plots :
. green - when the slope of 8range SMA(Typical,1) + 10range SMA(Typical,1) are both going up
. red - when the slope of 8range SMA(Typical,1) + 10range SMA(Typical,1) are both going down
. nothing - when they are not going in the same direction
I've applied it to a 4range chart along with the VisualSMA's (see the pic) and I can see the following:
1. the slope of both SMA(Typical,1) are going up but the VisualSMA's lying and going down.
2. both SMA(Typical,1) are NOT going in the same direction but VisualSMA's are lying and plot the opposite.
You can trust the slope of a VisualSMA, but you need to understand what it does. The slope is painted backwards from the last value calculated from the 8-range bars to the prior value calculated from the 8-range bars. The slope is only known, once that last 8-range bar has closed. However, you already try to use it before it is known.
You have to understand what repainting means. I do not code repainting indicators in general, but the VisualSMA is an exception. It does not repaint relative to the 8-range bars - it simply connects two data-points - , but it repaints relative to the 4-range bars, as the connection of two data points from the 8-range bars may include many data points from the 4-range bars.
Therefore you should only use the VisualSMA in StrategyMode if you want to use it for calculating other indicators.
Yes, you have got the trend filter right. Let us have a look at the last green box. Historical data is made up of 1-tick bars. So the trendfilter collects the information from the previous bars of the secondary bar series (BarsInProgress ==1 and BarsInProgress==2). It does not have the information yet that the Typical Price of the secondary bar series has moved down. If you compare with the VisualEMAs, you will notice that the previous close of the secondary bar series was one candle back - aligned to the second but the last green box of your trend filter. So the trendfilter simply remains grreen in that state, because the next tick of the secondary bar series has not been registered.
The VisualSMA has a negative slope, it already uses the information from the next tick and then paints the slope back. The lag is compensated, but this is achieved through repainting the connection between two consecutive 8-range or 10-range bars. The VisualSMA does not lie, it just seems to look into the future. If you use the VisualSMA in StrategyMode it will be in harmony with your trend filter.
Real-Time data would be different
If you use real-time data, the picture will be different. Each tick registered will temporarily change the value of the 4-range, the 8-range and the 10-range bars. So in real-time your trendfilter will not be green but already red, because it will collect the last value from the secondary bars at that stage when the bar 1 on your chart closes. This is in line with the CalculateOnBarClose = false settings for the primary bars. The current value of an indicator is shown, even if the bar has not closed. In real-time those current values from the secondary bars are used to calculate the trendfilter. When the bar is closed it will use the last known value, which is an intrabar value and no longer available with historical data.
This mean that your trendfilter will also show different values, once you have loaded historical (1-tick -per-bar) data.
Could you zip a file with the part of your brain that understands all this and send it over? Thanks....
. that means the CrossingArrowsMTF indicator will also show different results in real time, right?
. could this historical/real-time "problem" with indicators that have different dataseries be solved if they used tick information from the gomrecorder framework?
. does that also mean that this a common problem with all MTF indicators? That is, there will always be a difference between historical and real-time calculus?
There is a common problem with all MTF indicators, which is linked to the way OnBarUpdate() works.
OnBarUpdate() will always run the primary Bars [BarsInProgress == 0] first. It will then call the added bar series [BarsInProgress == 1, BarsInProgress == 2, etc.].
Now imagine that both your primary bar and your secondary bar close at 5:10 PM. The primary bar is run first and the indicator values are set for that bar. Then OnBarUpdate() will run the secondary bar and calculate the values for the 5:10 PM bar close of the secondary bars. But you can no more use them for setting the indicator values, because the indicator values were already set for the 5:10 PM bar, when OnBarUpdate() had called the primary bar.
This means that you will always come 1 tick late. All MTF indicators lag by at least 1 tick.
Now note the difference between historical and real-time data. Historical bars are 1-tick bars. Coming 1 tick late means that you will be 1 bar late. Real-time bars are less of a problem, because the 5:10 PM indicator value will have been calculated from the second-but-the-last tick of the 5:10 secondary bar. On historical data there is no second-but-the-last-tick, so the close from the previous bar will be used.
To solve this problem visually, you can simply repaint 1 tick back. This is the reason that the VisualSMA indicator has a 1-tick-repaint option, the FirstTickMode. But if you want to execute a strategy you can not repaint, because you would use information that is not yet made available by NinjaTrader - a case of the hindsight bias.
dont believe anything you hear and only half of what you see 