クラフターマクロが通信遅延の影響を受けないようにしてほしい

[btk]

例えばの話とはいえ、2000msのレイテンシを許容範囲内とするゲームて、それはリアルタイムに同期しているMMORPGでは絶対に不可能だと思うんだけど。
ターン制のカードバトルとかならまだしも。

＞Wait値が正しくても実行失敗だったらその回はなかったことにして素材を全部返却することでしょう
もうArtistさんに書かれてますけど、そんなチートしてくださいと言わんばかりの設計のがよっぽどありえないっす。技術云々以前に仕様として無理。

逆にいうと、これをチートされないように実装するには送ったマクロ（というか電文）を一つの塊にして、その一つの塊の実行結果をそのままサバ側で処理しクライアントに返すような実装ならできると思います。ただしこの実装にしたら長いマクロでも途中で中断はできなくなりますけどね。

ていうか書いてて思ったけど、これマクロにやらせようとするからだめなんだよなぁ。そもそも上から順に実行するだけのコマンド並べるのにwaitを指定しないといけないっていう設計がナンセンス。

マクロではなく簡易制作のオリジナルカスタマイズとかどうでしょ。クラフタ的にはこっちのほうがあってそう。
好きなように使用するスキルを順に並べて実行。もちろんwaitの指定なんか不要。
カスタマイズした簡易制作とレシピ、材料の情報をまとめてサバ側に伝えてサバで全部処理して結果をクライアントに返す。これならいけるんじゃないかな。

あとはこの機能を運営がよしとする＋処理負荷による費用対効果をどう判断するかですね。
これできたらほとんどBOTと見分けつかなくなりますけどｗ


#寝なきゃいけない時間ほどアイデアがでてくる不思議

[Serabina]

> そんなチートしてくださいと言わんばかりの設計のがよっぽどありえないっす。

確かにその通り。言われてはっと気づきました。すごくまっとうな指摘をありがとうございます。
一括で送るよりは既存プログラムの変更が少ないかと思って書いたのですが、致命的な穴がありましたね。

> waitを指定しないといけないっていう設計がナンセンス。

そうなんですよね。
各行に付けるWaitを廃止して、単にクライアントとサーバー間で同期通信させればいいだけじゃないですか。
お互いに相手の応答を待つだけという極めてシンプルな仕組みで解決できます。
手動より早く実行させたくないのなら、適当な秒数をユーザーではなくプログラムが挿入すれば済むこと。

> 手動で出来ない(連打してたらラグってスキル回しがおかしくなった)のに
> マクロでは出来る(ラグっても必ず書いてあるとおりに動く)
> とかには絶対ならないですね

運営がそう考えている可能性はありますね。
でも、マクロの方が一行失敗したあとの被害は手動より大きくなりがちなので、対策を要望してみる価値はあるかと。

それに、ラグ対策すれば通信環境の差によるユーザー間の不公平も小さくなります。
「高価な素材でマクロを使う方が悪い」と思えるような環境の人もいる一方で、私のようにたましか失敗しないからこそ失敗が許せない
比較的悪くない環境のユーザーもいるわけです。

このスレの反応をみたら、私の場合は比較的良好な通信環境のおかげでマーケット上の
「クラフターvsクラフター」バトルで得ているメリットは小さくないなと思いました。
　（対策を要望する個人的メリットはあんまりないな. . ）

[koga0679]

何か勘違いをされているようなのでコメントさせて頂きます。

マクロ機能っていうのは、クライアントが行うことが出来る機能をマクロとして提供しているに過ぎません。
もちろんwaitコマンド/wait代名詞も含まれます。


サーバーを利用させると言うのに関してですが、いくつかの問題があるかと思います。

一つは、単純に「メモリガ」となる問題
実行された分のマクロを利用できるようにプレイヤーの分だけメモリガ必要になります。
ハウジングの件を見てもサーバーのメモリを増やすのはそう容易いことではありません。
また、最大でマクロは15*60secの実行が可能です。そのため悪意のある人がいることを考えればこれはとてもリスキーなことではないしょうか？

二つに、コネクション制限の問題
同期的通信をという話がありましたので、この例をあげておきます。
同期を行って一定時間ののちに返答を返すという考え方は昔からあります。しかし簡単に実装出来るが故問題があります。
通信を行うに当たっての規格・仕様の上で一度に通信を行える上限というものがあり、先に挙げた方式ではそれを消費および保持し続けるために他のユーザーが通信を行えないなどの問題になります。


