would it not be better to just have a check to see if there is a primer open already, and if yes, then continue with primers bellow that primers rate?
i know that there should then also be a check if an existing primer is bigger than the normal trades
(because if we come back to an old primer that now is equal or smaller than the normal trade size we can ignore the old primer, and need to only look at the 0.06% again)
That part is not easy to program…
Re
D
then its a challenge 
go go go
If you have 1000 units sell and 13000 units buy then you have a drawdown of 12000 units.
Then you primers should be 5000 units because two primers shall be less and tree primers shall be more.
If the primers gets started then it shall continue putting primers downwards.
Then if one of the trailing stops (50 pips) hits on the first primer. Then it should start making buy trades again.
And if it raise another 100 pips then it should make normal sell trades till it reach the primer zone again. if the drawdown then is below 0,04% then it should close the primer as a normal trade and keep making normal trades until the drawdown is 0,06% again.
I know that it isn’t easy. But if it gets to work, it will be awsome
Initially I was just trying to understand CC’s code, but now I’m attempting to find solutions to problems on my own, but with little success. Can’t even get the drawdown calculation to mesh with the Excel sheet (which I just figured out after spending two days building functionality around it and wondering why everything else didn’t work…)
Re
D
Now that is very help. With a specific level of 0.04% to turn primers off I have something to test against. I’ve been using “one primer only” in order to have some way of testing, but I assume you can get into a situation where you need f.ex. short primers even though you have one open, but at a much lower level.
Will try to implement that once I figure about what’s wrong with my drawdown function.
Re
D
hehe, if i remember correct, there was a function to tag trades right?
so it should be possible to tag primers, and then look for that tag?
i didnt think it would be easy, but doable… that said, if webzones idea is easier to code, then there is no reason for taking the hard solution 
I just found a new problem. From time to time pending orders will trigger after general lot size has been increased. Wouldn’t it be correct to test for lot size on pending orders versus a global “current lot size” variable, and then reset pending orders with the new lot size if it is smaller (by the way I would probably just deleted it and add a new one)?
On the other hand I assume that also increasing lot sizes for any open orders will not be a good idea…
Re
D
yes, if there is pending orders smaller than the current lot size they should be changed to current lot size (or replaced, whatever is easiest) 
I couldn’t help my self starting to study a little. And i found this code to count buy and sell trades. that could be used to deside if the rate is going up or down, by making a comparing with
if countOrdersBuy<countOrdersSell return trend down, else return trend up.
But I can’t find a suitable code to do that (maybe I don’t look anough)
Can some one help me out a bit here?
//±-----------------------------------------------------------------+
//| CountOpenOrders function |
//±-----------------------------------------------------------------+
double GetInformation(int parameter)
{
int countOrdersBuy = 0;
int countOrdersSell = 0;
int total = OrdersTotal();
for(int i=total-1; i>=0; i–)
{
if(OrderSelect(i, SELECT_BY_POS))
{
if(OrderSymbol()==Symbol() && OrderMagicNumber()==MagicNumber)
{
if(OrderType()==OP_BUY )
{
switch(parameter)
{
case 0: countOrdersBuy++ ; break;
case 1: countOrdersBuy++ ; break;
}
}
if(OrderType()==OP_SELL)
{
switch(parameter)
{
case 0: countOrdersSell++; break;
case -1: countOrdersSell++; break;
}
}
}
}
}
switch(parameter)
{
case 0: return(countOrdersBuy + countOrdersSell);
case 1: return(countOrdersBuy );
case -1: return(countOrdersSell);
}
}
//±-----------------------------------------------------------------+
//| Calculate trend function |
//±-----------------------------------------------------------------+
The code should maybe be here.
I did allso find this to calculate the lots.
But I need a part to calculate the drawdown from it.
Here is the code.
//±-----------------------------------------------------------------+
//| BuyLotsCount function |
//±-----------------------------------------------------------------+
double BuyLotsCount()
{
int lcnt;
double BCount;
int ltotal = OrdersTotal();
for(lcnt=ltotal-1; lcnt >= 0; lcnt–)
{
OrderSelect(lcnt, SELECT_BY_POS, MODE_TRADES);
if(OrderType()==OP_BUY && OrderSymbol()==Symbol())
BCount = BCount + OrderLots();
}
return(BCount);
}
//±-----------------------------------------------------------------+
//| SellLotsCount function |
//±-----------------------------------------------------------------+
double SellLotsCount()
{
int lcnt;
double SCount;
int ltotal = OrdersTotal();
for(lcnt=ltotal-1; lcnt >= 0; lcnt–)
{
OrderSelect(lcnt, SELECT_BY_POS, MODE_TRADES);
if(OrderType()==OP_SELL && OrderSymbol()==Symbol())
SCount = SCount + OrderLots();
}
return(SCount);
}
//±-----------------------------------------------------------------+
//| Calculate drawdown function |
//±-----------------------------------------------------------------+
The drawdown calculation function should might be here :33:
I’ve got most of the pieces in place. Primers don’t always open properly, but I think that’s mostly due to limitations in the strategy tester (rate has moved too far in M1 tick to trigger, see order 431+433+434 as examples). I’m considering renting space on a 99% MT4 test server, but I’m not quite there yet. Deleting offside primers and restricting regular trades inside primer range is still missing, but I’ll take a crack at that tomorrow. Hopefully this is why the channel eventually blows up, but it would be nice if someone can look through the data and see if the underlying system interpretation is correct. I’ve been pretty liberal in explaining the code that I’ve added to CC’s.
I could never figure out CC’s lot calculations, so I made my own hack using BalanceRiskLeverage. So on my demo account of x100 leverage, I use 2.000$ balance and RiskPercentage=0.5 (in the code RiskPercentage is divided by 100 for the actual calculation as 0.5 just feels like a more natural way of saying “0.5% of balance per trade” than 0.005)
Please remember that I’m not a programmer and I have not even tried to make this work on other symbols than xxx/USD.
Re
D
Maybe CC could look trough it, he seems to be a skilled programmer
Logic question:
- If I have a short primer at 1.5000, then no regular short trades should be placed BELOW 1.5000 while primer exists.
- If I have a short primer at 1.5000, then regular short trades should still be place ABOVE 1.5000
Re
D
Then there shouldn’t be placed normal trades below 1.5000
WebZone, can you be more specific? The EA runs out of money and I thinks it’s because primers are too big. Is there an actual calculaton for this?
With 275.000 - 191.000 = 84.000 (balance is 12.741), there’s a lot of wrigleroom between 84.000/2=42.000 and 84.000/3=28.000. Should I go for 42.000-1 (rounded down to 0.41 lots) or aim for the middle with 35.000? Or should 3*primer equal difference plus 0.01?
Re
D
Guys,
Its nice to see good discussions going on. Sorry I was out for the last few days.
Here is my first version of the EA using equity drops. I will explain below briefly how it is functioning. Try it out and give suggestions. please go through results carefully and spot possibilities of optimizing it. I had a lot of trouble to get it work, hence the delay. I finished it yesterday and am also testing it now. Due to the high spreads on weekends in my account, the trials are not precise as will be on a weekday.
Kent/Dennis - I have used similar codes for trying to figure out the buy counts and the orderlots of buys and sells.
Parameters:
Lots: Leave it at zero for the EA to calculate auto lot sizes on account balance,
Percent: Risk percent based on which lot size will be calculated.
TP: take profit
Dist: Distance in pips after which opposite pending order will be placed. Based on kent’s explanation.
UseSL & SL: Leave it at false and 0.
UseAutoprimer: LEave it at true. Currently the EA will not work if set to false.
PrimerStep, PrimerTP, PrimerLockin: same as last revision.
Maxdrawdownpercent: Primers will be placed once this percent of drawdown is seen (explained in detail below)
Recoverypercent: Primers will be stopped and normal trades resumed once equity reaches back to level appreciated (explained in detail below)
Slip: Slippage
Explanation:
- Lets say you start with 3000$ balance. Normal trades will be placed first.
- Everytime equity reaches a new high, it is updated in a global variable.
- Depending on the max drawdown percent (lets say 20%), the EA will check if equity has dropped 20% down from its present equity high. Eg. Lets say equity went up to 3300 but then fell below 2640$ (20% drawdown), primers will be asked to be set.
- To start setting primers - the EA first checks how many buys and sells are opened. My understanding as I stated in one of the previous posts is that equity will drop rapidly when there is a one sided movement. hence there should either be one buy and many sells or one sell and many longs. If there are many buys then sell primers are introduced and viceversa if there are numerous shorts. (this logic might not be perfect. I need all your advice after you test out this version). The EA will automatically calculate the primerlot size based on Kent’s explanation in one of the posts. {(OpenBuys-OpenSells)/3}
- The primers will be stopped when equity rises back to an acceptable level close to Equity high, which is defined by Recovery Percent. (Optimal values of recovery percent has to be found). If this logic is not good but some other logic is required, let me know.
- Normal trades will be placed once primers are off.
- primers will again start if point 3 is satisfied.
Advice required:
- If maxdrawdown logic from equity high is a good method. I have not tried too hard to figure to how to calculate 0.06% equity drop per pip, but it will not be easy.
- If maxdrawdown logic is acceptable, then how much of drawdown will be close to levels of 0.06% equity drop.
- Is the logic to stop primers acceptable?
- Are the primer lots being calculated properly?
P.S. The current version is not very clean as I have been using many alerts for troubleshooting purposes. If any of it bothers just deactivate it using “//” in front of the code line.
Greenland strategy rev 2-0.zip (4.09 KB)
I’ve tried to implement all documented aspects of the Greenlander system. So far I have:
- Automatic placement of buy and sell orders every 50 pips
- Automatic lot increases based on AccountBalance and RiskPercentage
- Calculate drawdown and add primers at drawdown > 0.06%. Stop when < 0.04%.
- Primer lot size is (largest-smallest)/3
- Update primers with trailing stop, and add new one at +30pips
- Stop regular trades from being placed in primer ranges, if same direction as primer
- Replace pending orders after automatic lot increase
- Remove pending orders outside of range
Is there more to the system? What about money management?
I still think primers come in too often and too heavy, and I expect they are the reason why free margin bottoms out. I would need to find some way of combining log data to include margin data in order to get a clearer view, maybe as Excel charts. Probably the primers fight each other and thereby increase the amount of units too quickly, I don’t know yet.
Re
D
first try with rev 2-0 gave me stop-out after 2 month, so i changed the MaxDrawdownPercent to 40 and got the following 7 month run
2 observations so far, it seems that we still need some sort of correction when returning to an area where there is only trades open with small lot sizes (if we now run with 0.07 and return to an area where we still have alot of 0.01 trades open, we somehow need to get bigger lot sizes at this area)
and second, if you look at the drop at the end of my test, there doesnt seem to be primers opened, even though the equaty drops to a flatline
i cant open your pdf file