Supported mods
What WindLink has actually been run against on 26.1.x, and what happened. Anything not listed is untested rather than broken. The list is short because it is honest, not because compatibility is narrow.
| Mod | Kind | Status | Notes |
|---|---|---|---|
| Fabric API | required | verified | Hard requirement. Nothing loads without it. |
| Sodium | renderer | verified | WindLink's vertex work runs through it. Recommended. |
| Iris | shaders | verified | The channel bridge publishes WindLink's textures and uniforms through Iris. Needed for any shaderpack integration. |
| Continuity | resource | verified | Connected textures are untouched by the render takeover; both can be on. |
| Fresh Animations | resource | verified | Entity animation is separate from the wind field. No interaction either way. |
| Time-acceleration mods | gameplay | verified | WindLink runs its own real-time wind clock, so the wind is unaffected by a sped-up, slowed or frozen day. |
| BetterSmoke | visual | verified | Its smoke rides the shared wind field and gusts while keeping its own strength settings, so every one of its options still works. BetterSmoke's own files are untouched. |
| Motschen's Better Leaves & forks | resource | works, not formally tested | Bushy-leaf packs get bending fronds from mcw_leafSway. Confirmed by eye rather than by a test pass. See the note below. |
| Eclipse (MCWIND fork) | shaderpack | prototype | The reference vendoring: mcwind.glsl included unmodified and called for grass and canopy in both the geometry and shadow passes. Offered upstream to Eclipse's author rather than shipped, and not reviewed by them. |
On “verified”
Verified means run on 26.1.x this release and observed working. The frond behaviour for bushy-leaf packs is deliberately not in that category: its independent verification pass was stopped part-way to get the release out. It looks right and the correctness argument is sound (every vanilla leaf-cube vertex sits below the frond response ramp, so the terms are a hard no-op on vanilla geometry), but that is an argument, not a test result, and it is listed as such.
Shaderpacks
Any pack that implements MCWIND is supported.
There is no allow-list and no per-pack code. A pack that vendors
mcwind.glsl receives the provider's uniforms and channels automatically. WindLink
does not know or care which pack is loaded.
The clearest worked example is in someone
else's pack, not ours: MCWIND
wired into Eclipse. It vendors mcwind.glsl unmodified, byte for byte, and
calls it from both the geometry and shadow passes for grass, canopy, the debris wash and fire, with every dial exposed in its settings screen. You can
checksum the header in that repo against the one published here and get the same answer, which
is the only proof that actually means anything.
It is a fork offered upstream rather than a shipped adoption, and Eclipse's author has not reviewed it. It is here because it shows what the integration costs in a pack nobody wrote for this standard.
The PlunderPixels Shader is the feature showcase rather than the vendoring proof. It carries its own implementation, because it predates MCWIND and does a good deal the standard does not cover. New wind behaviour is built there first and distilled into the header afterwards.