qwepoi123 wrote: Tue Jun 17, 2025 11:20 am @mrtools ,Dear friend, I'm sorry but for some reason, all of my messages from yesterday have disappeared. It may be a violation of the forum's rules. Due to changing my trading platform, I need your help because of these reasons
The original author of these indicators is you, so I need your help to convert them into the EX5 version? Thank you, my English is not very good. I hope you can understand the trouble caused by this. Thank you! Thank you for your great contributions!

qwepoi123 wrote: Tue Jun 17, 2025 11:20 am @mrtools ,Dear friend, I'm sorry but for some reason, all of my messages from yesterday have disappeared. It may be a violation of the forum's rules. Due to changing my trading platform, I need your help because of these reasons
The original author of these indicators is you, so I need your help to convert them into the EX5 version? Thank you, my English is not very good. I hope you can understand the trouble caused by this. Thank you! Thank you for your great contributions!

ZigZag wrote: Thu Jun 12, 2025 8:26 pm If you are working with non-native code editor (like me), use this prompt for editor AI agent and feel free to suggest something else too if you found critical issues.

This is before you will start adding more complexity & bridges & features for your existing tools.

Also, run this prompt to every indicator you actuall use just like this !

You will be surprised.

If you are bulding new one add this one too "This code is built in accordance with the "Anti-Corruption Blueprint" architecture. It isolates the core signal computation, stores it in a "pristine" state, and applies all additional features modularly without feedback loops. Each feature is independent, user-configurable, and adheres to MQL5 standards and the strict constraints you have set.

Context: The following rules and prohibitions must be followed precisely when adding new features to an existing, functioning MQL5 indicator. The goal is to preserve the indicator’s stability, non-repainting nature, and compatibility, while adding new functionality in a modular way. All rules are critical, and violating them may break the functionality of the indicator."

Part 1: Context and Fundamental Rules

The “Engine” is Locked
◦ All existing calculation functions (e.g., ApplyAdaptiveFilter, CalculateAdaptiveNormalization, SetSignalVisualization) and their internal logic are untouchable.
◦ These functions must not be altered in any way, as they are proven stable and non-repainting.

OnCalculate() is Sacred
◦ The structure or calculation loop of the existing OnCalculate() function must not be modified.
◦ The only allowed change is appending an independent function call for a new feature at the end of the loop.

OnInit() is Sacred
◦ The content of OnInit() must not be modified unless a new feature explicitly requires the initialization of a new buffer or plot.
◦ In such a case, the change must be minimal and appended only at the end of the existing structure.

No Feedback Loops
◦ A new feature may only read from existing buffers (e.g., main_signal[], upper_zone[]).
◦ It must not write to or influence the calculation of these buffers in any way.
◦ New features must act as “readers,” not “writers” to the engine.

No Heavy Operations in OnCalculate Loop
◦ The OnCalculate() loop must not include heavy operations, such as:
▪ ObjectCreate
▪ File handling
▪ Loops iterating over historical data

Preserve Original Style
◦ The original formatting, indentation, and commenting style must be preserved.

Part 2: Additional Areas and Prohibitions

Data Type and Precision Rules
◦ Always use the double type for price and calculated values. Never use float.
◦ Never use NormalizeDouble() during calculations. Only use it for final output (e.g., Print(), Comment()).
◦ Remember, color is a distinct type – use ColorToARGB() or equivalent correctly.

Built-in Indicator Rules
◦ Indicator handles are to be created only in OnInit() and stored in global variables.
◦ CopyBuffer() is only allowed in OnCalculate() for fetching data.
◦ Do not call functions like iMA, iRSI, iATR inside the OnCalculate() loop.

Code Clarity Rules
◦ Do not use magic numbers (e.g., if(value > 1.5)) without defining them.
◦ New thresholds must be defined using input variables or #define macros.

Error Handling Rules
◦ Always check if function calls like SetIndexBuffer, CopyBuffer succeed.
◦ If CopyBuffer fails, skip the calculation for that candle.

Variable Management Rules
◦ Do not use existing global or static variables in new feature logic.
◦ Create clearly named, dedicated variables for each new feature.
◦ Do not recycle existing variables, even to save space.

Structural Compatibility
◦ New features must not alter the indicator’s existing visual or computational behavior unless explicitly requested.
◦ New visual elements (e.g., PlotIndexSetInteger, ObjectCreate) must be controlled via input booleans.

Compatibility Across Timeframes and Symbols
◦ Do not hardcode Symbol() or Period() comparisons.
◦ All features must function correctly across all symbols and timeframes.

Modularity and Removability
◦ Each feature must be implemented modularly so it can be removed without affecting others.
◦ All names (variables, functions) must be clearly tied to the feature name (e.g., ZeroCross_AlertFired).

No Assumptions
◦ Do not add logic or default behavior unless explicitly requested (e.g., ObjectDeleteAll()).
◦ All operations must be based on input values or existing code.

Use Only MQL5 Syntax – No MQL4
◦ Do not use MQL4 syntax (e.g., IndicatorBuffers(), SetIndexStyle(), ArraySetAsSeries()).

No PlotIndexSet... Calls in OnCalculate()
◦ Drawing is controlled by writing values (or EMPTY_VALUE) to buffers.

