A separate StartBehavior for EntryXXX and ExitXXX

[Brillo]

I have a strategy that holds for long periods of time and I'd like to be able to restart the strategy while it's in a position. This strategy is running Calculate.OnPriceChange.
Using the provided StartBehaviors I don't see a setting that will allow the strategy to restart running such that it will NOT submit another ENTRY order until flat but WILL submit EXIT orders. I think I could add a parameter and code for this but I'm thinking it must be a common problem and so I must be missing something in the API docs.

[NinjaTrader_ChelseaB]

Hello Brillo,

Immediately Submit with intra-bar granularity.

Below is a link to a forum post where I have detailed this.

https://ninjatrader.com/support/forum/forum/historical-beta-archive/version-8-beta/87750-load-cumulative-profit?p=783182#post783182

[Brillo]

I've read through the link provided. I still feel that there are some enhancements that can be made to NT that will help us create strategies that have more controllable start behavior.
For strategies such as the one I'm working on now, where it uses a long run of daily bars ( 1440 min bars actually ), it is not practical to use tick replay. It would take a very long time to start the strategy. I'm not sure that running on tick replay would help, however. The strategy looks for a condition to exist from examining the historical 1440 min bars closing price and it exists then at the open of the next 1440 bar and places an order. Throughout the formation of the current 1440 min bar that condition will remain true. If a user stops the strategy and restarts it, the strategy sees it to be true and is resubmitting the order which adds to the position (not desired). Instead the strategy needs a way to be told to assume the MarketPosition based on the historical backfill. Or at the very least offer an API in the strategy that allows devlopers to offer the strategy user a setting that that manually sets the strategy's MarketPosition and also tells the strategy not to place any orders for entering a position while starting. I think that would solve a lot of problems with restarting strategies.

[NinjaTrader_ChelseaB]

Hello Brillo,

As long as the strategy is running with Calculate set to OnBarClose, it will not be necessary to enable TickReplay.
However, if you are triggering intra-bar actions with .OnEachTick or .OnPriceChange it willl be a necessary evil to load the intra-bar information to trigger those intra-bar actions.

However, intra-bar granularity will be necessary to have orders match with the correct price and time so they can be resumed.

If you are ok with the orders being cancelled and re-submitted because they are not matching, intra-bar granularity will not be necessary.

It is possible to prevent a script from processing historically if you would like, by adding a return in the logic when historical.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/platform-technical-support-aa/104242-how-to-reset-sim-on-ninjatrader-8-can-t-close-open-position?p=811541#post811541

Changing the Position of a strategy could cause the working orders to not match the strategy position.
With Adopt Account position, you can have the strategy assume the account position and then in State.Transition place protective orders. Orders will not be possible to resume with this setting and previously placed working orders will be cancelled.

http://www.ninjatrader.com/support/forum/showthread.php?p=414006#post414006

[Brillo]

The strategy I have uses the closing prices of bars to enter trades. For entering OnBarClose is enough. But for exiting the strategy is calculating a limit exit based on an indicator running in the strategy. If the strategy is running OnBarClose then so is the indicator and the indicator is not using the latest price. Just for illustration see this:


The red lines and the blue bands are my indicators running on the chart OnPriceChange, separately from the strategy. The strategy is running OnBarClose and uses the same indicators internally. The strategy is supposed to place the order on 3368.00 price level which is calculated using the current bar in formation. But instead it's using the previous bar to get the price because it hasn't seen the new bar because it hasn't closed. In short the strategy must run with Calculate OnPriceChange or OnEachTick for it to correctly see the 3368 price that it should place a limit order at.

Because the indicator for exiting must use a Calculate other than OnBarClose the entire strategy that makes use of it must also use a Calculate other than OnBarClose. I have that working so the exit order is where it should be.

The only problem is restarting the strategy. Once the strategy is running this way when I restart it will submit the orders for entering again because when the strategy transitions to realtime it sees that the historical bars meet it's conditions for a market order. This is what I'm asking for the ability to suppress.

It is not enough to offer the user a startup parameter that avoids the entry orders submission for Historical bars ( or even any bars ) because the strategy logic (and probably the internal NT managed order API ) depends on it's Position to be MarketPosition.Long for it to operate correctly.

