Peaky on Steroids

[SteveHopwood]

Something I have been thinking about past few days is whether the distance price must travel between recovery stop orders should be the same regardless of timeframe.

Completely spot on. That is why there is only one MarketDistancePips inputs instead of one per time frame.

By the by folks, my code for calculating the number of pairs with open trades is correct, but the call to it is in the wrong place. I shall post a fix in time for the markets opening after the weekend.

[TraderJoeForex]

Completely spot on. That is why there is only one MarketDistancePips inputs instead of one per time frame.

Doh! Ok that's my free pass used up for this year. For some reason I thought it was one per time frame. Of course you thought of this first! Thanks Steve

[SteveHopwood]

V 1g is in post 1. I have moved the maximum pairs allowed filter to where it will do some good. Also, Gary just pm'd me with suggestions to help cut out the 'unknown ticket' errors that crop up.

For those of you who like to go under the bonnet, do a search for "Note to coders about hedging." This will take you to the explanatory comment about hedging. Underneath that and before the two blocks of code that set up the trade, insert this:

Code: Select all

   //A check that we are not already at our pairs limit. Abort the trade if so.
   if (SendLong || SendShort)
      if (OrdersTotal() > 0)
      {
         CountCurrentlyTradingPairs();
         if (PairsWithTrades >= MaxPairsAllowed)
            return;   
      }//if (OrdersTotal() > 0)
      

Then go to OnTimer() and delete the code block that contains the call to CountCurrentlyTradingPairs();

The other changes are in four code blocks, two each in these two functions:

• void CloseAllTrades(string symbol, int type, int magic)
• void NuclearOption()

You will see this block of code twice in each function:

Code: Select all

            if (result) 
            {               
               cc++;
               OpenTrades--;
            }//(result) 

Gary suggested adding this: FifoTicket[cc] = -1;

The block will look like this:

Code: Select all

            if (result) 
            {
               FifoTicket[cc] = -1;
               cc++;
               OpenTrades--;
            }//(result) 

[SteveHopwood]

I just realised that those four cc++; instructions in the trade closure blocks are the cause of the 'unknown ticket' errors. They are necessary when iterating through all the trades on the platform because otherwise the next trade in the list would become the current one, and so be missed when cc is decremented.

This is not the case with FifoTickets[] which is an array of ticket numbers that are not deleted at the time the trade is closed - this happens at the start of CountOpenTrades(). It does no harm to leave Gary's extra code in but cc++ definitely has to go. The block will look like this:

Code: Select all

            if (result) 
            {
               FifoTicket[cc] = -1;
               OpenTrades--;
            }//(result) 

This line of code is intended to avoid attempting to close an already closed trade:
if (!BetterOrderSelect(FifoTicket[cc], SELECT_BY_TICKET, MODE_TRADES) ) continue;

It will fail if the order closure return receipt has not arrived back on the platform and so order is still in the platform's memory even though it is closed. There is a time delay in between something that we see happen on the platform and this change being reflected in its memory - the reason for so many of the safety features in my single-pair EA's.

[SteveHopwood]

Here is a clever spot by odrisb, sent to me in a PM:

Hi Steve

I believe there might be the issue with the first entry in FifoTicket which is never assigned any tickets when filled from CountOpenTrades. CloseAllTrades tries to close a ticket in FifiTocket[0] which is never actually assigned any value in CountOpenTrades. I believe the simple change from CountAllTrades shown below might fix the issue? ie. FifoTicket[OpenTrades-1] = OrderTicket();

This would have been an issue for along while now so I hope I'm not missing something here. \":good:\"

Cheers

Here is the code as it stands:

Code: Select all

      OpenTrades++;
      //Store the latest trade sent. Most of my EA's only need this final ticket number as either they are single trade
      //bots or the last trade in the sequence is the important one. Adapt this code for your own use.
      if (TicketNo  == -1) TicketNo = OrderTicket();
      
      //Store ticket numbers for FIFO
      ArrayResize(FifoTicket, OpenTrades + 1);
      FifoTicket[OpenTrades] = OrderTicket();

Codeslingers can easily see what odrisb is getting at. I am not bothering with a fix for now - it is not a mis-logic that is causing problems. I have made the fix and will include it in the next update. I have moved OpenTrades++ thus:

