Why is this Indicator Double Plotting ATR Lines ?

Forums ProRealTime English forum ProBuilder support Why is this Indicator Double Plotting ATR Lines ?

Viewing 4 posts - 1 through 4 (of 4 total)
  • #76052

    I was trying to label the orange and blue indicator lines “Short Dev Stop” and “Long Dev Stop” so I could create a strategy with how the price interacts with either crossing a long (blue) or short (orange) SAR pattern. I have done all manner of relabelling but cannot get it to simply display orange Dev Stops labelled as Short Dev Stops and the blue Dev Stops as Long Dev Stops?

    Why is this indicator double plotting?

    The Original Code (which works but has no long / short labelling protocol (only Dev Stop 1.0, Dev Stop 2.2 etc) when using assisted creation)

    And one of upteen attempts to get it to work – including taking the “else” out after the code: r=0, g=191, b=255 and relabelling dev0 etc longdev0, to creating a unique set on ind0 etc to ind5 and making it in ind6 (instead of ind0) in the second set of “ind” values.

    Double plotting code: Incorrect double plotting of Dev Stops (orange and blue lines labelled as both long and short )

    This is probably really, really simple for a coder…. lol…

    More about the Kase ATR Dev Stop here: https://www.prorealcode.com/prorealtime-indicators/kase-dev-stop-v3/

    Thanks in advance,
    Cheers
    Bard

    #76072

    It does not duplicate lines, it’s you who DUPLICATED them at lines 91-96 and then returning all of them!

    The main issue is that their value is retained between bars, so there will always be 12 statuses to be displayed!

    If PRT supported alphanumeric variables it would be simple to set different TEXT to the original 6 variables (ind0-ind5) to tell SHORT from LONG data thus returning only 6 variables for 12 statuses, but this is not the case, so if you don’t want those many lines well… you have to back to the original code!

    Also, it would be great if you could use different RETURNs from within an IF…ENDIF block, but this is not the case, either!

    Only colours can help tell the difference with just the same label!

     

    1 user thanked author for this post.
    #76077

    Thanks @Robertogozzi,
    Duplication/Bars 91-96. Yes I know! You should’ve seen all the ways I tried to relabel those variables…
    Why doesn’t PRT support alphanumerics?

    Also do you know how you would optimise the Kase Dev Stop when using it in a system? It’s not like I am able to optimise values eg: between -1 and +1 by increments of 0.1 on a custom indicator like the Ehlers Supersmoother Oscillator (it’s on this forum, and -0.8 cross-overs to buy and + 0.8 cross-unders to sell are good values btw), because the Dev Stops are on the price chart and are  “fluid” in their ATR values? I know it can be done as a user on this forum did mention they’d optimised values and found that Dev Stop values of >4 and <5 worked best.

    Thanks again for you help,

    Best
    Bard

    #76079

    Support for alphanumeric data would make the system much more difficult to manage, since they should add text support (parsing, concatenation, contraction, deletion, replacement) which would involve “garbage collection”, i.e. manage defragmentation of memory…. a difficult and time consuming process. I think these are the main reasons, but hopefully this might change in the years to come.

    As for Kase Dev Stop, sorry but I never dealt with it so I can’t be of help!

    1 user thanked author for this post.
Viewing 4 posts - 1 through 4 (of 4 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login