Pipsgrowth EX12044 MultiIndicatorConfluence

Pipsgrowth EX12044 MultiIndicatorConfluence is the same single-handle, 38-input template as EX12043 with one operational change: a different magic number, 22212044 instead of 22212043. The file is tagged v1.0.1, the property version is 2.00, and the source comment on line 176 still labels the EA as 'Version 1.1' (a reference to the RSI sub-system, not the file version). The point of having a bumped magic on identical code is portfolio parallelism: the trader can run two or more instances of the same template on the same account with separate ticket buckets, so a $1,000 deposit can carry two simultaneous 5-ticket-per-direction stacks without their position caps colliding. Because every gate, every retry, and every input has the same defaults as EX12043, what follows is a deployment walk-through of what the EA actually does tick by tick and bar by bar — not a feature inventory.

The decision cadence is once per new bar, not once per tick. OnTick() in the source runs three phases in order: UpdateAdaptiveIndicators() refreshes the four derived buffers (volatility, the windowed moving average, RSI, Heiken Ashi), ManagePositions() walks every open ticket through the profit walker, and CheckForEntry() only fires when totalBars != iBars(_Symbol, PERIOD_CURRENT). That last comparison is what gives the EA its native rate-limit: even if every one of the four signal conditions fires on every tick of a fast M5 bar, the entry check still runs at most once per bar. The bar ceiling is structural, not configured — there is no input that turns it off.

The live entry path is a strict four-condition gate. Condition one: the most recent bar's close — or haClose[0] when UseHeikenAshi is on (its default) — sits above the windowed moving average for buys, below it for sells. Condition two: a fresh MA crossover has just printed, with the previous bar at-or-below the MA and the latest bar above it, or a 'strong' Heiken Ashi body has formed, where the test is body > 50% of the bar's full range and the body direction agrees with the signal. Condition three: the volatility filter passes, meaning volatility[0] > VolatilityThreshold * pointValue with the threshold input sitting at 0.3 points by default. Condition four: the RSI sub-system fires on either a fresh cross up out of the 30 threshold (rsiBuffer[1] < 30 && rsiBuffer[0] > 30) or a three-bar rising run with rsiBuffer[0] in the 30-to-50 zone. The sell side mirrors the gate using the 70 overbought line and the symmetric 50-to-70 fall corridor.

The 'adaptive moving average' the parameter panel advertises is a windowed SMA whose period length floats. CalculateAdaptiveVolatility sums the high-minus-low range over a window equal to max(AdaptiveMA_Period, 10) bars and stores the result in volatility[0]. It then averages the most recent 20 entries from that buffer to set a baseline. The ratio volRatio = volatility[0] / avgVolatility is fed into the next period's window: adaptivePeriod = base / (1 + (volRatio - 1) * 2.0) with the 2.0 sensitivity multiplier exposed as the AdaptiveMA_Sensitivity input. The result is clamped to a 5-to-50 bar range. CalculateAdaptiveMA then sums the last adaptivePeriod closes and divides to write adaptiveMA[0]. There is no Kaufman efficiency ratio, no smoothing constant, no recursive term — the math recomputes a period from the volatility ratio and the next pass uses that period as a fixed SMA window. A calmer market lengthens the window; a choppier market shortens it.

Heiken Ashi is built in code. CalculateHeikenAshi walks the last 20 bars and writes haClose[i] = (open + high + low + close) / 4 for each bar. The recursive HA open starts at the seed (open + close) / 2 for the current bar, and for every older bar it averages the prior HA open with the prior HA close — propagating the seed backward through the buffer. The haHigh and haLow arrays take the max and min of the original bar's high/low unioned with the current HA open and HA close. The only native indicator handle the EA asks MetaTrader for is iRSI(_Symbol, PERIOD_CURRENT, 14, PRICE_CLOSE). CalculateRSI uses CopyBuffer on that handle and copies exactly three bars into rsiBuffer, which is the only state GetBuySignal, GetSellSignal, and GetConfirmationSignal ever read. The 5-bar divergence branch in GetConfirmationSignal reads rsiBuffer[1] and rsiBuffer[5] directly and returns false if the buffer has fewer than 10 elements — a guard for partial-bar warmup or a re-attach after a network drop.

