Re: Moving Average indicators for MT4
3941Order block breaker indicator for MT4 provides the best BUY and SELL forex trading signals based on price exhaustion points.
Re: Moving Average indicators for MT4
3942@Millernioh
Gidday Mate..........
If you're going to post indicators etc. please be sure you're posting them in the appropriate thread
Gidday Mate..........
If you're going to post indicators etc. please be sure you're posting them in the appropriate thread
Re: Be very carefull with zip files and executables of any type .ex*, .lnk etc.
3943@Millernioh will you be so kind to answer the following question?:
"Why are you uploading these files inside a zip file?
buy-sell-magic1.lnk,
order-block-breaker-indicator.lnk,
supply-and-demand-zones.lnk."
"Why are you uploading these files inside a zip file?
buy-sell-magic1.lnk,
order-block-breaker-indicator.lnk,
supply-and-demand-zones.lnk."
Re: Moving Average indicators for MT4
3944@Jimmy, review this user and ban if necessary.Millernioh wrote: Sun Feb 15, 2026 10:41 am Fresh advanced indicator for creating an Expert Advisor (EA) for automatic multi-timeframe trading in MetaTrader 4.
supply-and-demand-zones_pre1.png
supply-and-demand-zonesv2.zip
Another virus-infected zip file uploaded!
The web page is not dangerous, but trying to download this file triggers all my virus software!
- These users thanked the author BeatlemaniaSA for the post (total 7):
- moey_dw, Jimmy, Tsar, ricosuaveiii, Cagliostro, Asante, kvak
- Rating: 4.1%
Millionaire Maker - “Amateurs chase. Professionals wait. Legends wait with a plan.”
BEATS V5 - "Enjoy The Quiet Between Trades”
Improve Your Trading Psychology - No fear, no doubt
Ultimate Risk Management - Maximize Your Trades
Supply and Demand Course - Learn Supply and Demand
BEATS V5 - "Enjoy The Quiet Between Trades”
Improve Your Trading Psychology - No fear, no doubt
Ultimate Risk Management - Maximize Your Trades
Supply and Demand Course - Learn Supply and Demand
Re: Moving Average indicators for MT4
3945Thank you, removed member and files. Will be deactivating older accounts with minimal, low quality posts this week and closely monitor all new files uploaded.BeatlemaniaSA wrote: Sun Feb 15, 2026 9:21 pm The web page is not dangerous, but trying to download this file triggers all my virus software!
IP address for reference:
165.231.94.18- Rating: 2.3%
Re: Moving Average indicators for MT4
3946Hello everyone, I attempted to replicate the Savitzky Golay SMA code via hard coding, both in its original and casual versions.
If any of our veteran forum programmers would like to review mq4, is included on post.
Savitzky–Golay smoothing is least‑squares polynomial regression applied on a moving window, implemented efficiently as a fixed FIR convolution when samples are equally spaced.
In most textbook/“centered” SG, the polynomial is evaluated at the center of the window, which in trading implies that the plotted point at time t depends partly on future bars (t+1, t+2…). That creates look‑ahead bias and “repaint‑like” behavior in signals.
A causal (one‑sided) SG avoids this by evaluating the polynomial at the newest point of the window, using only current + past samples. SciPy explicitly supports this concept via savgol_coeffs(..., pos=...) where pos “specifies evaluation position within the window” (default is the middle)—setting pos=window_length-1 corresponds to “evaluate at the last sample,” i.e., a one‑sided / edge-aligned design.
This report provides a corrected, single‑file MQL4 implementation of your SMA→SG MTF indicator, replacing the centered SG with a causal one‑sided SG (no look‑ahead), with MT4‑specific best practices: explicit ArraySetAsSeries for buffers and inputs, cached coefficients computed in OnInit, edge handling, and optional UseClosedHTFBar to stabilize MTF values. MQL4 documentation strongly recommends explicitly setting array indexing direction, and notes you must call ArraySetAsSeries() after binding buffers with SetIndexBuffer().
Centered SG vs causal SG: what changes mathematically
The original Savitzky–Golay method fits a degree‑k polynomial to m adjacent samples (equally spaced) and evaluates it at a chosen point (classically the center), yielding a convolution form.
The key ideas you can leverage for causal SG are:
SG output is an evaluation functional of a least‑squares fitted polynomial: you fit a polynomial on a window, then evaluate it at some position inside that window.
The “evaluation position” is not inherently required to be centered. The SG literature and implementations treat edge points by changing the evaluation position / coefficient set; Wikipedia explicitly notes strategies for “treatment of first and last points,” including deriving specific convolution coefficients for missing edge points (equivalent to evaluating at different positions).
SciPy operationalizes this as pos: “If pos is not None, it specifies evaluation position within the window. The default is the middle of the window.”
Show code
In trading indicators, centered SG can “lead” the price visually because it incorporates future data. Causal SG removes that look‑ahead but necessarily introduces lag/inertia like any past‑only smoother (it is still an FIR low‑pass smoother).
Choosing window and polynomial to manage lag vs smoothness
Your indicator is SMA→SG (SMA first, then SG). Both are smoothing stages, so parameter choice matters more for responsiveness.
What window length does in causal SG
A larger window length N:
Increases smoothing/noise reduction (more averaging/regression samples), but
Increases output inertia and can distort fast moves (the filter must reconcile more past samples). The SG literature highlights the core trade‑off: widening the window reduces noise but risks distortion, and design is a balance between noise suppression and distortion.
In causal (one‑sided) form, the window uses N past bars, so increasing N also increases how far into the past the estimate “reaches,” which typically increases perceived lag.
What polynomial order does in causal SG
A higher polynomial order p (still constrained by p < window_length) allows the local fit to represent more curvature/trend, typically reducing distortion of features compared to simple averaging; SG is often preferred for preserving shape/peaks relative to basic moving averages.
However, increasing polynomial order can reduce smoothing strength (more degrees of freedom for the fit) and can become numerically delicate at very high orders in some implementations.
Practical tuning guidance for your SMA→SG (causal)
Because you already apply an SMA, your SG stage can usually run with a moderate window and low-to-moderate poly:
If you want less lag: reduce SG_Window and/or increase SG_Poly modestly (e.g., 2→3), keeping SG_Poly << SG_Window. The formal constraint polyorder < window_length is required.
If you want smoother curves: increase SG_Window, or keep SG_Window fixed and reduce SG_Poly (approaches moving average behavior).
Remember: causal always lags more than centered because centered uses future samples (which you intentionally forbid in a no look‑ahead indicator).
Unspecified behavior note: your original SMA warm‑up behavior outputs the raw price (src) until full period is available. This is preserved below (even though alternative warm‑up rules exist), because you asked to keep original behavior when unspecified.
MQL4 implementation requirements and pitfalls addressed
This implementation follows MT4 rules and common failure points:
Array indexing direction: MQL4 timeseries convention is newest at index 0, but arrays passed into OnCalculate() “do not obligatorily” share that direction; you should explicitly call ArraySetAsSeries() for arrays you use to avoid default dependence.
Indicator buffers: After SetIndexBuffer, buffers are indexed like common arrays unless you explicitly change them; MQL4 docs instruct to call ArraySetAsSeries() after binding.
MTF mapping: iBarShift() maps chart bar time to a bar index on the target timeframe; its exact parameter controls whether “nearest” or -1 is returned in gaps.
HTF “current bar” instability: iClose(symbol, tf, 0) is the close of the current, possibly forming bar (updates intrabar). Optional UseClosedHTFBar shifts mapping from HTF bar 0 to bar 1 for stability.
If any of our veteran forum programmers would like to review mq4, is included on post.
Savitzky–Golay smoothing is least‑squares polynomial regression applied on a moving window, implemented efficiently as a fixed FIR convolution when samples are equally spaced.
In most textbook/“centered” SG, the polynomial is evaluated at the center of the window, which in trading implies that the plotted point at time t depends partly on future bars (t+1, t+2…). That creates look‑ahead bias and “repaint‑like” behavior in signals.
A causal (one‑sided) SG avoids this by evaluating the polynomial at the newest point of the window, using only current + past samples. SciPy explicitly supports this concept via savgol_coeffs(..., pos=...) where pos “specifies evaluation position within the window” (default is the middle)—setting pos=window_length-1 corresponds to “evaluate at the last sample,” i.e., a one‑sided / edge-aligned design.
This report provides a corrected, single‑file MQL4 implementation of your SMA→SG MTF indicator, replacing the centered SG with a causal one‑sided SG (no look‑ahead), with MT4‑specific best practices: explicit ArraySetAsSeries for buffers and inputs, cached coefficients computed in OnInit, edge handling, and optional UseClosedHTFBar to stabilize MTF values. MQL4 documentation strongly recommends explicitly setting array indexing direction, and notes you must call ArraySetAsSeries() after binding buffers with SetIndexBuffer().
Centered SG vs causal SG: what changes mathematically
The original Savitzky–Golay method fits a degree‑k polynomial to m adjacent samples (equally spaced) and evaluates it at a chosen point (classically the center), yielding a convolution form.
The key ideas you can leverage for causal SG are:
SG output is an evaluation functional of a least‑squares fitted polynomial: you fit a polynomial on a window, then evaluate it at some position inside that window.
The “evaluation position” is not inherently required to be centered. The SG literature and implementations treat edge points by changing the evaluation position / coefficient set; Wikipedia explicitly notes strategies for “treatment of first and last points,” including deriving specific convolution coefficients for missing edge points (equivalent to evaluating at different positions).
SciPy operationalizes this as pos: “If pos is not None, it specifies evaluation position within the window. The default is the middle of the window.”
Show code
In trading indicators, centered SG can “lead” the price visually because it incorporates future data. Causal SG removes that look‑ahead but necessarily introduces lag/inertia like any past‑only smoother (it is still an FIR low‑pass smoother).
Choosing window and polynomial to manage lag vs smoothness
Your indicator is SMA→SG (SMA first, then SG). Both are smoothing stages, so parameter choice matters more for responsiveness.
What window length does in causal SG
A larger window length N:
Increases smoothing/noise reduction (more averaging/regression samples), but
Increases output inertia and can distort fast moves (the filter must reconcile more past samples). The SG literature highlights the core trade‑off: widening the window reduces noise but risks distortion, and design is a balance between noise suppression and distortion.
In causal (one‑sided) form, the window uses N past bars, so increasing N also increases how far into the past the estimate “reaches,” which typically increases perceived lag.
What polynomial order does in causal SG
A higher polynomial order p (still constrained by p < window_length) allows the local fit to represent more curvature/trend, typically reducing distortion of features compared to simple averaging; SG is often preferred for preserving shape/peaks relative to basic moving averages.
However, increasing polynomial order can reduce smoothing strength (more degrees of freedom for the fit) and can become numerically delicate at very high orders in some implementations.
Practical tuning guidance for your SMA→SG (causal)
Because you already apply an SMA, your SG stage can usually run with a moderate window and low-to-moderate poly:
If you want less lag: reduce SG_Window and/or increase SG_Poly modestly (e.g., 2→3), keeping SG_Poly << SG_Window. The formal constraint polyorder < window_length is required.
If you want smoother curves: increase SG_Window, or keep SG_Window fixed and reduce SG_Poly (approaches moving average behavior).
Remember: causal always lags more than centered because centered uses future samples (which you intentionally forbid in a no look‑ahead indicator).
Unspecified behavior note: your original SMA warm‑up behavior outputs the raw price (src) until full period is available. This is preserved below (even though alternative warm‑up rules exist), because you asked to keep original behavior when unspecified.
MQL4 implementation requirements and pitfalls addressed
This implementation follows MT4 rules and common failure points:
Array indexing direction: MQL4 timeseries convention is newest at index 0, but arrays passed into OnCalculate() “do not obligatorily” share that direction; you should explicitly call ArraySetAsSeries() for arrays you use to avoid default dependence.
Indicator buffers: After SetIndexBuffer, buffers are indexed like common arrays unless you explicitly change them; MQL4 docs instruct to call ArraySetAsSeries() after binding.
MTF mapping: iBarShift() maps chart bar time to a bar index on the target timeframe; its exact parameter controls whether “nearest” or -1 is returned in gaps.
HTF “current bar” instability: iClose(symbol, tf, 0) is the close of the current, possibly forming bar (updates intrabar). Optional UseClosedHTFBar shifts mapping from HTF bar 0 to bar 1 for stability.
