Verity mod not working: source-first troubleshooting

When Verity-CE does not start or cannot reach an API, begin with the exact error rather than replacing files at random. This guide covers the public community project at Esylmu/Verity-CE. It does not diagnose an unrelated build that happens to use the same Verity name.

Confirm which build you installed

Record the repository URL, release tag, asset filename, Minecraft version, and loader before changing anything. The public release currently linked by this guide is named neoforge-1.21.1-1.0b(ce), and its asset name includes both mc1.21.1 and neoforge. Those labels are the first compatibility check.

If your file came from a mirror, a message attachment, a video description, or a different repository, this page cannot establish what that file contains. Return to the source that published it and use that source's documentation.

Preserve the first useful error

Launch failures often produce many follow-on messages after the original problem. Save the first error that names a mod, dependency, class, configuration field, or network response. Also keep the full loader log before launching again, because a later run may overwrite it.

Compare four items exactly:

The Minecraft version in the instance.
The loader named by the release asset.
The JAR filename you placed in the instance.
Any dependency or version named in the first loader error.

A mismatch in any one of these items is more useful than the final generic crash message.

Match the symptom to the first check

Do not apply every fix on this page at once. Start with the row that best matches the first visible symptom.

| Symptom | First check | What to save | | --- | --- | --- | | The loader rejects the JAR before the menu appears | Minecraft version and loader named by the release | The first loader error and JAR filename | | A dependency is missing or has the wrong version | The current README and the dependency named in the error | The complete dependency line, not only the final crash code | | The game starts but an AI-backed feature does not answer | API endpoint, model name, provider status, and quota | A redacted provider response and timestamp | | "API connection failed" appears | Authentication and endpoint path before changing Minecraft files | HTTP status or provider error with secrets removed | | A clean instance works but a normal profile fails | Conflict with another mod or old configuration | A list of files added after the clean test | | A tutorial expects a feature that never appears | Whether that tutorial covers the same project, build, and version | The tutorial URL, date, and exact release used |

If the symptom does not fit any row, preserve the original instance and collect evidence before uninstalling or replacing files. A reset that destroys the first error also removes the best clue.

Fix an API connection failure

The public README documents configurable values for an API base URL, API key, model name, and TTS/STT services. An "API connection failed" message therefore may come from the configured provider rather than from Minecraft or the loader.

Check the endpoint URL for missing path segments, extra spaces, and an incorrect protocol. Then check the provider dashboard for an expired key, disabled account, unavailable model, quota limit, or billing restriction. A model name accepted by one provider may not exist at another provider.

Do not post the complete configuration file in a public issue. Remove or mask API keys, tokens, account identifiers, and local file paths first. If a key has appeared in a screenshot, log excerpt, repository, or public message, revoke it and issue a replacement instead of continuing to test the exposed value.

Change one field at a time. If you change the endpoint, key, and model together, a successful or failed retry will not tell you which change mattered.

Read the API error without exposing a key

An authentication response such as 401 or 403 points to credentials or provider policy, while 404 often points to an endpoint path or model route. A rate-limit response such as 429 is different from a network timeout. These are starting points, not universal diagnoses; use the provider's current documentation for the exact meaning.

Before sharing an error, replace the full API key, authorization header, account identifier, and private endpoint parameters with [redacted]. Keep the status code, timestamp, model name, and non-secret response message. That leaves enough context for troubleshooting without turning a support request into a credential leak.

Diagnose a loader or dependency error

The project README says the community build targets Minecraft 1.21.1 and uses GeckoLib 4.9.1. Treat the current README and release notes as the source of truth if those details change. Do not add a dependency solely because an old tutorial names it.

Use a separate test instance containing only the loader, documented dependencies, and the Verity-CE JAR. If that controlled instance starts, reintroduce other mods one at a time. If it fails, preserve the clean log and compare it with the project's issue tracker before adding more files.

The README also mentions fixes for type-conversion errors and multi-end entity spawning conflicts. That does not mean every similar error has the same cause. Match the exact error and release before relying on a changelog item.

Check configuration without losing the original

Make a backup of config/verity-common.toml before editing it. Compare field names with the current README and keep placeholders such as your-api-key out of a live configuration. A placeholder is documentation, not a working credential.

If the game starts but an API-backed feature does not respond, separate the tests: confirm the game and mod load first, then test provider authentication, then test the selected model or speech service. This prevents a provider outage from being mistaken for a loader failure.

When to stop troubleshooting

Stop if the only available download is from an unverified mirror, if instructions require disabling security controls, or if a support request asks you to publish a secret. A working launch does not prove that an unknown file is trustworthy.

For a reproducible reset, remove only the last file or setting you added, restore the saved configuration, and retest in the separate instance. Do not delete worlds or a working profile as a first troubleshooting step.

What to include in a useful support request

A good report should let another person reproduce the same boundary without guessing. Include the repository URL, release tag, asset filename, Minecraft version, loader version, operating system, and the first relevant error. State whether the problem also occurs in a separate instance containing only documented requirements.

Do not say only "Verity is not working." That phrase can describe an incompatible JAR, a missing dependency, an API provider failure, a configuration typo, a conflict with another mod, or an expectation copied from a different build. The exact symptom determines which layer to inspect.

Attach logs as text when possible, after removing secrets and personal paths. Screenshots can hide preceding lines and make error text hard to search. Never attach a complete configuration file containing a live API key.

When an old guide and the current release disagree

Prefer the current repository and release page for the exact file you installed. An older guide can still explain a useful concept, but its loader, dependency, configuration field, or distribution path may no longer match. Do not combine instructions from two builds simply because both pages use the name Verity.

If the current project documentation is incomplete, record the gap and ask the maintainer rather than filling it with a mirror, guessed dependency, or uncited download. This is especially important for Lunar Client, Fabric, Bedrock, and older-version instructions that are not documented by the current public Verity-CE release.