Guidefor players4 min read
Does Oculus need Rubidium or Embeddium? CurseForge's own metadata disagrees
Oculus for 1.20.1 needs Embeddium, but its CurseForge file listings say Rubidium on older builds and say nothing at all on the newest one. The jars and the platform metadata do not match, and no changelog will ever mention it.
The question that will not settle
Oculus is the Forge port of Iris, and like Iris it needs a Sodium style renderer underneath it to draw shaders. On Forge 1.20.1 that renderer is Rubidium or its fork Embeddium. Which one Oculus wants has been asked on its comment threads continuously since 2023, and the answers contradict each other. Some people say Rubidium, some say Embeddium, some say roll back to 1.7.0, some say 1.6.15a specifically.
Everyone is partly right, which is the problem. The answer changed, and the place most people read it from did not.
What the files actually say
CurseForge stores dependencies per uploaded file rather than per project. Every version of a mod carries its own list, frozen at upload. Here is what Oculus's 1.20.1 files declare as required, read from the official CurseForge API:
| Oculus file | Uploaded | Declared required dependency |
|---|---|---|
| 1.20.1-1.8.0 | Dec 2024 | none |
| 1.20.1-1.7.0 | Apr 2024 | Embeddium |
| 1.20.1-1.6.15a | Feb 2024 | none |
| 1.20.1-1.6.15 | Feb 2024 | Embeddium |
| 1.20.1-1.6.13 | Dec 2023 | Embeddium |
| 1.20.1-1.6.9 | Sep 2023 | Rubidium |
Read that column top to bottom and the confusion explains itself. The record moved from Rubidium to Embeddium at the end of 2023, correctly. But two uploads, 1.6.15a and 1.8.0, declare nothing at all, including the newest file most people install.
Now open the jars. Oculus 1.7.0 and 1.8.0 both contain the same line in
META-INF/mods.toml:
[[dependencies.oculus]]
modId = "embeddium"
mandatory = false
versionRange = "[0.3.1,)"
The jar knows what it needs. The platform record for that same jar is empty. And 1.6.9, whose record says Rubidium is required, declares no renderer dependency in its jar at all.
What that does to you
If you install the newest Oculus through the CurseForge launcher, it resolves no dependencies, because the file declares none. You end up with Oculus and no renderer, and nothing warns you.
If you install an older Oculus, or open a pack pinned to one, the launcher faithfully installs
Rubidium, because that is what the 2023 record says. Rubidium is not what the jar wants. It
also cannot simply be joined by Embeddium later: Embeddium ships a stub entry declaring the
rubidium mod id so that mods hunting for Rubidium still find something, so both jars present
means two mods claiming one id, and the loader stops. And if Create is anywhere in the pack,
Rubidium triggers a separate crash entirely, covered in
the Flywheel and Sodium version error.
Then the fix creates one more trap. Embeddium declares an optional dependency on oculus with
the range (1.6.15,), strictly greater than 1.6.15. Someone who rolls Oculus back too far to
escape Rubidium lands on a version Embeddium rejects. That is the real reason the folk advice
names 1.6.15a and not 1.6.15. Nobody explains it, because it is one line in a file almost
nobody opens.
Checking any mod's real dependencies yourself
Two ways, and they answer different questions.
Read the jar. A .jar is a zip. Open it, read META-INF/mods.toml on Forge or
fabric.mod.json on Fabric, and look for the dependency blocks. This is what the loader
actually enforces at startup, so it is the authority. It costs about fifteen seconds and it
would have ended this question in 2023.
Read the platform record. On a CurseForge file's own page, the relations shown belong to
that file, not the project, so check the exact version you are installing rather than the
project page. Through the API, each entry in a file's dependencies array carries a
relationType, where 3 means required, 2 optional and 5 incompatible. This is what your
launcher will act on, which makes it worth reading even when it is wrong, because it predicts
what gets downloaded.
When the two disagree, the jar wins at runtime and the record wins at install time. That gap is the entire bug.
What to install
On Minecraft 1.20.1 Forge: Oculus 1.20.1-1.8.0 plus Embeddium, with no Rubidium jar in the folder. Delete Rubidium rather than disabling it. If Create is present, Embeddium 0.3.25 or newer, since Flywheel asks for that range.
Why this is not the split jar problem
It is worth being precise about what kind of failure this is, because it looks like a core and addon pair falling out of sync and it is not. In that case, two jars from one author genuinely drift apart in code, the older one really is incompatible, and the error is telling the truth. Updating both sides fixes it.
Here, nothing is out of sync. Oculus 1.8.0 and Embeddium work together exactly as their authors
built them. The jars are correct and their contents have said embeddium for years. What is
wrong is a row in a distribution platform's database describing those jars, and no update to
either mod can repair it, because neither mod is where the error lives.
That is why it belongs written down somewhere. No changelog will carry the line "the dependency list on our 2023 upload is stale," because changelogs describe code. Three years of people telling each other to try Rubidium, then Embeddium, then to roll back two versions, is what happens when the authoritative fact lives in a field nobody thinks to read.
