Clumpsは、密集した経験値オーブを一つにまとめ、オーブの処理負荷を軽減するためのMinecraft Java版MODです。作者は、Minecraft 1.17以降ではサーバー側への導入が必要と説明しています。
シングルプレイは自分のMOD用プロファイル、専用サーバーは管理者が起動するサーバー構成へ導入します。Fabric版では、対応するClumpsとFabric APIのJARをそろえます。
配布条件は2026年10月14日に作者資料で確認したものです。説明は公開資料に基づき、実機導入や性能・経験値回収量の測定は行っていません。
Clumpsは密集した経験値オーブを一つにまとめる
作者の配布説明では、狭い範囲に多数ある経験値オーブを一つのエンティティへまとめる機能が案内されています。エンティティは、ゲームが個別に処理する対象です。
オーブがプレイヤーに触れると、すぐに回収される処理も含まれます。作者は、顔の周囲に多数のオーブが残る状態を減らす用途として説明しています。
導入目的は、経験値オーブが密集する場面の処理を軽くすることです。普段重くなる場所に多数のオーブが残っているかを、導入前後の比較条件に含めます。
対応版はMinecraft・ローダー・依存MODを合わせる
Clumpsの配布ファイルは、Minecraftのゲーム版とMODローダー別に選びます。ローダーはMODを読み込ませる仕組みで、ClumpsにはFabric・Forge・NeoForge向けの配布があります。
2026年10月14日に正規配布ファイル一覧で確認したreleaseは次のとおりです。表の条件に合うファイルを、そのローダーの構成へ入れます。
| Minecraft Java版 | ローダー | Clumpsの配布版 | 追加依存MODの記載 |
|---|---|---|---|
| 1.21.1 | Fabric | 19.0.0.1・release | Fabric API必須 |
| 1.21.1 | Forge | 19.0.0.1・release | 当該ファイルに記載なし |
| 1.21.1 | NeoForge | 19.0.0.1・release | 当該ファイルに記載なし |
| 26.3 | Fabric | 26.3.2・release | Fabric API必須 |
| 26.3 | NeoForge | 26.3.2・release | 当該ファイルに記載なし |
Fabric用の二つのファイルには、Fabric APIがrequiredとして指定されています。Fabric Loaderを用意したうえで、同じMinecraft版に対応するFabric APIもmodsへ入れます。
同日に確認したFabric APIの対応ファイル例は、1.21.1用「0.116.17+1.21.1」と26.3用「0.162.0+26.3」です。これらは入手できる対応ファイルの例で、Clumpsが要求する最低版の指定とは区別します。
Forge・NeoForge用で追加依存の記載がない場合も、選んだローダー本体が前提です。MODパックを利用していれば、そのパックが指定するゲーム版・ローダー・依存の組み合わせに合わせます。
26.3・Forgeという条件では、今回のModrinth取得に該当ファイルがありませんでした。別ローダー用JARを流用せず、正規配布元で対応ファイルを選べる構成を使います。
Minecraft公式の26.3公開情報はゲーム本体の情報です。MOD構成を更新するときは、ゲーム本体と各MODの対応を合わせて判断します。
1.17以降はワールドを処理する側へ導入する
作者READMEは、Minecraft 1.17以降ではサーバー側、古い版ではクライアントとサーバーの両側に必要としています。導入先は、ワールドを処理している構成です。
シングルプレイとLANホストにも内部サーバーがあります。Fabricのネットワーク文書は、これらの内部サーバーと専用サーバーを、どちらもゲーム処理を行う論理サーバーとして説明しています。
| 遊び方 | 1.17以降の導入対象 | 作業する人 |
|---|---|---|
| シングルプレイ | そのワールドを開くMOD用プロファイル | 自分 |
| 自分がホストのLAN | ホストがワールドを開く構成 | ホスト |
| 専用サーバー | 管理者が起動するMODサーバー | 管理者 |
| 他人の専用サーバーへ参加 | 接続先サーバーの構成 | 管理者 |
他人のサーバーへ参加する場合、経験値オーブの処理は接続先の構成で決まります。Clumpsを使うかどうかは管理者の方針に従い、参加者は配布された構成を使用します。
MODパックが参加者側にもClumpsを含んでいるなら、その指定を維持します。サーバー側の必須条件と、パック全体の配布構成は別の条件です。
導入先は起動するプロファイルかサーバーのmods
ClumpsのJARは、実際に起動するゲーム用フォルダーのmodsへ置きます。複数のプロファイルやサーバーがある場合は、それぞれの保存先を分けて扱います。
ローダー別の導入先は、各ローダーの公式資料で案内されています。クライアント用フォルダーと専用サーバー用フォルダーを取り違えないことが前提です。
| ローダー | シングルプレイ・LANホスト | 専用サーバー |
|---|---|---|
| Fabric | 対象Fabricプロファイルのゲーム用フォルダー内のmods | 管理者が起動するFabricサーバーのmods |
| Forge | Forgeを有効にしたMinecraft構成のmods | 管理者が起動するForgeサーバー構成のmods |
| NeoForge | 指定したゲームディレクトリ内のmods | NeoForgeサーバー設置先のmods |
保存先の根拠は、FabricのMOD導入資料、Forgeの公式文書、NeoForgeのクライアント資料とサーバー資料です。
NeoForgeのクライアント資料は、独立したゲームディレクトリを指定するプロファイルを案内しています。一度起動すると、そのディレクトリにmodsが作られます。
Fabric公式資料が示す標準クライアントの場所は、次のとおりです。ゲームディレクトリを変更したプロファイルや別ランチャーでは、指定した保存先のmodsを使います。
| OS | Fabric標準クライアントのmods |
|---|---|
| Windows | %appdata%\.minecraft\mods |
| macOS | ~/Library/Application Support/minecraft/mods |
| Linux | ~/.minecraft/mods |
Fabric版は停止とコピー保存から一つずつ導入する
最初にゲーム・サーバーを停止し、ワールド・設定・現在のMOD構成を別の場所へコピーします。初回はワールドのコピーで動作させ、元のワールドを保管します。
Fabric用の手順は、次の順に進めます。専用サーバーでは管理者がサーバー側のフォルダーを対象にします。
- Minecraftの版と導入する側を決めます。すでにMODパックがある場合は、パックの指定構成を使います。
- シングルプレイではFabricのOS別導入資料に沿ったプロファイルを用意します。専用サーバーはFabricのサーバー向け案内に沿った構成を用意します。
- 正規配布ページでゲーム版とFabricを絞り、対応するClumpsとFabric APIのJARを選びます。
- 起動対象のmodsへ二つのJARを置きます。JARは展開せず、そのまま入れます。
- 既存パックでは、パックのMOD一覧と実際のmodsでClumpsの有無・版を確認します。すでに同じ版があれば追加せず、置き換える場合は元のJARをmodsの外へ保管します。
- 対象のFabric構成で起動し、ワールドのコピーで読み込みとオーブの挙動を確かめます。
導入時に変更するのは、この構成に必要なファイルだけです。描画距離や他のMODを同時に変えず、一つずつ進めると変更前後を比較できます。
起動エラーとオーブの処理を分けて切り分ける
起動前に止まる場合は、エラーに表示された版・ローダー・依存MODを照合します。起動後に変化が見えない場合は、導入した側とオーブが密集する状況を対象にします。
| 症状 | 照合する条件 |
|---|---|
| 依存MOD不足が表示される | Fabric APIの有無と対応ゲーム版 |
| 対応版・ローダーが合わない | Minecraft版、Clumpsの対象版、ファイルのローダー |
| 重複MODが表示される | 同じClumpsの新旧JAR |
| サーバーで処理が変わらない | 接続先サーバーの導入構成 |
| オーブが少ない場面でも重い | その場面の描画・処理・通信など、別の負荷要因 |
不足名や要求範囲は、実際のエラーに出た条件に従います。問題が起きた変更を一つずつ戻し、保存してある元の構成とワールドのコピーで比べます。
Fabricのログ説明では、ゲーム用ディレクトリのlogsに記録があり、最新のログはlatest.logです。クラッシュレポートは別のcrash-reportsに保存されます。
起動日時が一致する記録で、エラーに示されたMOD名と要求版を実際のファイルに照合します。クラッシュレポートの公式説明では、冒頭のエラーやSystem Details内のJava・MOD一覧が調査材料です。
記録にClumpsの名前が現れても、それだけで原因を確定せず、コピーした環境で変更を戻した結果も比べます。
導入前後の比較では、場所・人数・オーブが発生する条件をそろえます。専用サーバーでは、管理者がサーバー側の処理状態を記録します。
参加者の画面の変化とサーバー側の記録を対応づけ、同じ条件の結果を比較します。
問題が続く場合は、作者のIssuesへゲーム版・ローダー・Clumpsと依存MODの版、症状が出る状況を添えられます。共有するログからは、個人情報や接続先の情報を除きます。
更新・削除はワールドと依存元を含めて戻せる状態にする
更新前には、停止した状態のワールド・設定・現在のJARを同じ組として保存します。ゲーム本体の版も変える場合は、ローダーと他のMODの対応も合わせます。
Clumpsの更新は、対象ゲーム版・ローダーに対応する新しいJARへの置き換えです。Fabric APIも変更するなら、それを使う他のMODの条件を含めて選びます。
アンインストールでは、停止後にClumpsのJARをmodsの外へ保管し、ワールドのコピーで起動します。他のMODがFabric APIを必要とする構成では、Fabric APIを残します。
追加コンテンツを使う別のMODも同時に外す場合は、そのMODの削除手順と保存データへの影響を確認します。普段使うワールドは保管し、コピーで結果を確かめてから通常の構成へ戻します。
まとめ：Clumpsは対応ファイルとワールドを処理する側を合わせる
Clumpsの導入は、ゲーム版・ローダー・依存関係と、ワールドを処理する側を合わせて進めます。変更前の構成を残し、オーブが密集する同じ状況で比較するのが基本です。
- 作者の用途は、経験値オーブの集約と接触時の回収です。
- 1.17以降は、シングル・LANならホストの構成、専用サーバーなら管理者の構成へ導入します。
- Fabric用の確認ファイルにはFabric APIが必要です。
- JARは起動対象のmodsへ置き、同じMODの新旧ファイルを重ねません。
- 更新・削除は、元のワールドと構成を保管してコピーで進めます。
コメント