Something interesting from Chatgpt/AI please post here

kvak wrote: Mon Jun 08, 2026 4:50 am Hello, here is updated version with average pack and prices for test.

kvak wrote: Mon Jun 08, 2026 5:25 am and here is little updated version with colored ma, arrows and alerts...

xiannan wrote: Mon Jun 08, 2026 2:24 pm Hello, could you please share the source code files?

kvak wrote: Mon Jun 08, 2026 4:50 am Hello, here is updated version with average pack and prices for test.

Pelle wrote: Fri May 15, 2026 2:10 am AI have analyzed (AI) the code and your description of the discrepancy. This is a classic issue in MQL5 development related to History Synchronization and State Management when switching timeframes.

The Root Causes
Context-Dependent Z-Scores (The "Start of History" Problem): Your Z-score calculation depends on a 60-bar lookback (InpLenStat). In MT5, index 0 is always the oldest bar currently loaded on the chart.

Chart A (Stayed on 1m): Might have 10,000 bars. A bar at 12:00 has plenty of history behind it to calculate a valid Z-score.
Chart B (Switched back): MT5 often loads history in chunks. If it only initially loads 500 bars, the Z-score for those same bars might be calculated differently (or not at all) because the "window" of 60 bars looks different or hasn't loaded yet.
Object Persistence Bug (ObjectFind): In your code, you check if(ObjectFind(0, name) < 0) before creating/setting properties. If a bubble was created during a "partial" history load (with an incorrect Z-score), it will never be updated when the full history arrives because the object already exists.

Binary vs. Fractional Delta (Method Jump): There is a logical discrepancy in how bar_delta is calculated:

On a 1-minute chart, the code uses the mfm (Money Flow Multiplier) estimation (Fractional Delta).
On a 5-minute chart (with InpTFLower = M1), it sums up 1-minute bars using a simple Close >= Open logic (Binary Delta).
The sum of Binary Deltas for a 5m bar will not match the Fractional Delta estimation for that same 5m bar.
prev_calculated Optimization Lag: When history is prepended (scrolling back or syncing), the indices in your buffers shift. The code currently only calculates new bars at the end. This means historical bubbles aren't recalculated even if the data context around them changes.

Proposed Fixes
I will modify the indicator to:

Force Recalculation: Always refresh the last InpLenStat * 2 bars to ensure synchronization.
Update Existing Objects: Remove the ObjectFind check so that properties (color, tooltip, price) are updated if the calculation improves.
Synchronize Data Source: Add a "Data Quality" check to ensure lower timeframe data is actually ready before using it.
Stable Indexing: Use a more robust way to handle the start of the calculation.
I'll start by preparing an implementation plan.

Implementation Plan - Fixing Data Discrepancy in QuantMaster Liquidity
Proposed Changes
[Component Name]
[MODIFY]

QuantMasterLiquidityEvents.mq5
Logic Refresh: Modify OnCalculate to recalculate a larger buffer of bars (e.g., InpLenStat * 2) instead of just prev_calculated - 1. This ensures that as history syncs in the background, the Z-scores "heal" themselves.
Object Management: Change the object creation logic to always update properties (ObjectSet...) even if the object already exists. This ensures that if a Z-score changes after more history is loaded, the bubble size and color update accordingly.
Delta Consistency: Harmonize the delta calculation logic to reduce the gap between the mfm estimation and the sub-bar aggregation.
Data Sync Check: Add a check using SeriesInfoInteger to verify that the requested timeframe is synchronized before proceeding with CopyRates.

iardavan wrote: Tue Jun 09, 2026 10:04 am SOPR-Based Indicator for CFD / Forex Markets
Hello everyone,
I’ve developed a custom indicator inspired by the SOPR (Spent Output Profit Ratio) — originally a powerful on-chain metric from the crypto space — and adapted it for CFD and Forex trading.
What is SOPR?
SOPR (Spent Output Profit Ratio) is an indicator that reflects the degree of realized profit and loss for coins being moved on-chain.
It is calculated by taking only the coins/UTXOs that moved during a specific timeframe (daily, hourly, etc.) and computing the ratio between:

The price at the time the coin was acquired (UTXO creation)
The price at the time it was spent (sold/moved)

Interpretation Framework:

SOPR > 1 → Coins moved during the period are, on average, being sold at a profit.
SOPR < 1 → Coins moved during the period are, on average, being sold at a loss.
SOPR = 1 → Coins moved are, on average, being sold at break-even.
SOPR trending higher → Realized profits are increasing. This can signal that previously illiquid supply is returning to circulation.
SOPR trending lower → Realized losses are increasing, or profitable holders are not spending (HODLing).


I tried to bring this powerful concept into the CFD/Forex environment (where we don’t have real on-chain data). The result turned out quite interesting, and I’d love to get your feedback.
What I would like from the community:

Bug reports
Suggestions for improvement
Ideas on how to make it more effective for forex pairs, indices, commodities, etc.
Any thoughts on combining it with other classical indicators

I’ll share the indicator code/logic shortly (or in the next post) so we can discuss and improve it together.
Looking forward to your thoughts!

xiannan wrote: Tue Jun 09, 2026 3:44 pm Hello, brother, can you help me revise this solution you sent me? I sent it to my ai assistant, and it kept reporting errors after modification and optimization. I can't solve these problems. I hope you can help me. I wish you good health and all the best. If possible, please send the source file after modification. Thank you very much.

Pelle wrote: Thu Jun 11, 2026 12:22 am Try that version. After this I will not update this indicator again. This version was made with Gemini 3.5 flash.

### Change Log: Quant Master Liquidity Events (MQL5)

| Version | Date | Description of Changes |
| :--- | :--- | :--- |
| **1.01** | 2026-06-10 | **Statistical Accuracy:** Replaced population variance with sample variance ($N-1$) for Z-score calculations to ensure exact consistency with the TradingView Pine Script logic. |
| | | **Volume Engine:** Integrated automatic detection for real volume vs. tick volume. Optimized lower-timeframe processing by restricting the lookback history to 1000 bars, significantly improving performance and indicator stability. |
| | | **Visual Integrity:** Implemented dynamic tick-by-tick repositioning for bubbles and labels. Corrected bubble visibility logic so it properly respects the "Total Volume" input selection. |
| | | **Ghost Lines:** Built a FIFO (First-In, First-Out) queue mechanism that limits active ghost lines to a maximum of 10. This prevents memory leaks and keeps the chart clean. Ghost lines are now also properly restricted to only "Large" events. |
| | | **Dashboard:** Added dynamic resizing for legend and table cells (Small/Normal/Large/Huge). Implemented a full object cleanup routine when the dashboard is toggled off to ensure no residual UI debris is left on the chart. |
| | | **Live Stability:** Fixed a "sticky paint" bug by resetting signal event buffers at the start of each bar calculation, ensuring correct live updates. |