forked from animatedread/Warrior_EA
| Filename | Latest commit message | Latest commit date |
|---|---|---|
6308a19f27
The declustering the charts needed already existed - NmsLiveAccept, per-direction run-collapse plus cross-direction resolution plus strict alternation - and it was already set to 10 bars. It could not be TUNED: SignalClusterWindow was a compile- time const, so finding the right value needed a rebuild. That is the actual gap. Now three inputs, as enum dropdowns: Signal_CooldownScope per-direction, or a hard any-direction gate on top Signal_CooldownBars SCB_OFF..SCB_50, default 10 Signal_CooldownMinutes SCM_OFF..SCM_1440, overrides bars when set Minutes resolve against the CHART period and round UP, so a cooldown asked for in wall-clock is never silently shorter than requested and survives a timeframe change. SCB_/SCM_ prefixes are deliberately unique. M15/M30/M60 are ALREADY members of NF_LOOKBACK_PRESETS, and MQL5 binds a duplicated enum member to the first-declared enum silently - the obvious names would have compiled straight into the news filter's values. THE ANY-DIRECTION GATE IS ADDITIVE, NOT A REPLACEMENT, and the first cut of this had it backwards. Measured on the live log: the current rules draw 222 arrows over 4999 bars, while a BARE 10-bar cooldown permits up to 454 - because ALTERNATION is what declutters today, not the window. Swapping the rules out would have roughly doubled the clutter it was asked to remove. Layered, it can only ever suppress more. Suppressed bars still advance the per-direction last-SEEN cursors, so a run straddling the boundary does not restart as if it were fresh. Applied at all THREE sites that must agree - live inference, OOS pass-3 scoring and the chart renderer. Their own comments say why: an arrow set that does not obey the same rule as the traded set shows calls the EA would never take. Also corrects a stale comment that called this window "display only". It is not: when it suppresses, the live path zeroes the signal outright - no arrow, no vote, no position. Training never sees it, so these cost no retrain and are correctly absent from the fingerprint. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| GlobalEnums.mqh | ||
| InputEnums.mqh | ||
| README.md | ||
Enumerations Documentation
GlobalEnums.mqh
Defines the ENUM_SIGNAL enumeration for trading signal states:
Buy: Indicates a buy signal.Sell: Indicates a sell signal.Neutral: Indicates a neutral/no-action signal.Undefine: Indicates an undefined or uninitialized state.
InputEnums.mqh
Defines a large set of enumerations for configuration and input parameters used throughout the EA. These include:
- Custom menu and property enums for UI/configuration.
- Period presets (e.g., 5, 10, 14, 20, 30, 50, 100, 200) for indicator calculations.
- Training years presets for ML/AI training window selection.
- ATR multipliers for volatility-based calculations.
- Threshold presets for signal/trigger sensitivity.
- Risk/reward ratio presets for money management.
- Bars expiration settings for trade/session logic.
- Entry multipliers for order sizing.
- Trailing strategy types (none, ATR-based, SAR, MA, etc.).
- Money management strategies (fixed risk, intelligent, fixed lot, etc.).
- Day-of-week and session enums for time-based logic.
- ITF (Intraday Time Filter) settings.
- Hourly session presets (H1-H23) for time filtering.
Purpose: These enumerations provide a strongly-typed, maintainable way to configure and control the EA's behavior, supporting both traditional and AI/ML-driven logic. They enable dynamic feature selection, risk management, and strategy configuration, and are essential for modular, testable code.
Modernization Note:
- Enumerations should be referenced in configuration UIs and parameter files to enable dynamic, user-driven feature pipelines.
- Consider extending enums to support new AI/ML features and dynamic input selection as the EA evolves.