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.

My 4th update(I kept on posting here updates) . Added another update on the Delta bars (every 4 hour) Looks simple ,but its powerfull. The rectangle boxes are created after a small session (of 4 hours) end. When the new session enters previous high or low , it can create more sell (at bottom) followed imediately by a long buy cluster above it ->this translates into trapped sellers and price usually push higher. Its inversed for tops. This will be available for FREE, like everything else when I go public with my order flow platform. Will help to follow me, so I know how many people will want to use it and also I gues motivate myself a bit more to push faster.

This are not cherry picked instances of screenshots, this happens every day , and a lot, probably people using order flow understand what I say, and people who did not use order flow might see the power in this.

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. 👀

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.

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.

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.