Fractals4 -- new Fractals from Fx H0pe

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

one thing that I observed was the 2 blue lines that shows high and low for the High Volatility breakout mode. I took a note on what it was before and after I restarted the mt4 application and guess what, it was very different.

I've been looking at the code and I've found that the level of the blue lines use the spread value in its calculations. Here is the code in CalculateBreakOutHi() that takes the spread:

double ld_20 = 5.0 * pointValue + gd_468;

gd_468 = Ask - Bid, i.e. spread value in quote currency.

 

So if the spread changes, the levels can change.

[eusanka]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Ok, but this value was around 100pips in differance and I doubt that is due to the spread...

[copycat]

Re: Fractals4 -- new Fractals from Fx H0pe

 

It will still generate a new FXT file, just not use the file it generated.

 

Assuming the backtesting process begins with a sequence of steps that can be described as follows:

1. fd = fopen(symbol+period+"_0.fxt","w+");

2. fwrite(fd, stuff);

3. fclose(fd);

4. fd = fopen(symbol+period+"_0.fxt","r");

5. start_backtesting(fd)

 

Since we gonna use our custom .fxt file, can the "proposed loader" skip the step 1 to 3?

 

 

There is no such thing as a recovery trade in this EA. There are two volatility breakout strategies. Maybe one is better than the other, so you could choose to only use the better one.

 

Thanks for the explanation, I have to be honest that I didn't even bother to read the source code, just a quick back test of your customized version and the result turn me off totally.

 

Cheers.

[tantra]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Guys... i have loaded this EA onto my platform.. and I have two problems: firstly, everytime i run a backtest, it closes down my metatrader platform. Secondly, when i upload the EA it gives a message saying that 'Fractal EA is about to start on the account' and the closes down my metatrader!

 

I am using the Fractals4-908b_1.02 version on the eurusd H4 chart.

 

CAn anyone help please? I ahve uploaded all indicators into the relevant places, and the dll files in their places too.

 

Thanks in advance

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I have to be honest that I didn't even bother to read the source code, just a quick back test of your customized version and the result turn me off totally.

Did you put the correct UTC offset value of the broker's data in the settings?

How did your backtest results compare with the ones I and birt have shown in this thread?

 

The main reason why I've been focusing on this EA is because of good official forward test results as well as backtest results, plus the good technical detail they present on their web site.

The work I've been doing is really to verify the backtest results by doing my own tests over different sets of data, and at the same time understand what's going on inside to educate myself; the knowledge I gain can be useful in future.

 

Though if at any time in the future the forward tests start looking bad, I will probably shift my attention to other EAs whose forward tests look good at that time. It's like anything in life really, e.g. girls.

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Guys... i have loaded this EA onto my platform.. and I have two problems: firstly, everytime i run a backtest, it closes down my metatrader platform. Secondly, when i upload the EA it gives a message saying that 'Fractal EA is about to start on the account' and the closes down my metatrader!

I get problems too, and it may be related to their new DLLs and the parameter values. I was especially getting the error when I used preset files.

 

What seems to work for me is before starting a backtest, I open the parameters window, edit any of the values, press Ok, open it again and put the proper value back in.

[saendee]

Re: Fractals4 -- new Fractals from Fx H0pe

 

:)>- this version does not trade live **but thats good because last week it broke even forward demo on go trader settings risk 0.1 --aggressive 1 this week so far same setting no good 6 trades 4 losses 2 win + 2 open losing :shand: ENJOY

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

:)>- this version does not trade live

Did you actually try it on a live account? It's working fine in a demo account.

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

That will be great, it drives me nuts that when it re-generates the .fxt file everytime when I backtest. I still fail to understand why MQ took away the checkbox that allowed us to use the last generated .fxt files.

 

I ended up making something along the lines of the old recalculate checkbox, I'll explain more when I make it available.

 

In the meantime, the gain capital data totally sucks, their ticks are completely messed up, sometimes in a seemingly random order, it takes a shitload of work putting it together correctly.

[saendee]

Re: Fractals4 -- new Fractals from Fx H0pe

 

