Kagodora Updates

Development Journal – Ray 2044 – 2026-05-12

Issue Summary

The Kagodora KaDo time system exhibited two critical problems:

1. Ring (AhReIEnGo) did not advance correctly
   • The plugin stored a manual ring value (ahreienqo) in the database, but the front‑page display computed the ring from ray using an incorrect starting point (ray 2009 = ring 1).
   • The correct timeline requires ring 6 to begin at ray 1801, with ray 2009 being the 208th ray of ring 6, and ring 7 starting at ray 2161.
2. Front‑end time reset to a future value on refresh
   • The JavaScript used a static updated timestamp from the database that never changed after a “Save Current Time” operation.
   • Without updating the reference timestamp, each page refresh added the elapsed time since the original save, causing the displayed time to jump ahead of real time.

Root Causes

• Ring math error: totalRings = floor((ray - 2009)/360) + 1 assumed epoch at ray 2009, but the real epoch starts at ray 1801 (ring 6).
• Missing timestamp update: The AJAX save handler did not refresh the updated column. The JavaScript also did not reset its internal state.timestamp after a successful save.
• Conflicting data sources: The database stored ahreienqo separately from the computed ring, causing potential inconsistency between admin settings and front‑end display.

Remedies Applied

1. Corrected Ring Calculation

In PHP (helper function):

phpCopyDownload

function mathorian_kagodora_compute_ring($ray) {
    return 6 + floor(($ray - 1801) / 360);
}

In JavaScript (mirrored logic):

javascriptCopyDownload

function computeRing(ray) {
    let ring = 6 + Math.floor((ray - 1801) / 360);
    return ring < 1 ? 1 : ring;
}

Now ray 1801 → ring 6, ray 2161 → ring 7, etc.

2. Unified Ring Source

• The front‑page AhReIEnGo display now always calls computeRing(ray) – no longer relies on a stored value.
• The admin settings page shows the ring as read‑only, computed from the current ray.
• When saving any time update (via “Save Current Time” or admin form), the ahreienqo column is automatically set to the computed ring. This keeps the database consistent without allowing manual override.

3. Fixed Timestamp Drift

In the AJAX save handler (PHP):

phpCopyDownload

$wpdb->update($table, compact('ahta','ahsa','ahgo','ahdo','ray','ahreienqo'), ['id'=>1]);
$wpdb->update($table, ['updated' => current_time('mysql')], ['id' => 1]);

In JavaScript (saveCurrentTime function):

javascriptCopyDownload

fetch(ajaxUrl, { method: 'POST', body: params })
    .then(res => {
        if (res.ok) {
            state.timestamp = Date.now() / 1000; // reset local reference
        }
    });

Now every “Save Current Time” operation updates both the database updated column and the JavaScript state.timestamp, so the elapsed time calculation starts fresh from that moment.

Outcome

• Ring increments correctly every 360 rays, matching the intended calendar (ring 6 from ray 1801, ring 7 from 2161, etc.).
• Front‑end time persists accurately across page refreshes and browser restarts.
• Admin settings and front page remain in sync – the ring is always derived from the ray, eliminating conflicting values.
• “Set Time / Calibrate” and “Save Current Time” buttons now fully respect the corrected math and update the reference timestamp.

Next Steps

• Monitor the system for any further drift, especially across long periods without updates.
• Consider adding a server‑side cron job that automatically saves the current time every day to keep the database timestamp fresh even if the front‑end is not visited.
• Document the new ring formula for future reference.