Custom Bar Types

[Zeos6]

Currently, creating a custom bar type is so severely restricted that outside of some very basic modifications, it isn't of much use.For example,

1. The bar painting engine enforces the instrument tick size in specified for the instrument in the instrument manager.

2. Cannot add custom properties to bar types.

Item 1 is especially unnecessarily restrictive.The bar painting engine works just fine without it. You can test this out by changing the instrument tick size.Can we have the ability to build the bars based on our own minimum rice fluctuations? In the interim, is there a workaround for this. I really need to be able to build my own bars.

[NinjaTrader_ChelseaB]

Hello Zeos6,

You are correct that the tick size of an instrument cannot be changed from any NinjaScript.
This tick size setting should only be changed manually using the interface in the Instruments window. (The tick size of an instrument should match the exchange settings and should not be changed. Changing this to an invalid tick size can cause orders to be rejected by an exchange)

I am happy to submit a feature request on your behalf for the NinjaTrader Development to consider allowing the tick size of an instrument to be changed from a script.

It is possible to have custom inputs by overriding the existing properties with your own using Properties.Remove() and SetPropertyName().

Below is a public link to the help guide.

https://ninjatrader.com/support/helpGuides/nt8/en-us/?setpropertyname_2.htm

And a public link to an example.

https://ninjatrader.com/support/forum/local_links.php?linkid=1134

Bar type scripts do not do the rendering. These only set the open, high, low, close, and volume points for the bar. These price points must match a tick size.

Rendering is done in a chart style script.
You can render anything you want at any size in a chart style.
You could render bars that are not at a specific tick size.
You could render a circle instead of a bar if you really wanted to.

[Zeos6]

Hi ChelseaB,

Thank you for your reply.

I am aware that incorrect tick size can affect orders. That is a good point. Clearly if I am creating a modified view of an instrument I would not trade off of that but you do have a very good point that needs to be borne in mind.

I am happy to submit a feature request on your behalf for the NinjaTrader Development to consider allowing the tick size of an instrument to be changed from a script.

Yes, please do that. Thank you.

It is possible to have custom inputs by overriding the existing properties with your own using Properties.Remove() and SetPropertyName().

I am aware of these minor modifications. But these are very limited. In fact you can even create your own properties that show up in the property grid but they don't get "wired up" and therefore are non-functional.

Bar type scripts do not do the rendering. These only set the open, high, low, close, and volume points for the bar. These price points must match a tick size.

Not sure why I didn't pick up on this earlier but thank you for the clarification. This is precisely the area where allowing user specified tick size would come in very helpful.

Rendering is done in a chart style script.
You can render anything you want at any size in a chart style.
You could render bars that are not at a specific tick size.
You could render a circle instead of a bar if you really wanted to.

Thank you for clarifying this. This is interesting, especially the part about bars that are not a specific tick size. Do you have any code snippet of this (i.e. bars that are not at a specific tick size) that I could look at? It would be very helpful. Thank you.

[NinjaTrader_ChelseaB]

Hello Zeos6,

I have received tracking ID #SFT-1212 for your request to change an instruments tick size from a script.

I do want to note I personally feel this is not a good idea. Changing the instrument tick size will affect the orders and data. Even manually changing to an incorrect tick size will affect these items.


Regarding rendering, I would recommend looking at any chart style included with NinjaTrader. Try viewing the code for the MountainStyle chart style. In OnRender you can render anyt shape or path you want from any x,y point on the render target to any other point. You could completely ignore the bar information if you wanted.

Below is a link to an example indicator that shows the basics of rendering.

https://ninjatrader.com/support/forum/showthread.php?p=509144#post509144

Also, while a bar type script should always be setting open, high, low, and close at an exact tick size, there isn't anything to force this. As an example if you were to copy the HeikenAshi bar type script and remove every call to 'bars.Instrument.MasterInstrument.RoundToTickSize( )' this would be a bar that has open, high, low, and close values that are not set to an exact tick size.

[Zeos6]

Hi ChelseaB,

Thank you for your reply and for the tracking number. Thank you also for voicing your concerns.They certainly are valid.

