Ashley used 100 Time-Turning Sand on a destroyed hull tonight and got nothing back but a "wrong repair item" warning in the server log. The sand-on-ship-deed mechanic has been broken on the NL0bP fork since the canonical data ran out of sync with the skill system. Patched.
What was actually wrong
Two compounding bugs, one C# type confusion and one canonical-data gap.
Bug 1 — wrong column. The server-side check goes:
> Look up this slave's row in repairable_slaves. If it's there, compare its repair_slave_effect_id against the current effect's ID. If they match, repair. Else reject.
The repair_slave_effect_id column is a foreign key into repair_slave_effects.id (small values: 2, 3, 4, 5). The C# was comparing it against EffectTemplate.Id, which is the effects.id (16498, 19131, 19132, 29783, 43079, 43222 — the six RepairSlaveEffect rows). Those number ranges never overlap, so the check rejected every repair attempt regardless of whose sand was used.
Bug 2 — sand-version mismatch. Even if the comparison had been pointing at the right column, the canonical data only maps each slave type to ONE specific sand variant. Ashley's ship (slave type 21) maps to actual_id=2 — the oldest "Shatigon's Sand" introduced when this mechanic first shipped. There are now six different sand items in the canonical data, six different skill IDs (16561, 17595, 17596, 21651, 27968, 28045), six different RepairSlaveEffect rows — but the slave-to-effect mapping table was never extended past the first variant. The current-tier sand item (the one in Ashley's inventory, item template 35898) uses effect 43222 / actual_id=7 — which repairs zero ships in the canonical data. The five other tiers are similarly stranded.
In practice all seven sand items have identical gameplay effect ("restore a destroyed ship to full HP"). The version-specificity has no meaning in 3.0+ where they're all functionally interchangeable.
What this patch does
Replaces the strict-per-effect-id check with a Rookery rule:
> Any Shatigon's Sand variant repairs any repairable ship.
We still gate on the slave being in the canonical repairable list — gliders, mounts, and other non-repair-via-sand summons keep their original behavior. The only thing that changed is that we no longer require a specific sand tier match a specific ship's mapping.
What this means for you
If you have a destroyed ship deed sitting in inventory with a yellow "use Shatigon's Sand to reverse time" warning, the sand actually works now. Drop one onto the deed, wait the cast bar out, and the ship goes back to full HP.
We have no plans to differentiate between sand tiers in the future — they're treated as one item for repair purposes. If we ever do introduce tiered behavior (e.g., cheaper sand only repairs hulls, expensive sand also repairs guns), we'll patch the C# and the data together.
Behind the scenes
- One file changed:
RepairSlaveEffect.cs(about 25 lines of new comment explaining the why + a 3-line check that replaces the broken comparison). - No client patch. No DB migration. No new MariaDB table.
- Server restart applied at the patch landing. The pre-fix process logged six identical warnings before this fix shipped — those are the smoking gun in
Server.log. - The original "wrong repair item" warning is preserved but reworded with a
[Rookery]tag so the next time someone hits the defensive branch (truly non-repairable slave), we know it's not the fixed bug.