Time of writing the advisor - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I can send you one order that he did the source, you can look at who understands, quality or not he did it, I just do not understand, quality or not, the main thing he works on the algorithm, and as the inside, I do not know) 0
Most of the code is in the Trades.mqh library, which I assume he sent you. Please attach it for quality estimation.
You can't judge much from this file. It seems there are no checks and normalizations where they should be, but they might be in the included Trades.mqh file as well.
And most of the code is located in the same place.
However, I have something to say about the signal block.
1) comparison of doubles with each other without any normalization.
2) The MA price crossover is implemented without taking into account the situation when the candle close price is equal to the MA price. This is rare, but still possible.
I do not dispute that it is difficult and yes there are a lot of mistakes, but 2 months ago they were told that the errors are known, fixable and all the hardest part is over, unfortunately I'm not the one who does it, and someone who knows all the details of strategy, and he agreed to an hourly rate and a simple work report and I could not prove to him that it was bad and wrong
Does freelancing pay by the hour?
If you can resolve issues through arbitration, there is such a thing, they will sort it out.
Let me join in the discussion, if you're up to it ))))
First of all, of course to 82Dmitry82 and the rest of his team, I apologize for the delay in development. As I myself have indicated to their representative that I regretted that I took on the development, I admit that for me it is a difficult task. The task was divided into parts, but a strong complication of requirements revealed in the second stage, and in fact, since I took it, I decided to bring to an end, but it was not so easy.
Now, without disclosing the strategy, I will try to outline the fact of increasing the complexity of ToR, so that our programmers really appreciate how much this fact complicates the development.
The basis is the graphical construction of levels from which orders should be opened. These levels cannot be built right away on the chart edge without referring to history, we have to wait until the history is built or simply make the Expert Advisor refer to history itself and come to the edge of the chart with some data. This is what we have decided to do.
Initially, we imagined that we would run by candlesticks and estimate 4 parameters (Open, Close, High, Low) and build based on the conditions. And so we did the first part on a large TF (ToR is divided into 3 parts, 3 TFs for each of which there are different constructions and conditions for these constructions). When we shifted to the second TF and started testing essentially the ready second part, we identified errors and general discussion showed that a candle in the history should be tracked online (i.e. as if it was zero on the chart edge) and rebuilds should be done while the candle is still open, which is not realistic during the run through the history, because there are actually 4 parameters Open, Close, Low and High.
The general discussion has decided to go deeper and break it down to m1 in order to trace the candle online as much as possible (as if it were zero on the chart's edge). The idea to leave the history building as it is by 4 points and trace the correct logic at the chart edge (when Close[0] is floating) was rejected. The customers themselves understood that this fact, revealed in the process of development, significantly complicates the ToR. Already on that stage I wanted to abandon the development, but because the first stage was already done, and it's not really in my principles to abandon the development in the middle decided to continue. While adapting the existing algorithm to the fact that I should use M1 and trace higher TFs, I started to feel psychotic, because I had killed a lot of time for that, and during the process of not succeeding I used to break down and write to the clients that I should raise development cost, but when I got away from the computer and got a bit cold, I continued to correct the problem.
I suggested a time-based payment just because I was no longer able to pull the project for the negotiated amount. Although offered to give the source code to possibly find someone who will bring to mind.
If I had known from the beginning I would have used another approach to track М1 inside the higher timeframe.
If I've got an error in build, I will correct it. I have no opportunity to check everything myself, as there are a lot of conditions in the strategy that I cannot even remember. I have already checked all of them so that they do not conflict with each other, that is the main problem. It was done gradually, and customers admit that the strategy is difficult to understand, but in general it is now almost all prescribed, but as it works I can not even understand rightly or not)))
The last thing they stopped at was the case that was not taken into account (even according to the customers' representative) and now we have to write, paste and agree with a dozen other conditions one more time. So the move to an hourly rate for my part I think is justified.
82Dmitry82, if you want, we can talk to you personally about the advisor, you have my contacts. I have done another EA for you, I think you will appreciate its responsiveness and support, but I will ask for patience with this one, sometimes I put it off, just because I do not understand which side to go to, to start correcting another wrong level build.
At the moment there are over 1000 lines of code in the Expert Advisor and this is just the construction of levels, without any nice meshura and even orders, which have not yet been reached.
Let me join in the discussion, if you're up to it ))))
First of all, of course to 82Dmitry82 and the rest of his team, I apologize for the delay in development. As I myself have indicated to their representative that I regretted that I took on the development, I admit that for me it is a difficult task. The task was divided into parts, but a strong complication of requirements revealed in the second stage, and in fact, since I took it, I decided to bring to an end, but it was not so easy.
Now, without disclosing the strategy, I will try to outline the fact of increasing the complexity of ToR, so that our programmers really appreciate how much this fact complicates the development.
The basis is the graphical construction of levels from which orders should be opened. These levels cannot be built right away on the chart edge without referring to history, we have to wait until the history is built or simply make the Expert Advisor refer to history itself and come to the edge of the chart with some data. This is what we have decided to do.
Initially, we imagined that we would run by candlesticks and estimate 4 parameters (Open, Close, High, Low) and build based on the conditions. And so we did the first part on a large TF (ToR is divided into 3 parts, 3 TFs for each of which there are different constructions and conditions for these constructions). When we shifted to the second TF and started testing essentially the ready second part, we identified errors and general discussion showed that a candle in the history should be tracked online (i.e. as if it was zero on the chart edge) and rebuilds should be done while the candle is still open, which is not realistic during the run through the history, because there are actually 4 parameters Open, Close, Low and High.
The general discussion has decided to go deeper and break it down to m1 in order to trace the candle online as much as possible (as if it were zero on the chart's edge). The idea to leave the history building as it is by 4 points and trace the correct logic at the chart edge (when Close[0] is floating) was rejected. The customers themselves understood that this fact, revealed in the process of development, significantly complicates the ToR. Already on that stage I wanted to abandon the development, but because the first stage was already done, and it's not really in my principles to abandon the development in the middle decided to continue. While adapting the existing algorithm to the fact that I should use M1 and trace higher TFs, I started to feel psychotic, because I had killed a lot of time for that, and during the process of not succeeding I used to break down and write to the clients that I should raise development cost, but when I got away from the computer and got a bit cold, I continued to correct the problem.
I suggested a time-based payment just because I was no longer able to pull the project for the negotiated amount. Although offered to give the source code to possibly find someone who will bring to mind.
If I had known from the beginning I would have used another approach to track М1 inside the higher timeframe.
If I've got an error in build, I will correct it. I have no opportunity to check everything myself, as there are a lot of conditions in the strategy that I cannot even remember. I have already checked all of them so that they do not conflict with each other, that is the main problem. It was done gradually, and customers admit that the strategy is difficult to understand, but in general it is now almost all prescribed, but as it works I can not even understand rightly or not)))
The last thing they stopped at was the case that was not taken into account (even according to the customers' representative) and now we have to write, paste and agree with a dozen other conditions one more time. So the move to an hourly rate for my part I think is justified.
82Dmitry82, if you want, we can talk to you personally about the advisor, you have my contacts. I have done another EA for you, I think you will appreciate its responsiveness and support, but I will ask for patience with this one, sometimes I put it off, just because I do not understand which side to go to, to start correcting another wrong level build.
At the moment there are over 1000 lines of code in the Expert Advisor and this is just the construction of levels without any nice meshes and even orders which we have not got to yet.
All in all, it has become even more confusing than it was.
I have understood that we should check for the coincidence of conditions on a higher timeframe and if the coincidence is not found.
If I understand the algorithm correctly, it's not that complicated, 2-3 days at the most.
At the moment there are over 1000 lines of code in the EA, and this is just the construction of levels, without any nice meshura and even orders, which have not yet been reached.
1000 lines is by the way the average size of any EA above a simple one. I think the problem is that you have taken the wrong path when thinking how to circumvent problems that have arisen. 90% of success is to formulate the right problem, and its implementation is a tenth matter
.
.
In fact, if I had known from the beginning that it was necessary to track m1 inside the higher timeframe, I would have built the logic of the advisor differently.
.
At the moment there are over 1000 lines of code in the EA, and this is just the construction of levels, without any nice meshura and even orders, which have not yet been reached.
Let me support you.
Of course my strategy is not exactly like that, but similar. It takes into account support/cop levels, trend, reversals, pullback and many other things, without using external (custom) indicators.
I've been hand trading with this strategy for 3 years. All this time I was thinking how to implement it and programmed it for a year. Turned out less than 2000 lines.
All developers who are able to trade by hand, it is easier for them when they take some bars as a base for analysis.
But a bar, even if it is M1, is already the past. It is useless to build a strategy on bars (especially on higher ones).
It should be done using every tick.
In my program there is not a single array (in the absolute sense), and I do not analyze what was in the past. But of course I remember the necessary check points in real time (not in arrays).
In short: What is done by hand and is so easily and beautifully drawn on the graph, it is not always possible to program.
Let me join in the discussion, if you're up to it ))))
First of all, of course to 82Dmitry82 and the rest of his team, I apologize for the delay in development. As I myself have indicated to their representative that I regretted that I took on the development, I admit that for me it is a difficult task. The task was divided into parts, but a strong complication of requirements revealed in the second phase, well, in fact, since I took it, I decided to bring to an end, but it was not so easy.
Now, without disclosing the strategy, I will try to outline the fact of increasing the complexity of ToR, so that our programmers really appreciate how much this fact complicates the development.
The basis is the graphical construction of levels from which orders should be opened. These levels cannot be built right away on the chart edge without referring to history, we have to wait until the history is built or simply make the Expert Advisor refer to history itself and come to the edge of the chart with some data. This is what we have decided to do.
Initially, we imagined that we would run by candlesticks and estimate 4 parameters (Open, Close, High, Low) and build based on the conditions. And so we did the first part on a large TF (ToR is divided into 3 parts, 3 TFs for each of which there are different constructions and conditions for these constructions). When we shifted to the second TF and started testing essentially the ready second part, we identified errors and general discussion showed that a candle in the history should be tracked online (i.e. as if it was zero on the chart edge) and rebuilds should be done when the candle is not yet closed, which is not realistic during the run through the history, because there are actually 4 parameters Open, Close, Low and High.
The general discussion has decided to go deeper and break it down to m1 in order to trace the candle online as much as possible (as if it were zero on the chart's edge). The idea to leave the history building as it is by 4 points and trace the correct logic at the chart edge (when Close[0] is floating) was rejected. The customers themselves understood that this fact, revealed in the process of development, significantly complicates the ToR. Already on that stage I wanted to abandon the development, but because the first stage was already done, and it's not really in my principles to abandon the development in the middle decided to continue. While adapting the existing algorithm to the fact that I should use M1 and trace higher TFs, I started to feel psychotic, because I had killed a lot of time for that, and during the process of not succeeding I used to break down and write to the clients that I should raise development cost, but when I got away from the computer and got a bit cold, I continued to correct the problem.
I suggested a time-based payment just because I was no longer able to pull the project for the negotiated amount. Although offered to give the source code to possibly find someone who will bring to mind.
If I had known from the beginning I would have used another approach to track М1 inside the higher timeframe.
If I've got an error in build, I will correct it. I have no opportunity to check everything myself, as there are a lot of conditions in the strategy that I cannot even remember. I have already checked all of them so that they do not conflict with each other, that is the main problem. It was done gradually, and customers admit that the strategy is difficult to understand, but in general it is now almost all prescribed, but as it works I can not even understand rightly or not)))
The last thing they stopped at was the case that was not taken into account (even according to the customers' representative) and now we have to write, paste and agree with a dozen other conditions one more time. So the move to an hourly rate for my part I think is justified.
82Dmitry82, if you want, we can talk to you personally about the advisor, you have my contacts. I have done another EA for you, I think you will appreciate its responsiveness and support, but I will ask for patience with this one, sometimes I put it off, just because I do not understand which side to go to, to start correcting another wrong level build.
At the moment there are more than 1000 lines of code in the EA and this is just the construction of levels, without any nice meshes and even orders, which have not been reached yet.
From the description, it is clear that I haven't had TOR and the task looks like this: Make me this strategy, and it should work this way and at the same time think out how to implement all this, no algorithm.
In this case, it is a labor-intensive job, as I wrote above, the programmer starts to think, and the cost of thinking is different for everyone. Therefore, the price may be justified.
The division of labor was invented for a reason. The customer understands a programmer as a magician who can transfer any idea to code. In fact, a person's skills and competences are always limited, and in large companies there is a division of labor between a person who creates algorithms, an architect and a programmer - each of them have their own specialization. That is how the situation turned out.
Let me support you.
I don't have exactly the same, but a similar strategy. It takes into account support/cop levels, trend, reversals, pullback and many other things, without using external (custom) indicators.
I've been hand trading with this strategy for 3 years. All this time I was thinking how to implement it and programmed it for a year. Turned out less than 2000 lines.
All developers who are able to trade by hand, it is easier for them when they take some bars as a base for analysis.
But a bar, even if it is M1, is already the past. It is useless to build a strategy on bars (especially on higher ones).
It should be done using every tick.
In my program there is not a single array (in the absolute sense), and I do not analyze what was in the past. But of course I remember the necessary check points in real time (not in arrays).
In short: What is done by hand and is so easily and beautifully drawn on a graph, can not always be programmed.
You can program anything, but first you need to develop an algorithm, and that's a big part of the job. In essence, you must first turn what you see into formulas and logic, and then program them. And the former is very often underestimated.
Let me join in the discussion while we're at it ))))
....
As a matter of fact, if I had originally known what ....., I would have constructed the EA's logic differently.
....
This is a familiar situation. Before you start writing the code, you are planning its structure and the logic of its work, but once the algorithm is ready and is fully functional, you start adding some other conditions and new functionality, and eventually it becomes clear that it is easier to revise the entire structure and completely rewrite the entire logic, than to continue trying to fit some new concept into the old algorithm. It turns out that it is easier to rethink everything with new functions and conditions and rewrite the algorithm, but it takes a lot of time.
A good illustration of "the result of work without a project".
Everyone's not happy with each other, there's zero output...