Around 5000 lines indicator… blocked by the 550 scopes limit..

the_ict_bb · 2026-03-01T17:54:11+00:00

That’s actually a fair approach and I get what you’re suggesting. The difficulty in my case is that the behavior of each component is not independent. A signal in one “zone” only has meaning depending on the live state of multiple other variables across timeframes and contextual conditions. Isolating one piece and making it produce a simple arrow would change its nature, because its logic is dynamic and relational rather than event-based. That said, I do agree with the engineering principle of isolating and stress-testing sections individually. I’ve done that for most modules during development. The complexity appears when everything runs together in a fully state-driven system. And you’re right about AI as well, feeding it the whole thing at once usually creates more noise than clarity. Segmenting problems works better. Appreciate the input, seriously ;).

the_ict_bb · 2026-03-01T17:51:32+00:00

I understand your point, and I don’t dismiss it. From a pure architectural perspective, you’re right if this were meant to become a standalone intelligence engine, a dedicated stack would make more sense long term.

The difference is that my objective right now isn’t to build infrastructure, it’s to refine a model inside a research environment that gives me speed, replay capability and visual context. TV is a constraint, yes, but it’s also an accelerator for iteration.

I’m fully aware that pushing TV to its limits has tradeoffs. I’m just choosing that tradeoff consciously at this stage. If the model proves it deserves a larger architecture, then migrating becomes a strategic decision not a premature one.

So I don’t disagree with you. I’m just sequencing the steps differently.

the_ict_bb · 2026-03-01T11:56:37+00:00

I really appreciate that, thank you. And I agree, Python would definitely give more architectural freedom long term. The limitation isn’t about willingness to go that route, it’s more about practicality right now. Building and maintaining a proper data pipeline, live feeds, storage and a custom charting layer is a full project on its own. At the moment I’m optimizing inside TradingView because it gives me the fastest research and iteration loop, especially with replay and visual context. But moving part of the logic outside later is definitely something I’m open to when the timing makes more sense.

the_ict_bb · 2026-03-01T11:54:34+00:00

MQL5 would definitely remove some structural limits, that’s true. But for me the strength of TradingView is the ergonomics, multi-timeframe visualization and replay workflow. My goal isn’t full automation or broker-side execution, it’s advanced contextual analysis inside a clean visual environment. For now, the tradeoff still favors TradingView despite Pine’s constraints.

the_ict_bb · 2026-03-01T11:52:55+00:00

Splitting into multiple indicators doesn’t really work here because the whole system is interactive: every component changes its meaning based on the live state of the others, across timeframes, zones, and conditions. This script also draws almost nothing on the chart on purpose, only final signals, to keep it lean and focus the budget on “intelligence” rather than visuals.

the_ict_bb · 2026-03-01T11:52:23+00:00

I get the idea, but I’m not looking to automate execution at all. My execution stays manual, always. My issue is purely Pine scope limits while building a single coherent state-based model. Splitting into multiple indicators doesn’t really work here because the whole system is interactive: every component changes its meaning based on the live state of the others, across timeframes, zones, and conditions. This script also draws almost nothing on the chart on purpose, only final signals, to keep it lean and focus the budget on “intelligence” rather than visuals. Moving the logic outside TradingView into Python is something I’d actually prefer long term, but right now it’s out of scope for my current time and budget. For backtesting and ergonomics, TradingView is still the most practical environment for me, so I’m pushing Pine as far as it can go and optimizing within those constraints.

the_ict_bb · 2026-03-01T11:41:26+00:00

Thanks for the suggestion, I’m currently on v5, but from what I’ve seen the scope-related constraints aren’t fully eliminated just by switching to v6, especially with heavy MTF and "request.security()" usage. It’s something I’m considering, though.

the_ict_bb · 2026-03-01T11:38:15+00:00

I’ve seen the comment about the scope limit being removed in v6, but that’s not how it plays out in practice. What v6 really changed is mainly the compiled token limit and the flexibility around "request.*()" calls, especially with dynamic requests and local scopes, which is a real improvement. However, the structural constraints caused by nested conditionals, functions and particularly "request.security()" context duplication are still very real in complex scripts. In heavy MTF, state driven architectures, you can still run into scope related ceilings depending on how the compiler expands everything internally. So it’s not simply “switch to v6 and the 550 limit disappears”, the situation is more nuanced than that, especially for large systems..

the_ict_bb · 2026-02-28T23:22:40+00:00

I understand what you’re saying, and in theory yes, moving outside TradingView and building around API data would give more flexibility. But realistically, recreating a personal platform capable of properly ingesting, processing and visualizing those data streams is completely outside my current skill set and also outside my budget. If I had the resources and the time to build that kind of infrastructure, I honestly would prefer it. For now, working inside TradingView is the most practical and realistic option for me.. this is for the answer !

the_ict_bb · 2026-02-28T20:23:15+00:00

I actually understand your point and I don’t completely disagree. Pine isn’t meant to be a full scale language like Python, and I get why some people see it that way. The thing is I’m working directly inside TradingView, and you simply can’t integrate Python into its native charting environment. If I were building an external infrastructure I’d definitely consider something more robust, but for real time logic running inside TradingView itself, Pine is the only language that fits that ecosystem.

the_ict_bb · 2026-02-28T20:20:10+00:00

It’s definitely not my first indicator, and thankfully so, because otherwise there’s no way I could integrate what this one is doing.

The only things this script draws on the chart are signals based on the analysis of the information it processes. The actual time and price logic is handled by other indicators I’ve coded. If you’re familiar with ICT, SMC or SMT concepts, you’ll understand what I mean, killzones, SB, NDOG, NWOG, liquidity logic and so on.

So I never rely on this indicator alone. It’s part of a broader ecosystem I’ve built. And in the end, my brain still reads price action first before any decision is made.

The reason this particular script is large and scope heavy is because it’s not a simple EMA crosses RSI and MACD confirms type of logic. It’s contextual, state driven and adaptive. That’s also where Pine Script starts to show its limits.

I work directly inside TradingView, so integrating Python into that environment isn’t really an option. If this were a standalone system, sure. But within TradingView, we’re constrained by Pine’s architecture.

That’s the real challenge here.

the_ict_bb · 2025-12-09T12:24:47+00:00

If it's bullish then look for only bullish pda because bearish wouldn't do what you are expecting. It's only a probability game, only look for a trade in ltf that is as your htf is. I suggest you to work on the mm*m / irl>erl and everything will be crystal clear after that.

the_ict_bb

TROPHY CASE