简体中文
English
Website review
This review may include AI-generated content and is not individually verified. Domain, certificate and other facts come from the observed data on this page.
What is The NeoForged project?
The NeoForged project is the organisation behind NeoForge, a modding platform and loader for Minecraft. Its site, The NeoForged project, is primarily a download and documentation hub: you pick your Minecraft version and NeoForge version, get an installer, and then either run mods or start building them.
NeoForge occupies the same niche as older Minecraft mod loaders: it patches the game so third-party mods can hook into it, and it provides shared APIs so mods can interoperate. The page evidence shows two clear audiences, each with a different entry point.
Who it is for
- Players and server operators who want to run modded Minecraft. They need the installer files matched to a specific Minecraft version, plus a compatible set of mods.
- Mod developers who want to build or update mods. The site points new developers to a Mod Generator (produce a starter project, unzip it, begin coding) and points existing projects to an MDK list showing how to update build scripts.
- Modpack makers and server admins, who care less about the loader itself and more about which Minecraft version has stable NeoForge builds and which mods have caught up.
What the site actually covers
Beyond installers, the news stream is the useful part for judging project health. It mixes release announcements (NeoForge 21.6, 21.9, 21.11 for successive Minecraft versions), migration guides such as the transfer API rework, and security notes — for example a post by ChampionAsh5357 on patching a network object allocation exploit and how modders can mitigate similar issues in serverbound packets. There are also community items like the Serverside Summer mod contest results. That combination tells you the project ships releases, documents breaking changes, and expects mod authors to keep pace.
Trade-offs to weigh
- Version churn. Releases track Minecraft versions closely, and API reworks mean mods must be updated. A modpack pinned to an older Minecraft version may be more stable than the newest one.
- Ecosystem maturity. NeoForge is a relative newcomer compared with long-established loaders, so some mods may lag or only support other platforms. Check that the specific mods you need list NeoForge support for your target Minecraft version.
- Two different jobs. Installing is straightforward; developing has a real learning curve, which is why the project leans on its documentation and the Modding Wiki.
Next step: decide whether you are playing or developing. If playing, open the installer section, select your Minecraft version, and confirm your essential mods support that same version before committing. If developing, generate a starter project from the Mod Generator, or check the MDK list if you are porting an existing mod.
How do I install NeoForge for my Minecraft version?
Choose your Minecraft version in the installer section of The NeoForged project, download the corresponding NeoForge installer, then run it and select "Install client" (or "Install server" for a server). After installation, open the Minecraft launcher and pick the new NeoForge profile that appears in the version list.
A few things that trip people up:
- The installer is version-specific. A NeoForge build made for one Minecraft version will not work on another, so match the two exactly.
- If you play with mods, install NeoForge first, then drop mod files into the
modsfolder. Mods built for a different loader or Minecraft version will usually crash or be ignored. - For a server, the installer's server option produces a runnable jar; you still need to accept the EULA and set up Java before it will start.
If you are a mod developer rather than a player, the same site points you to a Mod Generator for brand-new projects and an MDK list for updating an existing build script.
Next step: if you are unsure which NeoForge build matches your game, check the site's news posts—release announcements such as the NeoForge 21.11 post name the Minecraft version each build targets, which is the safest way to confirm compatibility before you download.
How do I set up a new mod project with NeoForge's Mod Generator?
Start by opening the Mod Generator page on The NeoForged project and entering the settings for your new mod. Download the generated project, unzip it, and you have a working starting point. From there, the project's Documentation and the Modding Wiki are the intended places to learn the build and API.
If you already maintain a mod for another loader or an older version, the site points you to the MDK list instead, which shows how to update an existing build script to use NeoForge.
A practical first pass
- Generate the project with settings that match the Minecraft version and mod loader you actually target.
- Unzip it somewhere outside any existing project folder so the generated Gradle files don't collide with an older setup.
- Open the build script and confirm the NeoForge version and mappings, then run the standard Gradle tasks to sync and launch a development client.
- Rename the example mod ID, package and metadata to your own before writing any real code — doing this first avoids a tedious rename later.
Decide by situation
| Your situation | What to use |
|---|---|
| Brand-new mod, no existing code | Mod Generator, then unzip and build on the generated skeleton |
| Existing mod project | MDK examples for updating the build script |
| Learning the API and conventions | Documentation and the Modding Wiki |
A useful next step: generate a throwaway project with default settings and get it launching in the dev environment before you commit to your real mod ID and package name. That way any toolchain or Java version problem shows up while the project is still disposable.
How do I migrate an existing mod to NeoForge?
Start with the MDK list, then work through your build script and source code in that order. NeoForged's own guidance for existing projects is to "refer to the MDK list for examples of how to update your build script to use NeoForge" — so treat the MDK examples as your primary reference rather than guessing at configuration. The installer downloads and mod generator on The NeoForged project are aimed at new projects; for a migration you mainly need the documentation and the MDK samples linked from there.
A practical migration order
- Pick your target Minecraft version deliberately. NeoForge releases track Minecraft versions closely (for example, NeoForge 21.6 for 1.21.6, 21.9 for 1.21.9, 21.11 for 1.21.11), and snapshot builds appear early for upcoming versions. Migrating across several versions at once compounds breakage; stepping version by version is usually faster overall.
- Update the build script first. Copy the structure from an MDK that matches your target version — Gradle plugin, dependency coordinates, and repository declarations. Get the project to compile before touching gameplay code.
- Fix registration and API calls next. These are the areas most likely to have changed between versions, and the release notes for each NeoForge version are written specifically to explain what changed and how to migrate.
- Read the migration-focused posts. Some news posts are effectively migration guides — the transfer API rework post, for instance, gives an overview of the new system and then explains how to migrate from the old one.
- Re-test on a dedicated server, not just the client. Several NeoForge changes are server-side or network-facing, so single-player testing can hide problems.
Choosing how much to change
| Situation | Sensible approach |
|---|---|
| Mod is small, few dependencies | Migrate directly, following MDK examples |
| Mod is large or depends on other mods | Migrate in stages; keep a working branch per version |
| You also want to support older versions | Keep version branches separate rather than one codebase with heavy conditional code |
| Your mod sends custom serverbound packets | Read the network vulnerability post before release |
That last row matters more than it looks. NeoForged published a post explaining its patch for a network object allocation exploit and how modders can mitigate the same class of issue in their own serverbound packets. If your mod has custom networking, that is a security-relevant read, not just a compatibility one.
A concrete next step
If you have no existing project and are starting fresh, the path is different: use the Mod Generator, download and unzip the result, and learn from the Documentation and Modding Wiki. For an existing mod, open the MDK list, find the sample closest to your mod's shape (especially if it uses networking, data generation, or capability-like systems), and diff its build script against yours. That single comparison usually reveals most of what needs to change before you write any new code.
What changed in the transfer APIs in NeoForge 21.9 and how do I migrate?
NeoForge 21.9 reworked its transfer APIs (the item/fluid/energy-style "move resources between inventories" system) and the project published a migration write-up by Technici4n titled "The Transfer Rework." The short version: the old transfer API surface was replaced with a new design, so mods that moved items or fluids through transfer handlers need their code updated rather than just recompiled. The official post covers the new system first, then explains how to migrate from the old one — start there rather than guessing at renamed classes. See The NeoForged project for the post and release notes.
What to expect when you migrate
- A new API to learn, not just renamed methods. Expect the concepts (handlers, resource types, and how transactions/insertion and extraction are expressed) to be reorganized, so plan a real pass over your transfer code.
- Version pairing matters. NeoForge 21.9 targets Minecraft 1.21.9, so migration and a game-version bump usually happen together. Check the release post for that pairing before you start.
- Existing mod projects have a reference path. The MDK list is the project's recommended place to see how build scripts are updated for NeoForge; use it to get your Gradle setup current first, because build changes and API changes otherwise get tangled.
- Server-side behavior deserves attention. Transfer code often runs on the server, and the project has separately written about network allocation exploits and how modders can harden their own serverbound packets. If your mod sends transfer-related packets, review that guidance while you're already in the code.
A practical migration order
- Update your build script against the MDK list and confirm the mod compiles on the new NeoForge version before touching transfer logic.
- Read the transfer rework post end to end, noting which of your classes map to the new system.
- Rewrite one transfer path (say, item insertion) and test it in-game before converting the rest, so you isolate mistakes.
- Re-check any packets tied to transfers against the network-vulnerability guidance.
- If you're starting fresh instead of migrating, the Mod Generator page produces a ready-made project skeleton, and the Documentation and Modding Wiki are the learning resources the project points to.
The decision criterion is simple: if your mod only registers blocks and items and never moves resources between inventories, this rework likely doesn't affect you. If it does move resources, treat it as a code migration with testing, not a one-line version bump.
How can modders mitigate the network object allocation exploit in their serverbound packets?
The practical fix is to stop letting a client's packet data dictate how many objects your server allocates. NeoForge's own write-up on this is The NeoForged project's "Mitigating Network Vulnerabilities" post (ChampionAsh5357, May 11, 2026), which covers NeoForge's patch and what modders should do in their own serverbound packets. The underlying pattern is general advice, not a NeoForge-specific feature: validate before you allocate, and bound everything a client can influence.
What the exploit class looks like
When you decode a serverbound packet, it's tempting to write something like "read an int, then loop that many times creating objects." An attacker sends a huge int and your server allocates until it dies. The same applies to collection sizes, string lengths, list-of-lists nesting, and anything you deserialize into a fresh object graph.
Concrete mitigations
- Bound counts before allocating. Read the count, reject it if it exceeds a sane maximum for that packet, and only then build the collection. Prefer reading into a pre-sized or capped structure rather than growing on demand.
- Validate on the server thread, not just the netty thread. Cheap sanity checks (size, range, enum ordinal) can run during decode; anything that touches world or player state belongs on the main thread.
- Cap strings and byte arrays. A declared length is attacker-controlled input. Clamp it and check the remaining readable bytes before reading.
- Reject unknown or out-of-range enum/registry IDs instead of falling back to a default that creates objects.
- Rate-limit per player. Even a valid packet sent thousands of times per second is a problem; a per-tick or per-second budget on expensive serverbound packets limits the blast radius.
- Update NeoForge. The patch itself is the baseline; your own packets still need the checks above.
Deciding how strict to be
Ask what the packet is for. A hotbar-swap or movement packet should have a tiny, fixed shape — hard-code the maximum. A creative-mode or admin packet can afford larger payloads but should be gated by permission checks so untrusted clients can't reach it at all. If a packet's size is genuinely unbounded by design, that's a sign it should be split or replaced with server-side lookup by ID.
A useful next step: grep your codebase for readInt() immediately followed by a loop or new on a collection, and for any readUtf() or byte-array read whose length comes off the wire. Those are the spots to add a bound and a rejection path.
Cloudflare
User reviews (0)