Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
You can easily alter the code of any system indicator and then
-> save it under a new name
-> and compile it via F5
Doing this you can replace for example EMA, SMA, RSI, MACD by modified versions tkEMA, tkSMA, tkRSI, tkMACD and use those instead of the system indicators.
i'm pretty sure you can change the original @EMA.cs file and make your changes there, provided you edit outside of NT. this would clearly be unsupported and not-recommended (and everytime you upgrade NT they could be overwritten, not to mention if you mess up EMA then every other indicator that requires/uses EMA could be messed up as well).
I had waited for Ninajtrader 7.0.1000.5 for these bugs to disappear. I am partly disappointed.
One of the bugs has been fixed - the one that caused multiple first bars of sessions - the other one is still happily living within NinjaTrader.
I am disappointed with this because
-> it is always the users who have to test whether the software works
-> there is an obvious lack of resources, if simple bugs that have been clearly identified cannot be fixed
Just tested, with NinjaTrader 7.0.1000.5 GetNextBeginEnd() still returns the false session start time under the following conditions
-> chart built from tick bars
-> first bar of session bar closes at :00 (the case where the bar belongs to new session for tick but to old session for minute bars)
-> session template with night and day session (ES)
-> first bar of day session
-> create a small period tick chart for ES (to make sure that the first tick bar after the session begin closes at 8:30:00 CT)
-> apply the session template as per below
-> apply the indicator attached which will identify the first bar of the session and the session start time
Actually, the "real" last message from Bertrand was :
gomi, this is by design - the bars are stamped at their end (this has always been the case) - any tick after the 6 AM is counted then towards your newly started session.
Went back to the thread, the last message was edited, and now states :
We plan to have a resolution to this with NinjaTrader 7.0.1000.5.
Nice Edit, guys, so you don't have to advertise that there _actually_ was a bug....
Ninja's motto on Bar TimeStamp including ticks happening before the timestamp, so 15:30:00 bar doesn't include ticks happening at 15:30:00, is basically inaccurate. This is true ONLY for
Minute Charts, and
Second charts with period >1.
For second charts with period=1, the timestamp is actually the one of the ticks, so the 15:30:00 bar is actually the 15:30:00 tick.
For other types, you actually don't know. It depends how the ticks are split. If you are on a tick chart , you can have a lot of bars with 15:30:00 timestamp.
Last post from Ninja support in November 2009 was :
You are incorrect in your understanding. It's very simple to calculate the Begin/EndTimeLocal from the Begin/EndTimeExchange, the actual date is totally irrelevant. Just DayOfWeek matters. You will see with NTB5.
They actually deleted the post, and let the thread die, but then, a few betas later, the new version was actually implementing the solution I proposed even if I was "incorrect in my understanding".
Is it me or is this message modification habit a rude attitude ? No one says software can be bug free, but you can at least reckon the bugs to the guys who take time to test and raise them instead of calling them morons and correcting the software behind their back...
The other trick that I have encountered multiple times with NT support, is that when the analyst working on the thread is tired of dealing with you, he says, in order to continue work on this issue, write me by email to support attention so-and-so. Then they give you one of the standard textbook dismissals in private by email, instead of in the public eye of the forum.
It is my belief because of people like Gomi and FT that Ninja has a wider user base. And I for one, am very thankful. When I was choosing a platform to trade futures with, I relied in part on the user base to influence my decision. The last platform I used was pathetic, partly because it 'ignored' its users input.
Somehow in NT's case, I feel that they DO listen just not showing it/also struggling to keep up. Though Ray and co could do a little better by acknowledging the input/feedback and critique from its users, and especially the technically gifted amongst them. After all, the majority of users benefit when NT takes serious considerations of the items raised. It is because of the efforts of these few people that I am grateful and happy to use NT as a trading platform. Oh, if it wasn't for Gomi's contribution, I would have been with IRT in a heartbeat!
Just a suggestion to Ray/NT, maybe get your product manager, if you have one, to handle such matters. It may seem NT lacks a dedicated 'effort' to manage this, IMHO.
I do not believe that this issue has to do anything with customer relations. The customer support acknowledged the problem and also has proposed a solution with the new release. This is really a technical discussion regarding some ticks at the beginning of the session. Both problems I brought up have been dealt with, as expected. I was just not very happy with the outcome, as there was no direct solution to the problem.
As it is technical I will try to explain how an architectural decision complicates some of the functionalities that were added later.
Design: A minute or second bar with a time stamp of 8:30:00 contains trade data from a period prior to 8:30:00. A bar built from tick data with a time stamp of 8:30:00 contains trade data from a period prior to 8:30:00. This design feature is counterintuitive and responsible for some bugs that were introduced, because complexity is always punished, whether you develop a piece of software or a trading system.
Consequence: The method GetNextBeginEnd() uses the timestamp of a bar to determine the session start time and session end time of the current session. So if the timestamp of your bar is 8:30:00, what shall this method return? The start and end time of the session prior to 8:30:00 or the start and end time of the session starting at 8:30:00?
Problem: The method does not know what to return, until the underlying bar series is specified. If the bars are fixed period bars, the prior session should be returned, if the bars are built from tick bars, the following session should be returned.
Solution: Specify the underlying bar series. This solution was actually adopted by creating a new overload, which uses the underlying bar series. I must admit that I could not read from the release notes that a new overload was introduced, as I had no clue what they meant with signature. I just used my old indicator to check whether the problem persists. So there is a solution that can be implemented now, but I will have to change the code of all my session related indicators (at least 20), you will get the update notifications.
So this whole thing is not a customer support but a design question. This is the fundamental problem, the last three digits representing milliseconds:
tick bar completed at 8:29:59:950 -> time stamp rounded down to 8:29:59:000 (?)
tick bar completed at 8:30:00:450 -> time stamp rounded down to 8:30:00:000 (?)
minute bar completed at 8:29:59:000 -> time stamp displayed as 8:30:00:000 (?)
So it is an issue of rounding timestamps of bars built from ticks to the full second. Possible solutions:
(a) round them all up to the full second
(b) round them all down to the full second
(c) round them up and down, depending whether the ticks were detected prior to or after 500 milliseconds of the second interval have elapsed.
It is clear that solution (a) would have caused no problems, as both minute and tick bars could be treated in a similar fashion.
However, solution (a) has not been chosen for reasons that I do not understand. This triggered a whole flood of errors made both by developers and customers. Should have kept it simple and stupid.
For those who are not interested in details, but want to make sure that their indicators and strategies work correctly on bar series built from tick charts (this includes tick, range, volume, renko, etc. charts)
Please replace
with the overload
The original syntax is flawed, as it does not take into account the bar type, on which the method is used. Do not use the new overload outside OnBarUpdate().
Just having started getting into Ninja 7 I think some of you guys may be not seeing the forest for the trees. If you have used it for years I could see how the issues that would only effect a smaller % of the user base would be frustrating if they are messing with your own work but the scope of this project is really pretty amazing.
Everything else has pretty much been left in the dust IMO. By version 8 or 9 it will be game over.
I'm sure I will run into issues but that is only because there are things I should be able to do with Ninja that I wouldn't have even bothered to contemplate with other retail trading software.
Not running into bugs because you don't bother to do something with the software is not a "feature".