Ah OK. But since I fear that it is related to the way you code things, I am not so sure (and yes, I understand that it’s a quick and dirty to show us).

In the attachment you see a running (in “live”) system and a “tracking” means (per BackTest of the same code) that should always do exactly the same. Thus, compare the green/blue and the red/pink.
In very rare occasions the tracking means is not the same, and it is my task to find the culprit and take measures so the next time it will behave better (more equal).

A kazillion causes can make the tracking to be off, one of the first obviously the spread not being equal in Backtest vs Live. Still it is also often the code itself by doing things which are not “allowed” in Live vs Backtest. “Allowed” between quotes because it is often about rules of the broker, like that minimum distance of a StopLoss, which I *thus* simply avoid. How ? well, by just selling when my code finds it appropriate. IOW, I don’t leave that to the broker (which is what a Set Stop would do – mind you, this is NOT PRT doing it for you !). I have that Set Stop (in %) all right – see second attachment – but this is only for the case that my code would fail (unimaginable – hahaha), *OR* that something in the PRT server fails. Thus again, that SL resides at the Broker-side and he will take care of failures elsewhere (and if the broker fails I will get my money back :-)).

What I thus do is convert all from % to my internal SL code, and that fires when it wants. This is never at the SL you see in the 2nd attachment and it always fires earlier. It is still a % as applied to the PRT SL and it never ever failed. A distance to close to whatever ? … it can’t exist. It can’t exist because I (my program) sell when I want.

Anyway, 11 trades (in plus out) further during the writing of this, and all is still in sync. See 3rd attachment for motivation. Moral, you can make such tracking yourself and will see where it goes off. Of course this is not about the SL’s but they are hard to show. Haha. Ok, see the last attachment.

Apologies for all this text; I’m just having great fun with this stuff.

image_2021-11-19_094728.png image_2021-11-19_095944.png image_2021-11-19_100943.png image_2021-11-19_101152.png

This is my SL at such a far end that it will never trigger (unless something goes wrong) :

SET STOP %LOSS StopLossCustomP

Thus exactly the same as yours, except that it will never be at a too close distance. In my case this works out as what you saw in the previous post, 1900+ or so USD. In itself this is dynamic (StopLossCustomP) but this is unimportant.

In the first attachment you see the bluw lone at 141.xx which is the real dynamic StopLoss divided by 100 (thus curently it is at  USD 1410). That trade (not visible) just finished, and the SL resets to the maximum of 1940; you see that in attachment #2.

Still for this same example, this simple line determines the StopLoss in its basis :

StopLossA = 520

with the notice that in my case this is normalised to an amount of 100000, while the amount I use in this example from today is always 400000. Thus 4x 520 is in order, BUT this is related to an ever existing currency factor between the euro and the USD. And the USD has risen quite a bit (today alone already 1%). Thus yes, how can one make things complicated *or* … how can one make things independent of changing factors out of our control. However :
Where today your 0.5% suffices, tomorrow it may just not because of a lower price of the instrument you are dealing with. And there you’ll have your message again (too close, etc.).

Then we make a percentage of it, which is not what I want but which is needed because some kind of transactions require it :

If Not OnMarket then   // 21-03-2021,PS, This If is functionally new and implies that no StopLoss changes underway.

  // 21-03-2021,PS, Phew, it took me several hours to get the below right, hence to what it now is;
  // StopLossP is the StopLoss in Percentage, with the strict goal it had to remain the same as how
  // it was in absolute $. Thus, our calculated $325 (as of lately), should remain exactly that,
  // taking into account :
  // - That the 325 (or other optimal value) works on an ever rate of the 2nd Fx pair (EUR/USD);
  // - That today this rate may be different but all the relations should remain in-tact (CurrencyFactor);
  // - That all indirectly relates to the *original* set up buy qty of 100.000 pieces (of EUR);
  // - That we already went triple crazy of the contract amounts vs buy qty vs changing that;**
  // **): All the hours of attempt let remain those original numbers, see below.
  // In addition the normal StopLoss must also remain, because else things don't work elsewhere
  // (hence the StopLossP).

  StopLossP = 100 / (((100000 * Close) * CurrencyFactor) / StopLossOrg)

endif

Of course you notice my If Not OnMarket which is similar to what Nicolas advised. In my case this is merely related to having set things consistently in advance, like for example underway the currency factor difference (while trading currencies) should not play a role. Btw, you see the CurrencyFactor being used there as well. This is (and has to be) in everything.

It may also be good to notice that working with percentages is not really something usable, while “money” as such is. Thus I work with values (amounts) related to the invested money-amount (similar to the StopLoss of 520 you saw).

Blablabla ?
Only this part is left :

If TrendNet = -1 and GainOpen < -SignificantLoss then
  MustSell = 1
  If Grph5 then   // 30-07-2021,PS.
    Trigger = close + DevTrigger
    graphonprice(((Trigger))) COLOURED (0,0,255) as 
    "Exit market because of trend in wrong direction, etc. (SL)"
endif

with the Notice that SignificantLoss is the representative of StopLoss which in itself emerges by this :

If OnMarket then
  SignificantLoss = SignificantLoss - StopLossDecrease
  StopLoss = StopLoss - StopLossDecrease // (StopLossDecrease * BuySellAmount * ExtraFactor)

  // 20-08-2021,PS, WATCH OUT :
  // I take it that it is not even possible but this does *not* adjust the formal StopLoss dynamically. Maybe
  // this can be done after all by once in the minute or so removing the formal StopLoss (by making it equal to
  // 0) and next set a new one. Notice, however, that my own custom StopLoss surely works with this.
  // See more below under this date and SignificantLoss.

endif

… which is only a recursive trailing means I pointed out by the blue line.

And thus : again a lot of text but what happens is relatively easy. The moral again : I don’t leave it to the broker and just do it myself. This is nothing special in itself, but everybody uses his own means. Also keep in mind the importance of stuff like currency, and which may – or will not work out in backtesting but influence live. Especially when your account is in euros but you trade USD stuff, then things influence in an uncontrollable fashion. Not here (ehm, after a couple of years “finding out”).

Have fun !

image_2021-11-19_134315.png image_2021-11-19_134530.png