再現手順で記載した、NetMulticastやTickの処理がドラッグしているクライアントで行われません。
特にNetMulticastはReliableを設定しても処理されていない状況です。
<br/>
こちらに関して、何か設定等で回避して処理されるようにする方法はありますでしょうか？
<br/>
[Attachment Removed]
再現手順
ホスト・クライアント形式のマルチプレイヤーゲームを実装しています。
ウィンドウモードでプレイ中、ウィンドウ上部のタイトルバーをドラッグ中に
NetMulticastやTickを実行しようとします。
[Attachment Removed]
横から失礼いたします。
1.5秒以上応答が無いクライアントに対して Reliable に設定されている NetMulticast がドロップする潜在的な不具合があります。
[Content removed]
こちらを回避するための設定等は存在せず、エンジンコードの該当箇所を削除するか、1.5秒を延長するといったエンジン改造が必要になります。
弊社タイトルでは秒数を延長する事で解決できる事は確認しております。
ご参考になれば幸いです。
[Attachment Removed]
ありがとうございます。
そちらもEpicとしてはどのように対応すれば良いかの回答をお聞きしたいですね。
大本の報告としてはこちらと同じ状況で、この解決をするにはどうしたらよいか？という質問になります。
[Content removed]
[Attachment Removed]
お世話になっております。
Windowsのタイトルバーをドラッグすると、OSがメインスレッドのメッセージポンプを制御します。この間、エンジンのメインループが完全に止まります。
これにより、以下がすべて同時に発生します：
Tickが停止する → ドラッグ中のクライアントでゲームの処理が止まる
NetDriverのTickも停止する → パケットの送受信ができなくなる
ReliableなNetMulticastでも処理されない → 受信側のNetDriverがTickしていないためACKを返せず、Reliableの再送・順序保証の仕組みが機能しない
Reliableを設定しても解決しない理由は、UEのReliable通信は「再送と順序保証」の仕組みであり、受信側のNetDriverがTickしていないとACKを返せないためです。Tickが止まっている状態では、このやり取りが成立しません。
残念ながら、この問題をエンジンの設定で回避することはできません。これはWindowsのOS仕様による制限であり、エンジン側での対応は困難な状況です。
現実的な対処方法
- カスタムデリゲートでTick外の処理を通知する（推奨） FWindowsApplication::ProcessMessageのWM_ENTERSIZEMOVE / WM_EXITSIZEMOVEイベントを利用して、ウィンドウの移動開始・終了をゲーム側に通知するカスタムデリゲートを実装します。Tickの外で動作する処理をここから駆動させることができます 。
- WM_MOVEからTickを手動で呼び出す（非推奨） 技術的には可能ですが、通常のフレームライフサイクルを迂回するため、エンジンの内部状態が壊れるリスクがあります。Epicとしても推奨していません 。
お手数ですが、よろしくお願いします。
[Attachment Removed]
ご回答ありがとうございます。
対処法についても承知いたしました。
どのように対処するかは頂いた回答を含め検討いたします。
[Attachment Removed]