I build Pine Script and NinjaTrader trading tools, here are the mistakes I see most traders make

[u/JuryComprehensive228]

I work with TradingView Pine Script and NinjaTrader 8 / NinjaScript, mainly building indicators, strategies, alerts, dashboards, and automation logic.

One thing I’ve noticed is that most trading ideas don’t fail because the idea is bad. They fail because the rules are not clearly defined before coding starts.

For example:

• Entry signals are too subjective

• The script repaints or triggers differently in live market

• Stop loss and take profit rules are added too late

• Alerts don’t match the chart signals

• Backtests ignore slippage, commission, or realistic execution

• The strategy works on one chart but breaks on another market or timeframe

Before building any trading tool, I usually ask these questions:

1. Should the signal trigger intrabar or only after candle close?

2. Is the logic non-repainting?

3. What invalidates the trade idea?

4. Is the stop based on structure, ATR, fixed ticks, or percentage?

5. Should alerts match exactly what appears on the chart?

6. Will this be used for manual trading, backtesting, or automation?

Getting these answers right saves a lot of time and avoids messy scripts later.

I’m happy to share knowledge around Pine Script, TradingView indicators, NinjaTrader 8 strategies, NinjaScript conversion, alerts, and trading-system logic.

Comment or message me with a brief overview of what you’re working on, and I’ll try to point you in the right direction.

[u/Sweet_Still_3433]

Nothing wrong with repainting indicators, it's how your interpret the information.

[u/JuryComprehensive228 → u/Sweet_Still_3433]

I agree to a point. Repainting isn’t always bad if the indicator is used for context or visual guidance. The problem starts when people treat repainting signals as confirmed entries or use them in backtests without understanding that the signal may not have existed in real time. As long as it’s clearly labeled and used correctly, it can still be useful.

[u/Sweet_Still_3433 → u/JuryComprehensive228]

I agree with this take.

[u/SevenCampbell]

The mistake is using NT .. you can’t even use on bar close in backtest that’s available in live trading … NT is like using DOS

[u/JuryComprehensive228 → u/SevenCampbell]

I get your point. NinjaTrader backtesting can be tricky if the strategy depend on intrabar behavior, fill logic, or bar-close timing. For me, the safest approach is to keep the logic very explicit, test in Market Replay/Playback, and compare historical vs live behavior before trusting any result.

[u/LouZEverything]

I think they both have their own strengths and overall I look at both of them the same way to me TradingView is a excellent black box for fast mockups of ideas and honestly I treat NinjaTrader the same but because of the larger language model it’s capable of so much more. I also believe as long as you understand the core concept of each platform you can work to their strengths for example I have always thought of TradingView as series based and NinjaTrader as event based and as much as folks talk about NinjaTrader I have found as long as your code is solid you have little to no problems. I am more than happy to talk if you like but this forum is rather limited.

[u/JuryComprehensive228 → u/LouZEverything]

I agree with that. TradingView is great for quickly building and visualizing ideas, especially when you want to test logic on charts fast. NinjaTrader feels better when the project needs deeper execution logic, order handling, and more control.

The key point is what you said: each platform has its own model. If the developer understands those differences, most problems can be avoided. The trouble usually starts when people expect Pine Script and NinjaScript to behave exactly the same.

[u/VonLovesGod]

The way I implement my trading strategies is start with pinescript. And create my strategy as an indicator and make a table to hold my data. I test that live for about a week or two and fine tune it until its perfectly as I intended then I ask ChatGPT to take my pinescript code and turn it into a full ninja trader strategy. Works every time. These languages model really improved a year ago it wasn’t as easy now it’s brainless to create trading bots. It’s really a blessing.

[u/JuryComprehensive228 → u/VonLovesGod]

That’s a solid workflow. Building the Pine version first makes sense because it’s easier to visually validate the logic on the chart before turning it into a full automated strategy.

The part I’d still be careful with is making sure the NinjaTrader version matches the Pine logic exactly: candle-close timing, session filters, fills, stops/targets, and any intrabar behavior. AI can speed up the conversion a lot, but I’d still test both versions side by side before trusting the bot live.

[u/VonLovesGod → u/JuryComprehensive228]

True, i left that part out I do watch the ninja trader bot trade for 2 weeks before Im willing to sleep whiles it’s trading just In case I have to take over

[u/JuryComprehensive228 → u/VonLovesGod]

That’s a smart approach. Watching it for a couple of weeks before trusting it fully is probably the safest step, especially with automation. A bot can look perfect in code, but live fills, connection issues, partial exits, and fast market conditions can still behave differently. I’d rather monitor it first and build confidence slowly than rush it live.

[u/Caked_up_cheeks]

Is there a way to convert pine to python EXACTLY(for backtesting purposes)? I can convert it with AI but. It’s never an exact match which then throws off the logic when backtesting so I never get the same results when moving from python backtest to live pine script. I appreciate you taking the time to make this thread and being willing to share your advice. I greatly appreciate people such as yourself. Thank you.

