@pcz, thanks! I wouldn't have noticed the huge slippage.

@jcl, yes, as far as I understand my own code grin and as I intended this system, the price is 1 ATR(100) in H4 away from both TP and SL when the trade gets stopped in.

Quote:
"Thus many bars will trigger Entry and TakeProfit at the same time."


Of course, I'm all with you but again, as I learned from the robotwealth course, Zorro makes sure to not give overly optimistic results. It does so by counting a loss, if SL and TP are both hit within the same candle. Isn't that correct? If it's not, it should be implemented. And if SL isn't hit, well - why doesn't the backtester just calculates the Pips between the former pending order and the TP?

Quote:
"You can not test such a system in low resolution."


I would aggree if we weren't talking about pending limit orders with static SL and TP. I think the backtester isn't well designed if it can be confused with such simple trades. The only thing that probably needs less ifs and elses to simulate are Binary Options.

Quote:
"From what I understand, the code is also strongly dependent on BarPeriod since the price series is derived from it."


I don't understand the difference between Pending Limit orders calculated once per H4 bar or every 240 bars on M1....? From how TimeFrame is explained in the manual I conclude, that TimeFrame acts like I had set a different BarPeriod for all subsequent functions. For how the script is working it shouldn't make a difference if I set BarPeriod = 1 and Timeframe = 240 or BarPeriod = 240 and TimeFrame = 1 (or comment out TimeFrame alltogether).

I'm still learning. This script was just an exercise, so TimeFrame was used for practicing reasons and I used these ATR Bands because I'm using them in my manual trading. I fixed them to H4 in my MT4, to always have the same price levels.