^:)^ live it does not trade on axisodl have taken it of live account using electron eu & manual renko bars :-bd ENJOY

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I ended up making something along the lines of the old recalculate checkbox, I'll explain more when I make it available.

 

In the meantime, the gain capital data totally sucks, their ticks are completely messed up, sometimes in a seemingly random order, it takes a shitload of work putting it together correctly.

 

Ran into even more problems...

 

First, the FXT format has been updated while the old FXTHeader.mqh hasn't, so I had to figure out the changes.

 

Second, the tick data from Gain Capital is really bad. There are tons of missing ticks... I set a filter that alerts me of periods with no tick for 5 minutes - for EURUSD 2009.03.08 - 2009.08.21 (so for just 5 months), the number of alerts was over 5500. This was *after* I sorted the files because the ticks are not necessarily in chronological order, e.g. you will frequently see ticks from the previous week randomly mixed with the ticks from the current week.

 

The resulting quality for that period was 77% which pretty much means that we need good tick data.

 

On the bright side, Fractals did perform pretty nice on the tick data, a lot better than on the interpolated data. I'll attach the graph here, but I don't think it makes any sense to post the whole log due to the low quality of the data.

 

TesterGraph.gif[/attachment:28zg1hzw]

 

Edit: the 77% quality was due to other factors, not missing ticks (creating the FXT when offline didn't fill in some very important header fields). After creating the FXT online, the quality was 99% but the graph was identical, see below. Still, this doesn't excuse the extremely poor data quality.

 

TesterGraph.gif[/attachment:28zg1hzw]

[copycat]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Good work birt. Now the equity curve looks more promising with your tick data. =D> =D>

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Here are the UTC offsets for the FXDD data:

From					To						FXDD UTC offset
2004-10-31 01:00	2005-04-03 02:00	2              
2005-04-03 03:00	2005-10-30 02:00	3              
2005-10-30 01:00	2006-04-02 02:00	2              
2006-04-02 03:00	2006-10-29 02:00	3              
2006-10-29 01:00	2007-04-11 02:00	2              
2007-04-11 03:00	2007-11-04 02:00	3              
2007-11-04 01:00	2008-03-09 02:00	2              
2008-03-09 03:00	2008-11-02 02:00	3              
2008-11-02 01:00	2009-03-08 02:00	2              
2009-03-08 03:00	2009-11-01 02:00	3              
2009-11-01 01:00	2010-03-14 02:00	2              
2010-03-14 03:00	2010-11-07 02:00	3              
2010-11-07 01:00	2011-03-13 02:00	2              
2011-03-13 03:00	2011-11-06 02:00	3              

 

How sure are you of this? I'm asking because I used these offsets as a reference for calculating the GMT offset of the Gain Capital tick data and if I'm not mistaken, FXDD doesn't switch to summer time (my result when using the FXDD data to check was that Gain Capital had GMT-6 / GMT-4 and I believe it's -5/-4, but that could only work if there's no DST on FXDD and it's GMT+3 all the time). Would it be too much if I asked you to check it somehow?

 

Good work birt. Now the equity curve looks more promising with your tick data. =D> =D>

 

Unfortunately, on the previous interval it looks a lot worse. See graph below. Also, that's with GMT-4, even though I believe GMT-5 is correct (-5 yields even worse results).

[mike99]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Backtests using Every Tick over FXDD trade server data looks very different to backtests over MetaQuotes data downloaded through an Alpari UK terminal.

 

hi, hyperdimension,

 

I think you are really an expert of MT4. Could you please give me some suggestion where I should download data from to do backtestings? Currently, I am using FXDD M1 data. But FXDD data is always not up to date. I think it does not proive data for the most recent three months.

 

Thanks a lot.

 

Mike

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I believe it's -5/-4

Yes I think you are correct.

 

I've just visually compared a sample of one hour bars at peaks/troughs/large bars and around US daylight savings switch times (2009-03-08 03:00, 2008-11-02 01:00) with Interbank FX's data, which is definitely UTC time.

 

Edit: I've just also compared InterbankFX data with FXDD Web data. It appears that the switch dates/times that I was using for FXDD data are correct, and that Gain's data switches its UTC offset at the same time as US daylight savings, as does FXDD.

 