あと、失礼ですがラグがどういうものなのかパケットロスがどういうものなのか
一度しっかりとした理解をされた方がスレッドで討論をする上でプラスになるのかなと思います。

[gele]

ラグもなにも、サーバーからコマンド受け取りましたの返信が来てから次のステップにうつるようなwaitコマンド追加で何とかなりそうだけど（返答が帰ってこなければそこで止まる）、機能的にそこまで実装は無理なのかねぇ。
クライアント視点で考えればそこまで難しい機能でも無いですよ。（ただ、あのマクロの機能自体はテキストコマンドを数秒毎に流すだけだから今有るものの修正は大きいんだろうけど）

つーか、技術的な話は別にする必要が無くて、ラグってコマンドが実行されない場合はマクロを止めてくれって要望で十分な気がする。後は開発が考えるでしょう。

[Serabina]

> サーバーを利用させると言うのに関してですが、いくつかの問題があるかと思います。
> 一つは、単純に「メモリガ」となる問題

サーバーに一括送信する方法をもう少し具体的に考えてみるとこうなりますが「メモリガ」になりますかね？

　最大15行をまとめて送る
　サーバー内ではそれを一瞬で処理し、メモリ解放
　クライアントに結果送信
　クライアントでは結果を今まで通り、ゆっくり再生　（この間サーバーはそのクライアントに対してちょっと暇）

> 二つに、コネクション制限の問題

一般例ではなく、ここではマクロを実行する方法について話しているのですけど。

まず、クライアントがログインした時点でセッションを確保済みですが、それすらこの場合は論点として不要です。
マクロをサーバーの応答に同期して実行させるのがどういうことかと、
「サーバーからの応答が来てクライアントが次のコマンドを実行可能になるまで待つ」というだけです。
これでマクロ実行用のコネクションが増えますか？

[koga0679]

> サーバーを利用させると言うのに関してですが、いくつかの問題があるかと思います。
> 一つは、単純に「メモリガ」となる問題

サーバーに一括送信する方法をもう少し具体的に考えてみるとこうなりますが「メモリガ」になりますかね？

　最大15行をまとめて送る
　サーバー内ではそれを一瞬で処理し、メモリ解放
　クライアントに結果送信
　クライアントでは結果を今まで通り、ゆっくり再生　（この間サーバーはちょっと暇）

> 二つに、コネクション制限の問題

一般例ではなく、ここではマクロを実行する方法について話しているのですけど。

まず、クライアントがログインした時点でセッションを確保済みですが、それすらこの場合は論点として不要です。
マクロをサーバーの応答に同期して実行させるのがどういうことかと、
「サーバーからの応答が来てクライアントが次のコマンドを実行可能になるまで待つ」というだけです。
これでマクロ実行用のコネクションが増えますか？

途中で消えてしまったので簡潔に・・・・。

まとめて処理に関しては、再生の間にアクションを意図的に挟んだ際に問題があるのではと思いました。
コネクションは問題にはなりませんが、自分のも含め例外時の処理があるので簡単にはいかないかなと思いました。

あとは同期的に処理を行うのは、結局サーバーでマクロ全体でなくてもマクロであることを保持することが必要だったり、アクション処理時にマクロ実行であったことの通知など色々大変そうですね。

[Serabina]

> 意図的に挟んだ際に問題が

ワンボタン分のマクロが終了するまで別のアクションは受け付けないでもいいのでは。
停止できなきゃイヤだと言う人もいるかもですが。

> あとは同期的に処理を行うのは、結局サーバーで

クライアントの[Wait-実行]となっている部分を、[応答受信-実行]に変更するだけで済むはずですよ。
サーバーの側の変更は不要です。
サーバーは今でもクライアントからのコマンドを待ってから次に進むようにできてますし。

[hasigo]

> 意図的に挟んだ際に問題が

ワンボタン分のマクロが終了するまで別のアクションは受け付けないでもいいのでは。
停止できなきゃイヤだと言う人もいるかもですが。

> あとは同期的に処理を行うのは、結局サーバーで

クライアントの[Wait-実行]となっている部分を、[応答受信-実行]に変更するだけで済むはずですよ。
サーバーの側の変更は不要です。
サーバーは今でもクライアントからのコマンドを待ってから次に進むようにできてますし。

現状のモノを変えるのが難しい場合、<WaitForExit>的なテキストコマンドを一つ追加して貰えば色々解決する気がしますね。
Timeoutは5秒固定とかで、正常に終了した場合は次の行を実行、そうでない場合はマクロを停止。
とかにできればクラフタ系マクロでカナシイ目にあうことはかなり減らせそうですよね。