Nanningbob V5: Steve Hopwood's auto-trading robot | Page 48 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Nanningbob 4h trading system ver. 5.0 4,432 replies

Nanningbob 60x90 EA 3,920 replies

Help regarding NanningBob EA 27 replies

Nanningbob 4H trading system 2,017 replies

Help to improve profitable EA - 1H NanningBob 40MA 200 BB 10 replies

Attachments: Nanningbob V5: Steve Hopwood's auto-trading robot
Exit Attachments

Nanningbob V5: Steve Hopwood's auto-trading robot

  • #941
  • Edited 9:18am Sep 24, 2010 9:14am | Edited 9:18am
First of all, I would like to thank everyone for all their work on this EA.
I originally downloaded it whilst reading through the NanningBob 4Hr thread with the intention of using it to help me see where and when the different trades should be made. To say I was impressed is an understatement. I have now read right through your this thread to get up to speed. However, I don't wish to be just another freeloader, just here to grab someone elses work, so I am hoping to help as much as I can through testing and offering suggestions.
I am by no means a coder, but have a rudimentary knowledge of how EAs work.

If I may be bold enough to offer a suggestion now:-
The variable ReEntryLinePips is offered to the user in the settings dialog, but is over-written by Max's code which sets it's value according to the pair.
If the code was changed to

extern int ReEntryLinePips=0;

and

if (ReEntryLinePips == 0)
{
Max's code here
}

Then the default setting would be as per Max's code, but the user setting would be preserved.

Thank you once again for you work and I hope the above may be useful.

Cheers, Beastie.

EDIT: Steve beat me to it.
  • #942
  • Sep 24, 2010 9:28am Sep 24, 2010 9:28am
Quoting SteveHopwood
I had a pm from Beastie suggesting allowing ReEntryLinePips to override the automatic settings provided by Max, should the user wish to do so.

In the latest update, leaving ReEntryLinePips set to zero tells the bot to override this setting. Inputting a different value tells NB to use the input value instead.

Post 1 as usual, but you do not need this update if you never intend to override the automatic setting.

Nice idea Beastie; thanks.

Hi Steve,
I'd like to do alittle lobbying for this idea to be added to FTLR first chance you get....Great idea....

whip
  • #943
  • Sep 24, 2010 10:21am Sep 24, 2010 10:21am
Still seems to be a error re setting of TP values. Entries are working just fine. Running the latest with the master EA.
Cheers
CanuckCT
Attached Image (click to enlarge)
Click to Enlarge Name: 2010-09-24_1216.png Size: 10 KB
  • #944
  • Sep 24, 2010 10:39am Sep 24, 2010 10:39am
No recovery trade?
Attached Image (click to enlarge)
Click to Enlarge Name: problem 2.gif Size: 77 KB
  • #945
  • Sep 24, 2010 11:21am Sep 24, 2010 11:21am
Quoting CanuckCT
Still seems to be a error re setting of TP values. Entries are working just fine. Running the latest with the master EA.
Cheers
CanuckCT
Attachment
I do not have these problems
please use last version
Not bad !!
Attached Image (click to enlarge)
Click to Enlarge Name: last.jpg Size: 58 KB
Attached File(s)
File Type: mq4 NBv5-19082010-mx064.mq4   125 KB | 268 downloads
  • #946
  • Sep 24, 2010 11:44am Sep 24, 2010 11:44am
Updated...thanks
Cheers
CanuckCT
  • #947
  • Sep 24, 2010 11:49am Sep 24, 2010 11:49am
Ever since trade #3 was redone, all of my trades have been entered on #3. Not sure if this is a correlation or anything but it seems to see setups way before others. And so far my results haven't been as good as prior to #3 since I guess #3 wasn't working. Going to leave it #3 off next week to see how it does.
  • #948
  • Sep 24, 2010 1:38pm Sep 24, 2010 1:38pm