IB: 2009-06-30 14:00

Gain: 2009-06-30 10:00. UTC offset = -4

 

IB: 2009-04-06 01:00

Gain: 2009-04-05 21:00. UTC offset = -4

FXDD: 2009-04-06 04:00. UTC offset = 3

 

IB: 2009-03-26 12:00

Gain: 2009-03-26 08:00. UTC offset = -4

FXDD: 2009-03-26 15:00. UTC offset = 3

 

IB: 2009-03-08 23:00

Gain: 2009-03-08 19:00. UTC offset = -4

FXDD: 2009-03-09 02:00. UTC offset = 3

 

IB: 2009-03-06 21:00

Gain: 2009-03-06 16:00. UTC offset = -5

FXDD: 2009-03-06 23:00. UTC offset = 2

 

IB: 2008-11-04 04:00

Gain: 2008-11-03 23:00. UTC offset = -5

FXDD: 2008-11-04 06:00. UTC offset = 2

 

IB: 2008-11-02 23:00

Gain: 2008-11-02 18:00. UTC offset = -5

FXDD: 2008-11-03 01:00. UTC offset = 2

 

IB: 2008-10-31 19:00

Gain: 2008-10-31 15:00. UTC offset = -4

FXDD: 2008-10-31 22:00. UTC offset = 3

 

IB: 2008-10-30 02:00

Gain: 2008-10-29 22:00. UTC offset = -4

FXDD: 2008-10-30 05:00. UTC offset = 3

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Unfortunately, on the previous interval it looks a lot worse. See graph below. Also, that's with GMT-4, even though I believe GMT-5 is correct (-5 yields even worse results).

