SteveHopwood wrote:global wrote:SteveHopwood wrote:If, say, StopLoss is declared as an integer as in int StopLoss = 20:
double NewStop = NewStop = OrderOpenPrice() - (StopLoss * Point); is allowed and (StopLoss * Point) creates a 0.xxxxxxxx result.
The command using factor is OrderOpenPrice() - (StopLoss / factor);
But, if StopLoss is an integer then the code (StopLoss / factor) returns a zero value.
All the pip values in mptm were declared as integers, so when interacting with factor resulted in 0 being added to whatever the bot was supposed to be doing, and so trades were closing prematurely. All that was needed was to convert them to doubles - something Paul forgot to do and that I did not notice.
So, fix is in post 1; sing out if I am barking at the wrong moon and the fix does not work.

Thanks for the update Steve. I checked your updated code and I'm wondering if the int iPipsAboveVisual variable in line 901 needs to be converted to double iPipsAboveVisual from this line of code...
Code: Select all
bool CheckForHiddenStopLossHit(int type, int iPipsAboveVisual, double stop )
...because a little further down you divide iPipsAboveVisual by Pipfactor as below:
Code: Select all
double sl = NormalizeDouble(stop + (iPipsAboveVisual /Pipfactor), digits);
Nice one global and seems likely you are correct. Even if not, I have made the change and updated the post 1 version.
I tamper with mptm's code with the greatest reluctance. The Steve who started coding it back in about 2007 and the Steve who codes these days are completely different coding individuals. Had I understood even a fraction back then of what I understand now, the code would be completely different. Anybody updating my code
now has the me back from 2007 to contend with, and does so at the peril of the entire EA. I shall probably ignore well-intentioned updates in the future.
Added to my early inexperience is the fact that mptm's code has been expanded by several contributors over the years. I rarely have any idea what they were doing and just go with the flow. mptm is ridiculously complex and we are left this this unavoidable truth: tampering with mptm code invites LUC (Law of Unintended Consequences) to throw the bender of the decade for his buddies. What has happened here is a great example.

Hi Steve and all
I hope this post is in the right place...
I have just joined and this is my first post. I have found many interesting, informative and potentially useful 'bits and pieces' here. One of many questions which came to mind is in relation MPTM_Global, as it seems to be called now.
Steve (and anybody else who has played a part in the development of MPTM_Global), given what you have said above, is there any chance of a less complex-looking, easier to follow, not so susceptible to LUC version of the trade manager becoming available in the near future, or are all the gun coders, such as yourself, too preoccupied with other projects?
Is there something better in the works .........?
I did not have the privilege of following MPTM in it's development from an earlier stage, so need some guidance as to what some of the terms mean, and how the parameters interact with each other. I read somewhere about a pdf guide, but don't seem to be able to find that now........or would it be out of date now?
Here's a thought: Is there a place where user-guides/manuals and their revisions are or can be posted?
Thanks in advance
Chiman
PS. Although I know nothing about coding, I am keen to be an active contributor (rather than just a 'taker'). For example, I would be pleased to become part of any testing process that might be going on, as I am reasonably good at creatively conceptualising, analysing and evaluating, so may have something to offer there.....(no apologies for the UK spelling - even though my editor is telling me it's wrong

).