I guess that this error was also in previous versions. It is the reason for some strange TP values and also some order rejection.
in SetTarget and SetTargetH4 functions the Target with AtrVal Should be multiply with Point:

target4H = NormalizeDouble(EntryPrice - AtrVal*Point,Digits);

target4H = NormalizeDouble(Bid + AtrVal*Point,Digits);

target = NormalizeDouble(Bid - AtrVal * Point,Digits);

target = NormalizeDouble(Ask + AtrVal * Point,Digits);
  • #949
  • Sep 24, 2010 4:55pm Sep 24, 2010 4:55pm
Quoting arbinka
I guess that this error was also in previous versions. It is the reason for some strange TP values and also some order rejection.
in SetTarget and SetTargetH4 functions the Target with AtrVal Should be multiply with Point:

target4H = NormalizeDouble(EntryPrice - AtrVal*Point,Digits);

target4H = NormalizeDouble(Bid + AtrVal*Point,Digits);

target = NormalizeDouble(Bid - AtrVal * Point,Digits);

target = NormalizeDouble(Ask + AtrVal * Point,Digits);
Are you certain about this arbinka?

I am neither criticising nor suggesting you are wrong. It is just that I do not recall having to multiply an Atr return by Point to get a meaningful result. Glancing at a GJ chart shows a couple of Atr values of 0.7xxx, which also suggests that the result does not need a Point adjustment.

I trust your coding skills arbinka - they are better than mine, so what do you think?

  • #950
  • Sep 24, 2010 5:21pm Sep 24, 2010 5:21pm
Thank You Steve for let me in from the cold.
Here is Max and Louise results for this week on H1 0.1 lot
(First NBv5-19082010-mx056 and then upgrade to NBv5-19082010-mx061)
Attached Images
  • #951
  • Sep 24, 2010 11:20pm Sep 24, 2010 11:20pm
I can confirm that Max v 64 does indeed set some very odd-looking (and not correct) TP - see my screenshot from today

Odysseus

Quoting SteveHopwood
Are you certain about this arbinka?

I am neither criticising nor suggesting you are wrong. It is just that I do not recall having to multiply an Atr return by Point to get a meaningful result. Glancing at a GJ chart shows a couple of Atr values of 0.7xxx, which also suggests that the result does not need a Point adjustment.

I trust your coding skills arbinka - they are better than mine, so what do you think?

Attached Image (click to enlarge)
Click to Enlarge Name: max1.gif Size: 79 KB
forexfusiondotcom
  • #952
  • Sep 24, 2010 11:56pm Sep 24, 2010 11:56pm
Quote
I trust your coding skills arbinka - they are better than mine, so what do you think?

Don't conclude hasty conclusions about my coding skill...
You are of course right! The correction of this tricky bug (it appears only on symbols that have larger StopLevel Then the AtrVal. And Stoplevel is different with different brokers - even more tricky ...) so the correction layes one line before the "target" line:

if (AtrVal<MinDist) AtrVal=MinDist*Point; // MinDist Should be multiply by Point
target = NormalizeDouble(Bid - AtrVal,Digits); // No multiply for AtrVal
  • #953
  • Sep 25, 2010 12:32am Sep 25, 2010 12:32am
in both SetTarget and SetTarget4H functions you need to replace only one line:

double MinDist=MarketInfo(Symbol(),MODE_STOPLEVEL);

with this line:

double MinDist=MarketInfo(Symbol(),MODE_STOPLEVEL)*Point;

Then no other line should be modified!

I would like to thank Steve again to drawing my attention to my first floppy "correction"
  • #954
  • Sep 25, 2010 2:59am Sep 25, 2010 2:59am