GetConfirmationSignal is a separate gate with four modes. When both RSI_UseCrossoverSignals and RSI_UseDivergenceSignals are enabled, confirmation requires either a fresh 30/70 cross or a 5-bar price/RSI divergence. Crossover alone narrows the check to just the cross. Divergence alone narrows it to the divergence. Both off drops the function back to a plain 'RSI between 30 and 70' check. The volumeConfirm the source mentions is a placeholder returning true; the in-source comment notes that retail EURUSD rarely has reliable tick-volume data, so the EA does not require it. RequireToCheckForConfirmationBeforeAdding uses the same confirmation return value to gate pyramids — when any positions are open, the live confirmation must be true, otherwise new entries are denied regardless of how strong the primary signal reads.

Three pre-filters block entries before the signal path runs. IsMarketConditionsOK checks spread against MaxSpread (5 points) for a soft block, spread > 2 * MaxSpread for an extreme-spike hard-block, drawdown = (balance - equity) / balance * 100 against MaxDrawdownPercent (10%), and the open position count against MaxOpenTrades. IsPositionManagementOK walks every open position with this EA's magic, computes the per-ticket profit in points, and requires that all positions clear MinProfitInPointsPerTradeToAdd (20 points by default) for the pyramid to pass. IsOptimalTradingSession applies a London 8-16 / New York 13-21 / overlap 13-16 GMT window — but only when UseSessionFilter is true, which it is not by default. The strategy tester bypasses the filter via the isTester = MQLInfoInteger(MQL_TESTER) short-circuit at the top of the function, so backtests run across the full week regardless of the configured session window.

The profit walker inside ManageDynamicStopLoss is the only path that moves an open trade's stop-loss. Every tick, for every open ticket with magic 22212044, the function reads the current profit in points, updates lastHighestProfit[positionIndex] if the current reading beats the stored watermark, and computes lockSteps = floor(watermark / 30) and lockProfitPoints = lockSteps * 30 - 15. The new stop only applies if it is tighter than the current one — a buy's newSL must be higher than the existing stop, a sell's newSL must be lower. The walker only ever tightens; it never loosens a stop it has already pulled in. The 50-point initial stop and 100-point take-profit sit on the order ticket at open and are not modified by the walker until the watermark threshold (30 points of unrealized profit) is reached.

Pyramid-into-winners is the position-sizing policy. The first position in a direction opens regardless of the direction's existing profitability. Subsequent positions in the same direction only open if all of the existing positions in that direction are profitable by at least MinProfitInPointsPerTradeToAdd (20 points). MaxOpenTrades = 5 is enforced per direction — the account can hold up to 10 tickets at peak: 5 buys and 5 sells. The IsPositionDirectionProfitable function walks positions in the same direction only; mixed-direction profitability is not part of the test. A profitable buy basket does not let the EA add to a losing sell basket, and vice versa.

Three retry helpers wrap the order operations: TryClose_EX12044, TryClosePartial_EX12044, and TryModify_EX12044. Each runs a 3-attempt loop on REQUOTE, TIMEOUT, PRICE_OFF, or PRICE_CHANGED, sleeping 200 ms between attempts for the close and partial-close paths and 100 ms for the modify path. All three check the result retcode against TRADE_RETCODE_DONE and TRADE_RETCODE_DONE_PARTIAL before returning success. TryModify_EX12044 is invoked from ManageDynamicStopLoss; the two close helpers are defined but not currently called from the live path of this build, present for callers who want to wire in a basket-close or partial-close at the function-call level.

Debug logging is throttled at every layer. UpdateAdaptiveIndicators and CalculateRSI both use MathRand()%100 to gate their Print() output to roughly 1% of ticks. A separate tickCounter in OnTick triggers the full CheckAdditionalTradesConditions diagnostic walk every 50 ticks when EnableAdditionalPositionManagementDebug or EnableDebug is on, dumping the complete state — positions, signals, confirmation, market conditions, session — to the Experts tab. The five debug flags (EnableDebug, EnableRSI_Debug, EnableDynamicProfitManagementDebug, EnableAdditionalPositionManagementDebug, EnableIndicatorDebug) each gate their own subsystem; EnableDebug is the broad 'show me everything' master switch, the others are scoped.

In deployment the EA targets EURUSD on M5 or H1 with a recommended $100 starting balance and 0.01-lot scaling. The 5-point MaxSpread cap is the binding constraint on broker choice: a dealing-desk broker with 8-point spreads around rollover will block most entries, so the practical deployment is a raw-spread, sub-100ms-latency venue. The default config also reads at the file header: 'Suggested symbols: EURUSD (portable to other FX majors)' and 'Suggested timeframe: M5 (works M5-H1)'. Above H1 the volatility-bounded MA window stops responding meaningfully to intraday range changes, and below M5 the 5-point spread cap fails on most ticks during the rollover spread widening. M5 is where the .set files are tuned and where the documented backtests in the .mq5 header comments assume.