It is not a good solution to try and make the strategy adopt the account position. It's possible that users will have positions in the account unrelated to the strategy. I really don't like the synchronize account feature added to NT8.

I don't see how tick replay helps this situation.

For all of this I'm looking for a solution to the unwanted orders. The solution I thought of is what I suggested. I can think of 2 versions of this feature, either one suitable:
1. a new API that allows us to tell NT that the market orders placed at script startup should not actually be sent but that the managed api should assume the MarketPosition along with the order state and names that go along with it.
2. a new API that allows us to simply set the managed APIs MarketPostion and filled orders along their order names so that the Exit by name methods will work correctly.

Of these two options I prefer #2 as it's useful. It makes no assumptions and it's up to the script writer to make sure the logic is correctly RESTORING the order manager state to what it should be. #2 also means that the script writer must make sure that the orders at startup are not sent … that is, avoid the calls to EnterXXX based on logic that uses existing state APIs like the State==Historical that you suggested.
For example
if ( userParam == DontEnterOnStart && State!=State.Historical && myStrategyGoLongCondition )
{ call new #2 option apis to setup the MarketPostion.Long state in the strategy's managed order entry state
}

[NinjaTrader_ChelseaB]

Hello Brillo,

To summarize, your strategy uses Calculate set to OnPriceChange, and places a limit order using the price of an idicator.

Your are requesting a start behavior where working historical entry orders that have been submitted by you in the code and were not matched historically, to not be be submitted but for the exit orders to be submitted, is this correct?

I will submit your feature request.


TickReplay is necessary for scripts to run with OnPriceChange or OnEachTick in historical data. This is necessary if a price from a indicator is needed before the bar closes as you are doing. Even if its just for exit orders, those exit orders need to be submitted with the correct price at the right time.
Intra-bar granularity is necessary for accurate price fill information. For an order to be resumed, it has to be matched and that means the historical fill price needs to be as accurate as possible.

Both TickReplay and 1 tick intra-bar granularity are necessary to allow your strategy entry to be matched and resumed without a new entry order being submitted.


You have brought up the API (Application Programming Interface) used to connect external applications to interface with NinjaTrader.
Are you not using an internal NinjaScript Strategy and instead sending orders through the API from an external application.
Below is a link to a forum post about using the API and includes a sample project.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/100199-orders-are-not-displayed-in-chart?p=793626#post793626

[Brillo]

To summarize, your strategy uses Calculate set to OnPriceChange, and places a limit order using the price of an indicator.

YES

You are requesting a start behavior where working historical entry orders that have been submitted by you in the code and were not matched historically, to not be be submitted but for the exit orders to be submitted, is this correct?

YES but In the example I gave you I don't need exit orders to be submitted but perhaps someone else would. It should be generic enough to allow us to specify the OrderActions to submit and not submit.

I will submit your feature request.

That's great! Thank you.

TickReplay is necessary for scripts to run with OnPriceChange or OnEachTick in historical data. This is necessary if a price from a indicator is needed before the bar closes as you are doing. Even if its just for exit orders, those exit orders need to be submitted with the correct price at the right time.
Intra-bar granularity is necessary for accurate price fill information. For an order to be resumed, it has to be matched and that means the historical fill price needs to be as accurate as possible.

Understood. In the example strategy all decisions about submitting orders are done at the end of the bar.

Both TickReplay and 1 tick intra-bar granularity are necessary to allow your strategy entry to be matched and resumed without a new entry order being submitted.

You have brought up the API (Application Programming Interface) used to connect external applications to interface with NinjaTrader.
Are you not using an internal NinjaScript Strategy and instead sending orders through the API from an external application?

Not using this API. The "API" term is a reference to EntryLong, EntryLongLimit, etc.... the public NinjaScript interface as a whole.

Thank you for working with me and understanding this.
Tim

[NinjaTrader_Kate]

Hello Brillo,

Thank you for your suggestion.

I have added a feature request for this on your behalf. This request is being tracked under the number SFT-4672.

As with all feature requests, interest is tracked before implementation is considered, so we cannot offer an ETA or promise of fulfillment. If implemented, it will be noted in the Release Notes page of the Help Guide.

Release Notes — https://ninjatrader.com/support/help...ease_notes.htm

Please let us know if we may be of further assistance to you.

[Brillo]

Okay. Thank you!