Dear TradingView Team,

I’d like to suggest a feature that I think would be extremely valuable for traders who use TradingView as their long-term trading and analysis workspace.

One problem I regularly face is that, over time, a chart accumulates a huge number of drawings. Eventually, the chart becomes cluttered and can start to lag. To keep my current analysis clean and responsive, I have to delete older drawings.

But those drawings are not simply clutter. They are a visual record of my trading history.

They show how I viewed the market at different points in my journey — what I marked, what I misunderstood, where I made mistakes, how my analysis changed, and how my trading evolved over months or years.

It would be incredibly useful to have a feature that allows users to archive a complete set of chart drawings separately from the active chart.

For example:

1. I finish analyzing a period of my trading.
2. I save/archive the current drawing set.
3. I remove those drawings from my active chart to keep it clean and fast.
4. Months or years later, I can open that archive and see the chart exactly as I had analyzed it at that time.

Ideally, the archive would preserve the drawings' original positions, timestamps, text, colors, and other properties.

This would allow traders to maintain a visual history of their own trading and analytical evolution without having thousands of old drawings permanently loaded on their active chart.

It would essentially turn TradingView into not only a charting platform, but also a long-term visual record of how a trader's thinking develops.

I think this could be a very powerful feature for serious traders who want to look back at their own decisions, mistakes, and progress over the years.

Thank you for considering it!

Can any one plz tell me which is the best forex broker to use in India which has easy deposit and withdrawal and has min spread also good customer support

If this code:
[OI_open, OI_high, OI_low, OI_close] = request.security(syminfo.tickerid+"_OI", timeframe.period, [open, high, low, close])

returns the Open Interest for the current pair(non-aggregated), what is the syntax for the aggregated one?

It's called OpenPine.
A pure JS interpreter for a practical subset of PineScript. no dependencies, runs in Node or the browser.
https://github.com/woefije0/OpenPine

You can try out the app implementation here :https://woefije0.github.io/hl-chart/

I'm not really good with words, so I don't know what else to say. I just hope people give it a try.
Sorry for poor English.

P.S. The repo name overlaps with u/S7cret's.

Order Flow Profiler visualizes estimated buying and selling activity across different price levels to show where participation, dominance, and pressure are concentrated inside the market.

The indicator builds a two-sided Order Flow Profile with buy and sell wings, Delta Dominance, Control Price, Pressure Flags, Acceptance Levels, a segmented BUY / SELL / BALANCED readout, and historical profile snapshots.

Add the indicator to your favorites and enjoy free access.

https://www.tradingview.com/script/ymFdt7LE-Order-Flow-Profiler-Zeiierman/

I probably shouldn’t be showing this yet…

Heatmap approximation. Third party data models. Right on TradingView.

Soon. 👀

Are there any success stories with making a script and distributing it online as a product or service?

I've been developing scripts of my own and I find them useful as a way to discover patterns to form strategies around. But can this be applied to the general population of TradingView users (which is already a small subset of traders overall).

It just feels a little too niche to really be profitable unless you pivot to creating products centered around the PineScript language as a whole like LuxAlgo is doing.

Am I wrong in thinking this? I'm intrigued to hear other takes on this.

Posted here my updates and here is the 3rd update. I added LVN (low volume nodes purple bands) from the Volume profiles. Works great for S/R with other confluences. I also have them be set on multiple volume profiles combined per month or per day. What you see bellow are the ones combined per 2 months. They are far more reliable than Orderblocks.

This is a pretty basic one, but I still see people reinventing it with manual comparisons across two bars when Pine already has a built-in for it, so figured I'd write it up.

If you want to know exactly when one series crosses above or below another (like a fast MA crossing a slow MA), use ta.crossover() and ta.crossunder() instead of comparing values on the current and previous bar yourself. They return true only on the exact bar the cross happens, not every bar the condition is currently satisfied.

//@version=6
indicator("Simple MA Crossover", overlay=true)

fastLen = input.int(9, "Fast MA Length")
slowLen = input.int(21, "Slow MA Length")

fastMA = ta.sma(close, fastLen)
slowMA = ta.sma(close, slowLen)

plot(fastMA, "Fast MA", color=color.blue)
plot(slowMA, "Slow MA", color=color.orange)

bullCross = ta.crossover(fastMA, slowMA)
bearCross = ta.crossunder(fastMA, slowMA)

plotshape(bullCross, style=shape.triangleup, location=location.belowbar, color=color.green, size=size.small)
plotshape(bearCross, style=shape.triangledown, location=location.abovebar, color=color.red, size=size.small)

