Rozpocznij

Repainting

BTC Sniper Signals (High Accuracy, No Repaint)High-accuracy BTC signals built to catch real moves — not fakeouts. This system focuses on: trend continuation entries liquidity grabs (smart money moves) momentum confirmation precise entry timing It avoids: late signals choppy conditions overextended entries What makes it different: dynamic scoring system smart filters instead of lagging confirmations built specifically for BTC behavior ✔ No repaint ✔ Fast signals for 5m–1H ✔ Designed for consistency, not noise
Wskaźnik Pine Script®
od bretthenderson883
Buy/Sell Pressure Meter [AGPro Series]Buy/Sell Pressure Meter 🔹 Overview Buy/Sell Pressure Meter is a volume-flow analytics tool that quantifies the tug-of-war between buyers and sellers on every bar and on a rolling basis. Unlike traditional volume delta indicators that only plot raw bar-level buy minus sell, this tool layers four complementary lenses into a single oscillator: rolling pressure trend, imbalance streak tracking, intraday pressure shift count, and session-accumulated dominance. A subtle price-pane background tint gives a Bookmap-light read on intraday participation that works across crypto, futures, and liquid equities — without requiring tick-level order flow data. 🔹 Unique Edge Most volume-delta scripts answer the question "which side was bigger on this bar?" This one answers a different, more useful question for intraday traders: "who has been in control, and how stable is that control?" • Rolling Pressure Trend — a moving average of buy and sell pressure separately (dual histogram), so you see structural bias, not just bar-to-bar noise. • Imbalance Streak Tracking — counts consecutive same-side dominant bars and labels only the final length of each significant streak at the moment the streak breaks. No per-bar label spam, one clean marker per event. • Intraday Pressure Shift Count — how many times the rolling dominant side has flipped since session open. High shift count = rotational day. Low shift count = trending day. • Session-Accumulated Net Delta — cumulative bull vs bear contribution since the day began, independent of the rolling window. • Price-Pane Bookmap-Light Tint — a very high-transparency background tint paints the main chart pane when one side is rolling-dominant, so you see control visually without leaving the price chart. These five lenses together are deliberately designed not to overlap with raw volume-delta or cumulative-volume-delta indicators. They describe the character of participation, not just its magnitude. 🔹 Methodology Because standard chart data does not include true tick-level order flow, this script uses a widely-accepted proxy: up-bar volume is attributed to buy pressure, down-bar volume to sell pressure, and doji volume is split evenly. This is explicitly a simulated bias — not real bid/ask flow — and the script labels it as such in the panel. From that proxy: 1. Current-bar bull pressure percentage = buyPressure / (buyPressure + sellPressure) × 100. 2. Rolling pressure = SMA of buy and sell pressure over the user-defined window (default 20 bars). 3. A bar is classified bull-dominant when its bull pressure percent exceeds the dominance threshold (default 55%), and bear-dominant at the mirror level. 4. Streaks count consecutive bars of the same classification and reset when a neutral or opposite bar prints. Peak length is captured at the moment of reset and optionally labelled on chart. 5. Pressure shifts compare the current rolling dominant side against the last confirmed non-neutral dominant side; a change increments the intraday shift counter (only on intraday timeframes). 6. Session delta is the cumulative net delta since the last daily rollover. 🔹 Signals & States • Dual histogram — buy pressure (teal, upward) and sell pressure (pink, downward) plotted as rolling averages. • Net delta center line — accent-colored line showing rolling buy minus sell. • Price-pane background tint — subtle teal or pink when one side is rolling-dominant, gives a Bookmap-light feel without obscuring candles. • Oscillator-pane echo tint — even more subtle tint mirroring the dominant side in the indicator pane. • Shift markers — triangles on the pane when the dominant side flips. • Streak peak labels — plotted only at streak termination, showing final length (e.g. "Bull 7"). • Alerts — pressure shift to bull, pressure shift to bear, bull imbalance streak, bear imbalance streak. 🔹 Key Inputs Calculation: • Rolling Pressure Length — default 20. Higher = smoother, slower reaction. • Minimum Streak To Highlight — default 3. Used for alerts. • Dominance Threshold — default 55%. Share of total pressure needed to classify a bar as dominant. Visuals: • Tint Price Pane On Dominance — toggles the Bookmap-light effect on the main chart. • Show Streak Peak Labels + Minimum Streak Length To Label (default 5) — controls chart cleanliness. • Show Pressure Shift Events — triangle markers on shifts. • Background Tint Transparency — default 94, adjustable 80-99. Panel: • Panel Location, Theme (Dark / Light), Font Size, Label Font Size — all default to Normal and fully configurable. 🔹 How To Use This is an analytical tool, not a standalone trading system. Typical use cases: • Confirmation — when price breaks a structure level while the rolling net delta is strongly in the break direction and a streak is in progress, the break has participation behind it. • Exhaustion — a long bull streak peak followed by a rolling shift to bear, or vice versa, often marks the end of the current impulse. • Regime read — a day with many intraday pressure shifts is rotational; a day with 0-1 shifts is directional. Adjust your playbook accordingly. • Companion to S/R, supply/demand, and volume profile tools — use the streak peak and shift events as a participation filter when price interacts with a zone. Best results on liquid instruments with meaningful bar-to-bar volume variation. Low-volume illiquid tickers produce noisier readings. 🔹 Limitations & Transparency • The buy vs sell attribution is a proxy derived from bar direction and bar volume. It is not real order flow, Level 2, or tick data. Bookmap, CVD from exchange feeds, and footprint tools access information that bar-level scripts structurally cannot replicate. • On instruments or timeframes where many bars close near their open (doji-heavy regimes), proxy-based attribution becomes less informative. • The intraday shift counter is only meaningful on intraday timeframes; on daily-and-above timeframes the panel explicitly shows this as n/a. • The script is non-repainting on closed bars. Intrabar values update in real time and may change until the bar confirms. • Pressure shifts and streaks describe past and current state. They are not predictions of future price. 🔹 Risk Disclosure This script is provided as an analytical tool for educational and research purposes. It does not constitute financial advice, a trading signal, or a recommendation to buy or sell any asset. Past performance of any pattern, streak, or shift event does not guarantee future results. Users are solely responsible for their own trading decisions and risk management. Always combine any indicator with broader market context, position sizing discipline, and your own due diligence.
Wskaźnik Pine Script®
od AGProLabs
2
Realtime Non-Repaint PathName: Realtime Non-Repaint Path Searchable Name: Realtime Non-Repaint Path Technical name: Realtime Non-Repaint Percentage-Reversal Path Short title: RT NR Path Summary Realtime Non-Repaint Path is a standalone path-visualization and path-state script designed to show live non-repainting directional path structure and a simplified hidden path reveal. It uses a percentage-reversal path model to classify live path direction, maintain a live anchor/candidate structure, draw a live eased path, rebuild a simplified hidden path from reversal pivots, and display state labels, alerts, and a compact status table. Its strongest advantages are live path clarity, non-repainting state transitions on closed bars, simpler path interpretation, and visual structure that can complement entry-focused scripts. Its main known weakness is that it is not a full trading engine: it does not perform full pivot confirmation, trade management, advanced filtering, replay-state reconstruction, or broader regime/stat handling. This script is best understood as a path-focused operational visualization and state-classification script rather than a complete trading engine. It is designed to be useful on its own while remaining simple enough to inspect, test, and modify. How it works The script begins with a simple percentage-reversal path model. It tracks a live anchor price, a live candidate extreme, and a current live path direction. When price moves far enough away from the current anchor by the user-defined reversal percentage, a live directional path is established. As long as price continues making new extremes in that direction, the live candidate continues updating. When price reverses enough from that candidate extreme by the same percentage threshold, the live path flips and a new anchor/candidate cycle begins. The displayed live path is not drawn as a raw straight jump between points. Instead, it is eased between the current live anchor and live candidate so that the path remains visually readable while still staying tied to the current live state model. Because the live state is updated bar by bar using only information available so far, the live path is intended to function as a non-repainting path-state view on closed bars rather than as a hindsight-only reconstruction. In addition to the live path, the script can also reveal a simplified hidden path. That hidden path is rebuilt from percentage-reversal pivots over a user-defined recent history window. It detects reversal pivots using the same percentage-reversal logic and then draws an eased pivot-to-pivot hidden path across the selected history range. This keeps the script path-focused, visually useful, and easier to interpret. The script also displays optional confirmed turn labels, a last-bar live state label, path-up/path-down alerts, background coloring based on current path direction, and a compact status table showing the current live state, anchor, candidate, and percentage distances. These features make it useful as a visual path-state companion script rather than as a full signal-and-execution engine. Path model note This script’s path model is based on percentage reversal. That makes it intentionally simpler and easier to understand, but it also means it does not attempt to replicate the broader complexity of a full trading engine. The hidden path shown here should be interpreted as a simplified path reveal, not as a complete trade-selection or execution model. Features Live non-repainting path state machine User-defined percentage reversal threshold Live anchor and candidate path structure Eased live path display Simplified hidden path reveal over recent history Confirmed path turn labels Last-bar live state label Background coloring by live path direction Path-up and path-down alerts Compact status table with anchor/candidate/path-distance information Strengths Path Clarity edge — provides a cleaner live view of path direction than raw candles alone. Non-Repainting State edge — live path direction and flips are based on the current bar-by-bar percentage-reversal model rather than hindsight-only reconstruction. Simplicity edge — simpler structure makes it easier to inspect, test, and modify. Companion Script edge — pairs naturally with entry-oriented scripts by showing whether path direction is currently up, down, or neutral. Visual Structure edge — live path, hidden path, labels, background, and status table make path structure easier to read quickly. Interpretability edge — the script is straightforward enough to be useful as both a live visual aid and a path-study tool. Weaknesses Not a full trading engine weakness — does not include full trade management, entry/exit handling, or execution logic. No advanced filtering weakness — does not include broader filtering or replay/stat reconstruction layers. Threshold sensitivity weakness — path behavior depends heavily on the user-selected reversal percentage, so different settings can materially change the path and turn structure. Path-state, not profit-state weakness — path direction does not guarantee profitable entries or strong follow-through. Simplified hidden path weakness — the hidden path is intentionally simplified and should not be mistaken for a complete internal market model. No regime/stat engine weakness — does not contain broader regime scoring, detailed replay diagnostics, or a larger state/stat engine. Who it’s for This script is best suited for traders and TradingView users who want a simpler live path script, users interested in non-repainting path direction on closed bars, users who want a visual companion to entry-focused scripts, users who want to inspect market path structure with less complexity than a full trading engine, and users interested in learning from or modifying a smaller path-focused script. It is especially suited for users who want a practical path/state layer rather than a complete trading engine. Who it’s not for This script is not best suited for: users looking for a complete pre-built trading engine users expecting advanced pre-entry classification users expecting full entry/exit/trade management users looking for advanced regime, replay, and state/stat reconstruction users expecting this script by itself to solve the false-pivot or follow-through problem users looking for a complete trade-selection and execution workflow rather than a smaller standalone path script Known limitations Realtime Non-Repaint Path is much better at showing live path direction and simplified path structure than it is at acting as a complete trading system. The live path is driven by a percentage-reversal state machine and the hidden path is rebuilt from simplified percentage-reversal pivots with eased pivot-to-pivot connections. Because of that, it should be viewed primarily as a path/state visualization and classification script, not as a complete trade-selection or execution engine. Different reversal-percentage settings can also materially change how often the path flips and how sensitive the script is to movement. Final note This is a standalone path script, not a guaranteed predictive system and not a full operational trading engine. Its strengths are concentrated in live path visibility, simplified hidden path structure, non-repainting state handling on closed bars, and quick visual interpretation. It is best used as a path-focused companion or as a simpler standalone script for studying live path behavior rather than as a substitute for a more complete engine.
Wskaźnik Pine Script®
od AceInfinity
Hodrick-Prescott filter [Jamallo](2025) Intro The Hodrick-Prescott (HP) filter is a tool originally developed by economists to remove short-term noise from data and reveal the underlying long-term trend — think of it like a moving average, but mathematically smarter. Instead of just averaging recent prices, it solves for the smoothest possible trendline that still follows the data. Applied to price, it produces a cleaner baseline than most traditional moving averages. --- However it comes with 3 problems in practical day trading. Problem #1 Standard HP Repaints History (core issue) The standard HP filter is non-causal — the value at any point in time depends on future values CEPR, meaning past signals can change retroactively. How I solved it: Switching to a one-sided implementation fixes this — it only looks at past data, so history never changes once a bar closes. Problem #2 One-Sided HP Hooks at Turns Going one-sided introduces an endpoint artifact — near turning points the trend line briefly curves in the wrong direction before reversing, producing a false signal. How I solved it: Feeding the HP output into a range filter solves this. The line only moves when HP breaks outside a volatility band, so the false hook gets absorbed into a flat zone and never fires a signal. Problem #3 Fixed Band Would Be Too Rigid A fixed band would whipsaw in volatile markets and lag in calm ones. How I solved it: Instead the band is sized dynamically using a percentile of True Range, scaling automatically with current market conditions.
Wskaźnik Pine Script®
od Jamallo22
Auto Trend Drawing [LuxAlgo]The Auto Trend Drawing indicator summarizes price action into a smooth, continuous curve that highlights the primary market direction and structure. It is mostly a fun and silly experiment in reproducing users attempts at drawing trends on the chart using the brush tool. This indicator is subject to repainting and is displayed retrospectively based on the most recent price data. 🔶 USAGE The Auto Trend Drawing tool provides a clean, visual representation of the current market "flow" by stripping away minor price noise and focusing on significant pivot points. Traders can use this indicator to quickly identify the prevailing trend, potential trend reversals, and the overall rhythm of the market. Unlike standard trendlines that connect two specific points, this indicator creates a dynamic curve that adapts to the most significant price movements within a user-defined window. 🔹 Trend Identification Bullish Flow: When the curve is sloping upward and the price generally stays above or near the curve's trajectory. Bearish Flow: When the curve is sloping downward and the price remains below or near the curve's trajectory. Consolidation: When the curve flattens out, indicating a lack of clear directional momentum. 🔶 DETAILS The script employs a multi-step process to generate the trend curve: Normalization: Price data is normalized using the Average True Range (ATR). This ensures that the simplification process remains consistent across different assets and timeframes regardless of their volatility. Ramer-Douglas-Peucker (RDP) Algorithm: This algorithm identifies the most "important" anchor points in the price series by recursively simplifying the path. It removes points that deviate less than a certain threshold (set by the Simplification Multiplier) from a straight line. Catmull-Rom Splines: Once the key anchor points are identified, the script uses Catmull-Rom spline interpolation to connect them. This creates a smooth, aesthetic curve that passes through every identified anchor point, providing a more "organic" look than jagged lines. 🔶 SETTINGS Window Size: Determines the number of recent bars the indicator analyzes to build the curve. Simplification Multiplier: Controls the sensitivity of the trend detection. Higher values filter out more noise, resulting in a smoother, more "macro" curve. Lower values allow the curve to follow price more closely. ATR Length: The period used for the ATR normalization process. Curve Tension: Adjusts how tightly the spline curve follows the anchor points. A value of 0.5 is centripetal, while higher or lower values change the curvature between points. Curve Resolution: Sets the number of sub-points calculated between each anchor. Higher values result in a smoother-looking line. Line Color: Changes the color of the trend curve. Line Width: Adjusts the thickness of the displayed curve.
Wskaźnik Pine Script®
od LuxAlgo
1
LOWESS Channel & Extrapolation [LuxAlgo]The LOWESS Channel & Extrapolation indicator calculates a Locally Weighted Scatterplot Smoothing (LOWESS) curve to define a non-linear trend and projects it into future bars using local regression slopes. It provides a dynamic channel based on the standard deviation of residuals, helping traders identify overextended price levels and potential mean-reversion points. The LOWESS Channel & Extrapolation indicator is subject to repainting and displayed retrospectively. 🔶 USAGE This tool is primarily designed for trend analysis and identifying exhaustion points. Because the LOWESS algorithm recalculates based on the most recent data window, the entire historical curve can adjust, making it a powerful tool for backtesting and analyzing past market structures rather than for real-time signal generation without confirmation. 🔹 Trend Identification The central fit line represents the smoothed local trend. When the curve is sloping upward, the local market sentiment is considered bullish; conversely, a downward slope indicates bearish sentiment. 🔹 Overbought/Oversold Conditions The dashed outer channels represent a volatility-adjusted boundary. When price moves outside these boundaries, it is statistically overextended relative to the local trend, often preceding a move back toward the mid-line. 🔹 Extrapolation The indicator extends the most recent local regression slope into the future. This provides a "path of least resistance" projection based on the current momentum of the smoothed curve. 🔶 DETAILS The LOWESS (Locally Weighted Scatterplot Smoothing) algorithm works by performing a separate weighted linear regression for every data point in the window. It uses a "tricube" weighting function, which ensures that data points closer to the focal point have a higher influence on the fit than points further away. This results in a curve that is much more flexible than a simple moving average and can adapt to complex price cycles without the lag associated with traditional filters. The channel width is determined by calculating the Standard Deviation of the residuals (the difference between the actual price and the LOWESS fit). This ensures the channel expands during high volatility and contracts during consolidation. 🔶 SETTINGS Length : Determines the number of historical observations used to fit the LOWESS curve. Larger values result in a smoother, more macro trend. Span : The fraction of data points used for each local regression. A higher span (closer to 1.0) creates a smoother line, while a lower span allows the curve to follow price more tightly. Channel Multiplier : Multiplier applied to the standard deviation of residuals to define the distance of the upper and lower bands from the mid-line. Extrapolation Bars : The number of bars to project the current trend into the future. Fit Color : Sets the color and transparency of the central LOWESS line. Channel Color : Sets the color of the dashed outer bands and the background fill. Line Width : Adjusts the thickness of the central fit line.
Wskaźnik Pine Script®
od LuxAlgo
Whittaker Envelope [LuxAlgo]The Whittaker Envelope indicator is a visualization tool that uses Asymmetric Least Squares (ALS) to create a smooth, non-linear envelope that adapts to price extremes and troughs. This indicator is for visualization purposes only and should not be used for direct trading signals without confirmation. It is important to note that this script is displayed retrospectively . Because it calculates the best fit over a fixed historical window (the last N bars) using an iterative optimization process, the entire shape of the envelope can change as new data arrives. This means the indicator repaints and should be used to analyze overall market structure and volatility rather than for real-time execution. 🔶 USAGE The Whittaker Envelope provides a unique way to visualize the "breathing" of the market. By applying different asymmetry parameters, the indicator generates a lower boundary that seeks out price troughs and an upper boundary that seeks out price peaks. 🔹 Trend and Volatility Analysis The area between the upper and lower bounds represents the smoothed price range. A widening envelope suggests increasing volatility, while a narrowing one indicates consolidation. The dashed midline acts as a smoothed average of these two extremes, providing a baseline for the current trend. 🔹 Extrapolation The tool includes a linear extrapolation feature that projects the current trajectory of the envelope into the future. This can help users visualize the potential direction of the trend if the current momentum persists. 🔶 DETAILS The script implements the Whittaker-Eilers smoothing algorithm, which balances two conflicting goals: fitting the data points closely and keeping the resulting curve smooth. By using Asymmetric Least Squares (ALS), we assign different weights to prices depending on whether they are above or below the curve. For the upper band, we use a high asymmetry value ( p ) so the curve is "pushed" toward the peaks. For the lower band, a very low p value is used to "pull" the curve toward the troughs. 🔶 SETTINGS Length : The number of recent bars included in the calculation window. Lambda (λ) : The smoothing factor. Higher values result in a stiffer, straighter envelope, while lower values allow the bands to follow price more closely. Lower Asymmetry (p) : Controls how the lower band reacts to prices. Typically set to a very low value (e.g., 0.001) to ensure it follows the bottom of the price action. Upper Asymmetry (p) : Controls how the upper band reacts to prices. Typically set to a very high value (e.g., 0.999) to ensure it follows the top of the price action. Iterations : The number of times the ALS algorithm runs to refine the fit. More iterations provide a more accurate envelope but require more computational power. Extrapolation : The number of bars to project the current slope of the bands into the future. Source : The price data used for the calculation (default is Close).
Wskaźnik Pine Script®
od LuxAlgo
Price Simplification [LuxAlgo]The Price Simplification indicator provides a streamlined representation of price action by reducing complex market movements into essential trend segments using the Ramer-Douglas-Peucker (RDP) algorithm. This indicator calculates its output based on a fixed window of historical data. Consequently, the line segments are displayed retrospectively and are subject to repainting as new bars develop and the calculation window shifts. 🔶 USAGE The indicator is designed to help traders identify the core structure of price movement by filtering out "noise"—small fluctuations that do not significantly impact the overall trend. By simplifying the price into a series of connected segments, it becomes easier to visualize support/resistance levels, trend slopes, and market geometry. Users can adjust the level of simplification to suit their needs: A lower ATR Multiplier will result in a line that follows price closely, capturing more minor swings. A higher ATR Multiplier will produce a more aggressive simplification, highlighting only the most significant market turns. 🔹 Extension Line The script includes an "Extend Last Segment" feature. When enabled, it projects the trajectory of the final simplified segment into the future using a dashed line. This projection begins one bar after the most recent data point, providing a visual guide for the current price momentum without overlapping the historical simplification. 🔶 DETAILS The core logic of this tool relies on the Ramer-Douglas-Peucker (RDP) algorithm, a classic algorithm used in computer graphics and cartography to reduce the number of points in a curve. The algorithm works through an iterative process: It starts with a line segment connecting the first and last points of the lookback window. It identifies the point between these two ends that is furthest from the segment (perpendicular distance). If this maximum distance is greater than a specified threshold, that point is kept as a "key point," and the algorithm splits the segment into two parts, repeating the process for each. If no point is further than the threshold, all intermediate points are discarded, and the segment remains a straight line. To ensure the simplification remains consistent across different assets and timeframes, the script normalizes price coordinates using the Average True Range (ATR) . This means the threshold for keeping a point is relative to the current market volatility rather than a fixed price value. 🔶 SETTINGS Window Size : The number of recent bars used to apply the RDP algorithm to. ATR Multiplier : The sensitivity of the simplification. Higher values lead to fewer segments and a simpler line. ATR Length : The period used to calculate the ATR for price normalization. Line Color : The color of the simplified polyline. Line Width : The thickness of the polyline and extension. Extend Last Segment : When enabled, projects the slope of the final segment forward as a dashed line starting one bar after the last point.
Wskaźnik Pine Script®
od LuxAlgo
Market Acceptance Envelope [Interakktive]The Market Acceptance Envelope (MAE) is a diagnostic tool that shows where price statistically belongs — not where it might go. Unlike traditional bands that expand with volatility, MAE expands with acceptance: regions where price rotates comfortably, efficiency drops, and the market agrees on fair value. This is the anti-Bollinger thesis: bands should represent where price IS accepted, not where it MIGHT reach based on standard deviation. █ USAGE The filled corridor represents the current acceptance zone — where price has demonstrated rotational behavior with low directional efficiency. When price is inside the corridor, it's "home." When outside, it's exploring territory the market hasn't yet accepted. For discretionary traders, MAE provides instant context: "Is price where it belongs, or is it extended?" For systematic traders, the exported values (confidence, asymmetry, position) can inform position sizing and filter logic. █ ACCEPTANCE CENTROID Unlike traditional bands centered on a moving average, MAE uses an Acceptance Centroid — a time-weighted price level where acceptance behavior concentrates. The centroid is calculated by weighting price by: • Inverse efficiency (low efficiency = high acceptance) • Volatility stability (stable vol = higher weight) • Dwell factor (time spent near level) This means the centroid drifts toward where price actually rotates, not simply where it averages. █ ASYMMETRIC BOUNDARIES MAE calculates upper and lower boundaries independently. Markets rarely treat up and down equally — during uptrends, the upper boundary may be wider (more accepted upside exploration), while the lower boundary stays tight (quick rejection of dips). This asymmetry is visible on the chart and exported as a metric (-1 to +1). █ CONFIDENCE-BASED VISIBILITY The corridor's opacity reflects acceptance confidence: • High confidence → clearly visible corridor (price is in accepted rotation) • Low confidence → faded corridor (trending/directional market, acceptance not established) When the corridor fades, it's telling you: "Acceptance hasn't been earned here yet." █ WHAT THIS INDICATOR IS • A diagnostic acceptance envelope showing where price statistically belongs • Asymmetric by design — upper and lower calculated independently • Confidence-weighted visibility — fades when acceptance is not earned • Non-repainting — uses closed-bar data only █ WHAT THIS INDICATOR IS NOT • NOT Bollinger Bands (no standard deviation around a mean) • NOT Keltner Channels (no ATR-scaled envelope) • NOT a signal generator — no touches = signals philosophy • NO arrows, NO entries/exits, NO buy/sell recommendations █ HOW IT WORKS MAE uses an acceptance-weighted calculation approach: 1. ACCEPTANCE WEIGHT Each bar receives a weight based on: • Efficiency: (1 - efficiency) — low efficiency = rotational = high acceptance • Volatility Stability: stable vol environment = higher weight • Dwell Factor: price staying near central tendency = higher weight 2. ACCEPTANCE CENTROID Weighted average of price using acceptance weights: centroid = Σ(price × weight) / Σ(weight) Smoothed adaptively — faster during drift, slower when stable. 3. ASYMMETRIC BOUNDARIES Upper and lower distances calculated separately: • rngUp = acceptance-weighted average of (price - centroid) when price > centroid • rngDn = acceptance-weighted average of (centroid - price) when price < centroid 4. CONFIDENCE SCORE Composite of average acceptance weight, volatility stability, and centroid stability. Maps to corridor opacity: high confidence = visible, low confidence = faded. █ SETTINGS Market Acceptance Envelope — Core • Acceptance Lookback (20): Bars to evaluate for acceptance conditions. Higher = smoother, slower response. • Preset (Swing): Scalper = tight/fast, Swing = balanced, Position = wide/stable. • Envelope Sensitivity (1.0): Width multiplier. Higher = wider corridor. Market Acceptance Envelope — Visuals • Show Corridor (true): Display the acceptance corridor. • Show Centroid (false): Display the acceptance centroid line. Market Acceptance Envelope — Data Window • Show Data Window Values (false): Export MAE metrics for external use. █ EXPORTED VALUES When Data Window is enabled: • mae_upper: Upper boundary value • mae_lower: Lower boundary value • mae_centroid: Acceptance centroid value • mae_width: Corridor width (upper - lower) • mae_asymmetry: Asymmetry ratio (-1 to +1, negative = lower wider) • mae_confidence: Acceptance confidence (0-100) • mae_position: Price position (-1 = below, 0 = inside, +1 = above) █ SUITABLE MARKETS Works on all markets: Stocks, Futures, Forex, Crypto, Indices. Works on all timeframes. Higher timeframes show more stable acceptance zones. █ DISCLAIMER This indicator is for educational and informational purposes only. It does not constitute financial advice. Past performance does not guarantee future results. Always conduct your own analysis and use proper risk management. This is a diagnostic tool — it provides context, not signals.
Wskaźnik Pine Script®
od Interakktive
2
Continuation Suite v1 — 5m/15mContinuation Suite v1 — 5m/15m (Non-Repainting, S/R + Trend Continuation) What it does Continuation Suite v1 is a practical intraday toolkit that combines non-repainting trend-continuation signals with auto-built Support/Resistance (S/R) from confirmed pivots. It’s designed for fast, liquid names on 5m charts with an optional 15m higher-timeframe (HTF) overlay. You get: stacked-EMA bias, disciplined pullback+reclaim entries, optional volume/volatility gates, a “Strong” signal tier, solid S/R lines or zones, and a compact dashboard for fast reads. ⸻ Why traders use it • Clear bias using fast/mid/slow EMA stacking. • Actionable entries that require a pullback, a reclaim, and (optionally) a minor break of prior extremes. • Signal quality gates (volume vs SMA, ATR%, ADX/DI alignment, EMA spacing, slope). • Non-repainting logic when “Confirm on Close” = ON. Intrabar previews show what’s forming, but confirmed signals only print on bar close. • S/R that matters: confirmed-pivot lines or ATR-sized zones, optional HTF overlay, and auto de-dup to avoid clutter. ⸻ Signal construction (no magic, just rules) Bullish continuation (base): 1. Trend: EMA fast > EMA mid > EMA slow 2. Pullback: price pulls into the stack (lowest low or close vs EMA fast/mid over a lookback) 3. Reclaim: close > EMA fast and close > open 4. Break filter (optional): current bar takes out the prior bar’s high 5. Filters: volume > SMA (if enabled) and ATR% ≤ max (if enabled) 6. Cooldown: a minimum bar gap between signals Bearish continuation (base): mirror of the above. Strong signals: base conditions plus ADX ≥ threshold, DI alignment (DI+>DI- for longs; DI->DI+ for shorts), minimum EMA-spacing %, and minimum fast-EMA slope. Reference stops: • Longs: lowest low over the pullback lookback • Shorts: highest high over the pullback lookback Alerts are included for: Bullish Continuation, Bearish Continuation, STRONG Bullish, STRONG Bearish. ⸻ S/R engine (current TF + optional HTF) • Builds S/R from confirmed pivots only (left/right bars). • Choose Lines (midlines) or Zones (ATR-sized). • Zones merge when a new pivot lands near an existing zone’s mid (ATR-scaled epsilon). • Touches counter tracks significance; you can require a minimum to draw. • HTF overlay (default 15m) draws separate lines/zones with tiny TF tags on the right. • De-dup option hides current-TF zones that sit too close to HTF zones (ATR-scaled), reducing overlap. • Freeze on Close (optional) keeps arrays stable intrabar; snapshots show levels immediately as bars open. ⸻ Presets • Auto: Detects QQQ-like tickers (QQQ, QLD, QID) or SoFi; else defaults to Custom. • QQQ: Tighter ATR% and EMA settings geared to index-ETF behavior. • SoFi: Wider ATR allowances and longer mid/slow for single-name behavior. • Custom: Expose all key inputs to tune for your product. ⸻ Dashboard (top-right) • Preset in use • Bias (Bullish CONT / Bearish CONT / Neutral) • Strong (Yes/No) • Volatility (ATR% bucket) • Trend (ADX bucket) • HTF timeframe tag • Volume (bucket or “off”) • Signals mode (Close-Confirmed vs Intrabar) ⸻ Inputs you’ll actually adjust Trend/Signals • Fast/Mid/Slow EMA lengths • Pullback lookback, Min bars between signals • Volume filter (vol > SMA N) • ATR% max filter (cap excessive volatility) • Require break of prior bar’s high/low • “Strong” gates: min EMA slope, min EMA spacing %, ADX length & threshold Support/Resistance • Lines vs Zones • Pivot left/right bars • Extend left/right (bars) • Max pivots kept (current & HTF) • Zone width (× ATR), Merge epsilon (× ATR), Min gap (× ATR) • Min touches, Max zones per side near price • De-dup current TF vs HTF (× ATR) Repainting control • Confirm on Close: when ON, signals/SR finalize on bar close (non-repainting) • Freeze on Close: freeze S/R intrabar with snapshot updates • Show previews: translucent intrabar labels for what’s forming ⸻ How to use it (straightforward) 1. Load on 5-minute chart (baseline). Keep Confirm on Close ON if you hate repainting. 2. Use Bias + Strong + S/R context. If a long prints into HTF resistance, you have information. 3. Manage risk off the reference stop (pullback extreme). If ATR% reads “Great,” widen expectations; if “Poor,” size down or pass. 4. Alerts: wire the four alert types to your workflow. ⸻ Notes and constraints • Designed for liquid symbols. Thin books and synthetic “volume” will degrade the volume gate. • S/R is pivot-based. On very choppy tape, touch counts help. Increase min touches or switch to Lines to declutter. • If your chart timeframe isn’t 5m, behavior changes because lengths are in bars, not minutes. Tune lengths accordingly. ⸻ Disclaimers This is a research tool. No signals are guaranteed. Markets change, outliers happen, slippage is real. Nothing here is financial advice—use your own judgment and risk management. ⸻ Author: DaddyScruff License: MPL-2.0 (Mozilla Public License 2.0)
Wskaźnik Pine Script®
od DaddyScruff
1
Higher-timeframe requests█   OVERVIEW This publication focuses on enhancing awareness of the best practices for accessing higher-timeframe (HTF) data via the request.security() function. Some "traditional" approaches, such as what we explored in our previous `security()` revisited publication, have shown limitations in their ability to retrieve non-repainting HTF data. The fundamental technique outlined in this script is currently the most effective in preventing repainting when requesting data from a higher timeframe. For detailed information about why it works, see this section in the Pine Script™ User Manual . █   CONCEPTS Understanding repainting Repainting is a behavior that occurs when a script's calculations or outputs behave differently after restarting it. There are several types of repainting behavior, not all of which are inherently useless or misleading. The most prevalent form of repainting occurs when a script's calculations or outputs exhibit different behaviors on historical and realtime bars. When a script calculates across historical data, it only needs to execute once per bar, as those values are confirmed and not subject to change. After each historical execution, the script commits the states of its calculations for later access. On a realtime, unconfirmed bar, values are fluid . They are subject to change on each new tick from the data provider until the bar closes. A script's code can execute on each tick in a realtime bar, meaning its calculations and outputs are subject to realtime fluctuations, just like the underlying data it uses. Each time a script executes on an unconfirmed bar, it first reverts applicable values to their last committed states, a process referred to as rollback . It only commits the new values from a realtime bar after the bar closes. See the User Manual's Execution model page to learn more. In essence, a script can repaint when it calculates on realtime bars due to fluctuations before a bar's confirmation, which it cannot reproduce on historical data. A common strategy to avoid repainting when necessary involves forcing only confirmed values on realtime bars, which remain unchanged until each bar's conclusion. Repainting in higher-timeframe (HTF) requests When working with a script that retrieves data from higher timeframes with request.security() , it's crucial to understand the differences in how such requests behave on historical and realtime bars . The request.security() function executes all code required by its `expression` argument using data from the specified context (symbol, timeframe, or modifiers) rather than on the chart's data. As when executing code in the chart's context, request.security() only returns new historical values when a bar closes in the requested context. However, the values it returns on realtime HTF bars can also update before confirmation, akin to the rollback and recalculation process that scripts perform in the chart's context on the open bar. Similar to how scripts operate in the chart's context, request.security() only confirms new values after a realtime bar closes in its specified context. Once a script's execution cycle restarts, what were previously realtime bars become historical bars, meaning the request.security() call will only return confirmed values from the HTF on those bars. Therefore, if the requested data fluctuates across an open HTF bar, the script will repaint those values after it restarts. This behavior is not a bug; it's simply the default behavior of request.security() . In some cases, having the latest information from an unconfirmed HTF bar is precisely what a script needs. However, in many other cases, traders will require confirmed, stable values that do not fluctuate across an open HTF bar. Below, we explain the most reliable approach to achieve such a result. Achieving consistent timing on all bars One can retrieve non-fluctuating values with consistent timing across historical and realtime feeds by exclusively using request.security() to fetch the data from confirmed HTF bars. The best way to achieve this result is offsetting the `expression` argument by at least one bar (e.g., `close [1 ]`) and using barmerge.lookahead_on as the `lookahead` argument. We discourage the use of barmerge.lookahead_on alone since it prompts the function to look toward future values of HTF bars across historical data, which is heavily misleading. However, when paired with a requested `expression` that includes a one-bar historical offset, the "future" data the function retrieves is not from the future. Instead, it represents the last confirmed bar's values at the start of each HTF bar, thus preventing the results on realtime bars from fluctuating before confirmation from the timeframe. For example, this line of code uses a request.security() call with barmerge.lookahead_on to request the close price from the "1D" timeframe, offset by one bar with the history-referencing operator [ ] . This line will return the daily price with consistent timing across all bars: float htfClose = request.security(syminfo.tickerid, "1D", close , lookahead = barmerge.lookahead_on) Note that:  • This technique only works as intended for higher-timeframe requests .  • When designing a script to work specifically with HTFs, we recommend including conditions to prevent request.security() from accessing timeframes equal to or lower than the chart's timeframe, especially if you intend to publish it. In this script, we included an if structure that raises a runtime error when the requested timeframe is too small.  • A necessary trade-off with this approach is that the script must wait for an HTF bar's confirmation to retrieve new data on realtime bars, thus delaying its availability until the open of the subsequent HTF bar. The time elapsed during such a delay varies with each market, but it's typically relatively small. 👉 Failing to offset the function's `expression` argument while using barmerge.lookahead_on will produce historical results with lookahead bias , as it will look to the future states of historical HTF bars, retrieving values before the times at which they're available in the feed. See the `lookahead` and Future leak with `request.security()` sections in the Pine Script™ User Manual for more information. Evolving practices The fundamental technique outlined in this publication is currently the only reliable approach to requesting non-repainting HTF data with request.security() . It is the superior approach because it avoids the pitfalls of other methods, such as the one introduced in the `security()` revisited publication. That publication proposed using a custom `f_security()` function, which applied offsets to the `expression` and the requested result based on historical and realtime bar states. At that time, we explored techniques that didn't carry the risk of lookahead bias if misused (i.e., removing the historical offset on the `expression` while using lookahead), as requests that look ahead to the future on historical bars exhibit dangerously misleading behavior. Despite these efforts, we've unfortunately found that the bar state method employed by `f_security()` can produce inaccurate results with inconsistent timing in some scenarios, undermining its credibility as a universal non-repainting technique. As such, we've deprecated that approach, and the Pine Script™ User Manual no longer recommends it. █   METHOD VARIANTS In this script, all non-repainting requests employ the same underlying technique to avoid repainting. However, we've applied variants to cater to specific use cases, as outlined below: Variant 1 Variant 1, which the script displays using a lime plot, demonstrates a non-repainting HTF request in its simplest form, aligning with the concept explained in the "Achieving consistent timing" section above. It uses barmerge.lookahead_on and offsets the `expression` argument in request.security() by one bar to retrieve the value from the last confirmed HTF bar. For detailed information about why this works, see the Avoiding Repainting section of the User Manual's Other timeframes and data page. Variant 2 Variant 2 ( fuchsia ) introduces a custom function, `htfSecurity()`, which wraps the request.security() function to facilitate convenient repainting control. By specifying a value for its `repaint` parameter, users can determine whether to allow repainting HTF data. When the `repaint` value is `false`, the function applies lookahead and a one-bar offset to request the last confirmed value from the specified `timeframe`. When the value is `true`, the function requests the `expression` using the default behavior of request.security() , meaning the results can fluctuate across chart bars within realtime HTF bars and repaint when the script restarts. Note that:  • This function exclusively handles HTF requests. If the requested timeframe is not higher than the chart's, it will raise a runtime error .  • We prefer this approach since it provides optional repainting control. Sometimes, a script's calculations need to respond immediately to realtime HTF changes, which `repaint = true` allows. In other cases, such as when issuing alerts, triggering strategy commands, and more, one will typically need stable values that do not repaint, in which case `repaint = false` will produce the desired behavior. Variant 3 Variant 3 ( white ) builds upon the same fundamental non-repainting approach used by the first two. The difference in this variant is that it applies repainting control to tuples , which one cannot pass as the `expression` argument in our `htfSecurity()` function. Tuples are handy for consolidating `request.*()` calls when a script requires several values from the same context, as one can request a single tuple from the context rather than executing multiple separate request.security() calls. This variant applies the internal logic of our `htfSecurity()` function in the script's global scope to request a tuple containing open and `srcInput` values from a higher timeframe with repainting control. Historically, Pine Script™ did not allow the history-referencing operator [ ] when requesting tuples unless the tuple came from a function call, which limited this technique. However, updates to Pine over time have lifted this restriction, allowing us to pass tuples with historical offsets directly as the `expression` in request.security() . By offsetting all items in a tuple `expression` by one bar and using barmerge.lookahead_on , we effectively retrieve a tuple of stable, non-repainting HTF values. Since we cannot encapsulate this method within the `htfSecurity()` function and must execute the calculations in the global scope, the script's "Repainting" input directly controls the global `offset` and `lookahead` values to ensure it behaves as intended. Variant 4 (Control) Variant 4, which the script displays as a translucent orange plot, uses a default request.security() call, providing a reference point to compare the difference between a repainting request and the non-repainting variants outlined above. Whenever the script restarts its execution cycle, realtime bars become historical bars, and the request.security() call here will repaint the results on those bars. █   Inputs Repainting The "Repainting" input (`repaintInput` variable) controls whether Variant 2 and Variant 3 are allowed to use fluctuating values from an unconfirmed HTF bar. If its value is `false` (default), these requests will only retrieve stable values from the last confirmed HTF bar. Source The "Source" input (`srcInput` variable) determines the series the script will use in the `expression` for all HTF data requests. Its default value is close . HTF Selection This script features two ways to specify the higher timeframe for all its data requests, which users can control with the "HTF Selection" input (`tfTypeInput` variable):  1) If its value is "Fixed TF", the script uses the timeframe value specified by the "Fixed Higher Timeframe" input (`fixedTfInput` variable). The script will raise a runtime error if the selected timeframe is not larger than the chart's.  2) If the input's value is "Multiple of chart TF", the script multiplies the value of the "Timeframe Multiple" input (`tfMultInput` variable) by the chart's timeframe.in_seconds() value, then converts the result to a valid timeframe string via timeframe.from_seconds() . Timeframe Display This script features the option to display an "information box", i.e., a single-cell table that shows the higher timeframe the script is currently using. Users can toggle the display and determine the table's size, location, and color scheme via the inputs in the "Timeframe Display" group. █   Outputs This script produces the following outputs:  • It plots the results from all four of the above variants for visual comparison.  • It highlights the chart's background gray whenever a new bar starts on the higher timeframe, signifying when confirmations occur in the requested context.  • To demarcate which bars the script considers historical or realtime bars, it plots squares with contrasting colors corresponding to bar states at the bottom of the chart pane.  • It displays the higher timeframe string in a single-cell table with a user-specified size, location, and color scheme. Look first. Then leap.
Wskaźnik Pine Script®
od PineCoders
15
Smoothing R-Squared ComparisonIntroduction Heyo guys, here I made a comparison between my favorised smoothing algorithms. I chose the R-Squared value as rating factor to accomplish the comparison. The indicator is non-repainting. Description In technical analysis, traders often use moving averages to smooth out the noise in price data and identify trends. While moving averages are a useful tool, they can also obscure important information about the underlying relationship between the price and the smoothed price. One way to evaluate this relationship is by calculating the R-squared value, which represents the proportion of the variance in the price that can be explained by the smoothed price in a linear regression model. This PineScript code implements a smoothing R-squared comparison indicator. It provides a comparison of different smoothing techniques such as Kalman filter, T3, JMA, EMA, SMA, Super Smoother and some special combinations of them. The Kalman filter is a mathematical algorithm that uses a series of measurements observed over time, containing statistical noise and other inaccuracies, and produces estimates of unknown variables that tend to be more accurate than those based on a single measurement. The input parameters for the Kalman filter include the process noise covariance and the measurement noise covariance, which help to adjust the sensitivity of the filter to changes in the input data. The T3 smoothing technique is a popular method used in technical analysis to remove noise from a signal. The input parameters for the T3 smoothing method include the length of the window used for smoothing, the type of smoothing used (Normal or New), and the smoothing factor used to adjust the sensitivity to changes in the input data. The JMA smoothing technique is another popular method used in technical analysis to remove noise from a signal. The input parameters for the JMA smoothing method include the length of the window used for smoothing, the phase used to shift the input data before applying the smoothing algorithm, and the power used to adjust the sensitivity of the JMA to changes in the input data. The EMA and SMA techniques are also popular methods used in technical analysis to remove noise from a signal. The input parameters for the EMA and SMA techniques include the length of the window used for smoothing. The indicator displays a comparison of the R-squared values for each smoothing technique, which provides an indication of how well the technique is fitting the data. Higher R-squared values indicate a better fit. By adjusting the input parameters for each smoothing technique, the user can compare the effectiveness of different techniques in removing noise from the input data. Usage You can use it to find the best fitting smoothing method for the timeframe you usually use. Just apply it on your preferred timeframe and look for the highlighted table cell. Conclusion It seems like the T3 works best on timeframes under 4H. There's where I am active, so I will use this one more in the future. Thank you for checking this out. Enjoy your day and leave me a like or comment. 🧙‍♂️ --- Credits to: ▪@loxx – T3 ▪@balipour – Super Smoother ▪ChatGPT – Wrote 80 % of this article and helped with the research
Wskaźnik Pine Script®
od simwai
1
VHF Adaptive Linear Regression KAMAIntroduction Heyo, in this indicator I decided to add VHF adaptivness, linear regression and smoothing to a KAMA in order to squeeze all out of it. KAMA: Developed by Perry Kaufman, Kaufman's Adaptive Moving Average (KAMA) is a moving average designed to account for market noise or volatility. KAMA will closely follow prices when the price swings are relatively small and the noise is low. KAMA will adjust when the price swings widen and follow prices from a greater distance. This trend-following indicator can be used to identify the overall trend, time turning points and filter price movements. VHF: Vertical Horizontal Filter (VHF) was created by Adam White to identify trending and ranging markets. VHF measures the level of trend activity, similar to ADX DI. Vertical Horizontal Filter does not, itself, generate trading signals, but determines whether signals are taken from trend or momentum indicators. Using this trend information, one is then able to derive an average cycle length. Linear Regression Curve: A line that best fits the prices specified over a user-defined time period. This is very good to eliminate bad crosses of KAMA and the pric. Usage You can use this indicator on every timeframe I think. I mostly tested it on 1 min, 5 min and 15 min. Signals Enter Long -> crossover(close, kama) and crossover(kama, kama ) Enter Short -> crossunder(close, kama) and crossunder(kama, kama ) Thanks for checking this out! -- Credits to ▪️@cheatcountry – Hann Window Smoohing ▪️@loxx – VHF and T3 ▪️@LucF – Gradient
Wskaźnik Pine Script®
od simwai
Chandelier Exit ZLSMA StrategyIntroduction Heyo guys, I recently checked out some eye-catching trading strategy videos on YT and found one to test. This indicator is based on the video. Usage The recommended timeframe is 5 min. Signals Long Entry => L Label Price crosses above ZLSMA and Chandelier Exit shows Buy Long Exit => green circle Price crosses below ZLSMA Short Entry => S Label Price crosses below ZLSMA and Chandelier Exit shows Sell Short Exit => orange circle Prices crosses above ZLSMA Ty for checking this out. Enjoy! -- Credits to @netweaver2011 - ZLSMA @everget – Chandelier Exit
Wskaźnik Pine Script®
od simwai
19
Adaptive Fisherized KSTIntroduction Heyo guys, here is a new adaptive fisherized indicator of me. I applied Inverse Fisher Transform, Ehlers dominant cycle analysis, smoothing and divergence analysis on the Know Sure Thing (KST) indicator. Moreover, the indicator doesn't repaint. Usage I didn't backtest the indicator, but I recommend the 5–15 min timeframe. It can be also used on other timeframs, but I have no experience with that. The indicator has no special filter system, so you need to find an own combo in order to build a trading system. A trend filter like KAMA or my Adaptive Fisherized Trend Intensity Index could fit well. If you find a good combo, let me know it in the comments pls. Signals Zero Line KST crossover 0 => Enter Long KST crossunder 0 => Enter Short Cross KST crossover KST MA => Enter Long KST crossunder KST MA => Enter Short Cross Filtered KST crossover KST MA and KST above 0 => Enter Long KST crossunder KST MA and KST under 0 => Enter Short KST crossunder 0 => Exit Long KST crossover 0 => Exit Short More to read: KST Explanation Enjoy and let me know your opinion! -- Credits to - @tista - @blackcat1402 - @DasanC - @cheatcountry
Wskaźnik Pine Script®
od simwai
2
Adaptive Fisherized Stochastic Center of GravityIntroduction I modified the script "Fisher Stochastic Center of Gravity" of @DasanC for this indicator. I added inverse Fisher transform, cycle period adaptiveness mode (Ehlers) and smoothing to it. Moreover, I added buy and sell and beautified some stuff. Lastly, it is also non-repainting! Usage This indicator can be used like a normal stochastic, but I don't recommend divergence analysis on it. That fisherization stuff seems to make the graphs unuseable for that because it tries. It works well on every timeframe I would say, but lower timeframes are recommended, because of the fast nature of stochastic. Usually it does a good job on entry confirmation for reversals and trend continuation trades. Recommended indicator to combine with this indicator is RSI cyclic smoothed v2 . This is the best RSI version I know. In trending market it is recommended to look more on the inner bands and in flat market it is recommended to look more on the outer bands. When RSI shows oversold and this indicator shows a crossover of the Center of Gravity plot through the bottom line -> Long entry is confirmed When RSI shows overbought and this indicator shows a crossunder of the Center of Gravity plot through the top line -> Short entry is confirmed Settings The adaptive mode is enabled by default to give you straight the whole indicator experience. The default settings are optimized, but should be changed depending on the market. An example: Market has a low volatility and a high momentum -> I want a slower/higher length to catch the slower new highs and lows. Market has higher volatility and a low momentum, -> I want a faster/lower length to catch the faster new highs and lows Signals Crossover Buy -> cog crossover signalLine Sell -> cog crossunder signalLine Overbought/Oversold Crossover Buy -> cog crossover lowerBand Sell -> cog crossunder lowerBand I use this indicator a lot, because I don't know a better stochastic on this community here. @DasanC did an awesome work with his version I used as base for this script. Enjoy this indicator and let the profit roll! 🔥
Wskaźnik Pine Script®
od simwai
9
All for One Moving AverageThis is a collection of all the moving averages available. Some are built-in, a couple were tricky to source out. Higher timeframes can be specified so you aren't limited to your chart setting. Repainting has been disabled by default. There is also an option to use Heikin Ashi candles as the input source rather than standard bars. Hope that someone finds this useful. If you'd like anything added please DM me and I'll include it! Feel free to copy this into your own strategies/indicators. ~Dark
Wskaźnik Pine Script®
od darkbrewery
2
HTF High/Low Repaint StrategyHere is an another attempt to demonstrate repainting and how to avoid them. It happened few times to me that I develop a strategy which is giving immense returns - only to realize after few forward testing that it is repainting. Sometimes, it is well disguised even during forward testing. In this simple strategy, conditions are as below: Buy : When a 3M bar produces high and low higher than it's previous 3M bar high, low Sell : When a 3M bar produces high and low lower than its previous 3M bar high, low. Default setting is : lookahead = on and offset = 0 This means current 3M bar high low is plotted for all the daily bars within this month. Which means, strategy looks ahead of time to see this 3M bar high is higher than previous 3M bar high during the start of the first daily bar. Hence, this combination leads to massive repaint. For example, trade made on October 2nd 2018 already knows well ahead of time that price is going to go down in next 3 months: Similarly, after 2 years on October 2nd 2020 - the strategy already knows that last 3M high is going to be breached on 7th December 2020 Solution: If you are using security for higher timeframes, safer option is always to use offset 1. Further details in the trading view script: BUT It may still repaint if we are passing function to security. For example: f_secureSecurity(_symbol, _res, _src) => security(_symbol, _res, _src , lookahead = barmerge.lookahead This function will likely avoid any repainting with Higher timeframe if we are passing in built variables such as high, low, close, open etc. But, if we try to pass supertrend, this will not produce right results. This is because supertrend calculation in turn uses high/low/close values which do not consider the offset while calculating. Hence, even with offset 1, this will still produce issues. Hence, the call: = f_secureSecurity(syminfo.tickerid, derivedResolution, supertrend(3,10), offset) will again lead to massive repainting. Solution to this is to implement supertrend function and use high, low, close values derived from secureSecurity. Quick tips to identify or be suspicious about repainting Unbelievable results on all timeframes and all instruments with both long and short trades Lower timeframes giving significantly higher returns on backtest when compared to higher timeframe If these things happen, be wary about repainting and do a through check of all security function usage in your strategy. All the best :) PS: Apply 3-5 days resolution and see the fun. Also, WHC is one hell of a Christmas tree. Could have made immense profit in the same strategy even without repainting.
Strategia Pine Script®
od Trendoscope
14
Higher TF - Repainting + Limiting backtest resultsThis strategy is for illustration purpose only. Do not use this as there is massive repainting. As usual, I was experimenting with adding different entry/exit filters to my main strategy. Thought of adding higher frame filter, picked the code for getting higher time frame supertrend from someone else's script and copied it without thinking much about it. security(syminfo.tickerid, f_multiple_resolution(HTFMultiplier), supertrend(SupertrendMult, SupertrendPd), lookahead = true, gaps=true) Started getting better results with this result. I was very much impressed and while trying to enhance further, I started disabling my other entry and exit filters which I generally use. That worked pretty well without any of my other filters. Hence, thought I will forward test this on a smaller timeframe. To my surprise, even in forward testing, i was not able to notice repainting very much. It also appeared that smaller timeframes yielded better results. (This wasn't the case with any of my strategies) Which then prompted me to study the security function and lookahead and gap parameters. Learned that lookahead and gap when set to true will lead to massive repainting - specially if you are using higher timeframes. Hence, these parameters are not advisable to use in strategies. Further information here: www.tradingview.com I added three repaint options to further illustrate how security function will work: Yes : Use security with lookahead and merge set to true No - set lookahead false : Use security with lookahead and merge set to false No - do not use security : Falls back to original command on current timeframe. Switch timeframe to HTF resolution to compare the difference. Conclusion : Always set lookahead and gaps to false when using security function in strategies. PS: Script also contains code to limit backtesting to certain days/months/years. This can be used as is in other scripts.
Strategia Pine Script®
od Trendoscope
2
How to avoid repainting when NOT using security()Even when your code does not use security() calls, repainting dynamics still come into play in the realtime bar. Script coders and users must understand them and, if they choose to avoid repainting, need to know how to do so. This script demonstrates three methods to avoid repainting when NOT using the security() function. Note that repainting dynamics when not using security() usually only come into play in the realtime bar, as historical data is fixed and thus cannot cause repainting, except in situations related to stock splits or dividend adjustments. For those who don’t want to read Configure your alerts to trigger “Once Per Bar Close” and you’re done. For those who want to understand Put this indicator on a 1 minute or seconds chart with a live symbol. As price changes you will see four of this script’s MAs (all except the two orange ones) move in the realtime bar. You are seeing repainting in action. When the current realtime bar closes and becomes a historical bar, the lines on the historical bars will no longer move, as the bar’s OHLC values are fixed. Note that you may need to refresh your chart to see the correct historical OHLC values, as exchange feeds sometimes produce very slight variations between the end values of the realtime bar and those of the same bar once it becomes a historical bar. Some traders do not use signals generated by a script but simply want to avoid seeing the lines plotted by their scripts move during the realtime bar. They are concerned with repainting of the lines . Other traders use their scripts to evaluate conditions, which they use to either plot markers on the chart, trigger alerts, or both. They may not care about the script’s plotted lines repainting, but do not want their markers to appear/disappear on the chart, nor their alerts to trigger for a condition that becomes true during the realtime bar but is no longer true once it closes. Those traders are more concerned with repainting of signals . For each of the three methods shown in this script’s code, comments explain if its lines, markers and alerts will repaint or not. Through the Settings/Inputs you will be able to control plotting of lines and markers corresponding to each method, as well as experiment with the option, for method 2, of disabling only the lines plotting in the realtime bar while still allowing the markers and alerts to be generated. An unavoidable fact is that non-repainting lines, markers or alerts are always late compared to repainting ones. The good news is that how late they are will in many cases be insignificant, so that the added reliability of the information they provide will largely offset the disadvantages of waiting. Method 1 illustrates the usual way of going about things in a script. Its gray lines and markers will always repaint but repainting of the alerts the marker conditions generate can be avoided by configuring alerts to trigger “Once Per Bar Close”. Because this gray marker repaints, you will occasionally see it appear/disappear during the realtime bar when the gray MAs cross/un-cross. Method 2 plots the same MAs as method 1, but in green. The difference is that it delays its marker condition by one bar to ensure it does not repaint. Its lines will normally repaint but its markers will not, as they pop up after the condition has been confirmed on the bar preceding the realtime bar. Its markers appear at the beginning of the realtime bar and will never disappear. When using this method alerts can be configured to trigger “Once Per Bar” so they fire the moment the marker appears on the chart at the beginning of the realtime bar. Note that the delay incurred between methods 1 and 2 is merely the instant between the close of a realtime bar and the beginning of the next one—a delay measured in milliseconds. Method 2 also allows its lines to be hidden in the realtime bar with the corresponding option in the script’s Settings/Inputs . This will be useful to those wishing to eliminate unreliable lines from the realtime bar. Commented lines in method 2 provide for a 2b option, which is to delay the calculation of the MAs rather than the cross condition. It has the obvious inconvenient of plotting delayed MAs, but may come in handy in some situations. Method 3 is not the best solution when using MAs because it uses the open of bars rather than their close to calculate the MAs. While this provides a way of avoiding repainting, it is not ideal in the case of MA calcs but may come in handy in other cases. The orange lines and markers of method 3 will not repaint because the value of open cannot change in the realtime bar. Because its markers do not repaint, alerts may be configured using “Once Per Bar”. Spend some time playing with the different options and looking at how this indicator’s lines plot and behave when you refresh you chart. We hope everything you need to understand and prevent repainting when not using security() is there. Look first. Then leap.
Wskaźnik Pine Script®
od PineCoders
27