yukieijiのメモ代わりブロマガ

PCやMinecraft(時々プログラミング)で思ったり感じたことをメモ代わりに残すブログ

TensorFlowの勾配計算の闇

プログラミング
研究でTensorFlowを使ってて勾配計算における闇を発見してそれに2日位悩まされたので記事にしておく
TensorFlow 1.xの話です

・TensorFlowの勾配計算って？ああ！！

通常TensorFlowを扱う時、以下の様に書いて勾配計算って全く気にせずに書くと思います。(というかTensorFlow1.x系列だと勾配自体がブラックボックスに近い技術になってる気がする)
import tensorflow as tf

optimizer = #optimizerの宣言
train_op = optimizer.minimize(#誤差)
RNNなどで勾配クリッピングする際は以下の様に書いて勾配を少し意識すると思います。
import tensorflow as tf

optimizer = # optimizerの宣言
grad, vars = zip(*optimizer.compute_gradients(# 誤差))
cliped_grad = # 勾配クリッピング処理
train_op = optimizer.apply_gradients(zip(cliped_grad, vars))
それ以外では勾配を意識することは無いと思います。ところがどっこい、optimizerのminimizeメソッド内部処理(https://github.com/tensorflow/tensorflow/blob/05ab6a2afa2959410d48aab2336cea9dc1e2c13e/tensorflow/python/training/optimizer.py#L355)を見てみるとcompute_gradientsメソッドを呼び出して勾配を計算し、その勾配をapply_gradientsメソッドで適用してることがわかると思います。minimizeメソッドを使用することでということは知らないうちに勾配を計算して、適用してることになります
これから勾配計算の仕様と闇に触れます。

・勾配計算と適用の仕様

1.勾配計算の仕様
基本的にはcompute_gradientsメソッドに誤差を引数として実行することで勾配が計算されます。
これの戻り値は勾配とその勾配を適用するための変数がペア(勾配と変数のタプル)になったリストになります。なのでZip関数を使用することで勾配と変数をそれぞれリストとして取り出すことができます。型は勾配：tf.Tensor、変数：tf.Variableとなります。
2.勾配適用の仕様
勾配をモデルに適用するするためにはapply_gradientsメソッドに勾配と変数のタプルのリストを引数として実行することで適用されます。
なので一回勾配に対してクリッピングなどの処理を行なった場合は再度Zip関数を使用してペアのリストにする必要があります。
次からその勾配計算に関する闇に触れます

・闇1．勾配クリッピング

1つ目の闇は「勾配クリッピング」です。
TensorFlowには値やノルム等で値をクリップする手段が多数用意されています。しかし、勾配(tf.Tensorのリスト)を扱える関数はtf.clip_by_global_norm以外存在しないです。その他の方法でクリッピングしたい場合はfor文で回さないといけないです・・・・（なんともめんどくさい）
TensorFlow公式チュートリアルもtf.clip_by_global_normでクリッピングをしているので、それでやれってことなんでしょう・・・
以下コードです
import tensorflow as tf

optimizer = # optimizerの宣言
grad, vars = zip(*optimizer.compute_gradients(# 誤差))

# グローバルノルムでのクリッピング
cliped_gnorm_grad, norm = tf.clip_by_global_norm(grad, # クリップする値)

# それ以外でのクリッピング
cliped_other_grad = [# one_gradに対してtf.clip_by_valueなどの関数を適用する for one_grad in grad]

・闇2．勾配を計算グラフ外に取り出す

2つ目の闇は「勾配を計算グラフ外に取り出す」です。
なんでいちいち勾配を計算グラフ外に取り出すの？って思うかもしれないですがモデルが巨大(EfficentNet-B8とか)になってまともにバッチ数を稼げない時に、少ないバッチ数で勾配を数回計算してその勾配の平均値を取ったりすることで擬似的にバッチ数を稼ぐことができます。なのでそういった時にどうしても勾配の値を一回計算グラフ外に出したりします。
普通にTensorFlowを使用している方なら「余裕じゃん、勾配自体をsess.runで呼び出せば出てくるでしょ？(以下のコード)」と思うのですが、そこが闇ポイントです。
import tensorflow as tf

optimizer = # optimizerの宣言
grad, vars = zip(*optimizer.compute_gradients(# 誤差))

init = tf.global_variables_initializer()
with tf.Session() as sess:

init.run()

gradients = sess.run(grad, feed_dict={# データとプレースホルダ})
上記のコードは正常に動作しません(コメントの部分を正しく書き直しても動作しません)、「嘘だ！！」と思う方は実際に書いてみて実行していただければ
エラーの内容としましてはsess.runで実行するオペレーションがNoneになってるよってエラーです。
「tf.Tensorを指定して実行しているのに何故？」「tf.TensorなのにNoneっておかしくね？」って首を傾げる人は多いと思います。このエラーが出る原因は、勾配自体が特殊なTensorになっているからです。勾配のリストの一部を表示した時、tf.Tensorと型が出ますがその後の名前がこのエラーの原因です。名前の後ろに"Control_dependency"とあると思いますこれはTensorFlowの中のTensorでも「実行する前に値が入ってないと行けないTensor」(https://www.tensorflow.org/versions/r1.15/api_docs/python/tf/control_dependencies)になります。なのでsess.runで実行することはできません。
「じゃあどうするの？」ってなりますがsess.runにvarsつまり、勾配をセットする変数を指定すること(以下のコード)で取り出すことが可能になります。
import tensorflow as tf

optimizer = # optimizerの宣言
grad, vars = zip(*optimizer.compute_gradients(# 誤差))

init = tf.global_variables_initializer()
with tf.Session() as sess:

init.run()

gradients = sess.run(vars, feed_dict={# データとプレースホルダ})
勾配計算なのに変数を指定する・・・・闇が深い・・・

・闇3．勾配を計算グラフ外に取り出すオペレーションを文字列で指定する

3つ目の闇は「勾配を計算グラフ外に取り出すオペレーションを文字列で指定する」です。
グラフを外部から読み込んだ時、どうしても文字列でオペレーションを指定する必要があるので時々こうなります・・・
上の2つ目の闇を読んだ方は「変数の名前の文字列のリストを指定すればいい」と考えてコードを打ち込んで実行すると思いますが、エラーもなく実行できますが、それが深い深い闇の入り口です・・・

import tensorflow as tf

optimizer = # optimizerの宣言

grad, vars = zip(*optimizer.compute_gradients(# 誤差))

gradient_op = [var.name for var in vars]
init = tf.global_variables_initializer()

with tf.Session() as sess:

 init.run()

 gradients = sess.run(gradient_op, feed_dict={# データとプレースホルダ})
上記コードが実行できるのでこの勾配に対して、色々と操作してモデルに勾配適用しようと思ったら何故かエラーが出ます。何故かというときちんと勾配がグラフ外に取り出せてないからです。printとかで計算した勾配を見てみると1組の整数型のタプルを要素に持つndarray(データタイプはオブジェクト)のリスト(正しい勾配はfloat32のデータを持つndarrayのリスト)になっています。一見すると勾配計算間違えたのかな？って思いますがオペレーションの設定ミスです。
原因は変数は変数であり実際の勾配の計算オペレーションとは違うところです。変数の名前はkernelという名前が最後につき、勾配はControl_dependencyという名前がついています。実際のオペレーションはControl_dependencyで行われ、それがkernelに代入されるという流れなので文字列で指定する場合は勾配の方のTensorの名前を設定する必要があります(以下コード)
import tensorflow as tf

optimizer = # optimizerの宣言

grad, vars = zip(*optimizer.compute_gradients(# 誤差))

gradient_op = [one_grad.name for one_grad in grad]
init = tf.global_variables_initializer()

with tf.Session() as sess:

init.run()

gradients = sess.run(gradient_op, feed_dict={# データとプレースホルダ})
同じ勾配計算なのに、文字列だと勾配、テンサーだと変数を指定しないといけない・・・闇が深すぎる・・・・

TensorFlow2.x式の低レベルな書き方

プログラミング
世界中で最も使われていて最も現場で使われているTensorFlow(以下TF)が去年、機能拡張を含んだ大型バージョンアップを行いました。その際にAPIの大掃除が行われTF1.x系列で使っていた低レベルな書き方が通用しなくなりました

この記事は低レベルでゴリゴリ色んな所をカスタマイズして書きたいって人を支援できたら幸いです(自分自身もよくわかってない点もある)

1.前話

・TF2.xで生き残っているTF1.xの書き方
TF1.xとTF2.x両方に通用する書き方はKerasのFunctional APIとSequential APIです。
それ以外の書き方は消えました。というかTensorFlow自体が「Kerasをベースに書いてね」という感じです。tf.layersとかは消されて使えません
また、TF1.xからTF2.xに更新した際、まともに変更せずに動くのはKerasのみ(カスタムレイヤーとか使わずに)を使って書かれたコードだとおもいます(変換プログラムもあるけど使えるのかね)
※TF1.xから更新してTF2.xのKerasを動かす場合、多分Kerasのインポートを以下の様に変更する必要があります。

from tensorfrow import keras

・どうしてそんなひどい事をしたの？
答えは単純です
「PyTorchとかの方がPythonic(Pythonぽくて)ぽくって、書きやすいから」です
あとPyTorchの追い上げがすごいってのもある

(引用:https://trends.google.co.jp/trends/explore?date=today%205-y&q=TensorFlow,PyTorch,Keras,Chainer)

あとPyTorchとかKerasはオブジェクト指向ぽくかけて、TF1.xは関数型(tf.layersとかもろ関数型)ぽいからってのもあります。またはDefine on Run(TensorFlow)とDefine by Run(PyTorch)の違いもあったりします
Define on RunとDefine by Runの解説はこの記事ではしませんが、気になる方は調べていただければ

「Kerasでオブジェクト指向的なモデルの書き方は無いんじゃない？」って感のいい読者なら気づいたかもしれません。確かにTF1.xのKerasにはオブジェクト指向的な書き方は存在しません、TF2.xのKerasにはオブジェクト指向的なモデルの書き方ができます。本記事はその点にも触れます


2.本編

・TensorFlow2.0の書き方
TensorFlow2.0はKerasの作者によるColab Notebookによると以下の書き方があります。
この記事では最も左下の書き方を解説します。


・Fully flexible with TensorFlow2.0(最も低レベルな書き方)
TT2.xで最も低レベルな書き方は以下になります
　・レイヤー :tf.keras.layers.layerを継承したクラスで書く
　・レイヤーブロック :tf.keras.layers.layerかtf.keras.Modelを継承したクラスで書く
　・モデル :tf.keras.Modelを継承したクラスで書く
　・訓練イテレーション:クラスを宣言してその中で回す
一番上以外はちょっとピンとこないと思います。一個ずつ解説します

・カスタムレイヤー :tf.keras.layers.layerを継承したクラスで書く
TF1.xのカスタムレイヤーの書き方がそのまま使えます。
基本的に __iniit(self)__で必要な変数を宣言してbuild(self,input_shape)で使うレイヤーと重み、バイアスを宣言します。以下例
(引用と参考:https://www.tensorflow.org/tutorials/customization/custom_layers)
class MyLayer(tf.keras.layers.layer):
　　　def __iniit__(self, output, **kwargs):
　　　　　super(MyLayer, self).__init__(**kwargs)
　　　　　self.output = output
　　　def build(self, input_shape):
　　　　　self.kernel = self.add_variable("kernel",shape=[　　　
　　　　　　　　　　　　　　　　　　　　int(input_shape[-1]),
　　　　　　　　　　　　　　　　　　　　self.num_outputs])
　　　def __call__(self, inputs):
　　　　　return tf.matmul(inputs, self.kernel)
・レイヤーブロック:tf.keras.layers.layerかtf.keras.Modelを継承したクラスで書く
CNNとかで使われている層を重ねたブロック。上のカスタムレイヤーも入れて書くことも可能
tf.keras.layers.layerで書く場合は重み、バイアスの宣言は行わないようにする
tf.keras.Modelでも書ける(モデルの入れ子ができるため)けど入力の型が取れないから正直微妙である。以下例
class MyLayerBlock_layer(tf.keras.layers.layer):
　　　def __iniit__(self, filter, kernel_size, channel_axes=-1 **kwargs):
　　　　　super(MyLayerBlock_layer, self).__init__(**kwargs)
　　　　　self.filter = filter
　　　　　self.kernel_size = kernel_size
　　　　　self.channel_axes = channel_axes　
　　　def build(self, input_shape):
　　　　　input_filter = input_shape[self.channel_axes].value
　　　　　self.conv2_a = tf.keras.layers.Conv2D(input_filter, (1, 1))
　　　　　self.bn2_a = tf.keras.layers.BatchNormalization()
　　　　　self.depthconv2 = tf.keras.layers.DepthwiseConv2D(input_filter,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　self.kernel_size,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　padding='same')
　　　　　self.bn2_depth = tf.keras.layers.BatchNormalization()
　　　　　self.conv2_b = tf.keras.layers.Conv2D(self.filter, (1, 1))
　　　　　self.bn2_b = tf.keras.layers.BatchNormalization()
　　　def __call__(self, inputs, training=True):
　　　　　x = self.conv2_a(input_tensor)
　　　　　x = self.bn2a(x, training=training)
　　　　　x = tf.nn.relu(x)
　　　　　x = self.depthconv2(x)
　　　　　x = self.bn2_depth(x, training=training)
　　　　　x = tf.nn.relu(x)
　　　　　x = self.conv2_b(x)
　　　　　x = self.bn2_b(x, training=training)
　　　　　x += inputs
　　　　　return tf.nn.relu(x)

class MyLayerBlock_Model(tf.keras.Model):
　　　def __iniit__(self,
　　　　　　　　　　input_filter,
　　　　　　　　　　filter,
　　　　　　　　　　kernel_size,
　　　　　　　　　　**kwargs):
　　　　　super(MyLayerBlock_Model, self).__init__(**kwargs)
　　　　　self.conv2_a = tf.keras.layers.Conv2D(input_filter, (1, 1))
　　　　　self.bn2_a = tf.keras.layers.BatchNormalization()
　　　　　self.depthconv2 = tf.keras.layers.DepthwiseConv2D(input_filter,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　kernel_size,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　padding='same')
　　　　　self.bn2_depth = tf.keras.layers.BatchNormalization()
　　　　　self.conv2_b = tf.keras.layers.Conv2D(filter, (1, 1))
　　　　　self.bn2_b = tf.keras.layers.BatchNormalization()
　　　def __call__(self, inputs, training=True):
　　　　　x = self.conv2_a(input_tensor)
　　　　　x = self.bn2a(x, training=training)
　　　　　x = tf.nn.relu(x)
　　　　　x = self.depthconv2(x)
　　　　　x = self.bn2_depth(x, training=training)
　　　　　x = tf.nn.relu(x)
　　　　　x = self.conv2_b(x)
　　　　　x = self.bn2_b(x, training=training)
　　　　　x += inputs
　　　　　return tf.nn.relu(x)
・モデル:tf.keras.Modelを継承したクラスで書く
Kerasのベースモデルクラスを使ってモデルを作ります。これでPyTorchっぽく書けてPythonicなモデルになります(オブジェクト指向的)
このモデルに対してcompileやpredictなどのメソッドを使うことができるが、作成したモデルを使ってtf.keras.models系の関数は使えません
このモデルに対して複数の入力を与える場合、それぞれの1軸をバッチ次元にしたリストを渡して__call__の時に分解します
class MyModel(tf.keras.Model):
　　　def __iniit__(self,output,**kwargs):
　　　　　super(MyModel, self).__init__(**kwargs)
　　　　　self.dense = tf.keras.layers.Dense(output)
　　　def __call__(self, inputs):
　　　　　x = self.dense(inputs)
　　　　　return tf.nn.relu(x)
・訓練イテレーション:クラスを宣言してその中で回す
これが一番の肝です。以下のようにタスククラスを宣言しモデルの初期化などを行った後訓練メソッドを呼び出すようにします
以下の場合だとtrainメソッドを呼び出せば訓練が開始されます。
何故、こんな面倒くさい事をやってるかというと@tf.functionの自動グラフ構築を必要な所で使うことによって最適かつ高速に訓練を行う事ができます(GoogleのTransformerでも使われてるテクニック)
Define on RunとDefine by Runを同時に操作できる強みがある
class MyTask(object):
　　　def __iniit__(self,model,optimizer,loss_func,acc_func):
　　　　　self.model = model
　　　　　self.optimizer = optimizer
　　　　　self.loss_func = loss_func
　　　　　self.acc_func = acc_func
　　　　　self.model.compile() #必要ならコンパイルしとく
　　　def train(self, epoch):
　　　　　for iter in range(epoch):
　　　　　　　x, y = (データの取得用の関数とかクラス)
　　　　　　　loss=train_step( x, y )
　　　　　@tf.function
　　　　　def train_step(self, x, y)
　　　　　　　with tf.GradientTape() as tape:
　　　　　　　　　　pred = self.model(x, training=True)
　　　　　　　　　　loss = self.loss_func(y, pred)
　　　　　　　grd = tape.gradient(loss, self.model.trainable_weights)
　　　　　　　self.optimizer.apply_gradients(zip(grd,
　　　　　　　 self.model.trainable_weights))
　　　　　　　self.acc_func.update_state(y, pred)
　　　　　　　return loss
　　　@tf.function
　　　def model_predict(self,x)
　　　　　return self.model.predict(x)

3.おわりに

これらのを利用することでTF1.x系でも、できた細かなカスタムや調整もできるようになったと思います
最後にTensorFlow v2.x系はまだちょっと未完成なところ(ver2.0では勾配計算に失敗したり、今でのカスタムレイヤーで複数出力を計算時にバグがあったり)があるので研究等で使う場合は十分に気を付けてくださいませ

GregTech 5/5Uのエネルギーシステムについて(公式GTNH wiki「Electricity」日本語訳)

Minecraft GregTech5U

この記事はGTNHの公式wikiの「Electricity」項目の日本語翻訳です(URL:https://gtnh.miraheze.org/wiki/Electricity)
一部見やすいように改変していますのでご了承下さい

2019/05/16:初版、1と2だけの翻訳
2019/06/18:3を翻訳開始

⚡INDEX

  1. はじめに
  2. 電圧と電流
  3. ケーブルと損失
  4. 変圧器
  5. 機械の爆発とケーブルの焼失
  6. エネルギー変換
  7. エネルギー保存の管理
  8. 新規プレイヤー向けのガイド


1.はじめに
⚠このページ及びGTNHの公式wikiの「Electricity」項目は未完成であり、情報を募集中です
このページ及びGTNHの公式wikiの「Electricity」項目は、IC2Exのエネルギーシステムに不満をもったGregoriusT氏がGregTechにver5(Minecraft ver1.7.2向け)から実装したエネルギーシステムについての解説です
よって全てのGregTech5のバージョンのエネルギーシステムの解説になります(非公式版も含む)

IC2のエネルギーネットと互換性をなくした理由はケーブルの減衰が機能しないことと、そのネットワークにパケットが存在しない、そしてそれを整数型から倍精度浮動小数点型に変更したからです(より大きなエネルギーストレージは恐ろしいです)。言うまでもなく、タイルエンティティを常に登録及び解除しないでエネルギーの流れを制御することは非常に難しいことです
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ー GregoriusT



2.電圧と電流
GregTechは電圧(Voltage 単位:V)とアンペア(Ampere 単位:A)という用語を用いて新しい電力システムを実装しています。「1アンペア」はIC2のEUの1パケットと同じで、「電圧」はそのパケットのサイズと同じです。EU/tは受け取ったEUの合計値です。
例えば、1つのマシンがある時に32Vのポケットを受け取り、そのあと24Vのポケットを受け取ったとしたら、受け取った合計のEU/tは32+24=56EU/tとなります。
IC2のエネルギーシステムとは異なり、エネルギーによって作用する全てのGregTechのブロックは、それらが作用できる電圧とアンペアの両方に制限があります。
機械によって入出力できるアンペアが異なります

  • GregTechの変圧器(Transformer)は昇圧時は、入力4A、出力1Aになり、降圧時は、入力1A、出力4Aになる
  • バッテリーバッファ(Battery Buffer)は1つのバッテリーにあたり入力2A、出力1Aとなる
  • バッテリー充電器(Battery Charger)は1つのバッテリーにあたり入力8A、出力2Aとなる
  • チェストバッファ(Chest Buffer)とスーパーバッファ(Super Buffer)は入力2Aとなる
  • エネルギーハッチ(Energy Hatch)は入力2Aとなる
  • 物質製造機(Mass Fabricators)は入力10Aとなる
  • マイクロウェーブエナジートランスミッター(Microwave Energy Transmitter)は入力3Aとなる
  • モンスターリペレンター(Monster Repellator)、ポンプ(Pump)、テレポーター(Teleporter)は入力2Aとなる
  • 他のすべてのEU受け取る機械はレシピに応じて少なくとも1Aを受け取ります:入力アンペア数はレシピで表示されるEU使用量の2倍を機械の入力電圧で割ったものに1を足したものです

　　・LVの遠心分離機が5EUのレシピを処理している場合、入力1Aとなる
　　・LVの化学炉が30EUのレシピを処理している場合、入力2Aとなる
　　・LVのアーク炉が96EUのレシピを処理している場合、入力は7Aとなる

  • 発電機は1Aを出力します
機械名 入力 出力
　変圧器(Transformer　※昇圧) 　4A 　1A
　変圧機(Transformer　※降圧) 　1A 　4A
　バッテリーバッファ(Battery Buffer) 　2A(バッテリー1個あたり) 　1A(バッテリー1個あたり)
　バッテリー充電器(Battery Charger) 　8A(バッテリー1個あたり) 　2A(バッテリー1個あたり)
　チェストバッファ(Chest Buffer) 　2A 　NONE
　スーパーバッファ(Super Buffer) 　2A 　NONE
　エネルギーハッチ(Energy Hatch) 　2A 　NONE
　物質製造機(Mass Fabricators) 　10A 　NONE
　マイクロウェーブエナジートランスミッター
　(Microwave Energy Transmitter)		 　3A 　NONE
　モンスターリペレンター(Monster Repellator) 　2A 　NONE
　ポンプ(Pump) 　2A 　NONE
　テレポーター(Teleporter) 　2A 　NONE
　その他の全ての機械 　((レシピEU*2)/機械の電圧)+1A 　NONE
　発電機(全て) 　NONE 　1A


機械にエネルギーを入力する際に以下のことに注意することがある:

  • 機械の電圧より高い電圧を入力すると爆発します。機械は必要になるまでエネルギーを受け取らないので、実際に動作するまで爆発することはありません！
  • 機械に過剰入力されたアンペアは機械の電圧の限界を下回っている限り効果がありません。機械は電圧を必要としない限り電流を流さずアンペアの端数も流しません、これによって電力に関して機械は機械自身で調整します

機械とレシピにはそれぞれ電圧のティアがあります。マルチブロックの機械はそのエネルギーハッチによって決定します。 機械のティアとレシピのティアは相互に作用するため、注意を払う必要があります

  • レシピのティアがマシンのティアより高かった場合、レシピは実行されません
  • レシピのティアがマシンのティアと同じだった場合、レシピは正常に動作します
  • レシピのティアがマシンのティアより低かった場合、レシピはオーバークロックされます。 オーバークロックされる場合は普通レシピの速度の2倍の速度で、2倍のエネルギーで実行されます。したがって、1ティックあたり普通レシピの4倍のエネルギーで実行されます

レシピのオーバークロックは機械の電圧とレシピが必要とする電圧との差の電圧ティアの1づつに実行されます。 もし、30EU/t(LVティア)で20秒で作業が完了するレシピをHVのマシンで実行される場合、2つのティアの差によって480EU/tで5秒で作業が完了します
GregTech:New Horizonsはバージョン2.0.2.5の時点で9つの電圧のティアが存在しています。そのうちの3つの電圧のティアは部分的な実装(*)で4つの到達不可能な電圧のティア(**)です
ノート:ULVティアはティア0として扱います

短縮形 電圧名 許容最高電圧
　ULV 　Ultra Low Voltage 　8
　LV 　Low Voltage 　32
　MV 　Medium Voltage 　128
　HV 　High Voltage 　512
　EV 　Extreme Voltage 　2048
　IV 　Insane Voltage 　8192
　LuV 　Ludicrous Voltage 　32768
　ZPM 　ZPM Voltage 　131072
　UV 　Ultimate Voltage 　524288
　UHV(*) 　Highly Ultimate Voltage 　2097152
　UEV(*) 　Extremely Ultimate Voltage 　8388608
　UIV(*) 　Insanely Ultimate Voltage 　33554432
　UMV(**) 　Mega Ultimate Voltage 　134217728
　UXV(**) 　Extended Mega Ultimate Voltage 　536870912
　OpV(**) 　Overpowered Voltage 　1073741824
　MAX(**) 　Maximum Voltage 　2147483647


3.電圧と電流
GregTechには現在独自の電気システムがあるため、GregTechのマシンへの電源供給にはGregTechケーブルを使用する必要があります
GregTechでIC2のEUを受け入れることができる唯一のマシンがGregTech5Uの変圧機(Transformer)|変圧器(Transformer)(IC2の変圧器(Transformer)と混同しないでください)

すべてのGregTechのケーブルには許容電圧と許容電流と損失があります:
・許容電圧より高いパケットを受け取るとケーブルは焼失してしまうでしょう
・許容電流より多くのアンペアを通電させたケーブルは焼失してしまうでしょう
　パケットが反発する可能性があることに注意してください。論理パスがEUをそこに流すべきではないとしても、そのケーブルに余分なパケットが流れない事を絶対に考えてはならない(必ずしも最適な電流がそのケーブルを流れるとは限らないという事。例えば分岐させたからと1Aのケーブルでも大丈夫ではなく、出力アンペアと同じかそれ以上に耐えうるケーブルを使わないと反発し合った時に焼失するおそれがある)
・

Spigot/Bukkit/Sponge/Bungeeプラグイン「Plan|Player Analytics」解説(2019/09/27更新:Plan v5.0のテストビルドに日本語ファイル実装)

Minecraft Minecraftサーバー Bukkit/Spigot

02/28の生放送でいろいろとやっていた設定していたプラグインです
このプラグインは多種多様の機能を兼ね備えて導入必須というレベルで素晴らしいプラグインですが、日本語の解説が0と言う悲しい事実なので解説していきます。コンフィグの詳しい説明とかはよくわかっていないのでそこらへんは割愛します
対応バージョンは1.7～1.13
配布先:https://www.spigotmc.org/resources/plan-player-analytics.32536/
開発GitHub:https://github.com/Rsl1122/Plan-PlayerAnalytics
Wiki:https://github.com/Rsl1122/Plan-PlayerAnalytics/wiki

2019/04/24:Plan ver4.8.2 DEV2にて日本語化ファイルが実装され使えるようになりました
また日本語翻訳に関するGitHubフォークとDiscordを立ち上げました
日本語化に関するGitHun:https://github.com/yukieiji/Plan-JapaneseTranslationProject
2019/05/10:Plan ver4.8.2が正式リリースされ日本語ファイルが正式に実装されました、下の方にやり方を書いておきます
2019/09/27:Plan ver5.0のテストビルドも日本語化が完了しました、インターフェースが一新されています。DL先→ :https://plan.djrapitops.com/job/Player%20Analytics/job/interface-redesign/


1.Plan|Player Analyticsって？ああ！！
聞いたことすらないプラグインだと思います。Planは導入されているサーバーの各種情報をブラウザ上で確認できるプラグインです。
プレイヤーの各種情報やプレイヤーがどれくらい活動してるのか、KDR、プレイヤーのPingなどいろいろと確認できます
更に下の画像の様にサーバーの負荷状況、メモリ使用率、TPS、CPU使用率なんかも確認できます。ここに書いてある機能はごく一部で、配布先の画像に機能一覧を載せた画像があります
データベースを使用することもできるため、ある程度高速に動作します



2.Spigot/Bukkit/SpongeへPlan|Player Analyticsの導入
何時ものようにプラグインフォルダにダウンロードしたjarファイルを入れて再起動するだけで導入自体は完了です。
デフォルトのPlanの使用ポートは8804番で、ブラウザに「http://localhost:ポート番号」と入力して表示されていれば成功です。ポート番号を開放すれば外部からも接続可能です
データベース関連を使用する場合、コンフィグより使用するデータベースなどを入力します。
プレイヤーの情報が表示されない場合は「/plan analyze」などをつかって分析をかけます
2019/03/07更新:更新でデーターベース関連が変更されてデフォルトのままだと動かなくなりました。なのでSQLiteかMySQL(MarinDB)を導入してプラグインのコンフィグを設定するか、コンフィグのデーターベースをH2に設定してください

3.Bungee/WaterFallへPlan|Player Analyticsの導入
Bungee/WaterFallへの導入はMySQLの導入や入れた後の設定が必要のためちょっとめんどくさいです。(MySQL以外もできるけどやり方がWikiに書いてないので割愛)
3-1:まずMySQLを導入予定のBungeeが実行されるマシンにインストールします
3-2:インストール後MySQLをPC起動時に自動実行するようにします
3-3:MySQLのルートパスワードを設定しMySQLのコマンドラインを起動しログインします(Linuxとかだと管理者権限で「mysql -u root -p」を実行するとコマンドラインが起動します)
3-4:Planが使用するデータベースを「CREATE DATABASE (データベース名);」で作成
3-5:Planが使用するデータベースを操作するユーザーを「CREATE USER '(ユーザー名)'@'localhost' IDENTIFIED By '(ログインパスワード)';」で作成、ユーザー名とパスワードは覚えておいてください
3-6:上で作ったユーザーにPlanが使用するデータベースの操作権を「GRANT ALL PRIVILEGES ON (データベース名).* TO '(ユーザー名)';」付与
3-6ex1:Bungee/WaterFallにつなげるサーバーがBungee/WaterFallと同じマシン上にない場合、「GRANT ALL PRIVILEGES ON (上で作ったデータベース名).* TO '(上で作ったユーザー名)'@'繋げるサーバーのIPアドレス' IDENTIFIED BY '(上で作ったユーザーのログインパスワード)' WITH GRANT OPTION;」を使って外部サーバーからMySQLを操作できるようにする
3-6ex2:そしてBungee/WaterFallのサーバーの3306番ポートを開放、別の外部サーバーがある場合3-6ex1を繰り返す
3-7:PlanをBungee/WaterFallのプラグインフォルダに導入して起動(切らなくておｋ)
3-8:起動したらPlanのコンフィグを開く
3-9:Server:のIP:の項目に自身のBungee/WaterFallに接続できるIPもしくはアドレスを入れる
3-10:Database:のMySQL:内にあるUser:に上のPlanが使用するデータベースを操作するユーザー名、Password:に上のPlanが使用するデータベースを操作するユーザー名のパスワード、Database:に上のPlanが使用するデータベース名を入れる
3-11:上記設定が終了後保存して「/planbungee reload」と入力してコンフィグをリロード、ブラウザに「http://localhost:ポート番号」と入力してウェブページが表示されることを確認する
3-12:Bungee/WaterFallに接続されている全てのSpigot/Bukkit/SpongeにPlanを上の2にある通りに導入し起動
3-13:Spigot/Bukkit/SpongeのPlanのコンフィグを開いてサーバー名を適当に変えておく
3-14-1:もしBungee/WaterFallを実行している同じマシンのサーバーならBungeeのPlanで使用してないポートの番号をWebserver:のPort:に入れる(WikiだとFreeって書いてあるから空欄にするんかなって思うけど次の作業でうまくいかないのでなんか入れとく)
3-14-2.1:もしBungee/WaterFallを実行しているマシンと違うマシンで実行されているサーバーならPlanのコンフィグが使用しているポートの番号を開放
3-14-2.2:Planのコンフィグを開きWebserverの欄の「Alternative_IP: true」に変更、その下の項目を「Address: "実行しているサーバーマシンのIP:%port%"」とする(%port%は自動的に決まるらしいのでこれで良いとのこと)
3-14:Bungee/WaterFallのほうで「/planbungee setup」と入力してセットアップモードを起動
3-15:Spigot/Bukkit/Spongeの方で「plan m setup (BungeeのPlanのアドレス):(BungeeのPlanが使用するポート番号)」と入力、BungeeのPlanのIPアドレスはBungeeが同じマシンにあるなら「localhost」、Bungeeが同じローカルネットワーク内ならローカルのIP、それ以外ならサーバーに接続するIPorアドレス、IPアドレスやローカルホストの場合は「http://」を最初につけないとだめみたいです
3-16:Bungeeのログに「Config file for server '(上で変更したサーバー名)' updated in /Plan/serverConfiguration」って出ていれば完了、Bungeeに接続されている別のサーバーがあれば、3-14より再度設定
3-17:「/planbungee reload」でPlanをリロード
3-18:ブラウザに「http://localhost:ポート番号/server」で追加されているサーバーがあれば導入完了
3-19:Spigot/Bukkit/SpongeのPlanフォルダ内にあるデータベースファイルを消しておく(Bungeeのデータベースに統合されるため)

3.日本語化やり方
1.Plan ver4.8.2以降を導入しSpigot/Bukkit/Sponge/Bungee/WaterFallを起動しコンフィグファイルを作成
2.コンフィグファイルを開き「Plugin」の「Logging」の中の「Locale: default」を「Locale: JA」に変更3.「Formatting:」の「Time_amount:」を以下のように変更

Year: '1年, '
Years: '%years% 年, '
Month: '1ヶ月, '
Months: '%months%ヶ月, '
Day: '1日 '
Days: '%days%日 '
Hours: '%hours%時間 '
Minutes: '%minutes%分 '
Seconds: '%seconds%秒'
Zero: '0秒'

3.完了後保存し「/plan reload」/「/planbungee reload」としてPlanを再起動、反映されない場合はSpigot/Bukkit/Sponge/Bungee/WaterFallを再起動する
3ex.コンフィグの「Network」/「Server」の「Name:」の欄は必ずアルファベットのA～Z、a～zまたは1～9のみを用いた名前に設定し、ウェブページを開いたときにコンフィグで設定した名前になっていることを確認する(日本語へ翻訳する文字列が使われていた場合、サーバー名やネットワーク名まで翻訳され正しく動作しなくなります)


4.余談
いくつか連携しているプラグインもあるみたいです ⇒ https://github.com/Rsl1122/Plan-PlayerAnalytics/issues/583


Minecraftのサーバーの種類まとめ(2022/02/05更新：更に追加でlog4jに関する脆弱性対応及びLoliServerを追加)

Minecraft Minecraftサーバー Bukkit/Spigot

Minecraftのサーバーを運用していてGitHubをいろいろとあさっていたらいろいろとMinecraftのサーバーを発見した(Spigot以外)のであとで分かるようにメモも含めてまとめときます
サーバーの紹介ではなくてサーバーの種類の紹介ですのでご注意を
またMinecraft:JavaEditionのサーバーのみの種類の紹介し、一部ビルドや実行できないものもあります

2019/03/19更新:Trident、Rainbow、SportPaper、CloudSpigot、Kettle、Mohistを追加、一部修正
2019/04/17更新:Uraniumの現状況を追加、KCauldronのURLを更新
2020/05/10更新:Thrmos非公式版(その1)とCatServerのURLを更新、AkarinとAtom、Mohistを更新、Atom非公式版を追加
2020/06/17更新:Migotのビルド方法を記載
2021/02/19更新:Mohistの詳細更新、PaperとAkarinに追記、Magma、Crucibeを追加
2021/02/22更新：EmpireCraft、Tuinity、Origami、Haricot、Airplane、Purpur、Yatopia、Ilblu、Ibento、Arclightサーバを追加
2021/12/10更新:log4jに関する脆弱性対応追加、Mohitに追記加
2021/12/10更新:更に追加でlog4jに関する脆弱性対応追加。Cubed、CloudSpigot、SportPaper、EmpireCraft、Tuinity、Airplane、Purpur、Yatopia、Crucible、Magumaに追記、LoliServerを追加

 

 

1.Minecraft公式サーバー系列
Minecraftの公式サーバーもしくはそれを派生させたものでプラグイン等は基本使えないけど別言語で書かれたものがあるのでパフォーマンスを重視させたものが多い印象

DL先:https://minecraft.net/ja-jp/download/server/
特になんにも考えなくても建てれるMinecraftのサーバー、古いバージョンを落とすのが結構めんどくさい
Minecraft純正のJavaで動くためパフォーマンスは微妙

  • cuberite

公式サイト:https://cuberite.org/
開発GitHub:https://github.com/cuberite/cuberite
対応バージョンは1.8～1.12のマルチバージョンでC++とLuaで開発されたMinecraftのサーバー、C++で開発されているためマルチコア対応でメモリーの消費も少ない高性能サーバー、独自のプラグイン(Lua)も使えるみたい
レシピはすべてテキストファイルに書かれて置いてあるのである程度のレシピ変更もMODなしで可能
現在も開発が行われている
動作プラットフォームはWindows、Linux、macOS、FreeBSD、Androidと多岐に渡ってる

  • Mineserver

公式サイト:https://mineserver.be/
開発GitHub:https://github.com/fador/mineserver
こちらもC++で開発されていて高性能なサーバーだが開発が2016年から止まっている
フォーラムの活動も終わってるみたい？
対応バージョンは1.8.9
動作プラットフォームはWindows、Linux、macOS

  • Rainbow

公式サイト:https://www.project-rainbow.org/
公式フォーラム:https://www.project-rainbow.org/site/index.php
対応バージョンはver1.8～1.13、Minecraft 1.8のサーバーをカスタムしたサーバーで、Bukkitのプラグインと独自のプラグインが使えるサーバー。最初から経済システムやバックパックなどのシステムが組み込まれている。フォーラムもあり

  • Trident

公式サイト:https://tsdk.xyz/
開発GitHub:https://github.com/TridentSDK/Trident
新世代の高性能かつマルチスレッドでバグが少ないMinecraftサーバーを目指して開発が行われていたが2017年から開発が止まっている模様、公式サイトも見えない・・・
対応バージョンは不明


2.Bukkit/Spigotサーバー系列
元々CraftBukkitより高性能なサーバーを目指して作られたサーバーだが、CraftBukkitがDLできなくなったためプラグインを使いたい場合や高性能なサーバーを建てる場合はSpigotを使うことが多い気がする

  • Spigot公式

公式サイト:https://www.spigotmc.org/
ビルドツールDLサイト:https://hub.spigotmc.org/jenkins/job/BuildTools/
対応バージョンはver1.8～ver1.13.2、日本語の最も情報が多く困ったら大体なんとかなる気がする。プラグインも大量にありCraftBukkitのプラグインもだいたい動く
自身でバージョンを指定してビルドしないといけないが一番めんどくさい所
ver1.7以降のサーバーがビルドできないのが悲しみ
2021/12/10更新：1.8～1.18にlog4jに関する脆弱性対応

 

  • Glowstone

公式サイト: https://glowstone.net/
開発GitHub:https://github.com/GlowstoneMC/Glowstone
古いバージョン:https://github.com/GlowstoneMC/Glowstone/releases
Wiki:https://github.com/GlowstoneMC/Glowstone/wiki
対応バージョンはver1.8～ver1.12.2、アルファ時代に存在したLightStoneを復活させて高速で互換性のあるオープンソースなサーバーを目指して開発されているサーバー。CraftBukkitプラグインとSpigotのプラグイン、更に下のPaperプラグイン、Glowstone本体のプラグインが使えるサーバー(それぞれのプラットフォームに依存しているNMSなどのプラグインは使えない模様)
長期サポートバージョンも配布されているためサポートやメンテンス面で非常に優秀
またビルドが必要としない点でユーザーフレンドリーな感じ

  • Cubed

開発GitLab:https://git.sw4pspace.net/sw4pspace/cubed
対応バージョンは不明、上のGlowstoneの広域な互換性を廃止させ多数の特徴を追加するためにフォークしたサーバー。
オープンソースのサーバーでありBukkit及びSpigotのプラグインのみの動作、フラットファイルを置き換えるバックエンドのデータベース、データベース操作のWebサービス、フロントエンドのWebページを簡単に操作できる事を特徴としている
なぜかjenkinsのダウンロードページを開くことができないため、自分でビルドする必要がある
2022/02/05:サイトにすらアクセスできなくなっていたため開発が終了した模様

 

  • Migot

開発GitHub:https://github.com/Poweruser/Migot
ビルドツール:https://github.com/Poweruser/MigotTools/releases
対応バージョンはver1.8.8(公式にはver1.8からってあったけどMigotのビルドデータが1.8.8以外なかったでござる)、マルチスレッディングに対応させたSpigotであり使用することができたら最も高性能なSpigotサーバーになると思うけど、自分の環境だとビルドできなかった悲しみ。もう長い間メンテンスされてないから修正はないかな・・・
2020/06/17:ビルドに成功し、動作確認も出来ました。
ビルド方法(必要環境：Linux/macOS、Maven、Java、Git)：
1.MigotToolsをGit Clone
2.その中のMigotTools/src/main/java/org/spigotmc/builder/Builder.javaの187行目の"http://～"を"https://～"に書き換え
3.「mvn clean package」でMigotToolをビルド
4.ビルドが完了したMigotToos.jarを使ってMigotをビルドするだけ
1～2がめんどくさい場合はフォークして修正したソースを以下のURLにあるのでそれをクローンしてビルドしてください
https://github.com/yukieiji/MigotTools

  • Paper

公式サイト:https://papermc.io/
開発GitHub:https://github.com/PaperMC/Paper
Paper公式ドキュメント:https://paper.readthedocs.io/en/stable/
ver1.12.2以前のバージョンのビルドDL先:https://papermc.io/ci/job/Paper/
ver1.13以降のDL先:https://papermc.io/downloads
対応バージョンはver1.8.8～ver1.18.1、次世代の高性能なSpigotを目指してSpigotをフォークしたサーバー。パフォーマンス向上の為数多くの最適化と改善が行われている。私が管理しているサーバーの連結されているバニラサーバーがこれを使っています、サーバーのログにいろいろと数値化されたワールドの情報が出るのですごく管理が楽です。またワールドの設定が事細かにできるのが素晴らしい(ログを見た感じだと作物の成長速度、アイテム消失速度、ホッパーの移動速度、TNTの爆発威力など)
これもビルドしなくて使えるので楽
2018/11/19更新:Paperを使ってみたけどいくつか使えないコマンドを使ったらスパムとしてプレイヤーを自動切断してくれる機能とかもあるみたい
2019/03/21更新:大手PvPサーバーで使用されているサーバーのフォーク元みたい
2021/02/19更新：Fork数が800、Issueも3000を超えてて結構開発が活発なサーバになってるっぽい
2021/12/10更新：1.17.x及び1.18.xに対してlog4jの脆弱性修正リリースがされていました

 

  • TacoSpigot

開発GitHub:https://github.com/TacoSpigot/TacoSpigot
ver1.8.8のDL先:https://ci.techcable.net/job/TacoSpigot-1.8.8/
ver1.9以降のDL先:https://ci.techcable.net/job/TacoSpigot/
対応バージョンはver1.8.8～ver1.13.2、上のPaperより高性能にすることを目的としてフォークされたサーバー。これもビルドしなくて使えるサーバー

  • Torch(非公式)

開発GitHub:https://github.com/GelandiAssociation/Torch
対応バージョンはver1.12.2、上のPaperにマルチスレッド処理を組み込むことで高速化することを目的として開発されているサーバー。

  • SportPaper

開発GitHub:https://github.com/Electroid/SportPaper
Stratus Network(PvPサーバー)で使用されているMinecraft ver1.8のPaperのフォークサーバー、新しいビルドシステムを使用しているみたい
2022/02/05追記:CraftBukkitのLog4jの脆弱性対策を取り込んでいるので、Log4j脆弱性されていることを確認

 

  • CloudSpigot

開発GitHub:https://github.com/Server24-7/CloudSpigot
配布先:https://ci.server24-7.eu/job/CloudSpigot/
Cloudz.mlで使用されているMinecraft ver1.8のPaperのフォークサーバー、Java11を使用して開発されていたみたいだけどJava8でもビルドできるようになっているみたい
2022/02/05追記:開発リポジトリがアーカイブ状態になっており開発が終了していました

 

  • Akarin

公式サイト:https://akarin.app/
開発GitHub:https://github.com/Akarin-project/Akarin
DL先:https://jenkins.bennydoesstuff.me/view/Akarin/
対応バージョンはver1.12.2とver1.13、ver1.14.4、ver1.15.2、旧Torchプロジェクトでゆるゆりの＼ｱｯｶﾘ～ﾝ／をモチーフにしたサーバー(名前アドがすごい)。新次元のサーバーを目指しパフォーマンス、安定性、改造性を目標としてPaperから派生したみたい。現在アルファ版みたいな感じらしい
きちんとSpigotのプラグインも使えるみたいです
AkarinForgeなるものも制作されているのでForgeBukkitの代わりになってくれると嬉しい
2019/03/21追記:↑AkarinForgeの開発が終了していた
2019/03/21追記:↑AkarinForgeの開発が再開してた
2021/02/19追記：AkarinForgeが開発リリースされてました

  • EmpireCraft

開発GitHub:https://github.com/starlis/empirecraft
対応バージョンはver1.9～ver1.16.2、Empire Minecraft Serverと呼ばれるサーバで使われているサーバでPaperから派生したみたい。幾つかの変更とSponge等への最適化が行われているっぽい
2022/02/05追記:PaperのLog4jの脆弱性対策を取り込んでいるので、Log4j脆弱性されていることを確認

 

  • Tuinity

開発GitHub:https://github.com/Spottedleaf/Tuinity
配布先:https://ci.codemc.io/job/Spottedleaf/job/Tuinity/
対応バージョンはver1.13.2～ver1.15.2、より多くなプレイヤーでもパフォーマンスが出るように上のPaperからフォークされたサーバ
2022/02/05追記:開発リポジトリがアーカイブ状態になっており開発が終了した模様

 

  • Origami

開発GitHub:https://github.com/Minebench/Origami
配布先:https://ci.minebench.de/job/Origami/
対応バージョンはver1.14～ver1.16、Minebenchと呼ばれるサーバで使われているサーバPaperのフォークサーバ、Tuinityの最適化パッチやコードが含まれている

  • Haricot

開発GitHub:https://github.com/kezz/Haricot
対応バージョンは不明で自力ビルドが必要っぽい、Beancraftと呼ばれるサーバで使われているサーバでPaperから派生したサーバ。Origamiのパッチが組み込まれていて、Paperへのアップストリームも行わている

  • Airplane

公式サイト:https://airplane.gg/
開発GitHub:https://github.com/TECHNOVE/Airplane
配布先:https://dl.airplane.gg
対応バージョンはv1.17.1、TuinityをアップストリームとしてるからTuinityと同じかも？Tuinityをフォークしてパフォーマンスの最適化が行われており、大量のプレイヤーやエンティティ、チャンクロードがある前提の大規模なサーバ向けのチューニングがされているみたい
2022/02/05追記:対応Minecraftバージョンを追記、頻繁にアップストリームへの追従があることからLog4j対策もされていると思われる。

 

  • Purpur

公式サイト:https://purpur.pl3x.net
開発GitHub:https://github.com/pl3xgaming/Purpur
配布先:https://purpur.pl3x.net/downloads/
対応バージョンはver1.14～ver1.18.1、Tuinityに存在しているPaperの最適化オプション以外にさらにユニークなオプションを追加して、より様々なゲーム体験を可能にしたTuinityのフォークサーバ
2022/02/05追記:PaperのLog4jの脆弱性対策を取り込んでいるので、Log4j脆弱性されていることを確認

 

  • Yatopia

公式サイト:https://yatopiamc.org
開発GitHub:https://github.com/YatopiaMC/Yatopia
配布先:https://yatopiamc.org/download.html
対応バージョンはver1.16.5、Tuinityのフォークで上に書いてあるAirplane、Akarin、EmpireCraft、Origami、Purpurに加え、FabricのMODであるLithiumとKryptonの最適化パッチやコードを加えたぼくのかんがえた最強のサーバみたいなやつ。色々な最適化パッチやコードを加えているせいかバグが多め？
2022/02/05追記:開発リポジトリがアーカイブ状態になっており開発が終了した模様

 

  • Ilblu

開発GitHub:https://github.com/Paul1365972/Ilblu
配布先:https://ci.codemc.io/job/Paul1365972/job/Ilblu/lastSuccessfulBuild
対応バージョンは不明でビルドサイトも落ちてて自力ビルドが必要っぽい、全てのプラグインが動作することを目標に作られたサーバー。上のYatopiaの最適化パッチとコードを組み合わせてる見たい

  • Ibento

開発GitHub:https://github.com/Paul1365972/Ibento
対応バージョンは不明で自力ビルドが必要っぽい、Ilbluになるべく全てのサーバのパッチを組み合わせることを目標に作られたサーバー


3.BukkitForgeサーバー系列
Forge環境でBukkitプラグインを動かしたいって人もいなくはないと思う、そうに違いない
一部ツールが使えないとかプラグインが微妙に動かないなどあるけど一部がSpigotになっている強力なサーバーなので使いみちは十分、また1.7.10で動くCraftBukkitのサーバーはこれを使わないとダメ
ForgeBukkitもCauldronも配布が終わっててすべて後継開発のものの紹介となります

  • KCauldron

SourceForge:https://sourceforge.net/projects/kcauldron/
対応verは1.7.10、Cauldronの後継開発のサーバー。以外にThrmosの公式より少しだけメンテされてたみたいです。Spigotのプラグインは使えないみたい
2019/04/16:リンクを更新

  • Uranium

開発GitHub:https://github.com/UraniumMC/Uranium
対応verは1.7.10、KCauldronから沢山のバグ修正とパフォーマンスの最適化を行ったサーバー。去年までメンテナンスがされていたみたいですが現在はダウンロードサーバーが落ちている始末。だが可動しているサーバーもあるためビルドさえすれば動くのかな？
2019/04/17:ダウンロードURLも開発も復活して、きちんと動作するみたいです

  • Thrmos

公式サイト:https://cyberdynecc.github.io/Thermos/
開発GitHub:https://github.com/CyberdyneCC/Thermos
対応verは1.7.10、KCauldronからパフォーマンスの最適化とバグ修正、そしてSpigotのAPIを組み込んだサーバー。2年間更新がなくメンテもされていませんが私のGTNHサーバーでバグも少なく安定して稼働しています(パフォーマンスも十分)
プラグインも大抵のものが使えるのとビルドしなくていいのがとても嬉しい

  • Thrmos非公式版(その1)

公式サイト:https://mcimaginarium.github.io/Thermos/
開発GitHub:https://github.com/MCImaginarium/Thermos 
対応verは1.7.10、上のThrmosをフォークしてバグ修正とある程度最新版まで対応させたサーバー。まだ開発が続いているみたい
2020/05/10追記：URLを変更。なんか最近になってからURLが変わって復活、そしてバグ修正とリリースが来てた

  • Thrmos非公式版(その2)

開発GitHub:https://github.com/Timardo/Thermos
DL先:https://github.com/Timardo/Thermos/releases
対応verは1.7.10、上のThrmosをフォークしてバグ修正をしたサーバー。まだ開発が続いている？一応今年中にアルファリリースが一回あった模様

  • Contigo

開発GitHub:https://github.com/djoveryde/Contigo
DL先:https://github.com/djoveryde/Contigo/releases
対応verは1.7.10、上のThrmosをフォークしてバグ修正と最適化をしたサーバー。すべてのMODを動かす事を目標とし、去年まで開発が続いていた模様。もうメンテナンスはされてないみたい
サーバー自体はきちんと動く(私のフォールバックサーバーの一つとして稼働中)

開発GitHub:https://github.com/djoveryde/Phoenix
対応verは1.7.10、ver1.10～1.12、上のContigoの製作者が作っているサーバー目的はContigoと同じだけどこちらも更新は止まっている模様
ビルドしたら動くのかな？

  • Kettle

開発GitHab:https://github.com/KettleFoundation/Kettle
DL先:https://github.com/KettleFoundation/Kettle/releases
対応verは1.12(ver1.7.10版はあるみたいだけどリポジトリがアーカイブになっている)、上のContigoをフォークして作られたサーバー。ContigoにPaperのパッチなどを当てているためパフォーマンス向上も果している模様。2019/2/22に新しくリリースされたばかりのサーバー

2021/12/10更新:Kettleの開発がKettleRedに移行ただし、何もリリースされてない

 

  • CatServer

開発GitHab:https://github.com/Luohuayu/CatServer
対応verはver1.12.2、ForgeとSpigotを融合させたパワフルで新しいサーバーを目指して開発が行われているみたい
2021/12/10更新:log4jの脆弱性修正リリースがされていました

 

  • Svarka

開発GitLab:https://gitlab.com/SantaGitHub/Svarka
対応verは1.10.2、まだ開発色が色濃く残るサーバー。特徴とかなーんにも書いてない

開発GitLab:https://gitlab.com/AtomMC/Atom
対応verは1.12.2、高性能かつBukkitとForgeが安定して動作するサーバーを目指して開発が進められてる。ビルドも必要ないから楽に使えるのもよし
2020/05/10追記:Atomの開発が終了？、リポジトリがアーカイブ状態になってた

開発GitHub:https://github.com/josephworks/AtomMC
対応verは1.12.2、Atomフォークのサーバで色々と更新中みたい

  • Mohist

公式サイト:https://mohistmc.com/

開発GitHub:https://github.com/MohistMC/Mohist

対応verは1.12.2、1.16.5、1.17、1.18.x、(最近では1.7.10の開発も)、AtomをベースにPaperのパッチを当てた中国生まれの高性能サーバー。Kettleと同じくPaperのパッチがあたっているが安定しているAtomをベースにしているのでこっちのほうが性能が高いかもしれない
2021/02/19追記:1.7.10系列で開発がされていた(内部的にはUraniumのForkみたい？)、Thrmos系列で開発が続いているサーバの一つに。コミュニティも大きくなってて、サーバには日本語も内蔵さている模様
2021/12/10更新:Mohitの公式URLが変わっていたので更新、1.12.2以降全てのバージョンでlog4jに関する修正もあり

 

 

  • Crucible

開発GitHub:https://github.com/CrucibleMC/Crucible
対応verは1.7.10のみ、まだまだ開発が続いていてコミュニティ活動もあるサーバ。Thermosからパフォーマンスやバグ修正に加え、Paperにも内蔵されているTimingsV2も実装されている。更に同オーガナイゼーションではGrimoire-Mixinsと呼ばれるMODが配布されており、それを使用することで一部のMODのバグ修正等を行える
2022/02/05追記:Log4jの脆弱性対策のパッチが当てられたバージョンがリリースされていることを確認

 

  • Magma

公式サイト:https://magmafoundation.org/
開発GitHub:https://github.com/magmafoundation/Magma
対応verは1.12.2、1.15.x、1.16.x、Paperのパッチをほぼ全て適用したForgeModが動くハイブリッドサーバー、まだ正式リリースはされておらず開発バージョンのみ、SpigotのプラグインだけではなくPaperのプラグインも動く模様
2022/02/05追記:Log4jの脆弱性対策のパッチが当てられたバージョンがリリースされていることを確認

 

  • Arclight

開発GitHub:https://github.com/IzzelAliz/Arclight

対応verは1.14.x、1.15.x、1.16.x、1.18.x。ForgeをMixinによって組み込んだSpigotサーバ、配布もビルドもきちんとされているためきちんと動くと思われ
2021/12/10更新:1.16.x及び1.18.xに対してlog4jの脆弱性修正リリースがされていました

 

  • LoliServer

開発GitHab:https://github.com/Loli-Server/LoliServer

対応verはver1.16.5、CatServerの後続開発版らしい、Log4jの対策もされていました



4.まとめ
いろいろなサーバーの種類をまとめたけど用途別に使うなら以下のサーバーを使うのがおすすめかな、1.7.10の最近更新されているようなサーバだとJVMオプションに「-noverify」を追加しないとダメみたい
・Minecraftのサーバーをとりあえず建てたい！！ → Minecraft公式サーバー
・プラグインは使わずに大規模なサーバーを建てたい！！ → cuberite
・プラグインをいれるサーバー建てたいけどめんどいのは嫌だ！！ → Spigot
・プラグインを最低限だけ入れていろいろとやりたい！！ → Purpur
・いろんなプラグインを使っていろいろとやりたい！！ → Glowstone
・MinecraftのサーバーとWebページを同時に建てたい！！ → Cubed
・プラグイン入れた状態で高速かつ高機能なサーバーを建てたい！！ → Paper
・プラグインを入れてバグっててもいいから超高速な高性能サーバーを！！ → Yatopia
・1.7.10のSpigotサーバーを建てたい！！ → CrucibleもしくはMohist
・1.10.2以降のForgeBukkitサーバー(Spigot)を建てたい → Mohist
・名前に惹かれるようなサーバーを建てたい！！ → Akarin もしくは Phoenix、CatServer、Rainbow、Airplane、ArcLight、LoliServer

それではよきMinecraftライフを

MinecraftのサーバーをWindowsからCentOSに変更したお話(2019/03/22更新:「Mate Desktop」と「Mozc」を追加しました)

Minecraft Minecraftサーバー
9/20のサーバーアップデート「Code:Orion」のときにMinecraftのサーバーをWindowsからCentOSに変更しました、その時の記録を残しておきます参考になれば

2019/03/22:デスクトップを「Mate」に変更したお話とMozcを入れた時の話を追加

  • 変えるメリット
デメリットが微妙に大きいので人によってはないかもしれない。まずはLinuxに変えるメリットデメリットを
・Linuxに変えるメリット
　　サーバー用のOSが無料で使える(一般向けのWindowsだとライセンス的にグレー)
　　コマンドでOSを直接操作程度できる
　　勝手にアップデートして再起動することがない(アホみたいな大型アップデートもない)
　　NTFSを頑張ったら読めるようになる
　　OSの文字コードUTF-8に統一されるのでプラグインのコンフィグに日本語があっても文字コードを気にしなくて良くなる
　　Minecraftのサーバーが落ちても自動で起動できるようなシェルスクリプトを書ける
　　Minecraftのサーバーのログがゲーム内の色と一致する
　　コマンド打っている途中にログに流されない
・デメリット
　　一部ツールが使えない(MCEditとかNBTExplorerとか)
　　エラーとかを解決したりするのに英語の知識がいる
　　一部ツールはビルドやコンパイルが必要になるのでプログラミングの知識が多少いる
　　Google先生と仲良くならないと辛い
Linuxに変えるメリットで一番大きいのは勝手にアップデートしない点とサーバーが落ちたら自動再起動する点が大きいと思う。
次はその中でCentOSを使うメリットデメリットを
・CentOSのメリット
　　10万以上するRedHatLinuxのクローンOSが使える(将来役に立つかも？)
　　ベースがエンタープライズのOSなので圧倒的な安定性
　　サポートも長い
　　高速なファイルシステム「XFS」が使える
・CentOSのデメリット
　　日本語の記事が大抵古い(使えるものもあるけど使えないものもある)
　　Ubuntuで使えてCentOSで使えないものもある(Chromeリモートデスクトップとか)
　　マウスによる複数選択ができない(GUIにもよるかもしれないけど)
実際に使ってみて運用して見てこんな感じです。ほぼ24時間可動させるようなMinecraftサーバーじゃなければ最初はUbuntuあたりから始めたほうがいいかもしれない、両方共サーバー版(サーバー用パッケージ)を入れるとCUIから始まりますが・・・
私は圧倒的な安定性とXFSとサーバーのお勉強のためにCentOSを選びました
次の項目から実際に運用するまでの記録を書いていきます

  • 移行する前の準備
今回のサーバーOS移行の目標は以下のとおりです
・元々可動していたMinecraftのサーバーはそのままでOSをWindowsからCentOSへ移行
・サーバーのパーツを色々と増設する(SSDを2つ追加)
・Minecraftサーバーファイルの階層を変更
移行前のサーバーの状態と移行後のサーバーの状態は以下の通りです
移行前移行後
OS 1Windows10 Home 64BitWindows10 Home 64Bit
OS 2なしCentOS 64Bit
CPUCore i7-5820K(定格)Core i7-5820K(定格)
メモりF4-3200C16Q-16GRK(DDR4-2133動作)F4-3200C16Q-16GRK(DDR4-2133動作)
マザーボードGA-X99-Gaming 7 WIFI(rev. 1.0) BIOSver:F23cGA-X99-Gaming 7 WIFI(rev. 1.0) BIOSver:F23c
SSD 1Samsung 850 Pro 256GBSamsung 850 Pro 256GB
SSD 2なしSamsung 860 Pro 256GB
SSD 3なしIntel 800P 118GB
(冷却:SilverStone M.2 SSD Cooling Kit)
HDD 1WesternDigital Black 3TBWesternDigital Black 3TB
HDD 2HGST 500GBHGST 500GB
MinecraftサーバーThermos ver1614 Build58ALPHA(GTNewHorizons ver2.0.5.1)Thermos ver1614 Build58ALPHA(GTNewHorizons ver2.0.5.1)
プラグインVault
NewHorizonsServerCore
MCBans
PermissionEX
AutoSaveWorld
LunaChat
みんとちゃん
DynmapCBBbridge		Vault
NewHorizonsServerCore
MCBans
PermissionEX
AutoSaveWorld
LunaChat
みんとちゃん
DynmapCBBbridge
なのでそれに伴う準備を行います
1.CentOSのインストーラを用意する(USBで準備しとくと早い)
2.Minecraftサーバーを止める(きちんとした方法で止めること)
3.Windowsで使っていたネットワークの設定をメモる(CentOSの場合、手動でネットワーク設定を行う必要があり自動でやってくれないのでメモりましょう。IPとかも変更する場合は必要ないですが変更したくない場合は必ずメモること)
3.各種プラグインのコンフィグファイル一式をメモ帳で開き文字コードをUTF-8へ変更(あとで変更できますが一部文字列がバグった状態になるのでやっておきましょう)
4.Minecraftのサーバーファイル及び必要なファイルのバックアップを別の外付けドライブなどに取る(Dynmapはファイル数が多いのでマップデータはあとで描画できるため動かさなくていい気がする*1
5.最終確認をしてWindowsを完全シャットダウンする(Shift押しながらシャットダウンする)
次から本格的な移行記録

  • 移行作業記録
1.CentOSを入れる用のSSD(Samsung 860 Pro 256GB)を増設する
2.付け終わったらそれ以外のSSDとHDDが外れていることを確認してCentOSのインストーラを接続しインストーラーを起動
3.CentOSをSamsung 860 Pro 256GBに入れる、今回は最小構成でインストールをする(インストールする際のネットワークの設定に上でメモった設定を入れる)
4.インストールが終わると再起動してパスワードを打ち込んでCentOSのCUI画面になる
5.今回はModサーバーでプラグインやらModやらファイルをごちゃごちゃ弄るのでGUIを入れる(今回は「sudo yum -y groupinstall "Server with GUI"」と打ち込んでServer with GUIをインストール)
6.インストールが終わったら、「sudo systemctl set-default graphical.target」と「systemctl get-default」と入力しgraphical.target に変更する
7.6が終わったら「reboot」で再起動
8.デスクトップ画面が表示され初期設定が始まるので行う
9.初期設定後ターミナルを開き「sudo yum update」でシステムのアップデートを行う
10.9が終わったら「reboot」で再起動
11.再起動後ターミナルで「java-version」と入力
12.11でOpenJDKなら誤動作を防ぐため消す(「sudo yum remove openjdk-8-jdk」と「sudo yum remove openjdk-8-jre」で消えるはず消したあとに一応「java-version」で確認しておく)
13.次にOracleからLinux 64bit版のJDKをダウンロードしてくる
14.ターミナルでダウンロードしたフォルダまで移動し「rpm -ivh <ダウンロードしたファイル名>.rpm」でOracle JDKをインストールする(一応「java-version」で確認しておく)
15.CentOSを一度シャットダウンしてIntel 800P 118GBと外していたHDDをつなげる(HDDだけ)
16.CentOSを立ち上げIntel 800P 118GBをXFS(サーバー本体の保存場所のためXFSで)、WesternDigital Black 3TBをEx4(XFSでも良いがメモリを食うのでEx4で(ホントはZFSが良かったがどうやっても入らなかった))、HGST 500GBをFat32でフルフォーマットをかける(XFSでフォーマットできない場合は一回Ex4でフォーマットを掛けてやればできる)
17.外付けHDDがNTFSなのでNTFSを読めるようにする(「sudo yum install ntfs-3g」でNTFS-3Gをインストール)
18.Intel 800P 118GBにMinecraftサーバー用のフォルダを作り外付けHDDからサーバーファイルをコピーする
19.SSDの容量的にDynmapとバックアップのデータは置けないのでサーバーのフォルダ内でターミナルを開きWesternDigital Black 3TBに実データを持つシンボリックリンクを作る(「ln -s <Dynmapのデータ置き場所> dynmap」と「ln -s <Backupのデータ置き場所> backup」)
20.19が終わったらサーバー起動用のシェルスクリプトを編集する(今回はModpackのサーバーファイルにあったものを編集して再起動時間を30秒後へ、Javaの起動オプションをWindowsと同じにした)
21.シェルスクリプトを実行させMinecraftサーバーを一度起動させる。問題がないかチェックを行う(シェルスクリプトファイルがある端末を開き「bash <シェルスクリプトファイル>.sh」で起動する。起動する際は毎回この作業を行う(めんどくさかったら自動化もできるらいし？))
22.サーバーの問題がなければ一度サーバーを閉じる
23.ファイアーウォールの「25565」番ポート(Minecraftのサーバー通信用)と「8123」番ポート(Dynmapの通信用)の通信を許可する（「sudo firewall-cmd --permanent --add-port=8123/tcp」と「sudo firewall-cmd --permanent --add-port=25565/tcp」を入力しSuccessと出たら「sudo firewall-cmd --reload」と入力、「sudo firewall-cmd --list-all」と入力し25565番と8123番ポートが開いてることを確認する)
24.fstabを編集しIntel 800P 118GBとWesternDigital Black 3TBを自動マウントできるように設定する(「sudo blkid /dev/sda」でディスクのUUID情報をとってきてそこから「sudo vi /etc/fstab」でfstabに書き込む)
25.SSHのデフォルトポートを変更しておく(「sudo vi /etc/ssh/sshd_config」でコンフィグを開き、ポートを好きな番号に変更しておく)
26.CentOS自体を再起動
27.問題なく自動マウントも成功したらサーバー起動で移行作業終了

  • デスクトップを「Mate」、入力を「Mozc」にしてみた
1.まずは「sudo yum install epel-release」でEPELのリポジトリを使えるようにする
2.次に「sudo yum groupinstall "X Window System"」ウィンドウ関連のシステムをインストール
3.次に本体であるMateデスクトップを「sudo yum groupinstall "MATE Desktop"」と入力し入れる
4.インストールが終わったら、「sudo systemctl set-default graphical.target」と入力し、デスクトップが起動するようにする(入力後「systemctl get-default」で「graphical.target」となっていたら成功)
5.「sudo vi ~/.bashrc」と入力し、以下を一番最後に挿入
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
export LANG=ja_JP.UTF-8
ibus-daemon -drx
6.Googleの日本語入力を使用するためiBus-Mozcを以下の順番でコマンドを実行し導入、導入の順番は守らないと動きません
・sudo yum install protobuf
・sudo yum install zinnia
・sudo yum install zinnia-tomoe-ja
・sudo yum install mozc
・sudo yum install ibus-mozc
6ex.これで全角半角がうまくいかない場合、コントロールセンターからキーボードを選択。レイアウトのタブから追加を選択し日本語の日本語(OADG 109A)に変更する
7.これで再起動を行い作業は完了です


*1:Minecraftのサーバーフォルダ)\dynmap\web\tilesの中にあるディメンションごとのフォルダ内にあるct、t、flatが描画データ