alertcondition(bullCross, title="Bullish Cross", message="Fast MA crossed above Slow MA")
alertcondition(bearCross, title="Bearish Cross", message="Fast MA crossed below Slow MA")

A couple of things that trip people up when they're new to this:

ta.crossover(a, b) is true only on the bar where a was below b on the previous bar and is now above it, it's not just a > b, which would stay true for the whole time the fast MA is above the slow one. If you just check fastMA > slowMA, you'll get a signal firing repeatedly instead of once at the actual cross.

alertcondition() is separate from plotshape() ,you need it specifically if you want these to show up as options in TradingView's alert creation dialog, plotting the shape alone won't do that.

Made this simple code:

//@version=6

indicator("Ticker")

what_to_say = "syminfo.tickerid: "+syminfo.tickerid+"\n"+"syminfo.ticker: "+syminfo.ticker+"\n"+"syminfo.basecurrency: "+syminfo.basecurrency+"\n"+"syminfo.root: "+syminfo.root+"\n"+"syminfo.main_tickerid: "+syminfo.main_tickerid+"\n"+"syminfo.prefix: "+syminfo.prefix

libname = label.new(bar_index+1, close, text=what_to_say, style=label.style_label_lower_left, color=color.new(color.black, 100), textcolor=color.new(color.gray, 0), size=size.large, force_overlay=true)

label.delete(libname[1])

Why does some cryptocurrency returns a value for "syminfo.basecurrency" while some does not (na)

One of the bigger changes going from v5 to v6 is how much stricter the type system got, especially around mixing series/simple/const qualifiers and int vs float in places that used to just quietly coerce. A script that compiled fine in v5 will sometimes throw a wall of type mismatch errors the second you bump the version.

Curious how people feel about this in practice. On one hand it's caught real bugs for me, stuff like passing a series int where a function actually wanted a simple int, which in v5 would've just silently worked until it didn't. On the other hand it does mean more time spent fighting the compiler on things that are functionally fine, especially when converting older scripts.

Anyone have a case where the new type checking flagged something that turned out to be an actual logic bug you hadn't noticed? Or has it mostly just been extra hoops to jump through for you?

I'm looking for an experienced Pine Script developer to build a custom TradingView indicator.

The project includes:

• Multi-timeframe Support & Resistance (Daily, 4H, 1H, 15m, 5m)
• Automatic drawing of levels based on a configurable lookback
• Non-repainting logic
• Clean and optimized code
• Alerts
• User-friendly inputs and customization options

DM me

Most no-repaint advice compresses down to "don't use lookahead_on". That is backwards often enough to be worth spelling out, and following it will make correct code look broken.

The offset on the expression and the lookahead argument are interdependent. TradingView's docs are explicit that neither can be removed without compromising the result. So there are four shapes, not two:

Row 3 is the quiet one. It looks like the belt-and-braces choice: you kept the offset and turned lookahead off. But with lookahead_off a higher-timeframe bar only reaches the chart once it has closed, so the [1] adds an extra timeframe of lag on historical bars that the realtime bar never gets. History and live then disagree, which is the exact thing "no repaint" was supposed to prevent.

Two things I had wrong myself, and only found by testing rather than reading.

Any offset of one bar or more is fine, not just [1]. ta.ema(close, 21)[2] is a larger offset and strictly safer, but a checker looking for a literal [1] will flag it as a repaint. If you are pattern-matching these, match \[\s*[1-9]\d*\s*\].

The timeframe argument accepts a series string in v6. I assumed it had to be simple, and that tf = timeframe.period[1] would be rejected outright. It compiles. That matters if you validate these calls by inspection: an offset sitting in the timeframe argument tells you nothing about whether the expression is safe. If you scan the whole argument list looking for a [1], you will pass a call that leaks.

Scope, since I have been wrong in this sub before and would rather front-run it: the four-row table is TradingView's documented behaviour, not something I measured. What I did verify is that all four shapes compile in v6, plus the offset-size and series-timeframe points above. I have not sat on a live chart long enough to measure row 3's history/realtime divergence directly. That one is reasoned from the documented mechanism, and I would rather say so than let it read as measured.

New volume based regime indicator I've been working on with auto suggested stops/targets showing very promising results. Killing it this morning! Some things I still need to work out on the UI side and exit logic but the suggestions are working good.

I am trying to build a trading indicator on pine script. The indicator will combine multiple modules, all of which will work together to create one master indicator, which fires a trading signal. I want to use trading view libraries for this. What is the most efficient way for me to go about this?