You are absolutely correct regarding potential issues with orders based on instruments with an incorrect tick size. The issue for me mainly is the fact that OnDataPoint() returns a bars object from the historical repository. There is no way to my knowledge of replacing this bar object with another series, either from the repository, or one created. So all these things are an attempt at being able to manipulate data that come in a fixed format to a new format that I want.

Regarding rendering, I would recommend looking at any chart style included with NinjaTrader. Try viewing the code for the MountainStyle chart style. In OnRender you can render anyt shape or path you want from any x,y point on the render target to any other point. You could completely ignore the bar information if you wanted.

Whilst this is true, you are still depending on the bars object and its rigidly enforced structure if you are trying to paint your own custom bars.

Also, while a bar type script should always be setting open, high, low, and close at an exact tick size, there isn't anything to force this. As an example if you were to copy the HeikenAshi bar type script and remove every call to 'bars.Instrument.MasterInstrument.RoundToTickSize( )' this would be a bar that has open, high, low, and close values that are not set to an exact tick size.

This is also true but is not generally the case. The Renko bars type enforces the tick size of the instrument with no calls to bars.Instrument.MasterInstrument.RoundToTickSize( ).

Thank you for your reference links and for your thorough answer. I truly appreciate the time you took to answer me. Thank you.

[NinjaTrader_ChelseaB]

Hello Zeos6,

When you mention
"Whilst this is true, you are still depending on the bars object and its rigidly enforced structure if you are trying to paint your own custom bars."
I'm not sure what you mean. You don't have to depend on the bars object if you don't want to. You could render a happy face if you really wanted. You can render whatever you want. You aren't stuck to using the bar values.

When you mention:
"This is also true but is not generally the case."
This is up to the script you are writing. The bar type scripts our development has written enforce the tick size because all bar type scripts should enforce the tick size. If you're script doesn't then it doesn't. Its not a general thing, it's whether you wrote that logic into your script.

That said, never manually set a tick size that is not the tick size set by the exchange for the instrument. Also, always round the open, high, low, and close of a bar to the instruments tick size or other issues will arise.

[Zeos6]

Hi ChelseaB,

You don't have to depend on the bars object if you don't want to. You could render a happy face if you really wanted. You can render whatever you want. You aren't stuck to using the bar values.

Absolutely true but misses the point of my inquiry. I basically wish to paint synthetic bars that match the existing bars except that they may have OHLC values that do not conform to multiples of the instrument tick size, which is enforced by the bar type..

This is up to the script you are writing. The bar type scripts our development has written enforce the tick size because all bar type scripts should enforce the tick size. If you're script doesn't then it doesn't. Its not a general thing, it's whether you wrote that logic into your script.

Not quite true ChelseB. I have a bar type script that I have debugged thoroughly and have even printed values from it. I can create a bar type with any values for OHLC, that is true, but after it is "processed" through bars type, all the bar values are rounded to the nearest instrument tick size regardless of my actual values, and the chart style prints the "corrected" values rather than the non-ticksize compliant values.

That said, never manually set a tick size that is not the tick size set by the exchange for the instrument. Also, always round the open, high, low, and close of a bar to the instruments tick size or other issues will arise.

I understand what you are saying here, and of course it makes sense. Yes, you do really need to know what it is that you are doing, and why you are doing it. The only reason I find for playing around with the tick size is because of:

1. The bars type engine is unnecessarily far too restrictive in terms of enforcing the instrument tick size which prevents us from drawing bars with arbitrary OHLC values, and

2. Although we can create a "synthetic" instrument in which we can manipulate the tick size - and it does plot correctly in real time - we are not able to load historical data to it based on a symbol map. It seems that historical data are retrieved based on the instrument/symbol name rather than its symbol map.

The end result therefore is that we are not able to draw synthetic bars with non-tick size compliant OHLC values. As a point of interest, other platforms are able to do this so I do not understand the rationale for such rigidity.

As always, thank you for your detailed and well thought out answers. I really appreciate it.

EDIT:
You state,

The bar type scripts our development has written enforce the tick size because all bar type scripts should enforce the tick size. If you're script doesn't then it doesn't. Its not a general thing, it's whether you wrote that logic into your script.

