How to Install Verity Mod

Back up your saves, install the matching loader, and run its profile once. Close Minecraft, place the verified JAR in that profile's mods folder, add only documented dependencies, then launch a disposable test world.

• Forge 1.20.1 for stable Verity JE 5.7.4 or the separate 6.0.0-beta.9 test release
• Matching Forge 1.20.1 GeckoLib alongside the Forge JAR
• NeoForge 1.21.1 for the older Verity JE 3.4.1 release
• Keep the JAR intact; do not extract it
• Test Verity alone before combining modpacks

Get GeckoLib for Forge 1.20.1 ↗ · Watch the Verity JE 6.0+ setup tutorial ↗

Download the package for your Bedrock version and open it with Minecraft. Apply the imported behavior and resource packs to a new world, then enable the Beta APIs or experiments named by that specific project.

Connection commands and AI services differ between projects. PnTMC's add-on requires the helper program for your platform, WebSockets, Beta APIs, and Cheats. On iOS, text chat is available but microphone input and !talk are not supported. Use the platform instructions below for the helper and connection steps.

PnTMC platform and connection instructions ↗ · Verity BE requirements and setup ↗

Open your launcher and create a separate installation for the required Minecraft release. Install Forge for the current 1.20.1 stable or beta branch, or NeoForge for the older 1.21.1 release. Start that loader profile once without Verity JE, reach the title screen, and close the game. This creates the instance folders and proves that the loader itself works before another variable is introduced.

Open the instance directory from the launcher, place the unchanged JAR in its mods folder, and add the matching GeckoLib build for Forge 1.20.1 when using either Forge release. Remove any previous Verity JAR from that instance. Launch again and create a temporary world. Stable 5.7.4 fixes a missing Groq model; the 6.0 test branch uses a new AI configuration and supports local Ollama without LiteLLM. Use the 6.0+ tutorial for that branch, then configure microphone access and voice settings separately.

• Back up saves and the working instance
• Install and test the loader by itself
• Copy the matching JAR without extracting it
• Add documented dependencies only
• Configure external services after the game loads

Choose one public Bedrock project, verify its creator and Project ID, and download the .mcaddon made for your game version. Open the package with Minecraft and wait for the import result. Create a test world, activate the package's behavior and resource components, then turn on only the Beta APIs or experiments listed by that project. Importing a file alone does not guarantee that its packs are active in an existing world.

Enter connection commands or service details only from the selected maintainer's instructions. If the add-on works in the test world, make a fresh backup of the world you eventually want to use. Apply the same pack and experiment settings there, and keep the original backup untouched. Never rename a Java JAR to imitate a Bedrock package or mix scripts from two separately maintained projects.

If Java crashes before the menu, remove unrelated mods, confirm the exact loader and game versions, and read the first specific error in latest.log or the crash report. If Bedrock imports successfully but nothing changes, confirm that the packs are applied to that world and that required experiments are enabled. Re-downloading is useful for a damaged file, but it will not repair a version mismatch or missing activation step.

Change one variable between tests and write down the result. Once the clean installation works, add other mods or packs back in small groups. Keep the known-good profile, test world, and previous release until the full setup has been stable through several launches. When seeking help, provide the edition, Minecraft version, loader or add-on release, creator, relevant error text, and the last action that worked without exposing private keys.

After a stable test, record the working file version, loader build, active packs, experiments, dependencies, and any provider model or endpoint. That record turns a future update into a controlled comparison. Keep credentials outside public screenshots and shared logs, and never upload a whole game directory when a short error section is enough. Restore from a backup if a valuable world behaves differently instead of repeatedly saving it during diagnosis.