複雑な処理となると別だけど規則的に動くだけなら簡単なのだろうね。実際中華BOTの激安のとかは敵の認識とかせずゲーム内BOTに移動を組み合わせるだけとからしいし。それはそうとマッチで使わずとEACがBOTの使用を検知したら問答無用でBANだろうから自己責任でね
通報 ...
複雑な処理となると別だけど規則的に動くだけなら簡単なのだろうね。実際中華BOTの激安のとかは敵の認識とかせずゲーム内BOTに移動を組み合わせるだけとからしいし。それはそうとマッチで使わずとEACがBOTの使用を検知したら問答無用でBANだろうから自己責任でね
上記座標データ使えばTACviewにも使える。要するに戦術的な議論は発散し荒れがちだけど定量的に示すツールは揃ってると伝えたいんだ。BOTが作るのがゴールではなくその先の理念が伝わらなかったな…。または理解できなければ寝てて良いよ。
どこの会社もそうだけどベテランの感覚論と暗黙知が多く定量化は軽視されてる。コンプラ・安全意識の高まりによる煩雑化や少子化による技能伝承不足で問題が顕在化してるからデータ分析/RPA技能はこんな小手先だけでも使える方が社会出てから便利だぞ。良かったら上葉も夏休み使って勉強してくれ。Pythonは商用有償化されたが大企業ならライセンス買ってるし
面白そうな話じゃない。これまでだって、雑談にはマッチ報酬とか性能測定の惑星研究家がいっばいいたし、普通にプレイしてても得られない知見を数多く提供してくれてたよ?夏も冬も関係なしにね。自分の興味がないことならスルーすればよろし。横から失礼。
フラシムのお約束なんでしゃーないんだけど公式機能でjsonでテレメトリ垂れ流ししてるの、そらBOTに利用されるよなと。 本来ならホームコックピットで使うためのものなんだが。
痛い事言ってくれたねぇハ4…。感覚論と暗黙知から定量化へってのは,兵器の発達なんてそこを追求している究極系みたいなもんだよ。標的の大きさを知っている前提で,かつ接眼レンズのメモリとの相対的な大きさで距離を素早く暗算したり三角測量をやって砲の仰俯角を動かし…なんてやってたのがいまやボタン一つで誰でもできちまうんだ。科学の力ってすげぇ!
いかに人がやってるように動かすAI vs AIがコントロールしてることを見抜くAIの争いが始まるw
だよね。今や自動化はメーカーにも浸透してるが、画像処理だレーザー測距だといいつつ誤差がいつも凄い。センサだけでなく誤差解析と統計の上に成り立つと実感するよ。WTはボタンぽちだもんね。json垂れ流しはホームコックピット用なのか…知らんかった。軍の教育に使える様にとかかと思ってたわ。↑葉 つCAPTCHAwww(なお突破される模様)。
完全自動空戦AIはどう頑張ってもフレーム問題を回避できないからまあ無理だろうなとは思う。1対1でのドッグファイトに入った時だけマニュアルでAI操縦に切り替えるみたいな方式なら出来ないことも無いんだろうか
DCSとかX-planeとかメジャーなフラシムには大体ついてるねテレメトリ出力 だからWTでもプロペラRPMに連動する扇風機とか、ゲーム内のジョイスティックの動作をサーボモーターに送ってマウスエイムの動作を再現するジョイスティック模型だとか作れるっちゃ作れる。
一度軌道に乗せてしまえば自動で動くものは便利なんだが軌道に乗せるまでが1年とか2年とか,ノウハウ無ければ5年かかってもできないのよね…。教示とか校正とか難しすぎるのよ…
昔レーダーFCSが消えた時に自作FCS作ろうと思って挫折したからこういう系のツール作るのって割と途方もない労力必要なのはまあ分かる
↑割と先人の知見が見つかるか否か説↑↑そそ例外・手介入が多くて網羅しきれん…。↑↑↑4DXワロタ。↑↑↑↑1v1ならフレーム問題なさそうだけど多v多だし教示が大変だろうなぁ(AI門外漢)
誘導する訳じゃないけど技術的情報をまとめる技術部ページもあるので有意な情報を残したい場合はそちらの利用も参考に
そうだね。割と存在を知ってるかが重要なことが往々にあるから雑談でも周知したかった。(自分もご指摘の技術部板を参考に、テキストハックの応用で遠方からmig-21"S"or"SMT"[フレア有無]判別とかさせてもらってるし)。あれunit.csvをexcelで開くと文字コードが変わってか壊れるのでNotepad++みたいな高機能テキストエディタ使った方が良いのに気づかず悩んでたなぁ。
海戦BOTはプログラムでロックした後、画像認識で左右偏差の補正やってるっぽいが、相手の距離とかで脅威度判定してる節は無いのね。8111情報で動くBOTやチートツール作るのはプログラムの知識相当無いと無理そう
別ゲーですけどユニットネーム系csvはオープンオフィスの表計算ソフトでいじってましたね。同じくexcelだと破壊されちゃうので
↑↑github参考に8111のpythonライブラリ展開。
先人の叡智。情報は多分揃ってるので後は使い方だね(オートエイムBOTは作る必要もないので考えたことないけど)。画像認識も別ライブラリ使えば多分簡単。pythonと先人サマサマよ。作例にないけど、テレメトリ内の各値を参照したければtelem.full_telemetry.get('IAS, km/h')←telemetryの任意のキー名称、で取り出せる。
ライブラリを使わない方法はseleniumで直接url叩く。
マウス入力を再現するライブラリはsendInput。マウス実座標が固定されていたりで他ライブラリは正常動作しない。ただ外部マウス入力でないのはeacにバレるのでeac駆除対象かと(おそらく)。kernelとか深い場所から外部マウス入力を装うとか、botではなくrobotでマウスを直接操作するしかeac回避はないので素人では限界(認識違いあるかも)。
たまに見かける旋回率とかをグラフに落とし込んでるやつ、あれはどうやってつくってるんだろう
すごいのができたなー。わしも作ってみよ。これつまりジョン・ボイドのEMダイアグラムが自動計測できちゃうってことだよね。たしかエレベータ作動角とか流れてたはずだから、エレベータが95%以下になったらブラックアウトしたと見なして、直線飛行してブラックアウト時点の速度を8111に送って再測定みたいなとこまで自動でできちゃう。
全力旋回のみならず、これまでマウス手操作では不安定で計測不可だったSEP=20,10,0,-10,-20等の緩旋回をbot活用し計測可能になった。ただ全自動かというと課題があるかな。①外れ値 (RBマウス操作由来の不安定さで必ず混じる外れ値を取り除く必要がある)②BOTの不安定さ (PIDなので初期値を整えないと発散する)③ ①②を組み込んだプログラム作成が普通に難しい。なのでこれまで通り手動でexcelデータをまとめるのが続くかも。
【↓ご指摘のE-M線図。おっしゃる通りこれが作りたい】
↑↑WTRTI計測後のデータをexcel分析だよ…。計算式のtemplateを張り付ければ結果が出るようにしてるから、基本転記だけすれば良いんだけど、上記①外れ値確認があるから手作業が無くせない…。
外れ値は例えばSEPが20±1を外れると表示させないようにするか、2~3試行回分を重ね書きすればいいかな(自分は業務ではチャンピオンデータに惑わされないように細線で数回分重ね書きしたデータで見る)。PIDについては自分ならZNステップ応答法とかでフィードフォワードで一発走らせて速度ごとのPIDパラメータ取得してから計測する感じかなぁ。あとわりと教科書で書いてないつまづきポイントで"飽和"って現象があるから、Anti-windup補償器を仕込んでおくかPD制御にしちゃうと安定するかもね。
外れ値の発生要因で一番の問題はG-Lockなんだよね。検出自体は搭乗員スタミナをプログラム上でシミュレートすれば解決しそう(搭乗員スタミナは8111範囲外、マウス制御でのエレベータ作動角上限はIAS,機種によって決まってて100%にならない(余談:マウスでも100%を開放するのがトリム旋回)。よって"直接"G-Lockを検出するすべはない)。だけどG-Lock復帰後(またはG-Lock防止後)に再度計測条件復帰する際に初期値次第で制御発散リスク(上記②)と、一瞬でも条件満たす瞬間はデータ記録されてしまうリスク(上記①)とがある。まぁ①はあまり心配してないけど②が設計負荷たけぇわ。
・重ね書きデータ→自分も現状手動でやってる。外れ値確認の基本だよね。研究所の人もやってたし間違いないかと。現状のグラフ外観から外れ値を探す手作業を自動化するのは大分難儀(条件付けが厳しい)だけどそも外れ値がかすむくらい重ね書きすれば影響は小だね(上記「①はあまり心配してない」の意図はコレ)。
・ZNステップ応答→参考になるわ。PID調整こそ現場感覚だもんねw、理屈だった調整方法知れるのはありがたい。臨界感度というように外乱に弱いからマウス制御のピッチヨーロールが複雑に絡む制御に適用すると発散しそうだけど高速応答の術として参考になる。
・FF制御→モデル化しないと発散する(それで会社残件抱え中)
・1発走らせてPIDパラメータ取得→知見を持ってないに尽きる…。想像は出来るが実装にあたって勉強からだわ。でも身につけば絶対役立つ。ただ負荷特性が状態によって変動するので(エレベータ作動時のダンピングとか[マウス特有])網羅しきれねぇんじゃないかな。
・Anti-Windup補償器→入力飽和だね。今回例でいうと、マウスが機体を置き去りに暴れると滅茶苦茶な旋回になるから制限掛けろと。役立ちそうだしつける必要はあるとは思ってたが名前があるのね。
Gロック後の復帰時に発散するのであれば、復帰時初期条件を水平直線飛行にすればよいのではと思ったけど、マウスの狙ってる方向が水平かどうかわからないのか。高度25500m以上に飛ばせば"戦場に戻れ"警告が出て高度25000m水平飛行に戻してくれるっぽいので、高度50000くらいに飛ばす→自動で25000mくらいに戻されるタイミングを高度監視して検知→元々計測したかった高度速度に戻して一定速で飛ばして……って感じになるのかな。
ZNステップ応答法は限界感度法と違って微小入力入れて応答の定常値を見る方法なので、自動で緩い水平旋回しながらマウス入力を100pxだけ上にズラして……というのをイメージしてた。でもたしかにキレイな旋回しててもGと速度で全部特性変わるから、網羅するだけでしんどくて、実際には片翼失速とかラダーだけ旋回ときちんとロールしてから旋回するパターンでグチャグチャになるのか。自分用計測ではマウスジョイスティックでやるかなぁ。どうせマウスジョイスティックでしか飛ばないし。
なるほど…?Excel使ったことないからよくわからんが、とりあえずデータの出し方と入力方法ググってみる。ありがとう
WT技術部のページのWTRTIの項目に一応簡単な説明足しておいたよ。
excelテンプレ
01template***の右側にまとまった列が計算列で、ロギングしたcsvに張り付ければ結果が出るようになってる。ただし列指定が柔軟でないので個人個人で設定要(つまり他の人は使えない)。計算を参考にするか、または結果がACC, TURNとあるので参考にして貰えれば。ただしデータとして不足があるので過去雑談、技術板で相談した通り追加測定を考えてるんだけどね。(そのためのこの木話題のBOT作成)
相談に乗ってもらったDRAGは"setting"の"fm mode/ON"で出現、luaスクリプトの理解等、こちらも進展はあるのだけどまとまってから話すね。
ごちゃごちゃと問題ばかり並べ立てて申し訳ないわ。素人で測定データがどうなるか想像が付かない故なのである程度は半自動(手動あり)でデータ確認してから自動化可否判断となるかな。そのときは(理解間違ってた)ZN応答とか織り込めたらいいな。