In my post that shows my results with AlpariUK data (http://www.indo-investasi.com/viewtopic.php?p=49898#p49898), I showed the equity curve with UTC offset switching and another without. I wrote:

The result without the UTC offset switching looks much better. One reason could be that the EA was developed & optimized without any UTC offset switching, but I'm not sure.

I think I should have rewritten that line to:

The result without the UTC offset switching looks much better. One reason could be that the EA was developed & optimized on Alpari data with a constant UTC offset of 2, but I'm not sure.

 

Their Quick Start Guide does not mention daylight savings at all, as if to assume that UTC offset of all brokers are constant year-round:

 

If your MT4 broker server time based on GMT+2 like ALPARI UK, Then you need to enter 2 at Broker_OffsetHour.

 

This is some of the broker server time that we know:

INTERBANK-FX = GMT

ODL = GMT

TADAWUL FX = GMT+1

ALPARI = GMT+2

INSTA FOREX = GMT+2

FXDD = GMT+3

FX OPEN = GMT+3

Those UTC offsets for Alpari and FXDD are for daylight savings time, whereas for Tadawul they've stated the offset for non-daylight savings time.

 

I've never actually found an EA that does UTC offset switching, even though Alpari data is (or "was" - when their actual trade server data was still available from their web site) one of the most commonly used data for EA development/testing/optimization. I checked Alpari's data a while ago and it switches to UTC + 2 on 31 March and back to UTC + 1 on the last Sunday of October. So it's not exactly conformant to standard European daylight savings time (start on last Sunday in March and end on the last Sunday in October).

http://en.wikipedia.org/wiki/European_Summer_Time

 

In the US, daylight savings time starts on the second Sunday of March and it ends on the first Sunday of November. In the past it started later and ended earlier.

http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Could you please give me some suggestion where I should download data from to do backtestings? Currently, I am using FXDD M1 data. But FXDD data is always not up to date. I think it does not proive data for the most recent three months.

Here's what I wrote earlier in this thread about getting more recent trade server data from FXDD:

You could get more recent data by running the FXDD MetaTrader terminal, ensuring in the options that the number of bars in a chart is set to maximum, then opening the chart of a symbol in M1 timeframe and holding down the Home key. It will then get around the latest 2 months of data from the connected trade server (not from MetaQuotes) and you can see the new bars appear in the chart and also if you open the History Center. You can then export the latest data to a HST file for use in your offline backtesting terminal.

 

You could also do the same to get one minute bar data of trade servers of other brokers, which can be useful to test EAs over different brokers to see whether the EA would still work well over specific broker's price feeds. The price feeds can differ from broker to broker due to different brokers having different market making algorithms, filters and liquidity providers.

 

You also need to use the period converter script to create the higher time frame data from the M1 data.

 

It would be better though to use real tick data, and that's what birt has been working on, but at the moment there is no practical and straightforward way, as there are a number of obstacles:

• We still don't have access to good quality real tick data. Gain Capital's tick data can take a lot of work to fix its problems, and even after that, we can't do anything about the holes (sometimes week-long). Oanda's tick data would be great, but it requires an Oanda account with at least 1K USD in it.[/*:m:1krua0ew]
  
• The data needs to be converted correctly to the new FXT format. I've checked the new format and there are a number of differences from previous versions in both the header and data.[/*:m:1krua0ew]
  
• The tick data needs to be converted to HST format as well. I think the current HST format is the same as previous.[/*:m:1krua0ew]
  
• The MetaTrader platform requires patching to allow testing over custom tick data.[/*:m:1krua0ew]

 

I think once we do get through these obstacles, we'll be able to test all the various EAs around and compare our results with results of tests over other data e.g. MetaQuotes indicative data and FXDD trade server data. I think we'll see large differences just as we've seen so far with Fractals 4.

 

With Fractals 4, the results look quite good using Alpari UK MetaQuotes data (using a constant UTC offset of 2), and I wish it was true and accurate, but I have to remain skeptical based on my tests over the FXDD trade server data and birt's results with Gain's tick data.

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

We still don't have access to good quality real tick data. Gain Capital's tick data can take a lot of work to fix its problems, and even after that, we can't do anything about the holes (sometimes week-long). Oanda's tick data would be great, but it requires an Oanda account with at least 1K USD in it.

I've been doing some googling and it turns out Dukascopy has free tick data. The problem is that it's in files that span 1h and that it's handled by a swf. Even though it allows you to save as CSV, the data on their site is in a proprietary binary format. I decompiled the SWF, wrote a script to parse the bin files and one of these days I'll write some scripts to download, parse & merge the data. The few files I downloaded seem to be of extremely good quality (a few ticks per second, with bid/ask volume for each tick). This would go a lot faster if I wouldn't be very busy with work.

 

The data needs to be converted correctly to the new FXT format. I've checked the new format and there are a number of differences from previous versions in both the header and data.

I identified the differences and rewrote FXTHeader.mqh to account for them. Found an old version of a Gain Capital data converter and adapted it to work with build 225. I'll rewrite it to work with parsed Dukascopy files.

 

The tick data needs to be converted to HST format as well. I think the current HST format is the same as previous.

The HST header is slightly different. I wrote a simple MQL script to parse the Gain Capital tick data and write history files for each period automatically. It's slow as hell as the moment as it does a tick data parse for each period. I'll probably optimize it to do all the periods in a single parse for the DukasCopy data.

 

The MetaTrader platform requires patching to allow testing over custom tick data.

I've written a loader that uses any existing FXT file before generating. So, basically, if you're testing EURUSD M1, if your tester/history/ folder already has an existing EURUSD1_0.fxt, it will be used instead of creating a new one. It works pretty much as an unchecked "recalculate" in MT4 build <208, except that there's no way to recalculate it unless you manually delete the file (or load MT4 without the loader).

 

I think once we do get through these obstacles, we'll be able to test all the various EAs around and compare our results with results of tests over other data e.g. MetaQuotes indicative data and FXDD trade server data. I think we'll see large differences just as we've seen so far with Fractals 4.

 

With Fractals 4, the results look quite good using Alpari UK MetaQuotes data (using a constant UTC offset of 2), and I wish it was true and accurate, but I have to remain skeptical based on my tests over the FXDD trade server data and birt's results with Gain's tick data.

Once I get the Dukascopy stuff in order, I'll make a backtesting thread and post everything in there. Ultimately, due to the size of the data, I will probably end up making a torrent with the parsed data, after I get some help testing it.

 

I gave you kudos for the previous message although I intended to give you kudos for the GMT offset one ;) The Dukascopy data is hopefully GMT+0 around the year so we won't need to have headaches figuring out the offsets.

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I've been doing some googling and it turns out Dukascopy has free tick data.

I check the dukascopy site and found the page you were referring to. I'm not sure why I didn't know of it before; either it's a recent addition or my attention was focused on the CSV data export page, which is a different data set - indicative data from a number of different sources, which we don't want; we want data from a single trade server. I had a lot of problems downloading that data too, my IP address was banned and using anonymous proxies worked only for a while.

 

Anyway, I've already started downloading tick data for EURUSD using a download manager. The tick data starts from 2007-04-01 00:00:00. The files are in zip-compressed bin files. The data format is quite simple: TIME, ASK, BID, ASKVOL, BIDVOL, each of 8 bytes. The main problem I initially found was managing all the files. For EURUSD alone there are 21408 files, and they are not named uniquely. But I managed to find a way to batch rename them from something like "23h_ticks.bin" to "EURUSD_2007_03_15_23h_ticks.bin". I'll write a C# program to convert them to CSV. The web page actually provides Java code for working with the tick data, which I found surprising. But I'll just with stick with C# & Visual Studio as it's easy to do.

 

I identified the differences and rewrote FXTHeader.mqh to account for them. Found an old version of a Gain Capital data converter and adapted it to work with build 225.

That was quick! It took me a while to work out the new FXT format and determine what's important and what's not. The worrying thing is that if the values for some of the fields are incorrect you may end up with wrong results. Did you notice that the first part (100 lines) of the data (after the header) is not actually tick data, but OHLC data? Also the flag at the end of each block seems like a random integer (either 1, 2, or 3), but I wasn't sure whether it is actually random or determined by some algorithm.

 

The HST header is slightly different. I wrote a simple MQL script to parse the Gain Capital tick data and write history files for each period automatically.

Since the Gain Capital tick data is not always in chronological order, the HST files should be created from the cleaned and correctly ordered data (exported from a database).

 

I've written a loader that uses any existing FXT file before generating.

That sounds like some good work that you've done there. I'm eager to try it. Can you tell me the hex offsets and new values you set to patch terminal.exe?

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I check the dukascopy site and found the page you were referring to. I'm not sure why I didn't know of it before; either it's a recent addition or my attention was focused on the CSV data export page, which is a different data set - indicative data from a number of different sources, which we don't want; we want data from a single trade server. I had a lot of problems downloading that data too, my IP address was banned and using anonymous proxies worked only for a while.

 

I didn't know of it before yesterday, either.

 

Anyway, I've already started downloading tick data for EURUSD using a download manager. The tick data starts from 2007-03-01 00:00:00. The files are in zip-compressed bin files. The data format is quite simple: TIME, ASK, BID, ASKVOL, BIDVOL, each of 8 bytes. The main problem I initially found was managing all the files. For EURUSD alone there are 21051 files, and they are not named uniquely. But I managed to find a way to batch rename them from something like "23h_ticks.bin" to "EURUSD_2007_03_15_23h_ticks.bin". I'll write a C# program to convert them to CSV. The web page actually provides Java code for working with the tick data, which I found surprising. But I'll just with stick with C# & Visual Studio as it's easy to do.

 

I already wrote a PHP script to download all the data. The tick data has different start values for each currency (or well, AUDNZD, EURCAD, USDNOK and USDSEK have different starting dates from the others). My script is automagically downloading their data and replicating the directory structure and I already wrote a different script to parse it into CSV files. The problem was that I only read their tick data description *AFTER* I figured it out myself and it took me quite a while to do it because they're in big endian byte order (even the doubles ffs). Imo, don't bother writing code to do it because I'll release my PHP code to download & parse the data when I release the CSV files.

 

That was quick! It took me a while to work out the new FXT format and determine what's important and what's not. The worrying thing is that if the values for some of the fields are incorrect you may end up with wrong results. Did you notice that the first part (100 lines) of the data (after the header) is not actually tick data, but OHLC data? Also the flag at the end of each block seems like a random integer (either 1, 2, or 3), but I wasn't sure whether it is actually random or determined by some algorithm.

 

Uhm, the FXT format is pretty much identical to the old one except that now it also stores the server name as an 128 bytes string, right after the copyright string (and it actually checks this). The second difference is that the FXT version is now 405 instead of the old 404. The lines you mention (after the header) are the bars. The GainCapital2FXT mql that you can find on google doesn't calculate them, yet the FXT files seem to work very fine without them (they're probably taken from history).

 

Since the Gain Capital tick data is not always in chronological order, the HST files should be created from the cleaned and correctly ordered data (exported from a database).

 

I already wrote a PHP script that does just that: sorts & removes duplicates from the CSV files (and before you ask, yeah, I made a script that merges the Gain Capital data files, too, assuming they're found in the same directory structure as they are online). I will also release these two scripts with the dukascopy scripts (and with the MQL scripts, of course), although they're pretty much useless, given the Dukascopy data.

 

That sounds like some good work that you've done there. I'm eager to try it. Can you tell me the hex offsets and new values you set to patch terminal.exe?

 

I'll do better than that, I'll upload the loader. Since the Gain Capital data scripts were in the same dir, they're also in the archive if you want to play with them.

 

http://www.4shared.com/file/129655215/57b17b02/

 

Loader: toss it in your MT4 folder and start mt4 with fxt loader.exe. After doing this, if you want to test EURUSD M1, just generate your EURUSD1_0.fxt file into history/tester before starting. If you don't, it will calculate it.

 

FXT generator: *IMPORTANT* connect to the server before you generate the file *IMPORTANT*, open a chart with the currency pair and timeframe you want and fire it up.

 

HST generator: you can use this one offline. Open a chart of the desired currency pair, timeframe doesn't matter. Run the script, wait a whole ton. When it's finished, exit metatrader, copy the history files from experts/files to history/server_name/.

 

The hex offsets if you want to patch manually (offset -> old -> new):

 

1402FC -> EE -> 00

1402FD -> 02 -> 00

14041B -> 9D -> 00

14041C -> 01 -> 00

 

And another one to ignore the server name check for the generated FXT files (e.g. run an Alpari-generated FXT on FXDD):

140521 -> 97 -> 00

[hyperdimension]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Imo, don't bother writing code to do it because I'll release my PHP code to download & parse the data when I release the CSV files.

Ok. I haven't touched PHP in years, just never needed it, and I like ASP.NET & C# & Visual Studio too much to switch to anything else unless I have to :).

 

The hex offsets if you want to patch manually

Excellent work. I wanted the hex offsets as well out of curiosity and see the changes you made, so thanks for that.

I'm still downloading dukascopy's EURUSD data so once that's done I'll convert it to CSV and spend some time to play with all of this stuff that you've done.

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

I just gave you another kudo because the more I use it , the more I like it. cheers.

 

Lol, thanks. I'll make a thread with all the scripts, some instructions and some of the dukascopy data later today.

[⭐ bbrain]

Re: Fractals4 -- new Fractals from Fx H0pe

 

As it turns out, my description was pretty accurate. Unfortunately, I don't have the time to make a loader now, but if you are eager to use custom FXT files, you can make MT4 .225 use an alternate FXT file (e.g. put EURUSD1_1.fxt in tester/history/ and it will be used instead of the EURUSD1_0.fxt that it's going to create) by patching terminal.exe with a hexeditor as follows (offset, change from, change to):

00141313: 8B 31

00141314: 8E C9

00141315: D4 41

00141316: 00 90

00141317: 00 90

00141318: 00 90

 

Note: if you patch terminal.exe that way, it will NOT backtest until you place a file named SYMBOLTIMEFRAME_1.fxt in tester/history/. For example, for EURUSD H1, you will need to place a file called EURUSD60_1.fxt in there. Your MT4 will *still* create the SYMBOLTIMEFRAME_0.fxt file, but it will not use it. Do not check "Use date".

 

As my time allows, during the next week I will make a universal MT4 .225 loader and also some pre-built FXT files to go with it.

Hi mate,

 

Maybe the best if we just turns out the recalculation in the ini:

.text:00516DE4 loc_516DE4: ; CODE XREF: check_ini+BB8�j

.text:00516DE4 lea eax, [esp+434h+Str]

.text:00516DE8 push 0FAh

.text:00516DED push eax

.text:00516DEE lea ecx, [esp+43Ch+var_304]

.text:00516DF5 push offset aTestrecalculat ; "TestRecalculate="

.text:00516DFA push ecx

.text:00516DFB call sub_428DC0

.text:00516E00 add esp, 10h

.text:00516E03 cmp eax, ebx

.text:00516E05 jnz short loc_516E42

.text:00516E07 lea edx, [esp+434h+Str]

.text:00516E0B push offset aTrue ; "true"

.text:00516E10 push edx ; Str1

.text:00516E11 call ebp ; _stricmp

.text:00516E13 add esp, 8

.text:00516E16 test eax, eax

.text:00516E18 jnz short loc_516E20

.text:00516E1A mov [edi+7A8h], ebx

.text:00516E20

.text:00516E20 loc_516E20: ; CODE XREF: check_ini+C08�j

.text:00516E20 lea eax, [esp+434h+Str]

.text:00516E24 push offset aFalse ; "false"

.text:00516E29 push eax ; Str1

.text:00516E2A call ebp ; _stricmp

.text:00516E2C add esp, 8

.text:00516E2F test eax, eax

.text:00516E31 jnz loc_51704D

.text:00516E37 mov [edi+7A8h], eax

.text:00516E3D jmp loc_51704D

 

I think this checks the ini. If we patch here that would be nicer.

 

Br.

[⭐ birt]

Re: Fractals4 -- new Fractals from Fx H0pe

 

Hi mate,

 

Maybe the best if we just turns out the recalculation in the ini:

.text:00516DE4 loc_516DE4: ; CODE XREF: check_ini+BB8�j

.text:00516DE4 lea eax, [esp+434h+Str]

.text:00516DE8 push 0FAh

.text:00516DED push eax

.text:00516DEE lea ecx, [esp+43Ch+var_304]

.text:00516DF5 push offset aTestrecalculat ; "TestRecalculate="

.text:00516DFA push ecx

.text:00516DFB call sub_428DC0

.text:00516E00 add esp, 10h

.text:00516E03 cmp eax, ebx

.text:00516E05 jnz short loc_516E42

.text:00516E07 lea edx, [esp+434h+Str]

.text:00516E0B push offset aTrue ; "true"

.text:00516E10 push edx ; Str1

.text:00516E11 call ebp ; _stricmp

.text:00516E13 add esp, 8

.text:00516E16 test eax, eax

.text:00516E18 jnz short loc_516E20

.text:00516E1A mov [edi+7A8h], ebx

.text:00516E20

.text:00516E20 loc_516E20: ; CODE XREF: check_ini+C08�j

.text:00516E20 lea eax, [esp+434h+Str]

.text:00516E24 push offset aFalse ; "false"

.text:00516E29 push eax ; Str1

.text:00516E2A call ebp ; _stricmp

.text:00516E2C add esp, 8

.text:00516E2F test eax, eax

.text:00516E31 jnz loc_51704D

.text:00516E37 mov [edi+7A8h], eax

.text:00516E3D jmp loc_51704D

 

I think this checks the ini. If we patch here that would be nicer.

 

Br.

 

That's more or less what I ended up doing, but directly in the FXT routines. The loader that I posted in this thread patches it so that it will only create the FXT file if there's no FXT there; if you put your custom-made FXT in tester/history it will just use that. It works just great so I won't bother firing up my softice machine for the ini thing :) However, if you can find out how to enable the recalculate checkbox, it's definitely a more elegant solution than mine.

[⭐ bbrain]

Re: Fractals4 -- new Fractals from Fx H0pe

 

That's more or less what I ended up doing, but directly in the FXT routines. The loader that I posted in this thread patches it so that it will only create the FXT file if there's no FXT there; if you put your custom-made FXT in tester/history it will just use that. It works just great so I won't bother firing up my softice machine for the ini thing :) However, if you can find out how to enable the recalculate checkbox, it's definitely a more elegant solution than mine.

 

No, your solution good, I dont play the recalculate button either. ^:)^