I support this. IB gateway makes more sense than TWS.
I use symbolic links
After install move the directory where you want it then create a .bat file with the following code:
@echo off
set svSourceDir=C:\Users\%username%\Documents\NinjaTrader 8
set svTargetDir=x:\new\location\of\your\files\NinjaTrader 8
mklink /J "%svSourceDir%" "%svTargetDir%"
This creates a symbolic link (acrually a directory junction) that points to where the data really is.
How about proper documentation for NinjaScript? An object inheritance map?
Having to reverse-engineer NinjaScript code from example files is doable but very error-prone and inefficient.
Having to contact support to learn that you must call Update(), first, to properly return a List to a calling Indicator, unless youâve Add()-ed the List to the script is insane.
NinjaScript documentation is poor.
Random, but I would prefer if I didnât have to reselect my desired ATM strategy to be able to place another order. Itâs very tedious to switch after each order.
expose a public StopBrush/Entry Brush, etc property that can be set programmatically.
Multiple object selection.
Multiple error copy selection.
Disable automatic scrolling - the number of times i touch my mouse wheel and the chart moves is REALLY irritating.
And/or copy & paste it from one window to another too.
I have to agree with the general sentiment in this thread. Relying on the native UI and out-of-the-box Managed strategies in NT8 is a recipe for frustration if you are running serious capital.
@scott_badtke - The discrepancy you are seeing between your backtest and live execution, even on âOnBarCloseâ, is a classic NT8 matching engine issue. In historical testing, NinjaTrader makes assumptions about intrabar price movement and fill probability. If price touches your limit/stop, the backtester assumes a perfect fill. In live routing, you are subject to the order book queue and slippage. Unless your strategy is specifically coded to use TickReplay and High Fill Resolution to simulate the exact intrabar micro-structure, your backtest will always be a fantasy curve.
Most of the limitations mentioned in this thread (backtest discrepancies, latency, custom lockouts, dynamic UI) are solved by abandoning the retail interface and building Unmanaged C# engines that route directly to the core. Thatâs how we structure it for prop firms, if anyone is hitting a wall with execution discrepancies and needs a quantitative engineer to audit their code or build a custom unmanaged architecture, shoot me a DM
