https://linen.dev logo
Powered by
【ゆるぼ】よく壊れるクライアント側のFormationデータの対策
# forum
h
Formationデータは号車の取得や前後車両の判別、先頭車両の状態のチェックなどあらゆることにおいて使われると思いますが、クライアント側のFormationデータはリログや描画範囲外から来た車両の読み込みなど、あらゆる状況においてよく壊れる印象があります。 サーバー側は生きてるけどクライアント側で死んでるケースが多いのですが、クライアント側のFormationデータを修正する方法とか仕組みについて、なにか知っていることがあれば教えていただきたいです。
h
Q. これって「オンラインサーバーのクライアント環境」つまりマルチ鯖でもFormationってしぬ？ それとも、オフラインの内部サーバーで、つまり「シングルで車両を展開したときにしぬ」？ いわゆるオフラインの内部サーバー、シングルだと、チャンクの凍結の関係で、凍結されたチャンクのレール上にある車両エンティティも凍結されるから チャンクの動作がアトランダムに凍結される設定だったり、読み込みが不安定な状態になると、ワールド内のレールエンティティの都合で「Formationに入ってる一部車両のデータが飛ぶ」はありえない？ 教えて有識者
だからってマルチがしなないのはちょっち不思議なんだが、ExtendRenderDistanceみたいに、マルチじゃないと動かせないMODとかあるから おそらくそういう処理の類な気がする
h
現状、症状を確認しているのはシングルプレイですが、仕組み上はシングルプレイでも理論サーバーの上(いわゆるサーバーサイド)で動いているのでマルチでも同様なのではないかなと思ってます。 サーバーサイドではFormationが生きているので車両を動かしたりデータを弄ったりはできるのですが、クライアントサイドで死んでいると(クライアントサイド完結で)編成内の他の車両の情報にアクセスできなくて困ってます。
h
なんとなく言ってる意味がわかってきた、そして悲しいのは意外とこの手の情報は不明だって事だな。。。 有識者プリーズ！！ んー、dataMapとかでFormationの外にデータを格納する仕組みを作って、ワールドにdataMapを保存して、選択的に自列車の他車両からデータを取得する、なんて方法を思いついたけど スマートじゃないし、できればFormationが壊れて欲しくないんだよなあ
そもそもこれをやる場合、Entityの名前とか番号も含めて取得して、~~それ~~→各編成に対して専用に可変名のdataMapを作ってあげなきゃいけないから、なんとなく重くなりそうだし Formationの状態を常に監視したい以上、俺が提案する方式だと、リンク時間を断続的に、１秒ごととかにしないと実用的じゃなさそう Formationエンティティ？に詳しい人いないかな
u
https://fixvx.com/hi03_s/status/1903849638127640938 これ無理やりformationデータ作り直して修正した感じでしたっけ？
h
クライアントで編成データチェック→問題があればdataMapでフラグ送信→サーバー側でチェックしたうえでformation.sendPacket()を実行って感じでやってます(ちゃんと治ってるかはよくわからない)
y
うちはformationが壊れるのは諦めた上で、逆転機を「前」にした瞬間に編成内の全号車のEntityIDを取得してdatamapに記録しておき、各号車のデータにアクセスする時はEntityID経由で呼び出して処理する方式を取っています。 咲島のTACOS自動放送システムなどで比較的安定稼働中。
u
動的処理を諦めて逐次の静的処理に収めた感じか。。。そちらも良いな 理想形としてはひーさんのやり方だな 気持ちよさそう
s
編成情報が破損するのは、クライアントとサーバーでは原因が若干異なります。 サーバー・クライアント双方に共通するものとして、編成情報の初期化に関するバグがあります。 車両が読み込まれた際に編成情報が初期化されるのですが、この際ワールドからエンティティが取得できなければFormationEntryがnullになるよう書かれています。しかしながらエンティティはマイクラの仕様上既に読み込まれたチャンクからしか取得できません。 クライアントであれば車両から離れて再度近づく場合に、サーバーであれば長編成をチャンクローダーがない場所に持って行った際などに編成の一部車両しか読み込まれていない状況が発生しますので、編成情報が破損します。 サーバーのみのものとして、編成情報の保持にentityIdを用いているバグがあります。 entityIdは一貫性が保証されておらず、エンティティが再生成される際(ワールドへの入り直しやサーバーの再起動、チャンクの再読み込みなど)に異なる数字となる可能性が高いです。 先ほど編成情報の読み込みでワールドからエンティティを取得すると書きましたが、entityIdで取得してしまうと正しくないエンティティや存在しないエンティティを読み込もうとしてしまい、結果として編成情報が破損します。
こちらのスクリプトを改変して、dataMapで編成全車両のuniqueIdやentityIdを持つようにし、破損した編成情報を適宜修復するようにしたり、Formationを使用したアクセスを諦め真冬 雪々さんのようにentityIdで車両を取得すれば何とか回避はできますが、データの同期や整合性を維持するための注意が必要だったりで、RTM自体のバグを修正するよりは難易度が高く手間もかなりかかると思います...
u
ありがとうございます として、特に編成がチャンク外へ出ていく／チャンク外からやってくる時（アクティブチャンクから凍結チャンクへ行く／凍結チャンクからアクティブチャンクへ来る）って やっぱりformationデータを動的に参照せず、予め別のdataMapへ逐次書き込みの方が良いんですかね？ ひーさんの無理矢理formation生成も、悪くない案だと俺は勝手に思ってるのですが（formationデータそのものが、限られた特定の要因で壊れてると俺は予想できなかったので）
わかる、しかしここら辺（スクリプト等追加要素を使用した車両機能の拡張開発）って、総統もあんまり触れてくれなさそうだし、kaizPatchの更新で改善されにくい ≒ 開発上触りにくい場所なのかなと思っていて 根治できれば理想ですが、当面の間は対症療法の方が良いのかなと思っています（ざこ） そもそもminecraftというゲームのシステム上、クライアント側の凍結チャンクでバグれば、意図しないプレイヤーをクラッシュさせる可能性もあるしな。。。（RTM上のformationデータが、ワールドに対してもっと堅牢になって、かつワールド状態に対してもっと柔軟になれば良いのだけれど）
**根っこが早く治って欲しいが、根っこがこんがらがってるように見える**ので マルチプレイを遊び方の前提としてるRTMにおいては、当面はスクリプト側で「formationは便利だけど、壊れやすいオブジェクト」って理解で良いのかなと落ち着いている
それこそjarでパッチを当てたら治せる‼️　なんて領域なら良いが、たぶんprivateのメソッドだらけだしな。。。
s
> ひーさんの無理矢理formation生成も、悪くない案だと俺は勝手に思ってるのですが サーバー側も割と編成情報が壊れてしまい、そうなるとこのスクリプトでは対応できなくなるのですが、サーバー側の編成情報があまり壊れないような環境や遊び方をしているのであればかなり良い対処法だと私も思っています
KaizPatchX / FixRTMで修正を入れるのであれば、気合で修正ができると思っています(蓋を開けてみないと分かりませんが)
u
俺は怖いので下がります。。。 プルリク待ってます♡
しょうみもとのRTMがスパゲティなところあるからな。。。（ズレた論点😋）
s
普段FixRTMを触っているのでそちらで読んでいるのですが、バグ自体は修正ができそうという感じです スクリプトで頑張るよりそちらのほうが楽かもしれません
u
EntityVehicleBaseあたりのコードをいじる感じですかね？（雑予想）
s
EntityVehicleBase、Formation、FormationEntryあたりをいじることになりそうです
理想的にはFormationでentriesを持たないよう実装を変えたいところですが、スクリプトとの互換的に厳しいので、力業になると思います。
u
良いアイデアだと思います👀 もしfixRTMでご提案なされるのでしたら、いっそダブル実装にしてしまうのはどうでしょう？（言うだけタダ） おそらくentries依存のスクリプトはたくさんあって、formationとかを継承しつつformationA(Advanced)みたいなクラスを建てて、リファクタしたいところだけメソッドの名前も新しく建てちゃうとか
PreviousNext
Powered by