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)
For those interested, I just updated this indicator in the downloads section. Just corrected a problem where it could not be serialized and saved with the workspace:
I created this because I was interested in determining the hours in an extended trading session for which liquidity is adequate to trade. I've also noticed, but not tested, that turning points in price seem to be highly correlated with spikes in tickspeed.
fluxsmith, this same issue occurs when trying to import the newly posted jhlDemandIndex. When you compile the Tsi4JefffromTMFT.cs file, the error message says "TSI does not exist in Jhl.Utility namespace." Can you post an updated Jhl.Utility …
Apparently the NT strategy wizard has a bug that doesn't like those fancy MA selectors some of the coders here made.
Solution:
Open the code and use search and replace to change:
'NinjaTrader.Indicator.MAV+MAType' into 'NinjaTrader. …
I actually just found that link while looking for the bug posting about my code, I'll have to go back and check out that thread ;-).
I've also discovered a method of supporting multiple MA types without having a compile time dependency on those you don't wish to use.
Today I'm reposting jhlTSI and jhlTSIv2. If anyone has problems importing the new versions, you'll need to copy the .cs files from the .zip manually, compile, and let me know your error (it'll be a conflict with some other source file not from those two archives). I'll respond with a fix promptly.
Thats great news... so glad you took the opportunity to do this!
I have a laptop without any of the indicators installed yet: I will wait until you are finished with all of them, and then install them all at once, and report back if there are any NT hiccups
Updated jhlEMA to use new version of JHL.Utility.MA and use JHL.Utility.MAType vs JHL.Utility.MA.Type. Also further reduces memory footprint and increases CPU efficiency (trivially). Changed CalculateOnBarClose default to true, as I intend to set the default according to the refresh efficiency of the indicators.
Not my doing: NT support has recommended not having any COBC entry in indicators that are used for strategies. I am not sure of the reason, though I do know it makes a small difference in backtesting. All the NT supplied indicators in their distribution (as far as I have checked) do not have any COBC line in their code.
Just my 2 CDN cents worth,
Jon
Writing to you from the wonderful province of Ontario, Canada. Home to the world's biggest natural negative ion generator, the Niagara Falls, and to those that dare to know how to go over it in a barrel. SALUTE!
Maybe I'll do some testing, but as far as I know if you set the strategy itself to COBC = true all indicators within it will be run at COBC = true regardless of their defaults.
I like to have an indicator default to COBC = false if it is efficiently calculated, and COBC = true if it cannot be, especially if it has to iterate bars in order to update. I can always change it from the default if I want.
Updated jhlWMA to use new version of JHL.Utility.MA and use JHL.Utility.MAType vs JHL.Utility.MA.Type. Also increases CPU efficiency (trivially). Changed CalculateOnBarClose default to true, as I intend to set the default according to the calculation efficiency of the indicators.