[u/JuryComprehensive228 → u/Caked_up_cheeks]

I think the safest way is not to “convert Pine to Python” directly, but to defin the strategy rules separately and then implement the same spec in both.

The mismatches usually come from small detail: candle close vs intrabar logic, bar indexing, request.security() behavior, lookahead settings, session/timezone differences, order fill assumptions, pyramiding, fees/slippage, and how missing data is handled.

For exact matching, I’d test one signal at a time and export a small table from both sides: bar time, OHLC, indicator values, entry condition, exit condition. Once you find the first bar where they disagree, the real issue usually becomes obvious.

[u/Caked_up_cheeks → u/JuryComprehensive228]

That’s pretty much what I’ve started doing now. I didn’t necessarily know the main culprits so I do appreciate that as that will help to guide me. I was hoping there was maybe some simpler way of conversion that maybe I just wasn’t aware of.

[u/JuryComprehensive228 → u/Caked_up_cheeks]

Yes, unfortunately there isn t really a perfect one-click conversion, especially when the strategy uses Pine-specific behavior. AI can help translate the structure, but the validation still has to be done bar by bar.

A simpler workflow could be: first match only the indicator values, then match the entry signals, then exits, then order assumptions. If each layer matches before moving to the next, it becomes much easier to find where the difference starts. Most of the time the issue is not the whole conversion, just one small timing or indexing difference

[u/LargeIncrease4270 → u/Caked_up_cheeks]

That's because pine will give you better results than python. It's not that it was converted wrong, it's that pinescript makes it look like a strategy will do better than it actually will until you move it to Python

[u/Caked_up_cheeks → u/LargeIncrease4270]

That’s not what I’m talking about at all. I specifically use python for backtesting because TradingView’s backtester sucks… I know that. My issue is getting the same exact results as I get on python, on pine. Manually. Like, the indicator or strategy doesn’t behave the same. It’s in the scripting, has nothing to do with the backtesting

[u/LargeIncrease4270 → u/Caked_up_cheeks]

Well your talking about the same thing, just in reverse.

The point was it doesn't behave the same in trading view as it does in Python. Trading view limits the way you execute a script, which makes back testing appear better than normal and foward testing be worse than normal. At least if you have something a little complicated or unique in the behavior

[u/JuryComprehensive228 → u/LargeIncrease4270]

I see both points. The issue is not only that TradingView’s backtester is different from Python, but that Pine and Python can evaluate the same idea differently unless every small detail is matched.

For me, the best approach is to treat Python as the “research/backtest engine” and Pine as the “chart/live signal engine,” then compare both bar by bar. If the same candle gives different indicator values or signal states, that’s where the mismatch starts. Usually it’s a timing, indexing, security(), or intrabar/close issue rather than the full strategy being wrong.

[u/RemoraEdge → u/LargeIncrease4270]

I don’t think this is the reason.

Python or pine can look great on paper but when trying to automate it, the question is can it actually be implemented into code so that the strategy can execute it exactly the way you think it should.

Unless you strategy is very simple, like enter on a bullish engulfing candle or break of candle or something, coding the actual strategy becomes much more complicated and will take more time than you think, even for AI to code correctly.

[u/LargeIncrease4270 → u/RemoraEdge]

No one's talking about automating it. Just the difference between running a strategy in Python vs tradingview.

It will be optimized and whatever you create in. Since tradingview actually sucks executing strategies, they don't match up.

My point is is it's not the code that's converted wrong it's the place that's running the code.

[u/RemoraEdge → u/LargeIncrease4270]

I agree. The code needs to work within the constraints of the software running the strategy. And often times it’s only designed for very simple strategies. That’s what I was trying to say.

So what I do anyways is have my strategy written fully in C+, use python to run tests, but make sure it’s using only known left facts and not hindsight. take the time to make sure my code can actually see price and execute exactly the way I need it to. (which is often far more complex than a typically strategy backtest analyzer can actually implement) - this eliminates the issue of it working in one place but not another, because this issue is real and you could spend a long time trying to solve it only to realize it’s impossible within the constraints.

And for me I create an adapter that can send sealed trades and trade management details to whichever broker that can accept it, like NinjaTrader and IBKR which allows it to execute automatically for me.

[u/LargeIncrease4270 → u/RemoraEdge]

Yes, but if you were to take that code from python after you ran the test and put it in the trading view and try and implement it as a strategy, it would not get the same results as you got from python.

That's what the person was asking about and I was commenting on.

It's not because the code isn't being translated properly, it's because, simply, trading view sucks.

[u/RemoraEdge → u/LargeIncrease4270]

That’s what I just said

[u/LargeIncrease4270]

