10.3 SCALPER/RANGE TRADE SYSTEM

[babalu4u]

Hi to all,

this indicator will plot your manual trades on the charts....

Happy Trading

[Faramirsen]

I very much understand the problem, it is why for years I never traded with SL and TP or they were based on programs running from my computer. Scalping however, requires tighter SL or you never will make money. I am sure the Jump EA will eventually be an all inclusive EA. Steve's MPTM has become so big with add ons it is really time for a simpler MPTM designed just for this system. We will upgrade it with each adjustment. I really want to finalize the trading system first and then add the bells and whistles. I am sure you appreciate seeing how a trading system is put together and the amount of time and multiple parties it takes to get one working.
For example Don's work on trying to get the Pivot and Open to GMT time so we have a universal system. That takes tremendous work and patience. Once he gets that to work then he has to make sure it uses as little CPU as possible so everyone can use it instead of just the people with super computers. I have a dual core with 8 ram. If it slows down or freezes my computer then I know others cant use it. So these things do take time. But hidden sl tp etc. will end up in the final product but other things need to take place first.

Thx. I understand that and it's logical. Great work of you all! Very nice forum here.

I just saw that Steve's MPTM has a hidden SL function - so at least for the initial start people can use that. But obviously after that the jumping EA takes over which would mean the SL is then communicated to the criminals. The MPTM has also a jumping SL function (including hidden function) so maybe that could be a start for a smart coder after everything is fine tuned

[spyderman]

Found a mistake in the writing: #4 should say if 4. White < Green < #3 Play for Big Sell Move Sorry about that.

Hey Bob,

How was the Calzone. Hope you had time for a nice nap after the A.Y.C.E.

Looking at the template, was wondering if #8 should read:
"Pink and Gold lines = Market is Ranging = Smaller Profits" rather than
"Pink and Yellow lines = Market is Ranging = Smaller Profits"

No big deal, just wanted to make sure I wasn't missing something.

[babalu4u]

Hi disbellj,

my be this function will help you for GMT time...

Code: Select all

#import "kernel32.dll"
int  GetTimeZoneInformation(int& TZInfoArray[]);
#import

#define TIME_ZONE_ID_UNKNOWN   0
#define TIME_ZONE_ID_STANDARD  1
#define TIME_ZONE_ID_DAYLIGHT  2

int TZInfoArray[43];	

datetime TimeGMT() 
   {//modified by euclid
	int ret = GetTimeZoneInformation(TZInfoArray);
	int bias = TZInfoArray[0];
	if (ret == TIME_ZONE_ID_STANDARD) bias+=TZInfoArray[21];
	if (ret == TIME_ZONE_ID_DAYLIGHT) bias+=TZInfoArray[42];
	return( TimeLocal() + bias * 60 );
   }

[spyderman]

So, I want to be sure I understand the trade EA's.

Both will only take trade (buy example) if price crosses the DO from below.

The 5.1 also requires a cross (from below) of the 5.1 ma.

Is that correct?

Is so then if price is on the wrong side of the DO, we can still place the EA and then it would take a trade upon a retracement and recross?

Thanks for clarification.

[disbellj]

Hey ya'll,

Been enjoying needed downtime after updating the indicator.

Just wanted to give notes on my thoughts:

I have the code to shift to GMT (0:00 is the target). I also have the code to shift to Eastern thanks to George (17:00 is the target). Let's just say that I must get the code together, but myself together first LOL.

As far as getting weekly and monthly, I figure Baluda's code for adding sunday to monday is simple, elegant, and is great for fixing the weekly pivots to be the same between criminals. I don't know about Monthly, but I guess I'm taking those correctness for granted.

What bothers me is H4 and D1 charts/opens/pivots, etc. I can't change the D1 or H4 charts on criminals without using a period converter to do so. Since this is the case, if working with criminal H4 candles and not applying a period converter, then I can only do a bsearch (I think it's called, never used it) to find the nearest criminal candle to 17:00 ET when on H4.

Now when using H1, it looks like since Cowboy IBFX and others may start later than 17:00, then I also must account for that in code, using some code (probably bsearch or iBarShift) to shift to the bar nearest to 17:00 ET.

I wish it were perfect, but it's not (I'm not that great of a coder). However, since Bob is obviously willing to adjust his strategies to try and simplify and bring together, I would ask him to see if he can use only H1 charts, since the shift is gonna be easier and more precise between us all if not using H4. Then W1 and MN1 pivots are already taken care of, and D1 open and pivot can be based off 17:00 ET all year.

To me or code, it really doesn't matter if we shift to 17:00 ET/21:00 GMT summer/22:00 GMT winter, or or 00:00 GMT. The code I plan to write basically after getting Eastern date AND time (or GMT date AND time, both of which I have code to do already), I say if TimeHour(Time) (hour of broker's time) + EasternOffset is equal to 17. That's easy. But what about if the candle is not there? We must shift it, and frankly my mind is just not working right now well. Sorry.

Just my 2 cents.

Kindest regards,

Don

[disbellj]

That is a lot shorter code than I'm using LOL. But I would NEVER base ANY time setting using TimeLocal. Never. All it takes is for user's time to be off and it throws everything off. Thanks for showing it though. I'm sure someone can use it, and probably get rid of having to use local time.

