derivato da animatedread/Warrior_EA
| Nome del file | Ultimo messaggio di commit | Ultima data di commit |
|---|---|---|
THE EXIT KNOB. Exit_On_Reversal_Vote (default false) replaces the deleted Signal_ThresholdClose with one boolean: false pins the close threshold to an arithmetically unreachable 101, true pins it to the SAME threshold the entry uses - the seed at first, then the derived value, republished together whenever it moves. A second threshold was always redundant; "the bot now says the other way" is one question. It also arms CExpertSignalCustom::m_holdToBarrier, which was DEAD CODE: HoldToBarrier(bool) had no caller anywhere in the build, so the flag had been permanently false and the disabled close threshold was carrying the whole hold-to-barrier policy alone. Both halves now move together. Default stays false because the reason is statistical: the gate certifies P(label agrees | vote fired) against a label that runs to the barrier, so an early close trades something never measured. Turning it on is a different strategy, not a tightening of this one. THE PIN. The live threshold now moves only when an era's weights become the checkpoint, and freezes once g_ensDeployApproved. Every era still derives its own rung - that is how the best one is found - but the rung that TRADES belongs to the checkpoint, exactly as the weights do. Two reasons, one measured and one structural: the per-era rung moves on 6-34% of steps (the live run flapped SP500 15 -> 10 -> 15 within a minute of starting), and without the pin a later era's rung could end up applied to an earlier era's deployed model. A ladder restart releases the pin, since clearing the checkpoint clears what it pinned. The era line now prints the rung its own numbers came from, so it stays honest when that differs from the pinned one. THE ATOMIC RENAME retried zero times. Six charts share the TrainPool and AltData directories, so a publish regularly lands while a peer chart holds the destination open and FileMove returns 5004 - 27 times in one day on the live fleet. Nothing was lost (the temp keeps the new content, the old file stays intact) but the row did not update until the next publish. Now four attempts at 25ms, on the FAILURE PATH ONLY - a successful rename never sleeps - and skipped in the tester, where the contention cannot happen and Sleep would distort a pass. A rescued retry is logged, so worsening contention is visible. Retrain-neutral. Compiled clean; NOT yet run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| ConfidenceBridge.mqh | ||
| IndicatorResources.mqh | ||
| IndicatorTuneRanges.mqh | ||
| Inputs.mqh | ||
| README.md | ||
| RiskBudget.mqh | ||
| TunedPeriods.mqh | ||
| Variables.mqh | ||
Variables Subsystem (Variables/)
Overview
The Variables/ directory contains global input parameters and runtime variables for the Warrior EA. These files centralize configuration, feature toggles, and runtime state, supporting both user customization and internal logic.
Key Components
Inputs.mqh
- Purpose: Defines all user-configurable input parameters for the EA.
- Contents:
- General EA settings (magic number, training mode, logging, etc.)
- Money management strategy selection and parameters
- Entry strategy and thresholds
- Trailing stop strategy selection
- Neural network/AI configuration (algorithm, layers, training years, etc.)
- Indicator and feature toggles (enable/disable specific indicators and features)
- Time/session filter settings
- Integration: Used for both manual and programmatic configuration of the EA. Enables dynamic feature selection and AI/ML pipeline configuration.
Variables.mqh
- Purpose: Stores global runtime variables and constants.
- Contents:
- EA name and database schema
- Backtesting and feature enablement flags
- AI/ML signal toggles (EnablePAI, EnableCONV, EnableLSTM)
- Integration: Used throughout the EA for runtime logic, feature gating, and database operations.
Integration Notes
- Centralized configuration and variable management improves maintainability and supports advanced, AI/ML-driven workflows.
- Feature toggles allow for rapid experimentation and safe deployment of new logic.
Documented April 2026. For further details, see the main project documentation.