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)
I'm not (obviously), but I'll take a stab at this.
Ray has said that the familiar program procedures that we use, like OnBarUpdate or Initialize, will be replaced by another structure, but that the changes will not be extreme, and that most indicators will need only a minor reorganization -- however, all will need something. No NT7 indicator or strategy will run without changes in NT8. (He went through this in one of his latest webinars.)
Also, if you mainly use the documented features, Ninja will preserve most or all of the present method/property calls. So not much will need to be changed there, either.
However, a lot of indicators go under the hood to do things that are not available in the presently-supported, documented features. For example, I just did a little work with StepMA, a nice indicator that accesses ChartControl, the Windows Forms control that creates the charts, and which is undocumented. They are completely changing this basic paradigm in the new release, and nothing from Windows Forms, or any control developed for it, will continue in its present form. Any such indicator will need a bigger rewrite.
So if you are doing some fairly vanilla stuff that uses the presently documented properties and methods of existing classes, you will need to change the structure of your code, but it won't be a big deal, and much/many/all(?) of the property/method calls you presently use will be OK or nearly so. If your code is doing some of the fancy, undocumented stuff that many of the best programmers on futures.io (formerly BMT) and elsewhere have sometimes used, you will need to address the new programming interface to get the same result. That code will have to fundamentally change.
Ray also said that they will document essentially all of the new classes and features. I think this will make NT a lot easier to program for -- you won't have to find out the undocumented, undisclosed features that you want to use, because there won't be any....
This is a long answer, and I don't want to have overstepped by junping in here. So the short answer is: all indicators will need a rewrite, but it usually will not be a big deal for most non-programmers who have gotten a little familiarity with Ninja Script. Some indicators, namely all those that are using special and undocumented features in the present version, will be more involved.
Based on Ray's last webinar, I think that the process, even for the previously-undocumented stuff, will be easier than one might think, since he will publish essentially everything.
If any of this is not correct, I hope that or will provide a correction. But this is what I gleaned from his last webinar, and I think it's essentially what we presently know about it. (I'll watch the next webinar for more info....)
Criteria remain unchanged. I fixed a bug where some users were receiving the Legendary mark without first being a Market Wizard. You would still qualify for Legendary based on your current stats, once you qualify for Market Wizard.
I've made a change to our mail server that will hopefully improve deliverability of our emails.
One trade off, however, seems to be that if you submit a post to a large thread, it takes considerably longer to process all the subscription emails. It used to be instant (5ms) and now I am seeing response times of 200-400ms for big threads.
The issue only occurs on submission of a new post. It just means it will be slightly slower. But I want to leave this config in place for long enough to collect enough data to see if the new mail server configuration improves deliverability. I will go from there.
If you are kind enough, please check your emails from futures.io (formerly BMT) and let me know if the links are working and if they showed up in spam or not spam.