The length of my code is not the problem and making the indicator slow down. The slowdown is simple to get rid of: Don't call anything more often than you have to. I have either been calling to get correct GMT offset either once every tick or once every minute. Both are obviously too slow. So I guess I'd either use PERIOD_H1 or PERIOD_D1 to update EasternOffset (or GMTOffset if user chose to do that, for comparison). If you look for LastVolume in start function, and find iVolume(Symbol(),PERIOD_M1,0) and change that TWICE in start function (top and bottom of start function), then save and compare the speed differences, maybe the users can let me know with what you already have, how often it should be updated. Note: If user puts on during weekend, and update is only allowed once per day, EasternOffset and therefore opens and pivots will be incorrect for first day of operation. This is why I didn't want to wait a whole day to update this information.

Everybody's got a 00:00 GMT candle, but not everyone has a 17:00 Eastern candle, which has been the difficulty in my mind how I'm going to implement. Some days my mind works very well, other days not well at all.

Kindest regards,

Don

Hi disbellj,

my be this function will help you for GMT time...

Code: Select all

#import "kernel32.dll"
int  GetTimeZoneInformation(int& TZInfoArray[]);
#import

#define TIME_ZONE_ID_UNKNOWN   0
#define TIME_ZONE_ID_STANDARD  1
#define TIME_ZONE_ID_DAYLIGHT  2

int TZInfoArray[43];	

datetime TimeGMT() 
   {//modified by euclid
	int ret = GetTimeZoneInformation(TZInfoArray);
	int bias = TZInfoArray[0];
	if (ret == TIME_ZONE_ID_STANDARD) bias+=TZInfoArray[21];
	if (ret == TIME_ZONE_ID_DAYLIGHT) bias+=TZInfoArray[42];
	return( TimeLocal() + bias * 60 );
   }

[disbellj]

Here's a daily open indicator that I updated today to point to Eastern 17:00 as day beginning.

It has ibarshift set to false, so if the criminal does not have the equivalent of the 17:00 bar on a certain day (sunday or H4 chart not having specific time looking for) then the next bar in time should be used.

I gave this code that should be able to be implemented easier, since both function to get EasternOffset and GMTOffset are both in here and give info on chart for both and functions anyone can use to get the offset they need, even though code in start uses EasternOffset.

Any coder is welcome to improve and/or update another indicator with these functions. I have it set to updating as paragraph below says, so shouldn't be slow after first couple of minutes of week, because the offset used is locked in and not looked for again. Once StartBar code fixed for open, can be used in pivots also.

Implemented a function in start that checks the broker time, and then checks it again in a minute, and if it's different in a minute, then that means the market is going, then I can get EasternOffset, and set WeekEndMode to True, and lock in AutoForexDayOffset as EasternOffset. This way, it checks the criminals time to see if broker is going, and then only has to get offset (go to the web) once.

Note: Even though I implemented as much as I did today, StartBar is still wrong it looks like (I set WeekEndMode to true and on FXDD set AutoForexDayOffset = -7 to get what I think is MB Trading/Eastern time).

Kindest regards,

Don

[atharmian]

Don,

I believe that you are spending too much time on the crim time offset issue Your brain cycles are much better spent on the actual work as evidenced by your fine work to date.

I am confused here. But why not let the user put in their own offset in the main Empty4 menu, with 0 GMT as default, as opposed to trying to auto-detect it and also put in a DST ON true/false option. Adding Sunday candles to Monday should also be a default.

This way it is up to the user to set his/her own candles synchronized. Regardless you will still be blamed and flamed for the offset going wrong with a given user- those bugs will keep coming up !

One more thing- I had an auto-update today by Empty4 upgrading my Build 438 to 445. This is bound to create new issues, so IMHO let people butt heads with the sync issue and do their own trial and error.

Regards,
Athar.

Here's a daily open indicator that I updated today to point to Eastern 17:00 as day beginning.

It has ibarshift set to false, so if the criminal does not have the equivalent of the 17:00 bar on a certain day (sunday or H4 chart not having specific time looking for) then the next bar in time should be used.

I gave this code that should be able to be implemented easier, since both function to get EasternOffset and GMTOffset are both in here and give info on chart for both and functions anyone can use to get the offset they need, even though code in start uses EasternOffset.

Any coder is welcome to improve and/or update another indicator with these functions. I have it set to updating as paragraph below says, so shouldn't be slow after first couple of minutes of week, because the offset used is locked in and not looked for again. Once StartBar code fixed for open, can be used in pivots also.

Implemented a function in start that checks the criminal time, and then checks it again in a minute, and if it's different in a minute, then that means the market is going, then I can get EasternOffset, and set WeekEndMode to True, and lock in AutoForexDayOffset as EasternOffset. This way, it checks the criminals time to see if criminal is going, and then only has to get offset (go to the web) once.

Note: Even though I implemented as much as I did today, StartBar is still wrong it looks like (I set WeekEndMode to true and on FXDD set AutoForexDayOffset = -7 to get what I think is MB Trading/Eastern time).

Kindest regards,

Don

[nanningbob]

Found a mistake in the writing: #4 should say if 4. White < Green < #3 Play for Big Sell Move Sorry about that.

Hey Bob,

How was the Calzone. Hope you had time for a nice nap after the A.Y.C.E.

Looking at the template, was wondering if #8 should read:
"Pink and Gold lines = Market is Ranging = Smaller Profits" rather than
"Pink and Yellow lines = Market is Ranging = Smaller Profits"

No big deal, just wanted to make sure I wasn't missing something.

#8 reads correctly When green and white are between pink and yellow lines market is ranging.
OR when the daily open and the daily pivot are between the Weekly Pivot and the Monthly pivot you have a ranging period or price action is switching from one trend to the opposite trend. Usually during this period of time you have a battle between bears and bulls and the moves will be smaller and price can quickly retrace back to its median. Price action moving beyond S1/R1 will be rare.