Pitchfork bug

[saltminer]

There is some funkiness with the Andrew's pitchfork.
After drawing one, let's say at a shallow angle forward, then scrolling forward through data the pitchfork visibly moves around rather than staying stable.
I have never seen this in ESignal. Those ones stick like glue.
Since the tines of the pitchfork are for support/resistance, having them wiggle randomly around as the bars go by is quite unhelpful.
I'd love it if you could fix this.
Thanks!
saltminer

[NinjaTrader_Eamon]

Hello Saltminer,

Thank you for your post.

Please double click on the pitchfork drawing tool. This will bring up the pitchfork properties. From the properties please enable 'auto-scale' does the pitchfork work as expected with this applied?

[saltminer]

No change in behaviour. Still funky. It should be easy for you to reproduce at your end. For the record, I am using 6.5.1000.4, and looking at tick charts on the YM.

[NinjaTrader_Eamon]

No change in behaviour. Still funky. It should be easy for you to reproduce at your end. For the record, I am using 6.5.1000.4, and looking at tick charts on the YM.

Please post screenshots if possible.

[saltminer]

Screenshots attached.
Note in Image1 the large green bar at 10:55. The lowest tine of the pitchfork passes beneath the low of that bar. Scrolling only a bar or so forward makes the pitchfork move so that it intersects that candle through the middle.
Clearly not functioning as intended.

[NinjaTrader_JoshP]

I've been trying to reproduce on my end but can't. For clarification this is a manually drawn PitchFork right? Or is it an indicator drawn PitchFork?

[Barbara2]

There are 2 different problems with the handdrawn objects and their extensions, as in Pitchforks, Rays and Extended Lines:

1) It looks like the slope of the extended lines isn't calculated from the 'exact real world' coordinates of the definition points and kept constant, but that it is recalculated from the transformed points in 'pixel' coordinates with far less resolution. See the jumping lines in the animated "Scroll.gif", while the scrolling changes the resolution of the price axis.
This makes extended lines with narrow spaced definition points almost useless in NinjaTrader.

2) It seems that the definition points are rounded to the price resolution of the underlying instrument (here 0.05 for the KS future). The problem is, that by dragging the complete drawing object, the points are obviously rounded independently and the proportion/slope of the drawing object changes very much, see the animated "Move.gif".
I have copied the pitchfork data to the clipboard and the xml data clearly shows the rounding (here 0.05) and the independent move of the definition points.

Even if you correct this error and keep the proportion intact, i think that the definition points should not generally be fixed to the price grid:
- the snap mode makes it already easy to fix the points to the bars
- if the points are not fixed to the bars, it is usually intentionally done to adjust the slope/width of the pitchfork/ray to the future price action.
This is currently almost impossible, at least with narrow spaced points like in pitchforks.

Please consider another improvement:
For the manual adjustment of the drawing objects, it would be practical to leave the original drawing in place until a dragged copy is placed.

[NinjaTrader_Dierk]

Thanks for your insights. We'll consider them for NT7.

[saltminer]

I was using manually drawn pitchforks.

To reproduce, create a pitchfork in a quite narrow window, such as in my image example, and do it on data from a couple of days back. Then with data available forward, scroll forward, and watch the pitchfork bounce around.

saltminer