Welcome to Forex-TSD!, one of the largest Forex forums worldwide, where you will be able to find the most complete and reliable Forex information imaginable.
From the list below, select the forum that you want to visit and register to post, as many times you want. It’s absolutely free. Click here for registering on Forex-TSD.
Exclusive Forum
The Exclusive Forum is the only paid section. Once you subscribe, you will get free access to real cutting-edge Trading Systems (automated and not), Indicators, Signals, Articles, etc., that will help and guide you, in ways that you could only imagine, with your Forex trading.
Elite Section
Get access to private discussions, specialized support, indicators and trading systems reported every week.
Advanced Elite Section
For professional traders, trading system developers and any other member who may need to use and/or convert, the most cutting-edge exclusive indicators and trading systems for MT4 and MT5.
Against the fast moving markets like news time, an idea I had sucessfully tried is just to have a fixed minimum time between two entries. The value of the next entry is not given by pipstep relative to the previous entry, but well by pipstep relative to the rate X minutes after the previous entry. By this way, the pipstep becomes dynamic following the instantaneous volatility.
Added time filter as interval besides pipstep. Settings is in milliseconds.
Added time filter as interval besides pipstep. Settings is in milliseconds.
Regards
David
David,
I think it should be better to use something like this:
PHP Code:
if (myOrderType==1 && ContinueOpening && TimeCurrent() > LastOpenTime + SleepTime)
with SleepTime in seconds.
The reasons to not use the Sleep() function are two: first, Sleep() does not work in backtester; and second, it's not a good idea to stop during this time the running of other parts of the EA like stops trailing.
Anyway, the instruction
PHP Code:
if(Use_time_interval){Sleep(SleepTime);}
is not at the right place now, it should be in the OrderSend() block.
I really appreciate your efforts to make this project live up to its potential, this discussion has occurred whilst I have been away from my PC and I have not had chance to discuss it with David. I have no coding skills but usually bounce ideas with David and when I arrive back home will make contact again via Yahoo Messenger.
I had come to the conclusion that the ultimate big loss was inevitable but you have rekindled my enthusiasm and look forward to further developments. You can count on my support with forward testing. I have an interest in its compatability with IBFX Mini and would like to be able to test on that platform.
I've got the code updated per the suggestions above but in testing it is not very successful.
I tried it with Davids time delay and it does not work in backtesting, may work fine in forward testing but there is still an inherent problem I'll mention in a minute.
Michel, I tried your suggestion as well which basically fixes the backtesting issue in the code David provided, but the problem I'm running into is we are basically creating a fixed value for delay time between the last order. This is not good for the less volatile times where the orders still may be close together but forced delay time misses trades.
I'm still trying to think of the best way to do this but basically the time between entries cannot be fixed. Or if it is fixed it should only apply to highly volatile times when more than one/two trades could occur per candle.
Still thinking...Suggestions?
Good to see you back in here yeoeleven, I think we can make this work, your forward testing will be a great help
Here is the code as updated with all of davidke20, Michel, and my additions. I've presently commented out the time delay stuff until we
decide on the best way to do this. In the meantime here is the code.
I cleaned up a lot of stuff and shortened some things as well.
I also added an extra function at the end that shall work as damage control.
Depending on the entry type in the entryDirection() function I added another auditTrade() function that checks to see if it has
substantially diverged from the entry indicator.
If we went long according to the entryDirection()function, each iteration the auditTrade()function checks the current indicator and if it is at a certain level
which we decide it will close all long orders at market price. This would be the opposite if we started short.
The next iteration there will be no open order and it will look for orders again according to the entryDirection() function.
Basically this is the same 10points3 but with the power to buy and close positions according to indicators instead of blind faith.
Sorry if this is confusing but its hard to translate code into word. I just wanted to provide you guys with the shell
because we can add as many criteria to the entryDirection() and auditTrade() functions as we want.
With this new code we could specify multiple different entry and exit criteria.
Lets keep this going.
EDIT: Forgot to add the attachment , got some things to do today, will do some brainstorming and check back here later.
EDIT2: Right now the entry and exit criteria is not very intelligent. Basically, if the RSI is below 50 and the current RSI is less than the RSI of the last bar, go short. If the RSI is above 50 and the current RSI is greater than the RSI of the last bar, go long. It then closes if profit is made or if RSI comes back to a certain number for protection in direction change.
Right now this is very static. If we want to make this work we will have to make it more dynamic. Here is why. If we were going long and the RSI crossed up past 50, no problem, we got in long and may close profit quick. Fine, now the RSI may be at 62 and rising. We get in for another long entry, we work our way up using martingale, but now we are at a greater risk because we are farther away from our auditTrade() close. Remember, it is presently static at 49. So if we got in going past 50 no problem, but now we are in at 62 and that is much farther from our protection of 49. We'll get hit harder the farther we are from our protection. This will need to adjust according to the entry. That is some of my future development thoughts besides getting the code to not buy more than twice per candle as mentioned previously.
...but the problem I'm running into is we are basically creating a fixed value for delay time between the last order. This is not good for the less volatile times where the orders still may be close together but forced delay time misses trades.
I'm still trying to think of the best way to do this but basically the time between entries cannot be fixed. Or if it is fixed it should only apply to highly volatile times when more than one/two trades could occur per candle.
Sorry for my bad english, but I do not mean to have a fixed time interval between entries. What I mean is this: assuming your pipstep is 10 and your time interval is 3 min, if some sell order is opened at time t, check the bid at time t+3*60 and add 10 pips to the value : this will be the entry level for the next sell order.
In slow market, the result will be more or less equivalent to the standard entry (last price + 10 pips); but in fast market, if the price goes up 15 pips during those 3 minutes, then your real pipstep will be 15 + 10.
All this works very well with limit orders but can be implemented with instant execution orders too.
Of course, you do not open another sell during those 3 minutes but you still have to take care of the other opened orders.
LOL, well it looks like most of the changes we've made thus far have updated our 10points3 to DLMv1.4-MQL4Contest.mq4 available from the author of the original 10points3 elcactus.com
I'm abandoning our original updated 10points3v0.03 and I'm now updating the DLMv1.4 discussed above. It seems to be cleaner code. I'm going to work with updating it.
Here is the code as updated with all of davidke20, Michel, and my additions. I've presently commented out the time delay stuff until we
decide on the best way to do this. In the meantime here is the code.
I cleaned up a lot of stuff and shortened some things as well.
I also added an extra function at the end that shall work as damage control.
Depending on the entry type in the entryDirection() function I added another auditTrade() function that checks to see if it has
substantially diverged from the entry indicator.
If we went long according to the entryDirection()function, each iteration the auditTrade()function checks the current indicator and if it is at a certain level
which we decide it will close all long orders at market price. This would be the opposite if we started short.
The next iteration there will be no open order and it will look for orders again according to the entryDirection() function.
Basically this is the same 10points3 but with the power to buy and close positions according to indicators instead of blind faith.
Sorry if this is confusing but its hard to translate code into word. I just wanted to provide you guys with the shell
because we can add as many criteria to the entryDirection() and auditTrade() functions as we want.
With this new code we could specify multiple different entry and exit criteria.
Lets keep this going.
EDIT: Forgot to add the attachment , got some things to do today, will do some brainstorming and check back here later.
EDIT2: Right now the entry and exit criteria is not very intelligent. Basically, if the RSI is below 50 and the current RSI is less than the RSI of the last bar, go short. If the RSI is above 50 and the current RSI is greater than the RSI of the last bar, go long. It then closes if profit is made or if RSI comes back to a certain number for protection in direction change.
Right now this is very static. If we want to make this work we will have to make it more dynamic. Here is why. If we were going long and the RSI crossed up past 50, no problem, we got in long and may close profit quick. Fine, now the RSI may be at 62 and rising. We get in for another long entry, we work our way up using martingale, but now we are at a greater risk because we are farther away from our auditTrade() close. Remember, it is presently static at 49. So if we got in going past 50 no problem, but now we are in at 62 and that is much farther from our protection of 49. We'll get hit harder the farther we are from our protection. This will need to adjust according to the entry. That is some of my future development thoughts besides getting the code to not buy more than twice per candle as mentioned previously.
, got some things to do today, will do some brainstorming and check back here later.
good work mr neta1o
Linear Mode
