2014/12/2 | 
カテゴリ: BungeeCordを入れてる環境にマイクラ1.8+Forgeを入れたクライアントで繋げると、こんなのが出ちゃいます。BungeeCordのバグらしい？(情報ソース) 今の所の最新版(#1021)でダメです。
BungeeCordはかなり細かくパケットを見てるようなので、ちょっとした違いでログイン不可になりますね。
12/2 訂正：Forgeのバグらしい?ちょっと微妙
|
||||||
|
since 2014/9/21 |
現在サーバに導入しているプラグインが1.8に対応しているか調べてます。タイトルに書いてなかったけど、Spigotなので追記しておきました。動作が○でも、後で不具合が見つかる場合もあるので、参考程度です。 公式で対応有無の記載関わらず、実際に動かしてみた結果です。 起動、動作が×でも対応版有無が○でちゃんと動いたら1.8OK欄は○にしてます。 調査に使用したバージョンは表示してませんが、まぁだいたい最新か、古くても1.7.10サーバで動いている物を利用しています。 とりあえず、2014/11/30時点での調査状況です。 12/02、12/06 赤字の所をちょっと更新 12/14 一応更新しました.この記事の更新はこれで最後にしておきます。なので、記載内容はこの時点での最新情報です. 12/06追記 ChestShopやTNTRunなどの看板の文字を読み取る系のプラグインは、看板文字の内部データが変化してるようで、ソレが原因で動かないみたいです。(今まではどうだったかわからないけど) 看板の文字を読み取って動くプラグインはこの辺を厳密にチェックしているので、これを不正な文字と判断してるようです。だから、ServerSignsみたいに看板系でも看板の文字を読まないプラグインはこの影響を受けないっぽい。 とりあえず、ソースをGetしてChestShopSign.javaのisValidPreparedSign関数の所、看板の内容を一行毎にチェックしているコードがあるので、その辺に以下の内容を加えてリコンパイルすれば動くようです ※改造は自己責任でｗ lines[i] = Pattern.compile(“§r”).matcher(lines[i]).replaceAll(“”); lines[i] = Pattern.compile(“§0”).matcher(lines[i]).replaceAll(“”); 12/06追記その2 ：確認出来ている不具合 二段の高さの花が壊れる(1.8自体の不具合) Alicorn Avalon 起動 動作 対応版有無 1.8OK 備考 AntiCreeper ○ ○ ○ ○ – ○ AntiWither ○ ○ ○ ○ – ○ BVotifier – ○ ○ ? – ? Forge+bungeeが動かないので未確認 BlockHat ○ […] SkyBlockの導入が出来ないか検証してみた。 どうしてこうマルチサーバ前提に作られていないのか・・・ ワールド 前提 報償 他ワールドと インベ分割 JoeSkyBlock v1.0.4 自動生成 (自作も可) 有り (必須では無い) 無し 出来る uSkyBlock v.0.9.6 自動生成 無し 有り 出来ない Mini-SkyBlock v0.2 今居るワールドに作る 無し 有り 出来ない askyblock V2.5 自動生成 無し 有り 出来ない IslandWorld v4.5 事前に生成 有り 有り 出来ない
Joe's SkyBlock 非常にシンプル。報償は無いが、SkyBlockへの参加・戻り時のインベントリの棲み分けがちゃんと出来てる。 flyやEnderChestの使用禁止、土地の保護も出来てる。 死んだときにSkyBlockと非SkyBlockのインベントリが逆転してしまうバグがあるのが致命的。 uSkyBlock SkyBlock […] プラグイン：Residence_v2.6.6.6.jar サーバ：spigot-1.7.10-R0.1-SNAPSHOT_1641.jar ResidenceはTownyのような町作り系のプラグインですが、Townyよりシンプルかな。結局使わなかったので、簡単にご紹介だけ。 使い勝手的にはWorldGuard(region)の逆という感じ。 どういうことかというと、regionは保護されてない土地に対して範囲を指定して保護するプラグインだけど、Residenceは保護されている土地に対して自分が使いたい土地を範囲で取得する感じです。なので、regionとTownyのいいところを両方持ち合わせている感じですね。 regionと同じ感じで細かく範囲を指定できる(Townyはチャンクだけ。Residenceはチャンクを範囲で指定もできるし、特定の立方体範囲もできる) しかも、WorldEditCUIにも対応してるみたい。 初期状態でワールドでの建築を拒否にしておけば、事実上荒らしの被害を受けない。（許可しない限り他者に建築を許可しないし、範囲を指定しないと自分自身も建築できないから）。この辺はTownyのメリットと同じ。 シンプルさではTownyよりも使い易いんだけど、必ず初めに範囲指定しないと建築できない煩わしさはTownyと同じで、管理者としては気にしなければならないポイントですね。デフォルトでワールド建築許可にしたらregionと何も変わらないし。 regionよりも安全に、且つTownyほど複雑にしたくないなら、間違えなくこれを選択した方がいいです。 
∧＿∧ （ ´∀｀）＜ ぬるぽ （ ・∀・） | | ｶﾞｯ と ） | | Ｙ /ノ 人 / ） < >__Λ∩ ＿/し’ ／／. Ｖ｀Д´）/ （＿フ彡 / マイクラサーバを運用する上で欠かせないのがプラグインやModだと思いますが、旨く動かないことも多いので、これらとどう付き合って行くかがマイクラサーバ運用の肝の一つだと思います。 本当はプラグインのソースまで読めればベストなのですが、さすがにそこまでは厳しいという人も多いと思いますので、エラーメッセージの読み方についてつぶやいてみます。 とても難しい内容だと思ってますが、サーバの管理をするなら避けては通れない道だと思うので、がんばって理解してみて下さい。 Javaとマイクラ まず、マイクラサーバの仕組みを紐解いてみます。マイクラサーバはJavaで動いてます。なので、Javaとマイクラサーバがどのように関連しているかを知ることが大切です。 ※このイメージが出来てないと、エラーログの意味がわからないので。 JavaはSun マイクロシステムズが・・・そんなことはどうでもいいや。一言でJavaと言いますが、プログラム言語、実行環境、開発キットを示す場合があります。なので、言葉の意味について整理してみましょう。 Java言語・・・プログラムを開発する為のプログラム言語。 Java実行環境(Java Runtime Environment/JRE) Java開発キット(Java Development Kit/JDK) なにそれ？って感じですが、プログラム言語については多くを語る必要は無いと思うので割愛します。 JDKに当たる物は別にJava特有では無く、Java以外の言語にもあるので珍しい物ではありません。要するにプログラム開発者向けのパッケージです。ただ、Javaの場合、開発者だけでなく使用者へ求められる場合も希にあります。JDKには(たしか)JREも含まれてるので、JDKがあればJREは不要だったはずです。（おぼろげ） 重要なのはJREです。 マイクラを代表とするJavaプログラムは、Windowsだけでなく、Unix/LinuxやMacでも動きます。本来これはOSの仕事でありつつも非常に難しいことで、Windowsが登場する以前は、ハードウェア毎にソフトウェアが売ってたくらい難しいことです（例えばNECパソコン用のゲームとか） OSが進化することで、このようなハードウェアの違いをOSが緩和してくれてますが、やはりWindows専用ソフト、Mac専用ソフトが登場しています。 Javaは、そういったOSの違いを緩和してくれることを主軸に作られたプログラム言語なんですが、そのOSの違いを緩和する仕組みとしてJVM(Java仮想マシン)というのが存在してます。そういうJavaプログラムを実行する環境がJREです。 だからそれが何か？と思われるので、マイクラなどを含めたJavaプログラムの実行環境を絵面にするとこんな感じになる訳です。 JDKはJREなどを含めた開発者向け便利ツールで、本来的には実行そのものに影響する物では無いので、ここでは省略します。 前述で、OSはハードウェアの違いを無くし、JavaはOSの違いを無くすと書きましたが、要するに、プログラムとハードウェアの間に立ってお互いの翻訳してるだけです。これと同様に、マイクラサーバにはプラグインを導入できませんが、これはBukkitやSpigotが間に立ってやり取りをしてくれているからなんです。 JREが重要というより、この構造が後述でもとても重要な意味を持ってくるので、ざっくり理解しておいて下さい。 そもそもエラーって何？ […] 滅多に書かない鯖管のつぶやき二回目です。 今回はマイクラサーバを建てる上でのハードウエアをどう考えるかについてつぶやいてみようと思います。 お金がジャブジャブにあればお金を掛けてリッチなサーバを建てればいいんですが、そうも行きません。限られたお金を使って必要最低限のリソース（CPU、メモリ、ディスク、電気、etc…）を買う必要があります。 ってことで、マイクラサーバを建てる場合の考え方を書いてみようと思います。 […] マインクラフトをマルチサーバ運営する方法について語ってみたいと思います。 マルチサーバと言っても、マルチワールドやマルチができるサーバのことではありません。マインクラフトサーバ(bukkitやspigotなども同様)を複数起動して運営することです。単一の物理サーバに複数のマインクラフトを立ち上げる事もあるし、物理サーバを分けて運営することもできます。物理サーバを分けた場合は、データ連係をどうするかが多少面倒になりますね。 そもそもなんでマルチサーバ運営を考える必要があるのか？ 負荷分散。PvPサーバ運営者が気にする点かな。 複数管理者連携。 バニラサーバとModサーバ運用←私はこれ その他（ログイン人数を合算させたりなど、見た目上一つにしたいとか） ちなみにかなり面倒なので、心して掛かった方がいいです。 以下、考えなければならないことと、実現方法です。 ベースシステム サーバを束ねるには、親となるシステムを構築する必要があります。マインクラフトクライアントからはそこにログインし、そこから適切なサーバへ振り分けられます。 マインクラフトサーバ bukkit…プラグインが豊富なサーバ。広く使われてるので情報が多く扱いやすい。 spigot…bukkit互換の軽量サーバ。後述のcauldron、BungeeCordとの親和性が高い。 forge…Modサーバを作るためのフレームワーク。Modの前提となっている場合が多い。また、クライアント側にもModが必要となるので、参加者側のハードルが上がる。当然、bukkitプラグインなどは使えない。 cauldron…spigot＋forge。以前はMCPCという名称だった。 マルチサーバ管理 BungeeCord…複数のマイクラサーバを連動させることができる。見た目上はバニラでは無いサーバに見えてしまいますが、ログイン先がバニラならバニラで入れます。サーバ間移動も相手がオフラインだったり、前提Modが必要だったりする場合は移動しないよう制御をしてくれます。 BungeeCordの説明は過去に書いてるのでそっちを見て下さい。 単純に入れればマルチサーバ化できる訳では無く、前提がいろいろあるので注意が必要です。 データ連動 サーバが違うとデータも別扱いです。お金、経験値、アイテムなどです。 ちなみに同じデータファイルを複数のサーバで共有した場合、競合が発生して高い確率でデータが壊れるか、書き込みができなくなります。なので、通常のデータ連係はデータベースを使わなければなりません。 幸いにもbukkit系のプラグインはデータベースに対応しているものが多いので、それを使っていきましょう。データベースの種類はSQLiteかMySQLがほとんどです。 MySQLの方がサーバを建てなければならないなど難易度が高いですが、使い方を覚えてしまえば連携のしやすさはこっちが容易です。 SQLiteはサーバが必要無い為、使用するのは容易ですが、サーバが無い分、マルチサーバからアクセスするのが難しいです。っていうかそもそもどういうやり方がいいのか想像付きません。 私の管理しているサーバでは以下の連動ができることを確認してます。それ以外もできるかもしれませんが、未検証です。 お金 CraftConommyを使ってます。元々Essentialsを使ってましたが、これはDBに対応してませんね。CraftConommyはDBに対応してるし、Essentialsのお金データをインポートできるので楽です(他の経済プラグインも対応してます)。 なお、変換の際にプレイヤー名にハイフンかアンダーバーが使われてると勝手に変換される(どちらかというとEssential側の仕様)ので、注意して下さい。 mcMMO、Jobs これらもDBに対応しており、複数サーバから同時にアクセスできます。私のサーバはJobsを連携してませんが、これはゲーム性の観点でしてないだけで、技術的にはできます。 注意しなければならないのは、例えばTownyの様なプラグインはデータ連係できますが、サーバ間データ連動ができないので問題が起きます。例えばサーバ二カ所でTownyを起動した場合、税金は二重課金されます。さらにお金が連動できていなければ片側のサーバでお金不足になる事もあります。 HarkEyeなども連動できそうですが、怖いのでやってません。 念のため補足しておきますが、DB連動できたとしてもお互いのトランザクション処理がちゃんとできているかは別問題です。上記のレベルであれば今の所問題は起きてません。 機能連携 ゲームでの機能連携ですが、だいたい以下の方法でできます。詳しくは過去のコンテンツを見て下さい。 Dynmap Dynmap-MultiServerを使う事で連動できます。 投票 BVotifierでできます。Votifierと連動もできます。 チャット CloudChatというツールでできます。私は使いたいと思ってますがまだ使ってません。ローマ字変換とか無いので。 サーバ間ゲート TeleportSignsでできます。他にもHomeコマンド連動とかできるのも有るみたい。 運用 マルチサーバを運用する上でいくつか気になることもあると思います。思いつく限り書き連ねてみようと思います。 ロビーとなるサーバは安定させるべき 単体でロビーサーバがあるのがベターですが、Modサーバなど安定しないサーバがある場合、ログインできなかった場合の待避サーバが設定できますので、そこにロビーサーバなどの安定したサーバを指定すべきです。そうすることで一カ所のサーバが死んでもプレイヤーは別のサーバで遊ぶことができます。 BungeeCordの扱いが難しい これが止まるとどのサーバにも入れません。また、管理者コマンドが少ないので、何かあったときに自由がきかないでやむを得ず再起動しなければならなくなる曲面も多いです。 ワールド名は同一にしない。 同じ名前のワールドがあるとおかしな動きをする物があります。特にデフォでworldという名前が使われているので、ここがネックになる場合があります（server.propertiesで変えられます） サーバ同士の連動性 例えばMySQLのDBサーバを建てた場合、マインクラフトサーバを上げたまま、DBサーバを止めてはダメです。ちゃんと、 […] BVotifier_v1.0.7.jar Japan Minecraft Serversなどの外部サイトで投票してもらってそのお返しにアイテムを渡したりできますが、仕組み的にはVotifierなどのプラグインで受信し、その情報をSimpleVoteListenerなどでコマンド化してます。 BungeeCordでマルチサーバ化してる場合は、何もしなければ当然どれか一つのサーバでしか投票を受信できません（サーバ分だけ投票サイトに登録すれば別だけど） それを一回の投票情報を複数のサーバに分散できるのがこのBVotifierです。BVotifierはBungeeCordのプラグインとして動作します。 既にVotifier運用しているなら導入は比較的楽です。何故ならこのプラグインはBVotifier→Votifierという連動をするので、Votifierも必要になるからです。 導入方法も簡単で、BVotifierをBungeeCordとマインクラフトサーバのpluginsディレクトリに置くだけです。Votifier側の設定はいじらないで連動してくれます。(※マインクラフトサーバ側は、Votifier.jarを消して、BVotifier.jarを有効にするが正解かも) ただし、ポート情報はバッティングしてはならないので、適当にずらして下さい。 設定は本当にこれだけ。なお、ログインしてないと投票してるように見えないですが、ログインすれば投票したことがわかります。 Dynmap-MultiServer_0.5.0.jar マルチワールドではなく、マルチサーバです。BungeeCordなどでマルチサーバ運用をする場合、Dynmapも複数に分かれてしまいます。それを束ねて一つのWebサーバにするのがこれです。 これ自体、何かのプラグインではなく、単体のJavaプログラムとして動作します。（BungeeCordと連携する訳でも無いです） 主立った動かし方は以下の通り。 ダウンロードして起動する。エラーで落ちるけど、この際にconfig、log、webディレクトリが作られる。 java -jar Dynmap-MultiServer_0.5.0.jar configをいじる。 各サーバのDynmapをJsonFileClientUpdateComponentで動作させる。 「- class: org.dynmap.InternalClientUpdateComponent」って設定とそれ以降の段落？の設定を全てコメントアウトし、「- class: org.dynmap.JsonFileClientUpdateComponent」って設定項目とそれ以降の段落（もともとコメントアウトされてる）を有効にする。 設定変更後にdynmapをリロードすると反映されるが、この段階でdynmapをブラウザで見れなくなります。 どのサーバのでもいいので、Dynmapの設定ディレクトリ以下のwebディレクトリを、Dynmap-MultiServerのwebディレクトリにコピーする。これは、Dynmap-MultiServer経由でWebを見る際のHTMLやCSSファイルを参照する為だと思います。 なので、webディレクトリ配下のtilesディレクトリ(マップの画像が格納されたものすごくファイルサイズの大きいディレクトリ)のコピーは不要。 Dynmap-MultiServerを起動させる。UNIX系ならコマンドの最後に&を付けてバックグラウンドで起動してあげればいいです。 java -jar Dynmap-MultiServer_0.5.0.jar & config/main.ymlの書きっぷりは以下の様な感じ config/main.yml Webserver: IP: 0.0.0.0 Port: 8123 webDir: web/ Title: Dynmap WorkerThreads: 16 DynMap: – Folder: /mcserver1/plugins/dynmap/web UpdateInterval: 4 – Folder: /mcserver2/plugins/dynmap/web UpdateInterval: 4 気にすべき点はポート番号と「DynMap」以下に各サーバのDynmapディレクトリを書き連ねるというところ。 また、運用する上で気にしなければならない点は以下のところかな。 上記の通り、Dynmap-Multiserverを動かすサーバから各Dynmapのディレクトリが見えないとダメです。1台のサーバにマインクラフトサーバを複数建てるなら全然問題無いですが、サーバそのものを分ける場合は、ファイル共有なり、NFSなりでディレクトリを共有しないとダメです。 Webの画面設定が結構難しいです(設定ファイルが無いので)。webディレクトリをコピーする前に、ある程度設定してしまいましょう。 各Dynmapのバージョンを合わせないとダメです。ちょっと苦労したのは、バニラサーバとModサーバとでバージョンが合わなかったこと。これは各Dynmapの「web/standalone/dynmap_config.json」の中の「coreversion」を見てますので、私はここの数字を変更して起動してます。 Dynmap-Multiserverの起動障害のうち、カレントディレクトリをjarファイルのあるディレクトリにしておかないと起動に失敗することがありました。 Dynmap-Multiserverを起動すると特定のサーバで存在しないワールドデータを見に行って落ちる事象が起きました。どうやって直したかわすれたけど、確かweb/standalone/dynmap_ワールド名.jsonってファイルが影響してた気がする。 JsonFileClientUpdateComponentを有効にした場合によくあるんですが、マップ上のプレイヤーの所在がよくわからなくなることがあります。未だに原因はよくわからないんですけどね。 […] BungeeCard_build#1013 TeleportSigns_v1.3.2 BungeeCardはサーバ間ゲートですね。プラグインではなく、Bukkitやspigotと同様に単体で可動するJavaサーバです。 よく、PvPサーバなどで見かけますが、ロビーサーバやゲームサーバなど一つのサーバ内で納められない場合や、全然別の他サーバとのサーバ間接続に使われますね。絵に描くと以下の様な感じ。 絵面的にはBungeeCardへログインしているように見えますが、入り口としての橋渡しになってるだけで、ログインすると直ぐにロビーサーバへ接続されます。 TeleportSignsは移動用のゲートを看板で実現するプラグインですね。BungeeCardはコマンドでサーバ間を移動するので、それをしやすくするだけのものです。 実現方法や機能制限などを纏めると以下の様な感じ。 BungeeCard自身が独自のポート番号を持つので、同じサーバ上のマイクラサーバが居るなら、その番号とは別にしなければならない。 BungeeCardを経由しなくても各マイクラサーバへのログインは可能(ただしそれは推奨できない。詳しくは次項以降) 1.7の後半のバージョンから、マイクラサーバが個人情報をUUIDで管理するようになったが、BungeeCard経由だとUUIDが変わるので、運用中のサーバにこの機能を追加すると「お初さん」になってしまう。回避するには以下の設定が必要。 ・spigotサーバを使って、設定ファイルspigot.yml内のbungeecordをtrueにする。 ・BungeeCardのconfig.ymlのip_forwardをtrueにする。 各サーバはonline-modeをfalseにしなければならない。(server.propertiesか、起動オプション-o trueを付ける) どこのサーバに居ても外部から見えるサーバ全体のログインプレイヤー数はカウントされる。 MinecraftForgeの入ったクライアントだとログイン時のサーバ一覧にバニラ(V)かどうかの表示がでますが、バニラでは無いという表示になってしまいます。それでもロビーサーバがバニラならバニラで入れるし、そのほかのサーバがModサーバならサーバ間移動の時に遮断されます。 ちなみにspigot.ymlのbungeecordをtrueにすると、BungeeCord経由でなければログインできなくなります。何れにしろonline-modeを切ると管理者アカウントを奪われる危険性があるので、直接ログインはしない運用にするのが吉ですね。 以下、設定方法です。 TeleportSignsを使うなら、BungeeCordのconfig.ymlのpermissionsにあるbungeecord.command.serverはadminに移すべき。看板を使わなくても誰でもテレポートできちゃうっぽいので。 また、以下の様な設定にすると、指定したプレイヤーだけがadmin permissionsに設定されたコマンドが使えますね。 groups: プレイヤー名: – admin config.ymlのlisteners設定の意味は以下の様な感じ。 max_players…最大ログイン数だが、これは表示上だけ。実際には個々のサーバの上限が制限となる。 fallback_server…ロビーサーバが死んでしまっている時に接続するサーバ名。 host…BungeeCord自体の接続設定「0.0.0.0:25555」みたいにすると「25555」ポートで接続可能となる。 default_server…ロビーサーバ motd…マイクラのクライアント側に表示させる紹介文 config.ymlのserversは、接続するサーバ分全て記入する。 サーバ名: address: 192.168.xxx.xxx:25553 ←マイクラサーバのIPとポート restricted: false motd: ‘サーバ説明’ ←サーバの説明。ほとんど表示されることは無い。 ちなみに、config.ymlにもonline_modeの設定がありますね。当然、trueで運用すべき。 ip_forwardについては上に書いた通りです。 […] |
|||||
|
Copyright © 2024 Site-A - All Rights Reserved Powered by WordPress & Atahualpa |
||||||
