Paper (Spigot) の EventPriority とは何か

2026-02-01T00:00:00+00:00
EventPriority を適当に設定するな
EventPriority とは</a> </h2>
EventPriority は，@EventHandler</code> annotation の引数として指定できる列挙型で，イベントリスナーの実行順序を制御するための優先度システム．
EventHandler (paper-api 1.21.11-R0.1-SNAPSHOT API)</a>
EventPriority (paper-api 1.21.11-R0.1-SNAPSHOT API)</a>
例えば複数のプラグインが同じイベント (例えば PlayerJoinEvent</code> ) を捕捉しようとしている場合，どのプラグインが先に実行されるかを決めるのが EventPriority である．
@EventHandler(priority =</span> EventPriority.</span>HIGHEST</span>)
</span>fun</span> onChat</span>(event</span>:</span> AsyncChatEvent) {
</span>  val</span> player</span> =</span> event.</span>player
</span>  //</span> ...
</span></span></code></pre>
この優先度は以下のようになっている．</p>
</th> 列挙型</th> 優先度</th></tr></thead>

1</td> EventPriority.HIGHEST</code></a></td> 最も高い</td></tr>
2</td> EventPriority.HIGH</code></a></td> 高い</td></tr>
3</td> EventPriority.NORMAL</code></a></td> 通常 (デフォルト)</td></tr>
4</td> EventPriority.LOW</code></a></td> 低</td></tr>
5</td> EventPriority.LOWEST</code></a></td> 最も低い</td></tr>
6</td> EventPriority.MONITOR</code></a></td> 監視用 (後述するイベントの結果を変更しない場合の優先度)</td></tr>
</tbody></table>
使い分け</a>
</h2>
EventPriority の使い分けは次のように考えると良い</p>

HIGHEST</code> / HIGH</code> : 他のプラグインよりも先に処理・キャンセルしたい場合に使用する．例えば，チャットフィルターや権限管理など，ゲームプレイに直接影響を与える処理に適している．</li>
NORMAL</code> : 特に優先度を指定しない場合に使用する．多くのプラグインはこの優先度で十分である．</li>
LOW</code> / LOWEST</code> : 他のプラグインの処理が完了した後に実行したい場合に使用する．例えば，ログ記録や通知など，ゲームプレイに直接影響を与えない処理に適している．</li>
</ul>
適当に設定すると不具合の原因になるので，特にサーバのメインプラグインなどを開発している場合は注意が必要である．</p>
MONITOR とは?</a>
</h2>
MONITOR</code> は，イベントの結果を変更しない場合に使用する優先度である．例えば，ログ記録や通知など，イベントの結果に影響を与えない処理 ( read-only</code> )に適している．優先度的には LOWEST</code> の次に実行される．なので，イベントの最終結果を監視したい場合に適しているのだ．</p>
ログ管理プラグインとして有名な CoreProtect では AsyncChatEvent</code> を MONITOR</code> で捕捉し，チャット内容をログに記録している</a>．</p>
@</span></span>EventHandler</span></span>(</span>priority</span> =</span> EventPriority</span>.</span>MONITOR</span>)</span></span></span>
</span>public</span> void onPlayerChat</span>(</span>AsyncChatEvent</span> event)</span></span> {</span>
</span></span>  String</span> message =</span> PlainTextComponentSerializer</span>.</span>plainText</span>(</span>)</span></span>.</span>serialize</span>(</span>event.</span>message</span>(</span>)</span></span>)</span></span></span>;</span>
</span></span>  if</span> (</span>message.</span>isEmpty</span>(</span>)</span></span>)</span></span> {</span>
</span></span></span>    return</span>;</span>
</span></span></span>  }</span></span>
</span></span>  //</span> ...
</span></span></span></code></pre>
MONITOR</code> の特別な仕様</a>
</h2>
前述した通り， MONITOR</code> は実行順序では最後になるが，単なる優先度ではなく，イベントの最終状態を観察するための専用列挙型として設計されている．</p>
キャンセル不可</a>
</h3>
MONITOR</code> 以外の優先度 ( HIGHEST</code> から LOWEST</code> ) では，イベントをキャンセルすることが可能である．例えば， PlayerJoinEvent</code> を HIGHEST</code> で捕捉し，以下のようにイベントをキャンセルすることができる1</a></sup>．</p>
@</span></span>EventHandler</span></span>(</span>priority</span> =</span> EventPriority</span>.</span>HIGHEST</span>)</span></span></span>
</span>public</span> void onPlayerJoin</span>(</span>PlayerJoinEvent</span> event)</span></span> {</span>
</span></span>    event.</span>setCancelled</span>(</span>true</span>)</span></span>;</span> //</span> プレイヤーの参加をキャンセル
</span></span></span>}</span></span>
</span></code></pre>
しかし， MONITOR</code> では，イベントをキャンセルすることはできない． MONITOR</code> で捕捉されたイベントは，すでに他の優先度で処理されており，その結果を変更することは許されていない．以下のコードは無効である．</p>
@</span></span>EventHandler</span></span>(</span>priority</span> =</span> EventPriority</span>.</span>MONITOR</span>)</span></span></span>
</span>public</span> void onPlayerJoin</span>(</span>PlayerJoinEvent</span> event)</span></span> {</span>
</span></span>    if</span> (</span>event.</span>isCancelled</span>(</span>)</span></span>)</span></span> {</span>
</span></span></span>        //</span> 他のプラグインがキャンセルしたかどうか判定できる
</span></span></span></span>        plugin.</span>log</span>(</span>"</span>Player join was cancelled"</span></span>)</span></span>;</span>
</span></span></span>    }</span></span>
</span></span>    //</span> でもこのメソッドでは event.setCancelled(true) しても何も起こらない
</span></span></span>}</span></span>
</span></code></pre>
あくまでイベントの監視用</a>
</h3>
MONITOR</code> は，あくまでイベントの最終状態を監視するために使用されるべきであり，イベントの結果を変更するために使用されるべきではない．例えば，ログ記録や通知など，イベントの結果に影響を与えない処理に適している．</p>
イベントキャンセルができない = 別のプラグインの妨害を無効化できるという考えなので，以下の使い方ができる．</p>
@</span></span>EventHandler</span></span>(</span>priority</span> =</span> EventPriority</span>.</span>MONITOR</span>)</span></span></span>
</span>public</span> void onPlayerJoinMonitor</span>(</span>PlayerJoinEvent</span> event)</span></span> {</span>
</span></span>    //</span> ログや統計情報の記録
</span></span></span>    logDatabase.</span>recordJoin</span>(</span>event.</span>getPlayer</span>(</span>)</span></span>,</span> !</span>event.</span>isCancelled</span>(</span>)</span></span>)</span></span>;</span>
</span></span>    
</span></span>    //</span> メトリクスの更新
</span></span></span>    metrics.</span>incrementPlayerJoinCount</span>(</span>event.</span>isCancelled</span>(</span>)</span></span>)</span></span>;</span>
</span></span>}</span></span>
</span></code></pre>
Tickrate への影響</a>
</h2>
MONITOR</code> は常に実行されるため，負荷のある処理 (例えばデータベースへのアクセスなど)を同期的に行うと，サーバの Tickrate に影響を及ぼしてしまう．そのため， MONITOR</code> で重い処理を行う場合は，非同期に処理を行うか，別のスレッドで処理を行うことが推奨される．</p>
@</span></span>EventHandler</span></span>(</span>priority</span> =</span> EventPriority</span>.</span>MONITOR</span>)</span></span></span>
</span>public</span> void onPlayerJoin</span>(</span>PlayerJoinEvent</span> event)</span></span> {</span>
</span></span>    Bukkit</span>.</span>getScheduler</span>(</span>)</span></span>.</span>runTaskAsynchronously</span>(</span>plugin,</span> (</span></span></span>)</span></span> -></span> {</span>
</span></span></span></span></span>        database.</span>recordJoin</span>(</span>event.</span>getPlayer</span>(</span>)</span></span>)</span></span>;</span>
</span></span></span></span></span>    }</span></span></span>)</span></span>;</span>
</span></span>}</span></span>
</span></code></pre>
^{1</sup>
PlayerJoinEvent</code> は実際にはキャンセル不可なイベント</p>
</div>}
Litematica での設計図の作り方
2026-01-26T00:00:00+00:00
Litematica の設計図についてのプレイヤー向けガイド的なもの</p>
Litematica の導入</a>
</h2>
Litematica は Mod なので各自で導入する必要があります．</p>
Litematica - Minecraft Mod - Modrinth</a></p>

対応バージョン: 1.12.x</code>, 1.13.2</code>, 1.14</code>, 1.14.2-1.14.4</code>, 1.15.x</code> ~ 1.19.x</code>, 1.20.1-1.20.4</code>, 1.20.6</code>, 1.21.x</code></li>
対象 Mod Loader: Fabric, Forge, LiteLoader, Ornithe, Rift</li>
</ul>
1.21.x の対応は Fabric のみなので，手元に Fabric の環境を作っておく必要があるので注意が必要 (LiteLoader ならまだしも Ornithe, Rift なんて使ってる奴おるんか？？？)1</a></sup></p>
ここでは Fabric 環境の構築方法や Mod の導入は省略します．ネットに死ぬほど情報が転がってるのでそれを読んでね．</p>
設計図とは</a>
</h2>
Litematica は *.schematic</code> という形式の設計図ファイルを読み込み，建築物を透かしで表示して建築をサポートする Mod です．</p>
今回のガイドはあくまで 設計図を作ること</strong> なので， 設計図を使うこと</strong> に関しては何も書きません．これもネットに死ぬほど情報が転がってるのでそれを読んでね．</p>
設計図を取る</a>
</h2>
WorldEdit ではお馴染みの木の斧ですが， Litematica では木の棒を使う．</p>
Litematica が導入された状態で木の棒を持つと左下に何か出てくると思う．</p>
</p>
見るべきところは一番下の Mode．画像では Area Selection</strong> になっています．これはエリア選択のモードってこと．</p>
もし違うモードになっていたら Alt を押しながらマウスホイールでスクロールすると切り替えられる．</p>
建築物のエリアを選択する</a>
</h3>
まずは Area Selection</strong> に切り替えて建築物のエリアを選択する．</p>
WorldEdit で編集するのと同じように建築物の対角線上に始点・終点でエリアを囲む．このときも囲み方も WorldEdit と同じ．右クリック・左クリックでそれぞれ始点・終点を選択します．</p>
</p>
こんな感じ．</p>
エリアが選択しきれない場合</a>
</h3>
建築物がデカすぎてエリア選択がうまくいかない場合は建築物をぐるっと含められるように始点・終点にブロックをおいて，空気ブロック (Air) もまとめて選択してしまうしかないです．</p>
設計図としては 空気ブロック (Air) は無視されるので大丈夫．</p>
設計図を保存する</a>
</h3>
それでは設計図を保存しよう． Litematica のメニューを開く． (初期設定ではキーが多分バラバラなので，各自キー設定を見るように．)</p>
いろんなのが出てくると思うが，まず Area Selection browser</strong> を選ぶ</p>
</p>
そしたら New selection</strong> からエリアを登録する．</p>
</p>
登録できたら登録したエリアの Configure</strong> を選ぶと出てくる Area Editor にある Save Schematic</strong> を選ぶ．</p>
</p>
適当な名前をつけて保存する．</p>
</p>
保存すると .minecraft/</code> のフォルダーにある schematics</code> フォルダーに先ほど作成した *.litematic</code> ファイルがある．これが設計図になる．</p>
</p>
*.litematic と *.schematics の違い</a>
</h2>
*.litematic</code> は Litematica 専用の設計図ファイルで，ブロック配置だけでなく，バージョン情報・材料リスト用データ・検証用データなど，Litematica機能向けのメタ情報が多く入っている．</p>
それに対して *.schematics</code> (*.schematic</code>) は Litematica が流行る前に存在していた設計図 Mod である MCEdit や Schematica などで使われていた「古い共通フォーマット」で， Litematica でも読み込めるが，材料リストなどのデータが使えないという欠点がある．</p>
基本は *.litematic</code> で OK.</p>
^{1</sup>
一部の Minecraft オタクしか知らんやろ</p>
</div>}


Git の cherry-pick について考える
2026-01-22T00:00:00+00:00
Git には既存のコミットの内容を適用する cherry-pick という機能がある．
今日はこの機能について考えたいと思う．</p>
git</span></span> cherry-pick [</span>--</span>edit]</span> [</span>-n]</span> [</span>-m <parent-</span>number>]</span> [</span>-s]</span> [</span>-x]</span> [</span>--</span>ff]</span></span>
</span>		  [-S[</span></span><</span>keyid></span>]] <</span>commit></span>…</span>
</span>git</span></span> cherry-pick (--continue</span> |</span> --skip</span></span> |</span> --abort</span></span> |</span> --quit</span></span></span>)
</span></code></pre>
Git - git-cherry-pick Documentation</a></p>
なんで cherry-pick っていうの?</a>
</h2>
元は英語の慣用句 「cherry-picking」 から来ているらしい．
慣用句としては「良いものだけを選んで取る」「いいとこ取りをする」という意味がある．</p>

the action or practice of choosing and taking only the most beneficial or profitable items, opportunities, etc., from what is available.</p>
"it is an exaggeration based on the cherry-picking of facts"</p>
</blockquote>
使い方</a>
</h2>
cherry-pick は，特定の commit を現在地点の branch へ適用するコマンドで，基本は引数に適用したい commit hash を選ぶだけ．</p>
git</span></span> cherry-pick <</span>commit-hash></span>
</span></span></code></pre>
commit hash は git log</code> で確認するのもいいし， GitHub からでも確認できる．</p>
(GUI 主義者はぜひ GitHub からコピーしよう．)</p>
commit</span></span> c0fd6e4c28967a66969cade0a212d7cee6d2728c</span>
</span>
</span>Author:</span></span> Sho Sakuma <</span>me@m1sk9.dev></span> Date: Tue Jan 20 20:37:02 2026 +0900 test: Add Kana Conversion Test</span>
</span></code></pre>
</p>
これが便利なシチュエーションとして</p>

他の branch から特定の修正だけを取り込みたい</li>
間違った branch に commit してしまった変更を正しい branch に移したいとき</li>
Release branch に特定の hotfix だけを適用したいとき

(でもこれは worktree で良くないか... というのは置いといて) 1</a></sup></li>
</ul>
</li>
</ul>
で役立つ．私もよく使う．</p>
#</span></span> 複数のコミットを順番に適用</span>
</span></span>git</span></span> cherry-pick <</span>commit1></span> <</span>commit2></span> <</span>commit3></span>
</span></span>
</span>#</span></span> コミット範囲を指定（commit1は含まれない）</span>
</span></span>git</span></span> cherry-pick <</span>commit1></span>..<</span>commit2></span>
</span></span>
</span>#</span></span> コミット範囲を指定（commit1も含む）</span>
</span></span>git</span></span> cherry-pick <</span>commit1></span>^..<</span>commit2></span>
</span></span>
</span>#</span></span> コミットせずにステージングエリアに追加</span>
</span></span>git</span></span> cherry-pick --</span>no-commit</span> <</span>commit-hash></span>
</span></span>
</span>#</span></span> コミットメッセージを編集</span>
</span></span>git</span></span> cherry-pick --</span>edit</span> <</span>commit-hash></span>
</span></span></code></pre>
ただ，この cherry-pick を行うと新しい commit hash として扱われることから， conflict が発生する．これらを解決しないと merge が出来ないので注意が必要．</p>
#</span></span> コンフリクトを解決後</span>
</span></span>git</span></span> cherry-pick --</span>continue</span></span>
</span>
</span>#</span></span> cherry-pick を中止</span>
</span></span>git</span></span> cherry-pick --</span>abort</span></span>
</span>
</span>#</span></span> 現在の状態をスキップして次へ</span>
</span></span>git</span></span> cherry-pick --</span>skip</span></span>
</span></code></pre>
^{1</sup>
worktree って分かりづらい機能だよなって思ってる</p>
</div>}


私の開発環境 2026
2026-01-14T00:00:00+00:00
2026年最初の記事です．</p>
あけましておめでとうございます．本年もどうぞよろしくお願いします．</p>
AI のおかげでかなり変わりました．ということで現状の私の開発環境を紹介します．</p>
AI についての考え方</a>
</h2>
AI 関連の記事に汚染されてしまった Zenn を嘆いていた私も今 Claude と Claude Code を使いまくってます．</p>
私はコードを全て AI に書かせて人間によるレビューを行わない Vibe Coding というスタイルに対しては懐疑的です． Claude Code にコード生成するのはあくまで補助的な役割で，コードの大枠は自分で書きます．</p>
AI を使って確かに効率化はできますし，私もそれはわかっているのである部分をより良い書き方はないかの質問や，初見のプログラミング言語を Rust や Kotlin など慣れ親しんだ言語で書き換えて理解する みたいなこともします．</p>
Vide Coding の全てを否定するわけではありません．私も簡単なコードや使い捨てプログラムなどは Claude に書いてもらって使います．ただ人が使うコードなど私だけが使うプログラムではない場合は Claude に任せてはいけないと考えています．</p>
</p>
前提</a>
</h2>

MacBook Air M2 (2022)

メモリ 16GB</li>
ストレージ 512GB</li>
</ul>
</li>
</ul>
MacBook Pro が欲しい〜〜〜〜 メモリ高騰を引き起こした OpenAI のアイツを俺は許しません</a>．</p>
また，私の設定は GitHub で公開しています．</p>
m1sk9/dotfiles: My dotfiles.</a></p>
ターミナル</a>
</h3>
ターミナルは引き続き Ghostty を使用しています．</p>
設定: dot_config/ghostty/config</a></p>
ghostty-org/ghostty: 👻 Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.</a></p>
Lua を使って設定ファイルを書ける WezTerm を検討していたこともありましたが，盆栽が続いたことがない (NeoVim など) ので諦めました．</p>
Ghostty はかなり気に入っています．2025年の中で Best Teminal</em> でした．</p>
</p>
エディタ</a>
</h3>
エディタは VSCode をやめて Zed を使用しています．今この記事も Zed で書いています．</p>
設定: dot_config/zed/private_settings.json</a></p>
zed-industries/zed: Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.</a></p>
VSCode は Electron を使っているからかかなり起動がもっさりしている印象で，使っていてかなりストレスフルだった印象があるとやっぱり速度を求めている私はしんどい...</p>
DevContainer への対応は始まったばかり</a>1</a></sup> なのかかなり甘いので，完全移行にはなっていませんが，今年は Zed を使うことが多くなりそう． Claude Code にビルドイン対応しているのも大きいので．</p>
</p>
Git 関連</a>
</h3>
こちらは引き続き lazygit を使用しています．TUI での操作が一番楽になってしまった．</p>
設定: dot_config/jesseduffield/lazygit/config.yml</a></p>
jesseduffield/lazygit: simple terminal UI for git commands</a></p>
カスタムコマンド</a> を定義して，全ファイルを stash したり，commit を打ち消すコマンドを追加したりもしています．</p>
customCommands</span></span>:</span>
</span>  -</span> key</span></span>:</span> "</span>u"</span></span>
</span>    context</span></span>:</span> "</span>files"</span></span>
</span>    description</span></span>:</span> "</span>Stash unstaged files"</span></span>
</span>    command</span></span>:</span> "</span>git stash save --include-untracked"</span></span>
</span>  -</span> key</span></span>:</span> "</span>r"</span></span>
</span>    context</span></span>:</span> "</span>status"</span></span>
</span>    description</span></span>:</span> "</span>Add remote url"</span></span>
</span>    command</span></span>:</span> '</span>git remote add origin "{{index .PromptResponses 0}}" '</span></span>
</span>    prompts</span></span>:</span>
</span>      -</span> type</span></span>:</span> "</span>input"</span></span>
</span>        title</span></span>:</span> "</span>remote url"</span></span>
</span>  -</span> key</span></span>:</span> "</span><c-c>"</span></span>
</span>    context</span></span>:</span> "</span>commits"</span></span>
</span>    description</span></span>:</span> "</span>Cancel commit"</span></span>
</span>    command</span></span>:</span> "</span>git reset --soft HEAD^"</span></span>
</span></code></pre>
</p>
開発環境</a>
</h3>
開発環境は次のように管理しています</p>

Rust: rustup を使って直接管理</li>
それ以外: mise</a> を使って管理</li>
</ul>
mise で管理している理由はまあ Node.js と npm エコシステムの1件</a> があったのもありますが，複数バージョンを管理する上で一番使いやすかったというのがあります．</p>
asdf など世に出回ってる管理ツールを使ってきたが，mise に勝る点がなかったです．それぐらい優秀．</p>
</p>
lefthook や terraform, tflint, trivy などもインストールできるのだいぶ強い．</p>
^{1</sup>
今見ると1月7日公開だった... そりゃ甘いね</p>
</div>}


直近のMinecraft界隈の話とサーバーを開けるのがどれだけ大変か
2025-12-17T00:00:00+00:00
俺の友達が Minecraft サーバについてのブログを出していた</a> ので，アンサーというかまあ直近の話でもしとこうかなと．</p>
大前提として俺は某鯖の運営を7月くらいに退いていて，これからの話は 個人的な見解</strong> として見てください．もうあの鯖とは関係持ってないからね．</p>
最近の Minecraft サーバについて</a>
</h2>
さっき出したブログでも触れられていたように，最近はMinecraftのコミュニティがあまり活発ではないのは事実．</p>
サーバリストも昔は Japan Minecraft Servers</strong> と Monocraft</strong> という2つのサービスで大いに賑わっていたんだけど，後者は半年前くらいにサービスが止まったまま動かずに放置されている．</p>
自分が サーバリストはすぐに死ぬもの</strong> って言ってるのもこういうことなんだけど，基本的に Minecraft コミュニティは 個人の力</strong> で賑わっているものが多いから資金繰りに失敗したり，モチベーションの維持に失敗してサービスを閉じざる負えなくなってしまう．</p>
運営がいるのは当たり前じゃない</a>
</h2>
Minecraft サーバでお金を稼ぐことは難しいから，基本的に Minecraft サーバの運営は全員無休のボランティアとして働いている．お金をもらっているわけではない．</p>
そしてその運営も各サーバのオーナーが信頼をおける人間じゃないといけないから，すぐに増員したりもできない</strong>．だって誰もお金がもらえないのに無休で働いてほしいって言われて働くわけないでしょ? ね?</p>
Minecraft の資金繰りの大変さ</a>
</h3>
ブログでも触れられていたお金の話をしたいと思う．</p>

皆様に満足していただけるものにするには費用がかかりすぎた</p>
</blockquote>
Minecraft のマルチサーバは本当にお金がかかります．マジで．</strong></p>
先ほどの記事では大雑把だったが，実際に今から立てようとすると，サーバ代: 12000円</a>，DDoS (サーバへの攻撃) への防衛: 4000円</a></p>
その他もろもろで月額3万円が必要になる．それを学生などが持つと考えるとどうだろうか．バイト代の半分も無くなってしまう．参考程度に某鯖のお財布事情でも見てみればいい．自宅サーバでもちゃんとかかる．</p>
seichi click networkのお財布事情とか</a></p>
実際運営している間もプレイヤーから「じゃあソシャゲみたいに課金要素追加すればいいじゃん」とか「法人化すればいいじゃん」とかめちゃくちゃ言われたけど 出来ない</strong>．</p>
ここで立ちはだかってくるのが Minecraft EULA というものの存在．</p>
Minecraft End(er)-User License Agreement (“EULA”)</a></p>
</p>

    はい今嫌な顔したそこの Minecraft 関係者
</div>
まあようは利用規約みたいなものなんだけど，この EULA の中には (Minecraft Usage Guidelines</a>) Minecraft を使って商標活動(平たく言えば金稼ぎ)をする上でのガイドラインが書いてある．</p>

Selling entitlements that affect gameplay provided they don’t ruin other players’ experience or give a competitive advantage in the game</p>
(ゲームプレイに影響を与える特典を販売してよいが、他プレイヤーの体験を台無しにしたり、ゲーム内で競争上の優位性を与えてはならない)</p>
</blockquote>
このようにソシャゲのような課金要素を明確に禁止と言われている以上 マルチサーバで資金を確保するのが難しい</strong> のである．(過去に俺にそういう文句を言ってきた人はこれを見て学んでください)</p>
</iframe>
それでも (俺が) サーバを開こうとする理由 / 運営活動をしていた理由</a>
</h2>
楽しいから</strong></p>
今自分がエンジニアとして会社で働いているのも，大学生として情報工学(平たく言えばプログラミング)を学んでいるのも元はと言えば Minecraft のおかげなので，それなりに感謝している．</p>
Minecraft は無限大なのでなんでもできる．だからこそ資金繰りが大変でもめちゃくちゃ文句言われてもなんとかモチベーションを保てている．(何回かやめようと思ったり，フレンドに愚痴ったりしたけど)</p>
だから今もどっかのタイミングでサーバを開こうとしてるし，運営活動をしていたのが理由の一つです．</p>
これが今言いたいことの全て! 以上です．</p>
おまけ: 新宇宙鯖 (SpaceServerUniverse) のこと</a>
</h2>
開発停止理由が公の場 (ブログで触れられていた) に出たので，ちょっと詳しい解説を加えようと思います．ここからはちょっと深い話になるので読みたい人だけ読んでください．</p>

オリジナルのワールド生成が出来ない…</p>
</blockquote>

技術的には可能だとは思うのですが、調べてもそのような文献が余り出てこないだけでなくコードを読むとMinecraftのワールドのアルゴリズムを理解していないと出来なさそうでした。厳しい。</p>
</blockquote>
リソースパック，データパックへの知見がある人は多分 簡単じゃん</strong> と思うだろうが， Bukkit (Spigot/Paper) だとちょっと話が変わってくる．</p>
2021年6月8日/11月30日にリリースされた Minecraft 1.17, 1.18 (洞窟と崖) ではワールド生成のアルゴリズムに変更が加わったので，過去の人間が開発していたカスタムワールド系のプラグインは全滅してしまった．現状の最新バージョン 1.21.10 でのアルゴリズムに関しては解明できていない．</p>
Java Edition 1.18 # 洞窟</a></p>

洞窟</p>

完全に作り変えられた。</li>
Y=-59まで伸びるようになった</li>
</ul>
</blockquote>
開発中に原因が突き止めればよかった．申し訳ないと思っているのでどっかのタイミングでこの原因を解明したいと思う．ちょっと待っててね．</p>


Node.js の環境を DevContainer に封じ込めよう
2025-12-10T00:00:00+00:00

この記事は mstdn.maud.io Advent Calendar 2025</a> 10日目の記事です．</p>
</blockquote>
11月24日 postman</code> や zapier</code> など 500 以上のパッケージがサプライチェーン攻撃を受けていたことが報告されました．</p>
Shai Hulud Strikes Again (v2) - Socket</a></p>
postmanやzapierが攻撃されていた。bunをインストールして悪意のあるスクリプトが動くっぽい / Shai Hulud Strikes Again (v2) - Socket https://t.co/q0xsBHYyhh</a></p>— hiroppy (@about_hiroppy) November 24, 2025</a></blockquote>
m1sk9.dev

Paper (Spigot) の EventPriority とは何か

Litematica での設計図の作り方

Git の cherry-pick について考える

私の開発環境 2026

前提</a> </h2> MacBook Air M2 (2022) メモリ 16GB</li>

開発環境</a> </h3> 開発環境は次のように管理しています</p> Rust: rustup を使って直接管理</li>

直近のMinecraft界隈の話とサーバーを開けるのがどれだけ大変か

Node.js の環境を DevContainer に封じ込めよう