Quoting obnoxious2
Ever since trade #3 was redone, all of my trades have been entered on #3. Not sure if this is a correlation or anything but it seems to see setups way before others. And so far my results haven't been as good as prior to #3 since I guess #3 wasn't working. Going to leave it #3 off next week to see how it does.
I have started to read through and try and understand the code this morning. One thing I have noticed is that the conditions for each trade type are tested for in numerical order (#1, #2, #3, #4) which seems logical. However, mode3buy status is set whenever the upper BB is above 50% of the distance between the upper gold line and screen top (for sells). This means that even if conditions exist for #1 or #2 trades, if the upper BB is within this zone, mode #3 will be set.
Perhaps #3 should be tested first, so that it will be overwritten if #1 or #2 conditions exist.
Whilst looking at info about #3 trades, I read that the BB should be moving away from price for a bulge trade to be valid. Should the test also include a comparison of the present BB position and it's position on the last bar?
I confess that so far I have only digested about half of the code so far, but I though this may be useful.

Cheers, Beastie.
  • #955
  • Sep 25, 2010 3:34am Sep 25, 2010 3:34am
Quoting arbinka
in both SetTarget and SetTarget4H functions you need to replace only one line:

double MinDist=MarketInfo(Symbol(),MODE_STOPLEVEL);

with this line:

double MinDist=MarketInfo(Symbol(),MODE_STOPLEVEL)*Point;

Then no other line should be modified!

I would like to thank Steve again to drawing my attention to my first floppy "correction"
thanks a lot for this bug
And that's all for the entire EA?
here we don't need ? :
double MinDist=MarketInfo(Symbol(),MODE_STOPLEVEL);
if (PendingOrderPipsDistance<MinDist) PendingOrderPipsDistance=MinDist;
  • #956
  • Sep 25, 2010 4:09am Sep 25, 2010 4:09am
Quote
thanks a lot for this bug
And that's all for the entire EA?
here we don't need ? :
double MinDist=MarketInfo(Symbol(),MODE_ST OPLEVEL);
if (PendingOrderPipsDistance<MinDist) PendingOrderPipsDistance=MinDist;
You don't need it there because when you later use PendingOrderPipsDistance you multiply it by Point as in this line:

EntryPrice = NormalizeDouble(Bid - (PendingOrderPipsDistance * Point), Digits);
  • #957
  • Sep 25, 2010 4:57am Sep 25, 2010 4:57am
thanks

i think we should also check the stop min dist in the Be JS and TS modules, since sometimes we get many errors 'invalid stops'

cheers
  • #958
  • Sep 25, 2010 5:28am Sep 25, 2010 5:28am
Ok, I will look at the code for JS and TS and see if I can find somthing (I'm not using those functions in may test and this is why i did not met the problem).

in the mean time I have another thing. I think that PendingOrderPipsDistance is not adjusted for digits in the init() function so it will not work correct for 5 digits broker.
The same is with ReEntryLine4HPips but I'm not sure that you are using the initial value of this variable.
  • #959
  • Sep 25, 2010 6:01am Sep 25, 2010 6:01am
Quoting Beastie Boy
Whilst looking at info about #3 trades, I read that the BB should be moving away from price for a bulge trade to be valid. Should the test also include a comparison of the present BB position and it's position on the last bar?
I confess that so far I have only digested about half of the code so far, but I though this may be useful.
Reading someone else's code is always difficult, so you are doing well to understand it.

#3 is a hard one to code because what constitutes a bulge is so difficult to quantify in code. I got nowhere with it and it was Simon who came up with what we have got. Feel free to try some refinement.

I do not allow the bot to send #3 and #4 trades. #1 & #2 are clear-cut and so better suited to automation.

  • #960
  • Sep 25, 2010 7:11am Sep 25, 2010 7:11am
Steve

I have downloaded the latest version. For some reason, on a backtest, the EA didn't place any recovery trades when one went wrong. It simply waited until it hit the emergency sl. Bizarely a couple of trades later it did decide to enter into recovery and it worked fine. I have attached the trades so you can see what I mean.

Any ideas?

Paul
Attached Image (click to enlarge)
Click to Enlarge Name: recovery trades.JPG Size: 164 KB
1 trader viewing now