【MineCraft】LogisticsPipesの遠隔要求の検索機能がクラッシュ
つい最近、LogisticsPipesのRemoteOrderLogisticsPipeとペアリングしたRemoteOrderで、アイテム名検索すると、クラッシュする自体が発生した。
※あくまで予想であり、確実な情報ではないのでご注意ください！！
記憶がぶっ壊れていなければ、下記記事で導入した肥料自動化の仕組みを作ってから、OpenBlocksのスプリンクラーが不要になる、進捗が進まなくなるという事象の起因と考えられることから、OpenBlocksを外して、死んだときのみお墓が生成される、GraveStone Modを導入した。
そのくらいの時期に、遠隔要求するときのRemoteOrderでアイテム名検索しようとすると、クラッシュして落ちるようになった。最初は日本語検索しようとしていたので、マルチバイト文字NGになったのかな(アップデートとかしてないですが・・・)？とよくわからない仮説を立てていましたが、普通に半角文字でもクラッシュするので、事象としては、検索自体ができなくなっていると言う感じです。
で、いつもどおりクラッシュログ確認しましたが、
マイクラってヌルポしか発生せんのかい！！
と叫びたくなる気持ちを全力で抑えて、スタックトレースを確認。
logisticspipes.gui.orderer.GuiOrderer.itemSearched(GuiOrderer.java:158)
やっぱり検索時に死んでるっぽいな・・・
例のごとくコードがないので解析できず、以下試行錯誤したこと。
- mod(OpenBlocks)を抜いたことでチェスト内に保管されていた、modのアイテムが正しく削除されず、Null扱いになってるんじゃないかと思い、チェストを破壊→チェスト再設置→アイテム再度格納
- チェスト及び引き出しコントローラーと接続している、ProviderLogisticsPipe(供給パイプ)とBasicLogisticsPipe(基本パイプ)を全部破壊→再設置して再接続をする。
結果はどちらも見当違いでした・・・
ヌルポのエラーメッセージに、「Rendering screen」とあるので(画面表示でしくじってる？)、一旦先生に質問。
・「Rendering screen」のみで検索からの知恵袋
→質問見ると、別modでもこのログは出るっぽい。で、回答者は、「modの競合か前提の入れ漏れでは？」と回答者。質問者が事後の説明してくれないから解決したかもわからん。こういうところ日本のコミュニティの良くないとこよね。
そもそも質問のログ見たらJavaの起動オプションのXmxが1Gになってるけど、ヒープの最大1GBじゃ処理追い付かないし、それ以上上げれないんだったら、そんな貧弱なマシンじゃ遅かれ早かれスペック不足で遊べなくなるで。しかも102個のmod入れてるけど、快適に動いてんの？まで回答してあげるのが本当の親切な回答なんじゃないかと。(ちなみに筆者はJavaのヒープ8GBにしてるので快適です)
話題が逸れました。ここから海外サイトネタです
・minecraftforgeでの質問(BetterQuestingで発生)
→簡単に流れ説明すると、
質：マイクラのバージョン1.12.2でmod動かしたらRendering screenで落ちるけどなんじゃい
回：その問題もう知っとるで、今修正終わったけど、ビルド終わってないからサーバにあげちょらん
終了。
やっぱり海外の人たちはやり取りが気楽でいいすね。原因わからんかったけど。
ただ、Intel(R) UHD Graphics 620これでプレイしようとしてるのは猛者だなと思った。バニラですら危ういのにmod追加したら物によってはやばくね？と。
と、各modで発生し得るエラーっぽいですね。
・「rendering screen logisticspipes」で検索
・Github、日本語版フォーラムで同様の事象報告、ただし、「java.lang.NoSuchMethodError」が発生ヌルポじゃない。
→いずれもCodeChickenlibsのバージョンが合っていない、Forgeのバージョンが古いだけなので、今回とは無関係か。
試験的に、最小構成でネットワークを組んで、検索機能を使用。
チェストに供給パイプをつなげて、遠隔要求パイプを接続しただけの構成。
チェストに入れた、土と焼き羊肉が正常にRemote Orderに表示されてる。
あれ？普通に検索できてる・・・
とまぁここまで書いて、ふと気づいた「Logistics PipesってGitHubでPJごと公開してるじゃん」と。というわけで、clone作るのは怖いので、zipでダウンロードからの解凍。
落ちている箇所のコード確認。※作者さんの了解とってないので、コードの貼り付けとかはしません。
クラッシュログの該当クラスと行を確認したところ、まぁなんとなくnullになる変数はわかった。というわけで、どこでnullになりえるのかをログから逆追い(この作業ほんと久しぶりだな・・・)
んで、なんでこうなるかも、ふんわりわかってきたけど、これ海外の人に説明するの難しいな・・・。ふんわりだからある程度の会話しなきゃいけんだろうし。
簡単に言うと、全アイテムを取得→Listに格納して、for文でぐるぐる回しながらそのアイテム情報を読み込んでいって、その間にnullチェックがないから、nullのアイテムがあっても情報読み込もうとするが、その実態がnullだからヌルポが起きるって感じです。
で、nullになりえそうなものがわからん・・・タイミング的には最初にも言った、OpenBlocks抜いたが故にチェスト内のアイテムがnullになった。が正解だとは思うんだが・・・
とりあえずできる手段として、Providerパイプをもう一回全部引っこ抜いて、設置→検索確認。で、落ちたチェストのアイテムを精査かなぁ。
というわけで、
引き出し側(画面左)は決まったアイテムしか入らないだろうという想像のもと供給パイプ外さずにダイヤチェスト側(画面右：何でも入れちゃうところ)を引っこ抜いて、RemoteOrderで検索
できたーーーーーー！！
いやマジで嬉しかった。
で、チェストの奥から1個ずつ供給パイプ設置→検索確認
1つ目：正常
2つ目：正常
3つ目：クラッシュ
おまえかーーーーーーーーーー！！
一旦3つ目を抜いて、他全部に供給パイプを設置して、検索できるかの確認。この作業クラッシュすると再起動必要で、5分くらい起動待ちが発生するんだよなぁ・・・
4つ目：クラッシュ
ここまでやって気づいたのですが2つ目と3つ目も場合によってはクラッシュします。。というわけでおしりから再開
16つ目：OK
15つ目：OK
14つ目：OK
13つ目：OK
12つ目：OK
11つ目：OK
10つ目：OK
おーけーここまでは順調です・・・
9つ目：OK
8つ目：OK
7つ目：OK
6つ目：OK
5つ目：OK
そろそろ問題のポイントです・・・
4つ目：OK うしろからやってくと4つ目OKになりますね。
3つ目：クラッシュ
クラッシュしたところで、ようやく2つ仮説が立てられました。
- アイテム数が多いんじゃないか説→1～6つ目のチェストはスタックできないアイテム(武器とかエンチャ本とかポーションとか)が多すぎて、RemoteOrderのページ数が10を超える。ちなみに1と4～16までつなぐとページ数は11ページ。全部つなぐと16ページを超える
- エンチャントされてるアイテムにOpenBlocksのものが含まれている(いた)説
切り分けが難しい(エンチャントされてるアイテム=スタックできないもの)ので、とりあえず、武器防具その他諸々を一回移動してから、すべてをつなぐ。
不要な方々です。量にすると3ダイヤチェスト強(種類数にして330種類)でました・・・
RemoteOrderのページ換算、だいたい5ページくらい。。。思ってた5倍くらい有りました・・・
断捨離を終えて、全部つなぎ直して10ページまで減りました。そして・・・
いよし！！
無事検索できました！！
いやー長かった・・・。マイクラ関連でコード解析までしたの初めてでした・・・。
原因は、太り過ぎによる限界突破ですね。
対策は、痩せること。
ちょっとふざけましたが、なんで種類が多すぎると、null参照しちゃったのかだけわからんですね。アイテム種類でList使ってるから限界超えることなんてないでしょうし。
そもそもnullチェック入れてよと思いましたけども。。。
まぁ逃げ道はあるので一旦良しとします。いつか英文考えてGitHubで課題起票しようと思います。長々とお読みいただきありがとうございます。
同じ事象の方がいて、なんでヌルポなのかわかる方いたらうれしーなー。
この記事が誰かの一助になれば幸いです。
余談・・・
銅インゴットが、108K(108000)個
RemoteOrderの表示「0M1」
これ表示バグってません？？それとも0.1M(100K)と表現したかったのかしら？
何れにせよ、やり過ぎた感は否めない。反省はしていません。
いじょうですー。つかれた。まじでつかれた。原因特定に2日もつかってしまった。