Technical Requirements and Best Practices
◦ Stable Drawing:
▪ All plot properties (PlotIndexSetInteger, PlotIndexSetString, PlotIndexSetDouble) must be set only in OnInit().
▪ Do not change plot types or persistent visual settings inside OnCalculate().

◦ Visibility Dynamics via EMPTY_VALUE:
▪ Drawing visibility is managed by writing EMPTY_VALUE to the buffer to hide plots for specific candles, without changing visual properties on the fly.

User Customizability
◦ All new features must be user-configurable, including line widths, colors, and thresholds.
◦ Each feature must have on/off switches grouped in the indicator settings.

MQL5 Standard Compliance
◦ All syntax, functions, and structures must follow the MetaTrader 5 MQL5 standard.
◦ Use SetIndexBuffer() for data binding (e.g., SetIndexBuffer(0, main_signal, INDICATOR_DATA);).
◦ Use only PlotIndexSetInteger(), PlotIndexSetDouble(), PlotIndexSetString() for visual settings.
◦ Do not invent functions like PlotIndexSetBuffer. Data binding and visual formatting are separate processes.

OnInit() Rules
◦ Use OnInit() for setting all visual properties of plots:
▪ For data binding: SetIndexBuffer()
▪ For visuals: Only PlotIndexSetInteger(), PlotIndexSetDouble(), PlotIndexSetString()
▪ Do not merge these processes. Keep binding and styling separate.

No Shared Global Variables (Shared State Ban)
◦ Do not use global or static variables to store intermediate results inside OnCalculate().
◦ Globals are only allowed for storing input values from OnInit() (e.g., MarketSensitivity = InpMarketSensitivity;).
◦ Previous candle values must always be read from buffers (e.g., GetSafeValue(volatility_buffer, shift + 1)), not globals.
◦ Violating this rule breaks multi-instance functionality; each instance must run independently in its own sandbox.

Global Filters are Untouchable
◦ Do not modify existing global filters.

Part 3: New Prohibitions and Clarifications

No Dynamic Re-definition of Buffers
◦ Do not attempt to change the type (INDICATOR_DATA, INDICATOR_COLOR_INDEX, etc.) or size of existing buffers at any point during execution.
◦ New buffers must be declared in OnInit() and remain unchanged throughout the indicator’s lifecycle.

No Iterative Calculation Attempts
◦ Do not add logic that tries to “fix” or iterate calculations inside OnCalculate() if the result is unexpected (e.g., repeated attempts with different parameters).
◦ This could cause instability and violate the non-repainting rule.

No External Dependencies Without Permission
◦ Do not add dependencies on external libraries, files, or resources unless explicitly requested.
◦ All logic required for a new feature must be self-contained within the code.

No Optimization Attempts Without Documentation
◦ Do not try to optimize existing code (e.g., simplify calculation functions) unless explicitly requested.
◦ Optimizations may silently break sensitive logic, especially in adaptive filters.

No Default Activations for New Features
◦ New feature parameters must not have default values that affect behavior without user intent.
◦ For example, a new alert must default to off (false), not on.

No Global State Variables for Temporary Use
◦ Do not use global variables to store temporary states (e.g., “was alert triggered on this candle”).
◦ Use clearly named local variables or buffers specific to the feature (e.g., new_feature_state_buffer[]).

No Hidden Functions or Background Calculations
◦ Do not add any logic that runs calculations or actions in the background without being visible or user-controlled.
◦ All actions must be tied to input parameters.

No Dynamic Time Interval Checks
◦ Do not add logic that checks candle time intervals (e.g., if(Time - Time[i-1] > some_value)) unless explicitly requested.
◦ This can lead to inconsistent behavior across timeframes.

No Overwriting Global Buffers
◦ Do not use existing global buffers as temporary storage in new feature logic.
◦ Always create new buffers for new features.

No Google-AI Style Logic Overwrites
◦ Do not replace or restructure existing logic even if it seems “better” or “simpler.”
◦ Google-style AI overwrites are dangerous—small changes may silently break non-repainting behavior or cause unexpected output.
◦ Example: Do not modify the function that calculates an adaptive average, even to add a new parameter. Instead, create a separate function.

Do Not Reduce Line Spacing or Compress Existing Code
◦ Do not reduce line spacing or compress code unless excess blank lines are truly unnecessary.
◦ Long and tightly packed lines make manual debugging significantly harder.

No Hardcoded MTF Values
◦ Do not hardcode any Multi-Timeframe (MTF) values, such as timeframes, data sync methods, or buffer sizes.
◦ All MTF features must be implemented dynamically using input ENUM_TIMEFRAMES parameters.
◦ Examples of prohibited practices:
▪ Hardcoded timeframe list (e.g., if(timeframe == PERIOD_H1))
▪ Hardcoded assumption of MTF data availability (e.g., CopyBuffer(handle, 0, 0, 100, buffer) without dynamic sizing)
▪ Hardcoded sync logic (e.g., assuming MTF data always aligns with current candle index)
◦ MTF functionality must be fully configurable via input parameters and work seamlessly across all timeframes without manual code adjustments.

siphoMaseti wrote: Fri May 31, 2024 8:33 am Can someone please share or code this for mt5 please