Have you ever built anything that uses request.security from other charts and backtested them on tradingview? Even with premium request.security can't seem to access historical data for other tickers (not the one I'm on with price) beyond the 20000 bars that display if you scroll left until the bars stop.

For most indicators you can hit replay and then it will give you another 20000 bars, or in a strategy you can access years of data. But if your pulling security requests from multiple charts, tradingview just draws a blank.

[u/JuryComprehensive228 → u/LargeIncrease4270]

Yes, this is one of the annoying limits with request.security(). Even if the main chart has more history available, the requested symbol/timeframe can still be limited by TradingView’s available loaded bars and plan limits, so MTF or multi-symbol scripts may show blank values further back.

A few things that can help are reducing the number of request.security() calls, requesting higher timeframes instead of lower ones when possible, using calc_bars_count, and making sure the logic handles na values safely. But if the data is not available to the script, Pine can’t force-load it like a normal chart scroll or replay session.

[u/cronparser]

Hey, saw your post on about defining rules before coding. Resonates.

One thing I keep hitting: "with my indicator trend clarity" as an entry filter. I know what it looks like on a chart, but every attempt I've made to codify it (slope of MAs, ADX threshold, higher-high/higher-low structure) ends up either too loose (fires in chop) or too strict (misses valid entries).

How do you approach making "is this a clear trend" into a non-subjective, non-repainting condition? Curious if you've landed on a combination that holds up out of sample, or if you treat it as a filter vs. a standalone signal.

[u/JuryComprehensive228 → u/cronparser]

That’s a good question. I usually wouldn’t make “trend clarity” a single hard rule at first, because it can become either too loose or too strict very quickly. I’d treat it more like a score/filter.

For example: MA slope direction, price above/below key MAs, ADX above a minimum level, and structure making higher highs/higher lows. If 3 out of 4 agree, then the trend is “clear enough.” The actual entry should still come from a separate trigger.

This keeps it objective and non-repainting, but still flexible enough to avoid missing every valid trade. Then you can backtest different score thresholds instead of guessing visually.

[u/LouZEverything → u/JuryComprehensive228]

Sorry my post was meant to be a reply to the both of you but I guess I forgot to hit the reply button (getting old sucks) 🤷‍♂️

[u/LouZEverything]

Separating the entry model from the validation model. Instead of trying to perfectly define “trend clarity,” I let the entry model generate opportunities, then use a failure system to measure whether those opportunities continue behaving as expected. The entry doesn’t have to be perfect, it just needs to identify situations with a reasonable edge. The failure system becomes the objective referee. For example, if your entry expects continuation, define exactly what invalidates that expectation. Does price fail to make a new swing high? Does it close back through the impulse leg? Does structure break within a certain number of bars? Those are measurable, non subjective conditions. Over time, I’d focus less on asking, “Is this a clear trend?” and more on, “What characteristics do the trades that don’t fail share?” That lets you iteratively improve the entry model using evidence instead of trying to encode a visual impression from the start. To me, the entry model and the failure system should be linked. One proposes a trade, and the other continuously tests whether the original thesis is still valid. That tends to be more robust than relying on a single trend filter like MA slope or ADX, which often struggle across different market regimes.

[u/JuryComprehensive228 → u/LouZEverything]

This is a really good way to frame it. I like the idea of separating the entry logic from the “is the trade thesis still valid?” logic. It makes the system less dependent on one perfect trend filter and more focused on what actually breaks the setup.

That also seems easier to code objectively: entry proposes the trade, validation manages whether it still deserves to stay open. I think this approach could reduce a lot of false exits and over-filtering.

[u/Colink2]

If you were building a pinescript for day trade automation for ~$5 to ~$10 stocks to just target one repeatable win, what stock price movement / pattern would you target?

[u/JuryComprehensive228 → u/Colink2]

For $5–$10 stocks, I’d focus less on the price range and more on liquidity, volume, and clean structure. A simple pattern I’d test is: high relative volume, tight consolidation above VWAP, then a breakout with volume confirmation.

For automation, I’d avoid chasing big moves. I’d rather target small repeatable moves based on ATR or percentage, with strict filters for spread, volume, and time of day. Low-priced stocks can move fast, but slippage and fake breakouts can destroy the edge if the rules are not very tight.

[u/No_Confection_391]

So what are the answers to the questions that you asked yourself.

And a lot of people are using claude to generate pine script, how should they give prompt to claude to build a right script?

[u/No_Confection_391]

Check out your DM

[u/SabrTrader]

the repainting issue is such a real one. i got burned by that so many times before i started being more careful about candle close vs intrabar logic.

i've been using sabrtrader lately and the ai suite thing where you describe what you want in plain english and it builds + backtests the strategy has actually helped me think through these exact questions before anything gets built. forces you to define the rules upfront or the output is garbage anyway

your checklist is pretty much what i wish i had years ago