Code: Select all

      //Store the latest trade sent. Most of my EA's only need this final ticket number as either they are single trade
      //bots or the last trade in the sequence is the important one. Adapt this code for your own use.
      if (TicketNo  == -1) TicketNo = OrderTicket();
      
      //Store ticket numbers for FIFO
      ArrayResize(FifoTicket, OpenTrades + 1);
      FifoTicket[OpenTrades] = OrderTicket();
      
      OpenTrades++;

Nice one, odrisb

-----------------------------------------------------------

I have moved all Peaky threads to their own forum in the Automation section.

[Zool]

I get a load of pips upfront and then M1 is out of action for a bit while recovery sorts it all out and In the meantime I have the higher timeframes also starting to deliver. And a certain % of these losing trades will close out as losers anyway from an opposite signal when it comes.

Well last week on M1 was not a certain % of the losers was closed out at loss, but all of them, since the price haven't retraced for such a long time that the bottom sixths line was crawled upward constantly, and closed them out at a minor retracement while there were multiple recovery stop orders in place. I agree that M1 can make the biggest gains in account balance, but this time all the profit was eaten with those closed out losers.

Steve: when the close trade on opposite signal is triggered and the trade is closed, PoS will not remove the recovery stop orders placed on that timeframe. Can you make it to delete the pending orders too, when the opposite signal close happens?

EDIT: attached a screenshot of one of my closed-on-opposite-signal M1 trades. It's on M5 because on M1 tf you cannot see the whole trade on 1 screen. The second sell was the glitch happened, when the recovery order placement was not working, and when finally it was fixed somehow PoS moved that order following the trade line as it was a normal order and later haven't placed additional recovery orders. The sell stops marked with pink rectangles are the remaining M1 recovery trades, after the original trade was closed.

[SteveHopwood]

Steve: when the close trade on opposite signal is triggered and the trade is closed, PoS will not remove the recovery stop orders placed on that timeframe. Can you make it to delete the pending orders too, when the opposite signal close happens?

Will do. It is what I intended, so something got lost in translation.

[SteveHopwood]

I have uploaded 1g again to post 1, with the change that Zool highlighted.

Go to line 1290 and you will see this snippet:

Code: Select all

      if (OrderType() < 2)
         TradeWasClosed = LookForTradeClosure(OrderTicket() );

if (OrderType() < 2) is telling PoS only to look for the need to close market trades, not delete pending trades. Remove that line and PoS will also delete pending trades.

[TraderJoeForex]

Well last week on M1 was not a certain % of the losers was closed out at loss, but all of them, since the price haven't retraced for such a long time that the bottom sixths line was crawled upward constantly, and closed them out at a minor retracement while there were multiple recovery stop orders in place. I agree that M1 can make the biggest gains in account balance, but this time all the profit was eaten with those closed out losers.

I didn't have any M1 losers last week but this morning my pairs have caught up! The 4 in recovery have now closed for loss with an opposite M1 signal.

This is going to be an issue for the lower timeframes. Steve would it be possible to have an option for PoS to ignore opposite signals for any pairs that are in recovery? Then once in recovery it will either be a basket close or up to the user to pull the plug on those trades.

Using USDCAD as an example. Price is at the bottom of every chart from M5 up to H4 (in fact H4 looks like it's forming level 3 right now). This should mean there will be a decent bounce up very soon and if my M1 long trade stayed in recovery it would most likely come good this week. PoS is entering long on M5, M15, M30 so it may not make sense for M1 long recovery to be cut short by close on opposite?

[SteveHopwood]

I didn't have any M1 losers last week but this morning my pairs have caught up! The 4 in recovery have now closed for loss with an opposite M1 signal.

This is going to be an issue for the lower timeframes. Steve would it be possible to have an option for PoS to ignore opposite signals for any pairs that are in recovery? Then once in recovery it will either be a basket close or up to the user to pull the plug on those trades.

Using USDCAD as an example. Price is at the bottom of every chart from M5 up to H4 (in fact H4 looks like it's forming level 3 right now). This should mean there will be a decent bounce up very soon and if my M1 long trade stayed in recovery it would most likely come good this week. PoS is entering long on M5, M15, M30 so it may not make sense for M1 long recovery to be cut short by close on opposite?

This is a problem of bad program logic that I foresaw when I planned the code - then forgot. I will sort it out this afternoon. Any codeslinger who looks at the bool LookForTradeClosure(int ticket) function will see immediately what I have done wrong.