Can you actually verify that this is the case Chelsea? I have written a bars type script with no such logic and the values are still is being rounded to the nearest tick size.

[NinjaTrader_ChelseaB]

Hi Zeos6,

Can you actually verify that this is the case Chelsea? I have written a bars type script with no such logic and the values are still is being rounded to the nearest tick size.

I spoke too soon on this after talking with a lead and didn't test this. After testing I'm finding that the historical data is always rounded both to any script calling Close[0] and on the chart.. However, in real-time I am able to get the un-rounded values in a script calling Close[0] but... the chart still shows the rounded values.

With all of this said, we feel that you are not using a bar type for the intended use. Bar types are intended to be rounded to a tick size, and this should always be done.

If you want to have un-rounded values rendered on a chart, do this with an indicator. The HeikenAshi indicator is a perfect example. It overlays on top of the chart and hides the real bars and the values from it can be called from other scripts.

Below is a public link to the HeikenAshi indicator.

https://ninjatrader.com/support/forum/local_links.php?linkid=730

[Zeos6]

Hi ChelseaB,

Thank you for your reply.

After testing I'm finding that the historical data is always rounded both to any script calling Close[0] and on the chart.. However, in real-time I am able to get the un-rounded values in a script calling Close[0] but... the chart still shows the rounded values.

That is exactly what I see as well. Thank you for confirming this.

With all of this said, we feel that you are not using a bar type for the intended use. Bar types are intended to be rounded to a tick size, and this should always be done.

You are correct in that I am trying to use the bar type in a manner not intended by the designer. My point simply is that the designer's view is unnecessarily rigid and narrow in scope. To me, a bar type is precisely that, a bar type; that is, any type of a bar, with no restrictions on it. What seems to be happening, however, is that NT imposes restrictions on this type by enforcing adherence to instrument tick size, but only for historical data. This is not necessary. In fact, the bars type script with non-compliant tick size works just fine with real time data. So, why the restriction on historical data? This is inconsistent behaviour and certainly suggests that the unrestricted approach is viable. In fact, I would argue that removing the tick size restrictions would improve the usability of the bar type scripts.

If you want to have un-rounded values rendered on a chart, do this with an indicator. The HeikenAshi indicator is a perfect example. It overlays on top of the chart and hides the real bars and the values from it can be called from other scripts.

I am aware of this approach Chelsea. Thank you. But there are advantages to using a bar type script over an indicator overlay script.

[NinjaTrader_ChelseaB]

Hello Zeos6,

If you have a good use case where an indicator overlay will not work and the bar type itself must have values that are not rounded to tick size, I am happy to forward this use case to our development.

[Zeos6]

Hi ChelseaB,

Yes I do, Try building a Renko chart with fractional brick sizes. For example, a Renko chart with a brick size of say 1.3 points for ES.

Thank you for your patience and your help. I appreciate it very much. In fact, this discussion with you has given me an idea of a workaround that seems to be working. So thank you.

As an aside, the data that appears in the Data box, that seems to come from the bars type. Is there a programmatic way to format the data that appears in the data box?

[NinjaTrader_ChelseaB]

Hello Zeos6,

I've submitted a feature request for the development team to consider allowing bar type scripts to save ohlc price points that are not rounded to tick size.

Once I have a tracking ID for this request I will post in this thread for future reference.

Unfortunately, FormatPriceMarker() only works for indicators. This would allow you to set the number of decimal places for the data box and price markers on the chart for indicator plots.

https://ninjatrader.com/support/helpGuides/nt8/en-us/formatpricemarker.htm

[NinjaTrader_ChelseaB]

Hello Zeos6,

I've received ID #SFT-3264 for your request to set ohlc price points in a bar type to use unrounded values.

Please note it is up to the NinjaTrader Development to decide if or when any request will be implemented.

We appreciate your suggestion on this.

[Zeos6]

Thanks ChelseB. I appreciate. Can you please also put in a feature request that would allow us to format the data in the Data Box from any script, for example ChartStyle, BarType, etc. Thank you.

[NinjaTrader_PatrickH]

Hello Zeos6,

Your feature request has been assigned the internal tracking id of SFT-3401.

Please let me know if you have any questions.