4 Ducks

[SteveHopwood]

Hi,

Is this EA working fine for anyone ?
My demo still shut down from rogue trade warning.

Cheers

Nope.

This is turning into a real bugger. I thought it would be soooooo easy to convert BASA. Later on, I will remove all internal closure code so we caj rely on tp/sl for closure, then gradually add it back in to isolate the cause.

[SteveHopwood]

V 1e is in post 1. I have disabled trade closing functions, so 4D should rely on tp/sl to exit trades.

We can start enabling them again to see what is causing the rogue trades when we are certain we are not getting them.

[Elixe]

I don't seem to have any rogue closures now (note that I already had fewer with the version removing the MA cross close).

I've just noticed something strange on nzdjpy

2 main trades opened in the same minute :

Code: Select all

20:34:23	open #106071527 sell 0.02 NZDJPY at 81.280 sl: 82.281 tp: 78.280 ok
20:34:30	open #106071550 sell 0.02 NZDJPY at 81.249 sl: 82.251 tp: 78.280 ok
20:34:30	modify #106071550 sell 0.02 NZDJPY at 81.249 sl: 0.000 tp: 78.280 ok
20:34:31	modify #106071527 sell 0.02 NZDJPY at 81.280 sl: 0.000 tp: 78.280 ok

I think this makes the stacktradeclosure go crazy because the price is actually over the stack BE line (it is atm at 81.157). It would also mean that the stackclosure is working as intended but the issue might be with the open. It seems that the buyline is still present after the main entry and so trigger's another trade on recross. I'm not very familiar with your shell code (but working on it ) but I will search for "when is the buy line deleted" as it looks like this is maybe the issue

[milanese]

I don't seem to have any rogue closures now (note that I already had fewer with the version removing the MA cross close).

I've just noticed something strange on nzdjpy

2 main trades opened in the same minute :

Code: Select all

20:34:23	open #106071527 sell 0.02 NZDJPY at 81.280 sl: 82.281 tp: 78.280 ok
20:34:30	open #106071550 sell 0.02 NZDJPY at 81.249 sl: 82.251 tp: 78.280 ok
20:34:30	modify #106071550 sell 0.02 NZDJPY at 81.249 sl: 0.000 tp: 78.280 ok
20:34:31	modify #106071527 sell 0.02 NZDJPY at 81.280 sl: 0.000 tp: 78.280 ok

I think this makes the stacktradeclosure go crazy because the price is actually over the stack BE line (it is atm at 81.157). It would also mean that the stackclosure is working as intended but the issue might be with the open. It seems that the buyline is still present after the main entry and so trigger's another trade on recross. I'm not very familiar with your shell code (but working on it ) but I will search for "when is the buy line deleted" as it looks like this is maybe the issue

Hi Elixe,
good observation
if you make a debugging version that prints out the ClosePrice you find it in void LookForStackBasketClosure(string name), you will see that ClosePrice = ObjectGet(name, OBJPROP_PRICE1); returns a value very near the stack trade open price.. so the problem is probably in this part..

Cheers
Tommaso

[SteveHopwood]

Hmmmmmm. The bloody thing appears to have stopped taking a gazillion trades a second then instantly closing them.

It also appears to take a 'Main trade' whenever one appears, whatever the value in MaxTradesAllowed.

So, we have endured a week of battling with something that should have been soooooooo easy. Shall I lock this thread guys, and start again from scratch? It might be quicker. On the surface, the basic strategy looks good; it is my implementation into an ea that is rubbish.

[RxCape]

Today I noticed that 4 Ducks was not placing stop losses nor TP settings. It was working in the prior version.

Like you said Steve, the strategy seems good. A few bugs need to be worked out.

[Elixe]

Hi Steve, I hate giving the last words to computer bloops making them think they outsmarted us, it gives them confidence and I don't want that

I might have found the bugger for the "double" open trades :

in the start() function, the check for buy is done before readindicator :

starts at line 4168 If (ObjectFind(buyline) > -1)
it calls HasBuyFilled() who calls SetUpAndSendTrade who removes the buyline on success.

After this, you call ReadIndicatorValues, that draw the buyline if OpenTrades == 0.
As the countopentrades as not yet been called for this run, it is 0, so it draws again the buyline.

Nothing then is called to redelete the buyline, until price crosses again the buyline (hence opening a new main trade, making the EA consider it is a valid basket)

Moving the has buy/sell filled trigger code part after the countopentrades might solve the issue.

I would also suggest to move the MAcross SL to MACross +/- 10 pips (or whatever seems good) to prevent the immediate closure when the buyline is very close to the MA60 on M5.

[vegastar]

Hi Steve, I hate giving the last words to computer bloops making them think they outsmarted us, it gives them confidence and I don't want that

I might have found the bugger for the "double" open trades :

in the start() function, the check for buy is done before readindicator :

starts at line 4168 If (ObjectFind(buyline) > -1)
it calls HasBuyFilled() who calls SetUpAndSendTrade who removes the buyline on success.

After this, you call ReadIndicatorValues, that draw the buyline if OpenTrades == 0.
As the countopentrades as not yet been called for this run, it is 0, so it draws again the buyline.

Nothing then is called to redelete the buyline, until price crosses again the buyline (hence opening a new main trade, making the EA consider it is a valid basket)

Moving the has buy/sell filled trigger code part after the countopentrades might solve the issue.

I would also suggest to move the MAcross SL to MACross +/- 10 pips (or whatever seems good) to prevent the immediate closure when the buyline is very close to the MA60 on M5.

Very nice spot! It might solve the issue. However, i am imagining the situation of ReadIdicator() draws buy/sell lines depending on zero OpenTrades, which is calculated in CountOpenTrades() (the block after ReadIdicator())

[SteveHopwood]

V 1f is in post 1.

Thanks guys for your suggestions. It transpires that Tommaso was looking at the code and believes he has sorted out the problems. Please read the details in 'Tomasso's contribution' in post 1. Many thanks Tomasso.

He has run the latest through crapergy tests to verify that the code is working correctly. I am unable to run confirmatory tests because Global Prime's demo server appears unavailable at the mo. I assume these will have awoken by the time markets kick off later on and will load the updated version onto my demo.

[SteveHopwood]

Watch the magic number input guys. Tommaso changed it to 1515 and I did not notice. I suggest you change it back to 0 and restart the account, as future updates will default to 0.