艦これ専用ブラウザ【艦これ Received data browser】（略称・KCRDB）及び関連ツールについて話すスレ。
必然的に通信内容や艦これ内部の仕様などの話題が出るため苦手な方はブラウザバック推奨
質問についてはテンプレを一読の上、過去スレまたは当スレのスレ内検索も併せてお願いします
尚、専用ブラウザは自己の判断・責任でご利用下さい
艦これブラウザとか(開発終了)
ttp://hetaregrammer.blog.fc2.com/
前スレ
【悠長化】KCRDB専用スレ13【出荷済み】
ttp://jbbs.shitaraba.net/bbs/read.cgi/netgame/12394/1435653764/
★提督のコメントやランキングのコメントが表示されない
→KCRDBフォルダの『KCRDB_FEATURE_BROWSER_EMULATION.reg』をダブルクリックでレジストリに登録
★タイトルから読み込みでフリーズする、LOADINGが終わらない、カクカクする、やたら猫る
→キャッシュクリアしましょう。併用している他の艦これ専用ソフトやFWの設定等も要確認
★艦これでは中破表示なのに、ツールでは大破と表示している
→仕様。艦これで中破でもKCRDBでは大破表示されることがあります(readme.html大事な事参照)
★KCRDB側の入渠や遠征の残り時間が艦これ本体より数秒ずれている
→仕様。完全に同期するわけではありません。ズレ幅が大きいならwinndowsの時計も確認を(ttp://www.nict.go.jp/JST/JST5.html)
★任務の遂行状況をより詳しく表示して欲しい（ex.あ号の回数表示）
→艦これサーバーが回数ではなく、50％・80％の情報しか送信してこないので実質不可能です
★デフォルトフォントサイズorメイリオフォントが見切れる
→倍率変更オプションがあるので、そこで調整を行って下さい
★グループ編成のタブ名をKCRDB内で変更できるようにして欲しい。
→グループのリストの内部処理の都合によって、現状では対応が難しいです
★ログにerrorやfailedの表示がある
→KCRDBの動作自体に不具合が無ければ基本的に無視して構いません
★資源・遠征経験値等を視覚的にグラフで見やすくして欲しい
→資源の増減や艦娘の育成状況をグラフ化できるツールを有志が作ってくれました。
ttps://github.com/gardejo/js-kancolle-logistics-visualizer
使い方 ttps://github.com/gardejo/js-kancolle-logistics-visualizer/wiki/Home-%28ja%29
設定ファイルを生成するツール ttp://kancolle.s601.xrea.com/kclv/
→有志の方がjsで作ってくれました。（KCRDBのフォルダに保存して実行。〜htmlファイルが作成される⇒ブラウザにドラッグ）
ttps://dl.dropboxusercontent.com/s/6ortcavxtaucgnn/convert_graph.html(遠征経験値は現在動作不可）
★戦記のファイル数が多すぎる。整理したい
→日付順にフォルダを自動作成してXMLを格納してくれるjsを有志の方が作ってくれました
ttps://www.dropbox.com/s/kj0fcr9s1m854wf/auto_classifier.js
★出撃記録をXMLに変換したい
→ ttp://www1.axfc.net/u/3285078?key=Sortie 前スレ68も参照
これらを試した上で動かない、あるいは不具合が起こるなら
不具合が分かる画像・KCRDBのバージョン（設定→Aboutに記載）とOS（32bit or 64bit）など詳細を添えて書き込むと返事があるかもしれません
ttp://matome.naver.jp/odai/2138807124629994001
||￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣||
|| ○荒らしは放置が一番キライ。荒らしは常に誰かの反応を待っています。
|| ○重複スレには誘導リンクを貼って放置。ウザイと思ったらそのまま放置。
|| ○放置された荒らしは煽りや自作自演であなたのレスを誘います。
|| ノセられてレスしたらその時点であなたの負け。
|| ○反撃は荒らしの滋養にして栄養であり最も喜ぶことです。荒らしにエサを
|| 与えないで下さい。 Λ_Λ
|| ○枯死するまで孤独に暴れさせておいて ＼ (ﾟーﾟ*) ｷﾎﾝ。
|| ゴミが溜まったら削除が一番です。 ⊂⊂ |
||＿＿＿ ∧ ∧＿＿∧ ∧＿＿ ∧ ∧＿ |￣￣￣￣|
( ∧ ∧__ ( ∧ ∧__( ∧ ∧ ￣￣￣
〜（＿( ∧ ∧＿ ( ∧ ∧＿ ( ∧ ∧ は〜い、先生。
〜（＿( ,,)〜（＿( ,,)〜（＿( ,,)
〜（＿__ﾉ 〜（＿__ﾉ 〜（＿__ﾉ
■初心者向け
必要なことはだいたい↑のまとめと過去ログに書いてある
書いてなかったら基本的にできないものだと思っていい
■出荷
クッキークリッカーのようなもの
エイプリルフール用に実装されたものでで特に意味はない
■らんらんこれくしょん 出荷用のナニか
MD5=3A720473F6653FE19082D3C17DF42AC5
ttp://www51.atpages.jp/kancollev/kcrdb/kcrdb_eid.php
>>2の「前スレ68」はttp://jbbs.shitaraba.net/bbs/read.cgi/netgame/12394/1405979264/68
ttp://jbbs.shitaraba.net/bbs/read.cgi/netgame/12394/1412253200/7
ttp://jbbs.shitaraba.net/bbs/read.cgi/netgame/12394/1412253200/477+479
今までWebBrowserでクリックイベント取れずにできなかったんだよね
Cursor.Current.Handleが65567でカーソルが普通と違うときのクリックをカウントして、
ドロなしで2回、ありで3回で出すようにしたら今のとこ動いてるけどHandleで指定ってできるのかな…
再起動しても変わらなかったけど自信ないな…
以上チラ裏でした。
うちもWindows8.1だわ
OSのバージョンとかFEATURE_BROWSER_EMULATIONとかで変わってくるのかもね
めんどくせえ…
ソフト消しちまったよちくしょう(´･ω･｀)
これレベルの専ブラあんま知らんからこれからどうすっかなぁ
今回は事前に新システム実装のアナウンス無かったし安定かな？
それともサプライズで何か追加してきたりして
七四式が代替候補だけど少し見づらいのが難点
自分もKCRDBは動くとこまで改造してたけど
ミジンコ過ぎて時間かかりすぎるから
そろそろ七四式に完全に乗換予定
KCRDBはあの機能欲しいとかいじりだすと
ゲームそっちのけになっちゃうのが難点だなｗ
修正個所多すぎて疲れたってのもある
前例からするとAPIの整理なんかはアナウンス無しでいきなりくるからなんとも
今見てきたが確かに代替としてはすごく良さそうやねぇ
修正云々もそうだけど改良でゲーム手付かずだったら本末転倒だしね
一時期離れてたのなら新しいツールのUIにもすぐ慣れるでそ
結局何に乗り換えても不便になるんだよな
第一艦隊プロファイルの戦闘毎の更新の修正途中でわけわかんなくなって投げたから
致命的なのが来てももう直せないかもしれない
2-5式（秋）とか熟練度考慮した制空値とかやりたかったけど俺には無理だった
やってる時間よりKCRDBいじってる時間の方が長くても全く問題ない
80%本気の冗談は置いておくとしても、KCRDBみたいにコンパクトに
情報詰め込める専ブラないから乗り換えとか考えられないわ
それでも軽くてコンパクトに必要な情報を見られるKCRDBから乗り換えることはできない
水上か機動かどっちといっしょなんだろうか、それとも別だろうか
とりあえず調べるか。
プリセット修理が仕様化しそうだから直しておいた。
今回のメンテで修正されると思ってたんだけどね。
にしても、そのままだとEnvironment.TickCountで時間管理してるんだな。
なんでDateTimeにしなかったんだろう。
とりあえずイベント終了までは使えそうな感じだから通知とか色設定とか作りこんだ
ついでにずっと放置してた回復タイミングの計算も修正したった
昔このスレで↓書いてくれた人ありがとう、とても参考になった
46 名前：URL規制は11月4日から@アフィ・ロンダ系転載お断り [sage] 投稿日：2014/11/02(日) 01:48:12 ID:HhiWiHXA0 [1/3] (PC)
明石の修理の時間のずれが気になったので調べたら、気になって仕様まで追ってしまった。
で、以下のようになってるっぽい？
・修理時間：Ttotalは母港に帰った時の時間で20分以上有効、秒切り捨て（1分単位）。
・1当たりの回復時間：T1は入渠ドックの計算と同じ。修復ウインドウのポップアップは0.5秒が切り捨てられてるので注意。
・TtotalがT1のN倍より大きければHPがN回復。等しいときはN-1しか回復しない。
・T1が20分overの時20分で回復〜は知っての通り。
日本語難しいな・・・これで説明できてるだろうか？ｗ
RepairShipInfoForm修正してみたらチェックしてる分には合ってるっぽいけども、合ってるといいな・・・
ソース弄れて、かつ試してみる気の起きる暇人さんどうぞ。
やっぱKCRDBが最高だったんや！
nT1がx分50秒になるケースでn-1しか回復しないケースがあったので
いまではnT1+10で判定してる
無駄になってるケースもあるかもしれなが検証がすげーダルいので、
回復してねぇ！？、よかいいかと諦めて放置
ちゃんと動いてくれてて良かった
ttp://www.dotup.org/uploda/www.dotup.org618784.png
輸送作戦はゲージが数値で表示されるからあんまり意味なかったけどw
まあ、実装間違ってなかった確認にはなったからいいか
輸送護衛部隊も特に問題なく動いてるし、今回のイベントは平和でいいな
あとはツェッペリンと嵐がとっとと出てくれれば・・・
E-5の二段階ゲージとか今後も似たようなの出てきそうだし
甲乙丙選択する前のゲージが9999になるの今回初めて知ったわ
KCRDBのためにプログラミングを始めたけれど
スレの情報がとても充実してるからなんとかなるもんだな
過去ログ含めてとても参考になった
任務6個程度だったらすぐできたのに
連合艦隊はほんと大変だった
あとは装備熟練度やらないとなぁ
連合艦隊対応が出来たなら楽勝だと思う
今後のことを考えて編成プリセット対応したけど意外と面倒だった
int[] array1 = new int[6];
int[] array2 = array1;
みたいなのが出てくるんだけど、これってわざわざarray2作る必要あるのかな
元がCとかC++だとポインタインクリメント用にコピー作ったほうが
ループが早い場合もあるし、その名残かも知れんな。
ShipListViewForm.cs
80行付近と900行付近
this.m_iFilterLvUpper = 150;→155にする
900行付近
GenericDecimalRangeDialog.ShowDialog
(out value, out value2, this, "レベル範囲指定", "表示する艦娘のレベル範囲を指定して下さい.", 0, 1m, 150m, 1m, this.m_iFilterLvLower, this.m_iFilterLvUpper)
の150mの部分を155mにする
…かな、足りてない所あるかも。
また一から覚え直すか
今度はどうやって弄ればいいのかメモ残しとこ
まぁGenericDecimalRangeDialog.ShowDialogのほうは999mとかでも良いんじゃないかとは思うが。
艦隊や入渠ウィンドウにはちゃんと表示されるから、グループを他ツールで補ってれば特に問題は無さそうね
突撃する人は気をつけて
アンインストールで解決したけど
これかな
どもです。
KCRDB.valuesetting.xmlの<QuestCategory>の設定項目を一つ増やせばＯＫでした
ふつーにクエスト窓のコードにハードコーディングしてたわ
KCUtiliry.QuestCategoryToColor
ってのがあったのでそれで参照してる場所を検索したら
KcrdbVisualSetting.csがでてきたのでこのファイルかと気がついた。
api_category8対応を入れてみた
編成プリセットはもっと大変かと思ってたけどship_deckの使い回しで
あっさり出来て拍子抜け。これならもっと早くやっとけばよかった
api_category8対応はxmlいじるだけでもいいけど色設定ダイアログの
任務種別色一覧に出て来ないのが気持ち悪くてソースもいじったわ
なんでここだけハードコーディングなんだろうな
画面もソースもすっきりしたw
報告乙
新ギミックがapi追加してないかどうかだけやな
まあ潰し方が違ったのかエラーが出てしまう。戦況がちゃんと取れてない。
中身は1-6の航空戦( api_req_sortie/airbattle )とほぼ同じだと思う。
E2は知らん。つかE1甲ラスダン硬いし猫祭りだし一旦中断してプログラム修正…
ちょうどいまE2-Iを通過したけど同じ
kcsapi_api_req_sortie_ld_airbattle
だった。
特に問題はなかった。
結局何をどうしたらいいのかさっぱりわからんかった
api_stage_flag2とapi_kouku2にすればなんとか動いている
複製分はif (objAt.ContainsKey("api_stage_flag2"))で括る
まだ悪瑞穂前の航空戦しか確認してない
戦況に出ないから総被ダメとかわからなくならない?
うちはExpandedBattleInfo***ShipElmにAirAttackDamage2を足して
第二航空戦のダメージも表示するようにしたなぁ
今回のはそもそも耐えるだけだから戦況もいらないかもだけどさ
それよりも与ダメなしなのに勝ち負けが出来るのはMVP予測機能に
影響があって頭が痛いんだがw
さてどう修正したものか
影響受けるのは勝敗予測の方か
どちらも被ダメ0だと表示はevenになるけど実際は完全勝利Sか
エラーさえ出なければそれでいいな
大破でても戦術的勝利だった気がする。
轟沈なのかなあ
与えられた結果を受け取るだけのマスだからなぁ
しかし元ソース、任務周りの数字の順番が謎にバラバラだったのは何でだろう。
と、いうか任務5に慣れすぎて6選ばずにやっていけてるw
即更新されるようにするにはどこ弄ったらええんやろか
BETAの21.0.0.204で直るみたいです
実行ファイルなしでプロジェクトのみ
割と変更あったみたいだな
明石タイマーも死んでる
なんだこりゃ
ドラム缶や大発の装備状況も取れない
これは面倒だな
こりゃダメだわ
特になんにもいじってないんだけど
なんじゃこりゃ
演習だけだけどｗ
しばらく使ってるとどこかで取得してきてちゃんと動くようになるｗ
中からapi_slot_itemとapi_kdock取り出してそれぞれのParse_Mainに流す
で起動からおｋかな
戦況が見れない
これはもうだめだな
対応するのがめんどくさければしばらく使ってりゃそのうち読み込むようになる、でいいのかなｗｗ
微妙に不具合はありつつも一応動くKCRDBはさすがだなあと改めて実感する
sortie/battleから取るようにすれば大丈夫そうかな
これなら装備廃棄のメッセージを潰せばとりあえずだましだまし使えるかな
今廃棄したけど正常だったし
sortie/battleのapi_deck_idを使うようにしたらとりあえず
ブラウザ起動直後から問題なくなったな
簡単な修正ですんで良かったわ。情報thx
なるほど出撃から戻ってくると動くわけだわ
装備廃棄してもエラーでなくなってるわ
肝心のその部分だけ抽出する方法がわからなかった
ごめん勘違いで嘘書いてしまった。
DeckIDが入ってるのはRequest.api_req_map/startで
Jsonのmap/startには最初から入ってなかった。
昨日はたまたま取得に失敗してたのか、今日はエラー出てないや
してやるだけでいいのかな
起動して即出撃しても装備破棄しても補給してもちゃんと表示されてるし
>>126
api_dataをGetObjAtして、そこからapi_slot_itemをGetArrayAtして、
_ParseSlotItem_Mainに食わせたらいけるで
api_kdockも同様
_OnAfterSessionComplete_Member〜 →
m_kcmemberdata.Parse〜 →
_Parse〜_Main
ここで従来なら jSONObjElement.GetArrayAt("api_data");ってなってるよね
今回はここでGetArrayAtするまえにGetObjAtしてそのあとGetArrayAt("api_slot_item")すりゃいいってことかな？
そのままGetArrayAt("api_slot_item")ぶち込んだらンなもんねーよって言われたわｗ
やったら怒られるに決まってるだろw
_ParseApiPort_Mainとか_ParseShip3_Mainで似たようなことやってるから見てみ
今回もまたコピペで乗り切ってしまったミジンコであったｗ
とりあえず母港までは正常に動くから満足してしまった感
他の専ブラもちょっと触ってみたんだけど痒いところに手が届かなかったんだよねえ
背景色が変えられなかったり、明石タイマーの艦の個別回復量&次回復までの時間が出なかったりで
ざっと動き見てみたけどデータ全部取れてるっぽいし
まあ他の専ブラで満足出来るならソースいじってまでKCRDBに
しがみつかないよなw
よっぽど大きなapi変更とかが入らない限りコピペ修正でいける
だろうからしがみつき続けるぜ
妙な暗号化さえ来なければ大丈夫だとは思うけど。
>>114 >>126 >>128 >>129 >>130
辺りの情報が特に役に立った。特に感謝。
>>137 のは具体的にどう修正すればいいのか解らなかった。
自分なりのまとめ。
修正箇所は３箇所。
１．「MainForm.cs」の「_FiddlerDelegate_AfterSessionComplete_Main」を修正。
・"api_get_member/" によるif文に「else if ("require_info" == text)」を追加。
・"slot_item" と "kdock" にあった記述を両方コピー。（requestBodyAsStringは１つだけでいい）
２．「KCMemberDataJSONParser.cs」の「_ParseSlotItem_Main」を修正。
・jSONObjElementから"api_data"をJSONObjElement型として取り出し、さらにそこから"api_slot_item"をJSONArrayElement型として取り出す。
３．「KCMemberDataJSONParser.cs」の「_ParseKdock_Main」を修正。
・２とほぼ同じ。
・jSONObjElementから"api_data"をJSONObjElement型として取り出し、さらにそこから"api_kdock"をJSONArrayElement型として取り出す。
何か間違っていたらフォローよろしく。説明下手なのは気にしないでくれると助かる。
「MainForm.cs」の「_DebugLoad」の方も修正した方がいいのかな。
エラー内容「Error : [svdata=/object{api_data}/array]は連想配列型ではありません.」
通信全面的に変更されたら修正できる気がしないし困ったなぁ
定義は_OnAfterSessionComplete_MemberKdockと同じ
_ParseRequireInfo_Mainでapi_dataからapi_slot_itemとapi_kdockを抜き出したらそのまま
this._ParseSlotItem_Mainと_ParseKdock_Mainに丸投げ
>>137がやっちゃだめって言ってるのをまさに手順1でやっているように見える
_ParseSlotItem_Mainを直すんじゃなくて、_ParseSlotItem_Mainに合う形式にしてからそこに流すんだ
おお、参考にしたらエラー出なくなった。まじ感謝。
フォロー感謝。
その後 _ParseMain で jSONObjElement.Resolve("api_data").Type をチェックして連想配列なら require_info とみなして処理
そうでなければ戦闘終了後に流れてくるslotitemとみなして処理、みたいな頭の悪いことをやった
たぶん真似しちゃいけないやつ
今まで通りの処理
catch
try
失敗してたらrequire_infoを整形して渡す
catch
それでも失敗したらエラー表示
ってした
著作権とかKCRDBの利用規約的に問題無いのかね？
現時点ではまだ著作権法は親告罪だし、更新を止めた作者様が
今更クレームを付けてくることはまず考えられないだろうから
1.MainForm.csでrequire_infoが来たときにハンドリングする関数を
_OnAfterSessionComplete_MemberMapInfo あたりをコピペして作る
2.KCMemberDataJSONParser.csにrequire_infoをパースする関数を
_ParseApiPort_Mainあたりをコピペして作る
(api_dataからapi_slot_itemを抜き出して_ParseSlotItem_Mainに渡して
api_dataからapi_kdockを抜き出して_ParseKdock_Mainに渡す)
たったこれだけじゃね? ほぼコピペで終わりじゃん
>>148
それを言ったらバイナリアップでもなんでもOKになっちまうだろ
そもそも訴えられたら負けることをやってる時点で問題じゃね?
ハイこの話はやめやめ
個人で細々とやる程度にしときましょ
ROM大杉ィ！
俺は連合も改修も熟練も索敵も対応したからもう夢も希望もないw
>>153
あれどんな人が落としたんだろうな
自分でいじれる人は落とす必要ないし、自分でいじれない人は
落としたところで今後の仕様変更に対応出来ない
そもそもちゃんとビルド出来るかどうかすら怪しい
結局自分でいじってるけど取り込める機能がないか興味本位で
落とした人がほとんどなんじゃないかと思ってるw
よくわかんないけど後で入手不可になったら困るし！
ビルドしたもののメンテでKCSniffer部分?がお釈迦になられたのですごすごと元(コピペ対応継ぎ接ぎ版)に戻ったよ
いじれる人に分類していいと思うわ
修正してるうちに機能追加とかも出来るようになるよ
やり方わかんなきゃここで聞けば大抵教えてもらえるし
新任務こなすので精いっぱい
未練たらたらでこのスレに残って様子だけ見てるのが私です
Mijinko Editに6任務対応と新年任務以降の色対策くらいしか施してないミジンコには今回の修正もちょっと・・・
最新のアップデートに対応出来なくても、他の専ブラよりも優れてるドッキング機能があるから離れられないんだよなぁ
一度ページにDMCAや警視庁へのメッセージ載せてgithubからロダまで一掃されたことがあるから
調子に乗ってるとマジで通報されかねん
そもそも作者って時点で行動力がないなんてことはあんまり考えられないからね
最初に色々表示されなくなったりエラー吐いたりするのはデータ形式が変わったからだが、適当に1回出撃すると直るのは何でなんだ？
着任時に送られてくるデータの形式は変わったけど、母港に戻る時のデータ形式は変わってないからそういう動作になる。
そもそもそのレベルのミジンコが今まで使えてたかどうかは疑問だけど
神気取りの奴が対応版何度か配布してたんだっけ
建造艦表示なしとかなんだこれ
全面的に弄らないとダメになったのか
スレにちゃんと目を通す人なら自分で修正出来るようになってるよ
エラーは吐かないからこのまま使うしかないか
ミジンコ的には数学と一緒なんだよね。
わかってる人は自力で対処できて他のわかってる人と答え合わせしてる。
根本がわかってないやつはコピペしてできたつもりになっていても、根本わかってないからちょっとでも変化するとお手上げになっちまう。
それすらしないのかな
書き換えて正常動作したらそれっきり
次に書き換える必要が出てきた時には内容も忘れてる
なるべくコピペで済ませようとするならどんな感じがベストだろうか
情報が変わった艦隊だけを上書きするようにしないといけない
ship_deckの対応手抜きしてる人は、第4艦隊に1隻だけで出撃とかすると
愉快なことになるw
preset_selectはship_deckのapi_deck_dataと同じだから同じ処理で行けるんだろうけど
手抜き見直すしかないか
やれフラグ立てて処理しろ、やれカウントして判断しろだの
新要素だけならそれが表示されなかったりするだけだし
その間に新要素対応するわ
支援艦隊的な扱いならなにもいじらなくて良さそうだけど
内火艇絡みでも何かありそうだけどシステム的には変わらないかな
輸送連合の時と同じようにapiを流用して
それ前回の直してないだけでは…
どうすればいいんだろうな
とりあえず大破進軍防止だけでも機能させたいのだが
今のを改造するか専用のウインドウを作るか
みんなどうやってる?
どうやるかは人それぞれだけど、俺は既存の_ParseDayBattle_Mainとかに
_combinedのパース処理を足し込んだ
水上部隊と機動部隊で情報の順番が違うから注意な
表示は第二艦隊まで一緒に表示したいから新しい窓作ったけど、第二艦隊の
表示いらないならそのままでもいいんじゃない?
第二艦隊の表示なくても大破進軍防止は出来るし
今のを改造、２艦隊分表示できるように拡張、情報も２艦隊分もたせた
結局戦況も含めてやったし、聯合艦隊種別で戦闘順も影響するし
航空戦もあるし結構な手間だった
なんとなく方向性が見えてきた
とりあえず今のをコピーして新しいウインドウにしてやってみるわ
実害はあんまりなさそうだけど
今までなかったものだからパースできてないんだろう
気付かなかったわ
なんやこのボタンくらいにしか思ってなかった
撃沈したはずなのに中破で残ってたり
基地航空隊の与えるダメージが別項目だからしかたない。
戦況の部分修正しないと直らん。
戦闘データにapi_air_base_attackって配列が追加されてて、
その要素のapi_stage3オブジェクトの更に子配列api_edamに敵へのダメージが入ってた。
api_air_base_attackを取得出来るようにすりゃいけるね
単純に処理追加するだけだから楽っちゃ楽
portとかrequire_infoには基地航空隊関連の情報がなくて、
出撃画面でイベント海域を開いた時に呼ばれる api_get_member/base_air_corps でようやく所属情報が得られる。
base_air_corps見る前の状態だと自前で未装備機体を抽出してunsetslotにないものを基地航空隊に所属してる機体と判定するしかなさげ。
KCRDBの戦闘フェイズごとのダメージ表示が欲しいいいい
支援が来たのか航空機が仕事したのか魚雷食らって大破なのか
後から戦闘結果だけ見たってわからんのだよーーー
まあ基地航空隊でフェイズ増えまくってるのとか頭悩ましそうだけど
連合は艦隊の耐久だけ表示してそれ以外は航海日誌拡張版にお任せしてる
HorizontalFormとVerticalFormとDamageDetailFormは
連合艦隊対応にして必要なときだけ表示するようにしてるな
基地航空隊の3隊集中とかまで表示してたらスペースがいくらあっても足りん
6回攻撃したとしても1列で
そうしないととんでもないことになるしなぁ
そして今のコードだと4隊目が追加されるとコード修正せにゃならんw
過去ログだとバイナリいじっての変更しかなかった
すでにいじりまくってるから一致するはずもなくｗ
修正しなくても特に問題ないなあ
ただ豚氏が開発続行を諦めたからミジンコ以下のみんなは他に移行しただけで
起動後数回の戦闘や数回の解体でエラー出るだけで、それ以降全く問題無く使えてるからミジンコでも安心
つぎはぎゾンビ豚化してるからもう何がなにやら
心配した任務も含めて。
一応ブラウザ版でデータを取得した後アンドロイド版から接続したら演習の結果は表示された
泥側に通知を送るシステムを組み込んだら大破警告できるかもね
Error : [svdata=/object{api_data}/object{api_hougeki1}/object{api_si_list}/array[1]/array[0]/"45"]は数値型ではありません.
まぁ追加必要ですよねー・・・・・
それ砲撃戦1巡目の例外なんだぜ
出撃中のみエラーが出るってこと？
うちは演習でもエラーでたよ
データ取り直さなきゃ・・・
api_opening_taisen
とりあえず戦況がらみはこっちか
hougeki1のほうは条件なんだろね
潜水艦以外がいて砲撃戦が発生した場合にでるのかな
api_si_listは普通は数値で来る所が文字できてるのか、forceIntかなにかで解決しないといかんのか。
先制対潜、砲撃戦両方に入ってるんだが、
・先制対潜はそもそも対処してないからスルー（ここを対処しないと戦況のダメージが足りない）
・砲撃戦での爆雷攻撃で文字列の"45"が送られてしまってる場合がある。
（多分先制対潜を行ってる艦の攻撃分）
なお、普通に数値の45が入ってるのもある（先制対潜しない艦の場合）。（1-5ボスで確認）
え？jsonそのものの取得は
設定→ログ2
そうじゃなくてエラーのでる該当の部分っていうなら
1-5で先制対潜艦を１隻いれて砲撃戦でも攻撃するように
調整すればボス戦とかで発生するよ
潜水混じりの編成を相手にしないといけないのかと勘違いしてた
そのとおりだよ。先制対潜のところはダメージしか見ないつもり。
現在の砲撃のところは対策しないとエラーでるから対処するつもりだけど。
Convert.ToInt32とかは文字列45を整数45にするだけだもんなぁ
ミジンコにゃ必要な関数探すのも一苦労だわ
Forceなんだし
req_infoで上の改装で整形すりゃいいのを学んだはずなんだけどなぁ
>260
[JSONArrayElement.cs]で下記ライブラリ追加
using System.Text.RegularExpressions;
GetForceIntAtでString受信したらJSONStrElementに流すelse if追加
その中にRegex.Replace(str,@"\D+","")で数字以外を置換で削除
Convert.ToInt32(str)でString=>Intしたらresultに引渡し
結構強引だと思うけど動いてるから満足
まったくもって理解できぬ
個人レベルならそれでもいいんだろうけどさすがに何百万人とぶら下げてるゲームでそれはなぁ
だって艦これって
本来想定プレイ人数数万人、サービス期間半年で終了する予定だったゲームなんだもの
それが何の間違いか異常なまでの人気コンテンツになってしまい
最初は想定もしていなかった新要素・新システムを元々のシステムの上にてんこ盛りにしてるんだから、
そんなものが綺麗なコードで書かれてるわけが無い
連合艦隊の処理は諦めてるけど基地航空隊の処理を追加した人はこんな面倒なことをしていたのか
基地航空隊の方が数段めんどくさそうだけど
詳細戦況窓に表示追加しようと思ったらいじくり回さないといけないが
開幕対潜も数値文字列の扱い方を変えるだけだからそんなに
大変じゃないと思うけどな
戦況窓への表示の話ね
開幕対潜はエラーを出なくするってだけならそんなに手間はかからない
しかし、ログの保存と表示までやろうとするともう手の付けようがなくなるな
ログは任務やEOの装備を記録するぐらいにしか使ってないからかかる時間に対してのリターンが小さすぎる
mainformに機能が集中しちゃってるのも逆コンパイルの業を感じる
そんな面倒くさいことしなくても、
try-catchしてlong.ParseにString渡して変換の方が簡単だと思う
いくら何でも開発がjsonの型を把握してないってのはまずいんじゃないのか？
GetForceIntAtの中でもfloatの判定やってるよね。
typeにもちろんStrもあるし同様に文字列判定して
文字列そのものを取り出してConvert.toInt32して返せばいいかと
もちろんtry catchで数値じゃない文字が来たときに例外throwしておかないといかんけど。
いままでどうやってのりこえてきたのか。
これでもやっていけるから問題ない
さすがに艦隊ウィンドウや各種情報がまったく表示されなくなったのはミジンコなりにVSいじって対応したけど、VSの触り方もう忘れた
何でこんな葬式ムードなん？
どこをいじればいいのかさっぱりだぜ
今までの修正に比べると全然簡単
やることは>>287
エラー出さなくするだけなら簡単
先制対潜の処理はよくわからん
JSONArrayElement.cs内のGetForceIntAtのところにある↓をコメントアウトすればいいんじゃね
ほかにどんな影響が出るかは不知火
throw new JSONParseException("[" + baseJSONElement.ToElmString() + "]は数値型ではありません.");
それやったらその後の処理でエラー出た
strのままだとどっかで処理出来なくなるっぽいね
まあここまでやったらstr変換しとけって話だけどｗ
これならコピペの範囲内で済むし修正箇所も5行程度
どのファイルのどの部分をどうやって書き換えるかを事細かく教えてクレメンス
return;
って入れるだけでいいと思うよ
先制対潜関連はミジンコには荷が重い
戦況なかったら大破警告もでないと思うけど
KCRDBを使ってる理由とか何が残ってるのか知りたい。
自分好みのウィンドウ配置
後発はどれも条件を満たさなくてなー
魔改造して使ってる人の大半はこんな理由だろう
というか思想がずば抜けて使いやすい
戦況や大破警告は七四式や拡張版なんかの他ツール頼り
グループ、遠征、入渠、建造、第一〜第四艦隊のウィンドウの視認性がKCRDBが一番なんでそこだけ七四式にドッキングして使ってる
手直ししながらKCRDBしか使ってないから知らなかった。
母港演習出撃ではエラーないな
通信方法の更新はランキングのAPIから提督IDが消えただけっぽいのでKCRDBには関係なしかな
よかったよかった
>>287
エラー吐かなくなった感謝
TryParse何それレベルだからすげー時間食ったわフフフ
何故いじってきたのか・・・それはもしバグっても困る人がごく限られているからだろう
これから悪い予感しかしない
俺もTryParse何それレベルだからどこをどう修正したのか教えてもらえると助かる
if文そのままコピペしていじってたけど出来なくて
グーグル先生にelse ifを教えてもらったら行けた
備忘録
text4 = this.m_memberdataRef.Basic.Experience.ToString("#,0");
欧米式の3桁ごとにコンマ入れるのよりも
日本では4桁ごとに入れた方がパッと見わかりやすいよね
一万 1,0000
百万 100,0000
一億 1,0000,0000
戦車と内火艇の資源獲得上昇も表示しようと思って
KcrdbMissionTrophySlotItemRatio.csv に追加しようと思ったんだけど
戦車と内火艇の id がわからん・・・
内火艇が167
であってたかな？
しかしこれ改修値も反映しようとしたら結構ロジックいじらんといかんね
なんであんな面倒くさい計算式にしたんだろ
次回新装備を追加するときは装備図鑑見ればええで
・各サーバ群の整備/補強
・一部ボイスデータの再圧縮/再実装
・一部文字/艦娘表示の修正
・「ラバウル基地サーバ」の大幅増強/拡張
・一部通信方法の更新 #艦これ
嫌な予感
どれくらいの規模で二次配布してんだろう？
だったとしてもまずい気はするが
自分でいじったのが一番使いやすい
ダメージ詳細で敵艦隊へのダメージ欄は追加したけど、
自艦隊へのダメージ欄も追加した方がいいのかな
追加したところで動作確認どうやったら出来るかわからんが
演習で五十鈴相手に潜水艦出しゃいいのかな
道中に夜戦があるときも潜水艦をデコイにしたりするし
史実での潜水艦の運用を考えると潜水艦雷撃支援を作ってほしいわ
漸減作戦
コード修正するか。
演習で1-5周回編成っぽいヤツに潜水艦出すぐらいしかないのか
連合艦隊に基地航空隊に先制対潜と、どんどんダメージ詳細画面がデカくなるぜ
ttp://www.dotup.org/uploda/www.dotup.org970878.png
テスト用にjson書き換えちゃえば？
正規のJSON持ってないと書き換えが正しいか確認できなくね？
と言いつつ自分もまだ対応してないけど、なぜかイベントが始まるといじりたくなる
連合艦隊で先制対潜くらうのはイベントでしか確認出来ないし
ゲームとしては潜水艦がほぼ確実に大破するクソゲーになるけどw
母港エラーなし
マゾだね！
まあゆーちゃんあたりにデコイやってもらうのがいいかｗ
あとは連合艦隊での確認か・・・いつ出来るんだろうなw
基本演習は戦況の損害率が2.5倍以上か否かしか見てないからなぁ
これは戦況改修しないと不便か・・・
大破防止窓が出ない可能性があるからねぇ
連合艦隊対応してる人なら第三砲撃戦追加したときと同じことを
やるだけだから簡単だしね
そういえば戦況窓に航空戦の勝利判定ロジック入れてなかったわ
夏イベ速攻で終わりそうだし入れとくか
戦艦と正規空母だけで構成されてる艦隊に潜水艦隊をぶつけて
「ん？どしたオラw なんかやってみ？www」
と底意地悪い遊び方をしたことはあるw
E-5クリアした後にログ取って作ったから全員がターゲットになってるログしかなかったのか
やっぱり実際に色々と試してみないとわからんね
>>366のパターンでまるゆ旗艦＋キラつける潜水艦の最小構成とか
瑞雲積んでそうな航空戦艦やら軽巡が多いときのデコイに１隻とか
良く使う
E-4Kマスの聯合艦隊からの夜戦開始マスの対応がぬけていた。
早急にやらねばｗ
普通の聯合艦隊の夜戦に渡す感じでいけた。
あとやってるのは制空値計算の熟練度・改修値を計算、触接開始率と選択率の表示
何気に第一Pウインドウはいじりがいがあるね
航空戦の対応が甘かったか敵にノーダメージのときの処理が抜けてたか・・・
やっぱ細かいところは色々試さないとなかなか気付かんなぁ
どうりでFw190とか表示されない機体があるわけだ
先制対潜可能駆逐リストと大発搭載可能艦リストが役に立った。
主にcondと大発がどこにあるかを見るためだけど。
連合艦隊の時は無条件に0突っ込まないとダメか・・・
あれ? 第一艦隊に潜水艦置いた場合、先制対潜のターゲットになるんだろうか
だとしたら無条件0はダメだし、どうするかな
どのみち現状ではどんなデータ来るかわかんないからテスト出来ないんだけどさ
今のところdf_listが6:6用になってるからなあ
深海側割り当てが7からだから味方割り当てが足りない
まあ聯合用に専用で割り振ればいいだけといえばそうなんだけどね
そう考えると、現状は無条件0で問題なさそうか
-1だと勝敗予測に影響するしね
まあ、イベントでそんな微妙な勝敗気にする必要ないと思うけどw
見てみたら、敵が5隻のときに夜戦突入するとapi_nowhpsの要素数が
12で来てるんだけど、これって前からそうだったけ?
13に満たないところは-1で埋められてたと思うんだけど
実際、昼戦のデータでは-1で埋められてたし
修正はすぐ終わるけど、なんか気持ち悪いなぁ
"api_nowhps":[-1,57,82,25,67,73,60,274,163,0,0,0],
ちなみに1-1でもログ見てみたけどこっちは13あった
イベント海域だけなのか、連合艦隊だとそうなるのか
E-4Kマスでは敵5隻でもエラー出ないから、Iマスだけの
JSONバグなのかも知れん
こういうの対応に困るよなぁ
とりあえず連合の時だけ１番目に-1のフラグが立っていれば要素数が12でも特例で通すようにするとかかな
"api_nowhps":[-1,24,72,53,13,20,8,48,35,27]
E-1Bマスでも試してみたけどこっちは要素数13だった
どうも連合艦隊の昼戦→夜戦のときだけこうなるみたいね
バグなのか仕様なのかわかんないけど
今までのイベントでもこうだったのかなぁ
全然気付かんかったわ
だってさ
どうせちょっといじるだけやろ
以前修正途中でぶんなげてどこをどういじったかも忘れたから
これはもだめかもわからんね
equiptypeに項目が1つ増えただけかな
MasterSlotItemElmとKCMasterSlotItemDataの三か所の4を5に変えた
扶桑型艦橋だ…
別ツールで代用してるけどデザイン見慣れなさすぎ
感謝感謝m(__)m
api_typeの新項目は一応保持する方がいいんだろうか？
3行いじるだけで終りね
arrayAt.ValidateFixedCount(5);
int[] array = new int[5];
this.m_tiType = new int[]の初期化で-1を1行追加
適当にこうやった
今後もいろいろ項目数が変わるから刎ねておいたんだった
コンパイルしてみたら奇跡的に通ったので直せたわ
助かった
苦戦中ワイ
MasterSlotItemElm
あと>>404のを一応やっておいたが
KCMasterSlotItemDataなんて弄らなかったで
これで行けたわ、ありがとう
いけました
ありです
結構前のメンテですでにそうなってたような
今しがたデイリーの建造と開発の任務やってて
１つ目の開発の後の
１隻目の建造がログから漏れてた。
そのあとの開発３つと建造３隻はちゃんとログ取れてる。
うーん。まあ別に大した影響ないしいいか。
感謝
まぁ問題ないか
助かりました
これでまた戦える
項目数のチェックだけ修正したんじゃダメなのか?
再立ち上げしたから初期の読み込みがされてないだけだったわ
なんでなのかまだ調べてないけど妙だ
進捗のパーセンテージの扱いが変わったのか?
クリアした瞬間のログ残しとかないとわかんね
>>404
>>408
でいけました
毎度皆様感謝です。
ハードコーディングの臭いがする
,{
api_no: 641 (number)
,api_category: 6 (number)
,api_type: 4 (number)
,api_state: 2 (number)
,api_title: 「航空基地設営」事前準備 (string)
,api_detail: 「航空基地設営」の事前準備を開始する。「ドラム缶(輸送用)」を二つ「工廠」で廃棄し、「7.7mm機銃」及び「九六式艦戦」を各二つずつ用意せよ！(任務達成後、用意した必要装備は消滅します) (string)
,api_get_material: [
200
,0
,0
,200
]
,api_bonus_flag: 1 (number)
,api_progress_flag: 1 (number)
,api_invalid_flag: 0 (number)
}
みたいな処理を見たので深く考えるのをやめた
やっぱりそうか…
廃棄は終了してるけどアイテムに存在しているだけで達成にする処理がサーバー側ではできなかったとかそういうのかな
サーバー側で出来ないこと仕様に盛り込むのは危険なのになあ
それをトリガに条件のチェックが出来るけど、『既にある』という状態をチェック
する仕組みがないんだろうねぇ
1回もログアウトせず新任務を全部クリアしたら任務欄10個でも溢れるw
物凄いハードコーディングだから将来的にバグの発生源になりそう
それとも個々に事後の達成チェックの処理もできるようにしたのかな
この程度の変更じゃ動じなくなってるのがアレだけど
とりあえず、連合艦隊での先制対潜の動作確認も出来たし、基地航空隊の
バグも潰せたし、連合艦隊の昼戦→夜戦のJSONバグ(仕様?)対応出来たし、
MVP推測機能の航空戦バグも潰せたし、なかなか有意義なイベントだった
しかし連合艦隊の昼戦→夜戦はバグなのか仕様なのかどっちなんだろうな
_OnAfterSessionComplete_MemberMapInfoってのが見つからない
勉強がてらrequire_infoに対応したいのだが、開始早々つまづいている
右クリックから定義へ移動とか参照の表示とかもできるだろうに
>>146じゃなくて>>149だった
ソリューション全体で検索してるけど、引っかからないんだよなぁ
ハンドラ関数だったらなんでもいいと思うよ引数だけ気をつければ
たとえば_OnAfterSessionComplete_Portとか・・・これはあるよな?w
もういろいろいじりすぎてどれが最初からある関数かわかんねぇわ・・・
…よくわかなんないし重要度低いし面倒で放置したまんまだ
>138,141,142
この辺見れば解決するやろ
ありがとう、そう言ってもらえてスッキリした
>>442
糞ミジンコだから苦労しているんだ、すまん
雑魚にはキツかった。そして無理矢理動かしてる感、というか元のプログラムの安定感をどんどん破壊してるのが・・・。
一部の処理について教えてもらえたら嬉しいんだけど
MainForm内の各apiの処理で使われている
if ('<' != responseBodyAsString2[0])
っていうのは値があれば処理、ってことでいいのかな？
訳分からんこと言ってたらごめん
サーバから送られてきたデータ(ResponseBody)の1文字目が < でなければ処理。
要するに、1文字目に < が来るのはhtmlデータが送られてきた場合で、それは正常なapiデータではないから除外してる。
即レスありがとう
正常なapiデータのみを処理することだったのね
勉強になるわ
自分のペースでやればいいだけマシかと。
ツール作者は大変だろうけど。
マクロ対策みたいなのは割と技術が割かれてる気がするけど他はからっきしやな
入っていても外すというハードコーディングが必要なわけだがw
surfaceでも買っとけ
どれぐらいのスペックがあればいいんだろう
五万はさすがにないと思うからタブレットじゃなくてノートとか2in1にしたほうがいいかな
ttp://pc.watch.impress.co.jp/docs/news/1021465.html
10.1インチで1920x1200出て5万切るし
CPUが若干非力なのとキーボードが独特なのは好き嫌い分かれそうだけど
まあ一番のネックはメーカか
復帰提督か？
どこかの時点の対処が抜けとるんだろうな
昨日まで普通だったウチは今も普通
なお6-5はまだ先になるかな
出撃してたらいつの間にか表示されるようになってたわ
多分昔の修正でどっかを対処し忘れてんだろうけど
キメラ改修だからどこがどうなってんのかこれもうわかんねぇな
半年前のレスにさかのぼればやり取りがある
ありがとう
いつのアプデによるものか分かるだけでも探す手間がだいぶ省けるわ
報酬で探照灯がもらえるだけだから問題ないかと
mapinfoいじりやがったな・・・
ttp://i.imgur.com/5cph1Qc.png
左の縦２つが味方用
両方聯合に備えるべきかなそのほうが放り込むの楽そうだし。
>>481
全く同じタイミングで同じ事やってるヤツいてわろた
間に一段api_map_infoが入っただけっぽいね
速攻修正出来て良かったわ
あと、今まで一回出撃しないとゲージ情報拾えなかったのが
最初から拾えるようになってるね
うちはもういろいろ諦めてこんなんなってる
ttp://www.dotup.org/uploda/www.dotup.org1025156.png
シンプルでいいね！
単にapi_map_infoが1段増えただけかと思ってたけど、
基地航空隊を使えるようにしたらapi_map_infoと同レベルにapi_air_baseが追加された。
なんかデータの持ち方見てると海域ごとに航空隊が配備されるみたいだな。
通常海域の航空隊とイベント海域の航空隊は別部隊になりそう。
要するにイベントで使いたい航空機は通常海域の航空隊から外してやらんとダメってこと。
なんで無意味に一段増やしたんだろと思ったらそういうことか
まあ基地航空隊を表示しないなら読み捨てとけばいいや
しかし、海域毎に航空隊配備しようと思ったら、それだけ分
アイテムが必要ってことか? なんという拝金仕様
機数減少か疲労してる部隊があったらログ表示するようにしとくと便利だと思うよ。
実装そんなに大変じゃなさそうだしやっとくかなぁ
でも基地毎に別管理となると表示領域がえらいことにw
api_req_combined_battle_ec_battle
api_req_combined_battle_ec_midnight_battle
これ
"api_maxhps":
{
-1,
味方本隊6隻分
敵本隊6隻分
}
"api_maxhps_combined":
｛
-1,
味方前衛6隻分(-1が6つ)
敵前衛6隻分
｝
になっとるし
fdam edamも１２ずつ用意されてるから
両方聯合対応のデータ型式だなあ。
秋イベ両方聯合くるかもね
>>488
型式にしておくのがよさそうだｗ
api_active_deck
が追加されててどっちが残ってるかの区別だろうなあ。
当てずっぽうでcombinedの要素が7以上なら敵艦隊の情報として
扱うように実装してたけど、これならいじらずそのまま行けそう
さすがに敵は護衛退避とかないよなw
Parser共通で処理してる場合はValidateFixedCountも外さないといかんね。
しかしまあいい加減６隻の縛りがあちこちに影響を及ぼしていて
統一感がなくなって来てるなあ。
MainForm内でのそれぞれの艦隊へのダメージの割り振りが
めんどくさいなあ。通常、聯合と共有してると特に。
すっぱり別関数にでもしたほうがいいかもしれない。
ttp://i.imgur.com/vKSDdpC.png
敵の第一艦隊が関わる砲撃フェイズを
最初普通に処理したら変な値になった。
敵味方逆のなのかなにかが抜けているのか
まだきっちりダメージが合わないなあ。
api_hougeki2とapi_hougeki3で
df_listが敵味方両方1-6の範囲になってる
そりゃ今の
ReappearanceBattleSequence
だと敵味方が別番号(1-6,7-12)割り振られてる前提だから
正しいfdamとedamの配列にならんわ。
api_at_eflag見てどっちの攻撃か判定する新しい
関数用意せなあかん。
開発引き継いだら死ぬでｗ
護衛同士１巡なぐって本隊同士（最大２巡）なぐるだと
護衛がのこって夜戦に持ち込めないみたいな展開がありそうだし
難しいところ
違法増築を繰り返した雑コラ扶桑艦橋状態になってるなぁ。
そのうち轟沈したイ級から艦載機飛んで来るようなバグが発生したりしてw
結局やったことは
１．UIを>>485から>>504へ増やし 増やした分のラベルの処理を追加
２．KCSortieDayBattleDataのCombined系の追加
m_tiShipKeCombined; //敵随伴の艦種
m_tiShipLvCombined; //レベル
m_ttiESlotCombined; //装備
m_ttiEParamCombined; //パラメータ
m_tiAbStage3CombinedEDam;//基地航空隊の敵へのダメージ
m_tiStage3CombinedEDam;//艦隊航空戦の敵護衛艦隊へのダメージ
private int[] m_tiNowHPsCombined;//敵聯合で要素を増やす
private int[] m_tiMaxHPsCombined;//敵聯合で要素が増やす
OpeneingとRaigekiの各要素を12隻分に拡大
３． ２で拡張した値を取得するように _ParseDayBattle_Main を修正
４．>>505の修正のために
BattleSequenceElmにm_tiAtEflagを追加
砲撃戦のFDamとEDamを計算する KCUtility.ReappearanceBattleSequenceEC を追加実装
５．MainFormの
_OnReceivedSortieDayBattle_Main内で４も使ってbattle_ecの際のダメージの配分処理
６．MainFormでいつものapiの分岐の部分で聯合艦隊処理の下でbattle_ecをチェックして
Parseに専用のフラグを渡す
聯合艦隊を自分で実装できた人ならまあ大丈夫かな。
７．夜戦用のcombined周りの追加とapi_active_deckの処理の追加も必要
だいぶ違う感じになったなー
m_tiShipKeなんかは数を6→12に増やしただけだし、
>>512は通常艦隊戦と連合艦隊戦はパーサ分けてるのかな?
あと>>512の対応だと、支援艦隊や航空戦2回に対応出来ないな
まあ連合艦隊同士の戦闘が実装されたらまたapi変わりそうだけど
パーサは一本。
ShipKeとかShopLvとかはapi側がCombinedで分割してあるからそのまま
Combinedとして拾ってきてる。
そもそもapi側もHPが敵味方混合でCombinedで割ってあるからね。
聯合対応の時点でその型式で取得してしまってるからそのままにした。
まとめるのは
m_addcontext.ExpandedBattleInfo.PlayerShip[]
でやってるし。
あとは砲撃ダメージの展開の時かな。
今回のapiの変更具合から、支援とか航空戦２回も実際に入ってくるまでは
どう実装されるかわからんし、そのときはそのとき。
この形式で出来ないわけじゃない。
まあ今回の変更の一番の肝は>>505だ。
自艦隊は1-6で相手側は1-12だな。
値被ってるのには違いないけど。
俺はKCSortieDayBattleDataで配列が6のやつを全部12にしてパーサの方で
12個データ放り込んでるわ。ValidateFixedCountは7か13なら通すようにして
ShipKeとかStage3なんかはCombinedが別だからオフセット+6して入れてる
api_stage3_combinedを処理しときゃ支援も第2航空戦も対応出来るし
ReappearanceBattleSequenceはapi_at_eflag渡して1だったら護衛艦隊側
それ以外だったら主力艦隊側として処理してるだけだな
関数分けたりはしてない
出来るだけ変更量少なく汎用性も持たせて修正したらこうなった
追加したメンバはapi_at_eflag入れる箱だけかな
あとは全部既存の拡張で済ませたわ
だからもう元には戻せないw
もちろんこっちもそうするんだけど
今回の敵聯合がチャンスなのにその線の修正ががなさそうなのがちょっとね。
これからも違法建築が続く気がする。
api_at_eflagで管理して、支援や第二航空戦はapi_stage3_combinedで実装
するだろうことが手に取るようにわかるしね
こっちもそれを見越して修正入れてるわけだけど
秋イベの連合艦隊apiがどうなってるか楽しみだ
現在砲撃＋雷撃のフェイズが最大４つでおさまってるけど
そこを拡張することになるだろうから
その並びがどうなるかでまた対処せにゃならんので大変だ
水上と機動でもちがうだろうし。
すんごい単純な構造だったんだな
>>512もただのサブルーチンだったしサブルーチンは殆ど大きなクラスには依存してないし
今まで何難しく考えてたんだろ
C#にテンプレートがあったか知らんけど変数が違うだけの処理が全種類分展開されてるだけ
たぶん分割の比じゃないめんどくささ
パーシャルで殆ど貪らなくていいメソッドとして隅においやっとくだけでいいわ
MVCのMの部分にdeckならdeckでデータ単位でメソッド含めて全部追加されてるだけなのかね
MとVとCみたいな縦割りだけじゃなくてMは更にデータ単位で横にぶった切れるんだ
けど大規模なapi修正入るまではこのままでいいわめんどくさそう
MainFOrmに交じってるのは十中八九MVCジェネレータが吐いた後のコード
それを変更しやすいように整理するのはMVCジェネレータ作るのに近い作業
>>529ドッキング含めて占有スペースなんとかしてくれりゃ７４行けるんだがなぁ
文字だけでいい
74式に移れない理由がそこなんだよね…
通常海域で問題なけりゃいい
イベントの時だけ74式使うかなぁ
まだ6-5未対応みたいだが
作業中に画面の隅っこで残り時間が見れればいい程度だと数ドットでもケチりたくなるよね
言ったけどダメだったならともかく
何も言わずにここであれこれ言ってても始まらんぞ
PCの目の前ならいざ知らずタブだとあれはストレス
むしろわざわざ逆コンパイルしていじってまで延命させる理由がある連中のスレなんだからそんなレス無意味
通常の連合艦隊はapi_fraiとかが要素6のままだと処理分け直さないと
いけないから面倒くさいわ
聯合vs聯合はともかく通常の聯合をわざわざ弄ることはないんじゃなかろうか
コスト的にみても。
どうおかしいのか具体的に言って。
>>547
旗艦さえ撃沈してれば2.5未満でもB勝利だし、四捨五入が微妙で実際は2.5に足りてないとかいうケースじゃないの？
どこかの丸め処理がおかしいんだっけ？
プロキシは使ってないし素のIEだと動くんでどうしたらいいのかわからん
再起動したら直ってたわ
どうやらOSか何かがおかしかった模様
お騒がせしました
logみたらfiddlerCoreがエラーはいてたようです
ここの情報が無かったらできなかった
先人たちに感謝
関数によってはほぼ〜_Main呼んでるだけとかエラーの為だけに関数挟んだりしてんだな
エラーに強くするのも大変そうだ
74に移行するとしたらどれくらいの対策が必要なのか見積もってみただけだよ
クラッシュしたときのメモリダンプを取得するかデバッガでアタッチすれば大体特定できる。スタックをたどってローカル変数も確認できるから下手にtry catchしてエラー原因を分かりにくくするのは再現性困難なときに解決に時間がかかる
他のみたいに仕様変更で動いてるフリして誤動作とかしないしスタックトレース吐くから未だに生きてるんだとおもうが
そもそもJSONにちょっと引っかかったくらいで落ちられたんじゃうざいことこの上ない
ちょっと調べてみたけど、一応手動や他のツールでダンプ取れるのね
他人のダンプは期待できなさそうだしKCRDBなんてVS上ならthrowで止まるし別にいいやって感じかな
いじったことのある範囲で覚えてる限りだと豚はfinally多用
Unhandledハンドラ以外のcatchは最後に殆どそのままthrow
エラーも例外も握り潰さないし滅多に流れ変えないから
必ずUnhandledハンドラでスタック記録してるみたいだけどどの辺りが原因わからなくなる要因なんだろうか？
スタックトレースを出力するだけだと例外の発生した場所と種類しか分からないことが多い。例えばindexoutoofrangeでエラーとなって、エラーの場所に複数の発生する可能性が考えられるときとかに判断がつかないじゃん。そういうときにスタックトレースを出力して情報を捨てて終わりというのは再現方法が不明なときに非常に困る。VSでデバッグ実行してるならそれでもいいと思うよ。
いや、どの専ブラが自動的にダンプ出力して利用者が開発者にダンプを
送れるようになってるのか教えて欲しいんだ
それ以前にここの住人は問題が起こればVSで動かすから必要ないんだけど
これまで仕様変更や修正ミスで例外起きても大抵Validateで引っかかってた
次に配列の例外でも大抵内容を一旦変数に入れるとこだな
例外の原因がわからないような長い行なんて見当たらんのだが
未だにKCRDBに追いつけないD級作者のネガキャンか？
即修正版がアップロードされてたような変態的な所業を知らないのかもね
ダンプどころかスタックトレースすら書き込まれなくても
エラーメッセージ自体が正確で最低限の情報を持ってるから可能な芸当だったのかも
豚の主戦場はデバッガが使えないようなカーネルの世界だからな
問題発生でもcatchfinallyでゴミを残さずその後も動き続けられる構造は重要なんだろ
別件で例外処理がひどすぎるプログラムを最近見て
つい反応してしまいました。
KCRDBについてはエアプですが、ときどきROMってます。
以下、長文です。
基本的にチェック処理をきちんとやっていれば問題ないです。
ひどすぎる例外処理ですが、最終的に
try{}catch(Exception e){ MessageBox.Show(e.StackTrase);};
のようにされていて、IndexOutOfRangeExceptionが発生していました。
以下はRelaseビルドの一般的な設定での話です。
シンボルファイル(.pdb)がその場にあるのであれば、
try-catch内の該当行数まで分かります。
（VSでデバッグ実行していても当然分かります。）
シンボルファイルは通常ではユーザーに配布しないので
該当行数は出力されず、あるメソッド内のどこかとしか分かりません。
配列アクセスが二か所以上ある場合はどこなのか特定できません。
（ソースコードを見て可能性を排除していけば絞り込めます。）
シンボルファイルがあることが前提ですが、
ダンプを取得すればWinDbgなどのツールでダンプ取得時点の
実行スレッドごとのコールスタックや変数などが分かります。
（シンボルファイルがなくても.Netならある程度分かります。）
また、ダンプをVisual Studioで開いても確認できます。
（VSをインストールすると.dmpファイルがVSに関連付けられます。）
ですので、想定していない例外を補足してログに出すよりは
ダンプを取得したほうが情報が多く得られます。
もちろん絶対に落ちてはいけないという要求があることもありますが。
ダンプの取得ですが、最近のOSではWindows Error Reportの機能を
使用するのが良いです。（WER ダンプで検索）
WERはレジストリ設定が必要なので、設定してしない状態で発生した場合は
タスクマネージャーでも取れます。（注意点があります）
また、ダンプを取得するWindows APIもあるので自作もできると思います。（やったことはない。）
あと、Windowsのカーネルモードドライバー開発という話であれば
カーネルデバッガーが用意されているのでデバッグできます。
２年以上前の代物を逆コンパイルしてまだ動かせるって時点で
おかしなことはしてないってわかろう
とんだら外部ツールでダンプ取って送ってくださいってユーザーに言ったとこで殆ど送ってこねえよ
それにスレ的にVS動かせて当たり前なのにダンプ取れて何がうれしいんだ？
何故彼はよりにもよって改造以上の芸当をこなせる面子が多いこのスレで偉ぶろうとしているのか
心情的にも特別な専ブラだ
惹かれる
だが実戦ではやはりKCRDBだ
新しい七四式が出た今でも
ワケしり顔がこざかしい理屈でKCRDBを評価する
航海日誌より増えた情報量
大きくなったメモリ使用量
ピュアに専ブラを追求していないと
わらわせるぜ
何も見えてないくせに
その時
その領域を共にした者だけが
KCRDB
この本質を知るんだ
ウーロンだオレ
自分で改造しろよ、手が掛かりは過去ログに沢山あるだろ
ちなソース書きっぱなしなんて時間が無限にありゃ無能で知ったかのマでもいつかはできるけどな
他人のソース読むのはそうは行かない 特に現場では
わざわざReleaseで追っかけるとかやってる人いたのか
printfでログ出力しまくってデバッグした世代の人かな
VSでデバッグ中にコード修正できないんだけどそういうものなの？
修正しようとするとエディットコンテニュのアラートがでて修正できない
さらにブレークポイントで停止しても「ローカル変数または引数が〜」のエラーが出て値参照できない変数が結構ある
これも見れるようにならんかね？
保護例外セキュリティ違反みたいなOSレベルの例外は続行不可で
ダンプするなら他のプロセスかOSに頼るしかない
ファイルオープンやシリアライザの例外は中で既に再スローしたりしてて
そのすぐ外側のcatchで即座にダンプ出力しようとしても既に意味がない
アプリ自身が例外throwの直前にダンプ出力ならいけるかも知れんが
そこに辿り着く時点でエラー検査してる訳だからダンプ取るまでもなく直接の原因はわかってる
ほんとに利用者にダンプ取らせたりそれを利用したりして役に立ってるのかね
標準ツールバーのドロップダウン（コンボボックス）にReleaseって書いてあったりする？
いやDebug選択されてるよ
ちなみに使ってるのはVisual Studio Express 2015です
もう１つ同時にVS立ち上げて簡単なプロジェクト作ってエディットコンティニュできるか確認して
それでできるなら両方のプロジェクトの設定並べて違う項目見つけて試してとしか言えないかな
ありがとう。とりあえずフォーム1個だけの簡単なアプリケーション作ってみたらデバッグ中の変更はできた
んでKCRDBの全てのプロパティを同じにして再度やってみたけど駄目だった
ちなみにこんなメッセージが表示されるのよね
ttp://i.imgur.com/pcnpJyR.png
怪しそうな「コードの最適化」「アンセーフコードの許可」「ネイティブコードのデバッグ〜」「Visual Studio ホスティング〜」などの設定は全てOFFになってる
VisutalStudioは初めて触ったけどあんまり問題を検索しても出てこないねー
.netバージョン同じ？
バージョンは最初2.0になってて最新の4.6に変更してみたりもしたけど現象は変わらないですね
恐らくexpressじゃなくてcommunity多数なのに加えて
みんな問題でてないかエディットコンティニュなんてなくてもみたいの多数かな
うちでもできてるし しらんけどきっとそう
いつもいったん止めてソースいじってリビルドして再実行してるから
別に困ってないし原因も調べてないけど
"エディット コンティニュは、.NET Framework 4.5.1 を対象にする 64 ビット プロジェクトでサポートされています。"
らしいから32bitなKCRDBだとダメってことじゃないかな。
それを処理できるように敵連合を実装したけど、
いっその事今の違法建築ぶっ壊してもっとスッキリした形に再設計して欲しい気もしないでもない。
たくさん残ってたら第二艦隊が夜戦に出てくるのな
どう処理したもんかな
たまたまアンセーフコードで保護例外起きたからダンプ取ってみた
即時プロセス停止にならないリニアアドレスからの読み込みは例外スローになる
（確かマップされてる領域次第で書き込みは即時停止、その時はダンプ取って意味がある？）
そうでなきゃスローされて、誰もcatchで捨てなければ通常はドメイン規定のハンドラ
プライマリスレッドじゃなきゃスレッド用ハンドラまで遡って例外処理が実行される
そこでも捨てられなければいつもの見慣れたぶっ飛んだぞごるぁウィンドウが表示される
ユーザへの窓が出たとこでダンプ取ってみたけど案の定フレームポインタ全部巻き戻されてんよ
これ例外発生の瞬間のダンプ取るのは至難の業だわ
仮にスローの度にダンプ取れてもXMLの例外の度にダンプ吐き出されちゃたまったもんじゃない
問題はなさそう。実装項目的にも変化なさそうだし
BGMが"母港"以外のときにラヂオをクリックするとapiが送られる。"母港"に切り替えるだけだから中身はない。
require_infoが見つからないんだけど、どこに含まれてるの？
api_get_member/の中にif ("require_info" == text)追加してなんやかんやすればええんかな
>138から追ってけば大体判るんじゃない
その箱から必要なもの("slot_item/k_dock"他)を取り出す
取り出したら今までと同じラインに流す
何を書けばいいのよってなら>145,146,149じゃないかね
無事諦めました
ツールスレで上をなかったことにしたい作者か狂信者とか見てると
細かい新機能はともかくKCRDB以上の物は出てこなさそうだな
艦これ自体下火気味だし更に酷いJSON仕様になったら今度こそ辞めれそうな気がする
途中でできないことに気づいてアップアップだったのかもだが
とにかく専ブラのハードル上げるだけ上げて未だに動いてる程だからな
本スレで名前出すとファビョったり埋めたりするのは対応できないだけじゃなくその辺の恨みもありそう
その辺の２番煎じ作者じゃ無理、諦メロン
あっちに行くのは禁止でKCRDB使ってもいないのが出張しておかしなこと連発とか最近ちょっとおかしい
OSの強制停止とキャッチされなかった例外での自律停止の違いもわからないのに
知ったかしてたのってどうせどっちかの作者だよな
煽るとか以前にちょっかいかけといてうざいと言われても長文垂れ流して
挙句の果てに赤っ恥ならイジられて当然だとおもわなくもないが
その辺理解せずに作ってんならそりゃ飛ぶ
きっと一週間後にはやる気満々になってるんだろうな。
今までの連合艦隊フラグを自艦隊連合フラグに読み替えて
新たに敵艦隊連合フラグを追加する形にしたから連合vs連合でも
対応出来る・・・はず
まあ戦闘フェーズがどうなるか次第だけど
欠点は運営側のFLASHのコードの保守も大変なのがほぼ確定してるとこか
戦闘フェイズのフラグが現在のありなしの形式だと
フェイズの並びはどうしてもapi別処理になるね。
フェイズタイプのenumみたいなのにすれば全部綺麗にまとめられそうだけど。
連合艦隊だから第二艦隊まで大破チェックが走るけどデータは
セットされてないから大破判定されちゃってたわ
battleresultには敵艦隊連合の情報ないしどうするかな
api_mvp_combinedが存在してかつnullじゃないときだけ第二艦隊も
大破判定するとかしないとダメかなぁ
CrackUpWarningForm.UpdateControlsFromKCData()
に
//６隻目のMaxHPが-1なら敵のみ連合とみなし、聯合フラグを切る。
とコメントがあるなあ
このクラスに聯合フラグを持たせているようだ。（もう忘れているともいう）
なお表示サイズもこのフラグで調整していたようだ、
で見ていた。（どうせ12隻に拡張してあるだろうし）
下手に新たなapiパースするよりそっちの方が良さそうだね
MainFormの中で閉じて処理出来るしそれでやってみるわthx
とりあえず6-5では問題なく動作してるけど
自艦隊連合でちゃんと動くかの確認は秋イベまで持ち越しだなぁ
今後更に違う拡張がきたら判定部分にきっちりコメントしとかにゃ前衛的な芸術コードができあがる
わけわかんなくなってるぜw
battle_waterかどうかのフラグ
戦闘フェーズの順番をどうするか切り替えるためのもの
これが連合vs連合でどうなるのか読めんのよなぁ
そそ、うちもそうなってしまってる。
Parser内部でフラグでの場合分けが項目毎に発生していて
キッチリコメントしとかないとエラいことになる。
api毎に番号振ってBattleApiType.CombinedWaterとか.EnemyCombinedとか
定義してもいいのかもしれないけど、その都度対応してたのでフラグだらけだ。
我流で綺麗にまとめてもトンデモ修正入ったら展開し直しが目に見えてるしな
どうしても最低限の追加で済ませようとしてしまう
どうしてもそうなるよね
連合艦隊とか敵連合艦隊でパーサ分けるならフラグいらないけど
先制対潜みたいなの追加されるとパーサ全部修正することになるし
運営が最初から連合vs連合を念頭にJSON設計してくれてれば
こんなことやる必要ないんだけどなぁ
回線不調で外に出ちゃったからどっか穴あるかもしれんけど
聯合艦隊くるまではそのまま進めるとしよう
2分前
api_req_combined_battle/ に、each_battle_water と each_battle (ともに対敵連合艦隊)が増えていますね
とのことなので準備が必要ですな
まああんまり変わらない感じかも。
ただＥ３でＳ取るのに手数たらねーよ って気はする。
req_conbined_battle_ec_midnight_battleの
maxhps_combinedの味方分に夜戦開始時のhpが入ってるなあ。
他の専ブラは相変わらずイベ海域でもないのに落ちたり一部機能しなかったりしてたようだが
こっちは相変わらずの無風で一安心
連合の夜戦はかなりデタラメなJSONになってんな
E4ボスですらインデックス範囲外を喰らってしまった。
最初は首を捻ったがツールスレ見てると大正解だったんだろうな
しかもこのパーサ、良く読むとリエントラントじゃねえのな
メモリ確保できずに止まることはあってもスタックオーバーフローで飛ばないのは強い
ソース嫁（１年以上気づかなかったがな）
無限にオブジェクトがネストしててもKCRDBのパーサは飛ばないように見える
読んだの大分前だから勘違いしてたらすまぬ
>>646
大量のデータのマージソートみたいな処理の場合、
再入なんかしたら一発でスタックオーバーフローするぞ
リストをスタックに見立ててループの中でリストの最後の要素を処理し続けていれば
再入せずにインスタンス単位で独立してのJSONやHTMLのたぐいの処理は可能
自前のスタックの代替構造はわりと基本的な技術
ちなグローバル変数なんてC#にないぞ
JAVA作者のどっちかくせえな
つまりはそういうことだろう
/ /. : / /. : / / . : / / ／ . : ／/ . : / . : . : . : ',
/. : / /. : / / . : 厶 ＜ . : ／／ . : , ′ . : ;/ . :} : ! ハ
_i : :| i i : : ｉ ,′ ＜. . . . . : ＞＜／ . : ／ . : ／/ . : . :/. :i| :∧
￣ l : :| | ! { : : l|ｉ : : | ｀T 厂灯≧x＼ ／ ／. : ／ / . : . ://. : ハ : :∧
／i:iﾍ: :| i i∧: : l|| : : |: : | {｀し//ﾄ ヘ ／. : ／厶==─--//. : / . : . : : ｉ｜
／i:ｉ:ｉ:ﾍ|戈ゝ､＼|| : : |: : | 上廴)ソ ＜._:_／⌒灯三≧ｘ /. : / . : } . : /'|｜
:i:i:i:ｉ:ｉ:／ .>‐一 l| : : |: : l {｀し//iﾘ ｿ. : / . : / . :/ l:ﾘ
:i:i:i／ /:i:i:/ 八: : lﾍハ ' ﾏ廴)ン／. : / . : / . :/ // 言ったはずだぞ…
. ´ ／ /:i:i:/ .__r── ､./＾ヽ ＿ 〈／／ . : . :/| //
-‐ ｉ:i:i:/ ,上ﾍfヾ⌒７ } / ヽ ／／: : . : : ..i:i:| 〃 私は…よったちたのって！
/:i:/ レ廴..ソ/Y .人 { ﾉ 〈／: : . :／ . :／i:i:i:| ′
.i:i:;′/ {くｿ ! イ ／⌒) ｀ ´ . ｲ ﾉ. : ∠厶イ:ｉ:|:i:i:i:ｉ|ヽ. この間もしょったんカルトだ！
'´ i:i:i:| ｉ＿＿ｖ' レ-<⌒{ ／＞ -- -‐ｧ ´. :／ :／/:i:i;仁ィ´川:i:ｉ|: . ＼
／ |:i:r'ア´ { ! 人＿_） ／.／:i:∧:iヽ}─‐┴┐´ ／ /:i:i/ | |:|ｊ:i:ﾘ＼: . ＼ カビ昆虫！！
／ |:_j j ヽ 从/ ） /／:i:／| i:i:i:i:Y´ ￣￣|´ /:i:i/ : | l:i:Ｔ′ ＼: . ＼
厂 r' ＞ 、/〈 { ￣） /_|i:i:/|:i:i:| |i;i:i:i:} - ､ ＿|⌒ヾi:i:i/ . : { |i:ｉ| ＼: . ＼
.〈 ヽ ＿／{ ヾ辷ァｸ､ ヾ⌒|:i:i:| ∧:i':ｲ ＼{ /ー' ,′ V:i:ﾘ ＼: .
`ァ ｝ ／人＿＿_,ノ ヽ 〉 .!:ｉ:ｉ|/ V:i:ﾊ r'､ / / . :/ /:i∧ ＼
｝く＼ ,／ ﾄ ｀ヽ、 〉 .!:ｉ:ｉ| V:i:ﾊ__,ノ^Y´ｉ| / . :/ : . /:i/ ヽ.
Kﾉ ｛ / |ハ Ｖ´ ,|:i:i:|＼ ヾ:ｉ＼__,ﾉ ﾘ . :∧: :厶ｲ: . ＼
ゝ､ ＼＿_/＿_!＿r一' ／ハ:i:ヽ ヽ r＼:i＼ ./ . :/ } : : : | : : . ＼＼
同時にE5のスタート地点開放完了。
ttp://i.imgur.com/jPBZk8r.png
なお直後の夜戦のjson つまり>>641の話
"api_maxhps_combined": [
-1,
14,
53,
49,
49,
34,
19,
57,
130,
130,
88,
35,
35
],
どこからMaxHP引っ張ってくるかな
デッキ番号と艦の並びから引き出せるかな。
昼のデータ放り込んで夜に取り出せばいんでね？
母港戻るまでにデッキ編成が変わるような仕様変更はそうそうなかろう
そうじゃなくて、再入（re-entrant)じゃなくて再帰(recursive)
リエントラントじゃないっていうのは、マルチスレッドや割り込みなどによる呼び出しに対して安全じゃないって意味だよ
マージソートでスタックオーバーフローなんてしないよ
再帰の深さはデータサイズのlogでしか増えないから
クイックソートの勘違い？
寝よう
豚のJSONパーサが異常なのは間違いない
JSON式が複数混入してても解釈しちまうからな
このスレでIndex例外のダンプ取れることにしてディスろうとしてたアレに見える
（MFCはメッセージポンプの外、.NETは内部のWndProcの内側で止まったダンプしか取れない）
アレを特定せんと他に移行してカスタマイズなりドッキングの（最悪）デッドコピー紛いの協力なり
する気になれんみたいなの少なくないのではないかと
昔は七四式のKCRDB化で更新が楽になると期待したけどもう今更かな
ああやっぱりこの戦況見やすいなあ
なんでゲージより数字の方がわかりやすいんだろう
戦闘前のHPがあるからかな？
あの時俺も話題に入ってたがドッキングがコンパクトって話にMainFormがでかい、だっけ
全然関係ないDisりで腰折ってくるしどうしようもねえんだよな
きっとみんな仕方なく自身で修正してるけど連合大変だから74かどっかに行きたいけど行けないんだよな
そうだろ？ｗ
ほんとうにやりたいんだったらgithubでやりとりすればいいだけの話
あれは目線がユーザじゃないしソースと実物で語ってないからすぐわかる
７４式にKCRDB以上になってほしいの？ほしくないの？
>>669はhubでKCRDBもどきに近づけるようなPR考えたことないの？
ここにいるなら夜戦JSONネタに加わってもおかしくはなさそうだけどそれもなかったよね
自力で何とかする人だけがKCRDB使えて戦果有利なのは一握りだけでいい、
７４式にPRもメンテも面倒だから誰かやらないかな、みたいな後ろ向きな考えは
殆どの人の頭の片隅をよぎったことくらいはあると思うが、それすら伝わってこない
_OnReceivedSortieNightBattle_Main内部で
int id = this.m_memberdata.Deck.DeckTable[1].ShipList[num11];
MemberShipElm melm = m_memberdata.Ship.ShipList[id];
expandedBattleInfoPlayerShipElm.MaxHp = melm.MaxHp;
てな感じでうまく対処できました。
ActiveDeckの値をもってきたほうがより良いかな
3-2-1でも使えそうだな。まあ今となってはめったにいかないが。
未だにE4が割れなくて胃が痛い
E5で第二スタート地点から輸送連合での1マス目が潜水艦確定かつ経験値がそこそこあって美味しい
第一にレベリング艦並べて第二を対潜先制組で固めると燃料20％だけでもりもりレベルが上がっていく。
3-2-1よりトータルの効率としては多分上。
ところでMain form.csの _FiddlerDelegate_AfterSessionComplete_Main や _DebugLoad に
oSession.GetRequestBodyAsString() が代入変数なしの単独で記述されてる箇所があるんだけど
これってなにか意味あるのかな？
第一にサラトガ、コマ、朝風、山風と適当な軽巡二隻
第二に軽巡雷巡駆逐四隻で新入りの経験地稼ぎ
おう、サラとコマはともかく幻の二隻さくっと混ぜないでほしいな
まあ砲撃戦やらないから関係ないのかも知れないけど
MaxHPとか、他にも怪しいところいろいろあるしね
違法改築繰り返してるような状況だから仕方ないんだろうけど
その内純正でも大破進撃しちまうんじゃないかと
例えばこんな感じの隠れ大破進撃とか起きそうで怖いね。
表示上まったく問題なく戦闘が展開してリザルトでも大破しているのが居ないように見えるんだけど、
実際は第一と第二への攻撃内容が一部逆になってて第二の駆逐艦が大破、他の駆逐艦もダメージ受けてて護衛退避の選択肢が出ない。
その結果、見た目上大破艦なしだから進撃して、次の戦闘が始まったら最初から大破してるのが居て轟沈。
純正のみの時は、、、、ナムナム
今回の対応中にもいろいろKCRDB内で轟沈判定発生させて
うおってなったりしてた。
単に新型式の砲撃戦のダメージの行き先のインデックス指定で+6抜けてたり
してただけだけどね。（こっちもいい加減違法建築）
違法建築具合を見てるとこういうミスが純正クライアントでも
実装中には起こってそうなんだよなあ。
コードはデータ構造以上に綺麗になれないから鯖もswfも相当姉歯ってるだろうし
いつ事件が起こっても驚かない
確実に大破検知しようと思ったら画像処理しかない
うざいし面倒だけど>>688去年夏みたいな目に遭う前にF5できる
多段刺してるとアプデで知らないのが来ても、動いてるフリせず
エラーがあってもresultで落ちずship_deckをほぼ確実に表示できるのしか使えないから
大型アプデ直後は動かすの結局これだけになっちまうんだよな
それ頂く、thx
エラー続行後のresult〜ship_deckの受信動作を保障しようとしてみた…
が、変に綺麗に整形してエラーがあったのかどうかすらわからなくなってたり、
battleを連合の時みたいに別名で取りこぼしてたりした時の
未初期化メンバの参照を確実にエラーで判定するのが困難だったりで
battleの処理よりその後の処理がどうしようもなさそうに見えるんだが、
誰かその辺がんばってみたことある人いない？
内輪を超えた範囲で共有するならkcrdb.exeを逆コンパイルするツールを決めて
（巨大な）パッチにして各自コンパイルしかないのかな
ドッキングウィンドウとかフルスクラッチが大変な部分だけをdll参照しつつ
他の部分はkcrdbの動作を再現するコードをフルスクラッチで作成・共有って方法もある。
違反にならないよね？
オリジナルは再配布せずにオリジナルを参照するexeの配布なら
フルスクラッチで作られてれば大丈夫だよね？
試行錯誤中…名前ぶつかるとダメだし2にするのは抵抗あるしネーミングに困る
今のところ、オリジナルのクラスの派生で全部騙し切れそうな気はするけど、
なんだかんだでMainFormの追加orオーバーライドの量はかなり多くなりそう
あれ？自分専用だったら別にドッキング機能要らなくね？
データ構造だけは逆コンパイルのパッチにしないと派生クラスのコード多くなるし、
実行時にオーバーヘッド増えそう
逆コンパイルの出力にプロジェクトファイルとデータ構造とprivateをprotectedにするパッチが無難と判断
そんでこれまで直接修正してた箇所を、exeの方で派生したクラスのメンバ関数に丸々持ってきて、
必要に応じてオリジナルのメンバ関数を参照、これで現状動くようにはなった
後は修正したとこ以外のフルスクラッチ化か…どこまで誤魔ｋ（ｒｙ
>>702
自分用ならラベルすらも省略し放題だけど、グループ増えた時にいちいち修正するのもね
レイアウトも最低でも戦闘と整理は分けたいし、未だ手放せない
資源たまるか飽きるまでは派生クラス側のフルスクラッチ化進めてみる
と一応言ってみる。
時代設定だとターボプロップ、一部ターボシャフトに似たタイプか
それにしてもinjectionって… ”噴” の直訳かよ相変わらず命名もひでぇ
既にローマ字汚染してるんなら素直に統一すれば恥をかかずに済んだのに
一式陸攻が重くなるな
修正入れなくてもエラーが出なくて大破進撃防止だけ機能してくれればいい
対応しないと受けた筈のダメージが加算されないからHPが多めに出る
すげぇ面倒くさい上にもう画面デカすぎて意味分からなくなる
ウチも縦削除して小を常用、横すらデバッグにしか使ってないな
ラベルの座標計算してそうなとことか地味に面倒なんだよね
まあ将来的にはやってくるのか…
その時が俺の終わりだな
時系列考慮すると陸上基地からシューティングスターあたり？
むしろAB空襲で深海B-17辺りが飛んでくる方が怖いかも
何かここの所これを連発するようになってしまった
特に不安定なネット回線につないでるわけじゃないんだけど
でしばらく当時のスレ読んでたけど豚さんやっぱすげーわ
それが問題じゃなきゃそれでいんでね
>>723
つい見返したが・・・先読みしたら躊躇なく実装もそうだけどさ
慎重みたいな悲観的みたいな思想でありながらそういうのさっくり組み込んでたよね
文字だけ読んでてアプデ次第でボロが出るだろと鼻ほじりながら流してたが
今のところ先読み的中多し＆違法改造ミスでのあぼーん以外はその通りに動作中・・・
、敵は第一第二の避雷になってるんだけど、味方の第一も避雷するのかな？
というか、対応するときに第二にしか被弾しない前提で組む方が面倒くさくない?
api_frai/api_eraiの番号通りに被弾判定するだけでいいわけだし
ttp://japan.cnet.com/news/service/35093745/
windowsアップデートで解消したからもしかしたらこの記事の不具合で出てた症状だったのかもしれない
手持ちのjsonと曖昧な記憶だと第一に避雷してなかったから他の人はどうか確認したかったんだ
そういや噴式対応まだやってなかった…
構造が夜戦HPでいよいよ破綻してきてるとこに命名までこれじゃなぁ
次のアプデこえー
しかし噴式とか穴開けてバルジとか、次のイベント嫌な予感しかしない
実害はないから良いけど
艦むすマスタの最大スロット数分しか読みに行かない実装だと補強分は無視されるな。
久々に近代化改修しないと
その都度改修しないからアドバイスも得られにくくなる
forceIntなら >264,273,277,292 見れば判るっしょ
運営はグラやデータ類のパブリッシュツール類は使えるかも知れんけど
それ以上のことをできる人間が一人もいない可能性が微レ存
今後いつどう変わろうと問題無いのでは・・・！！！
まぁ最近の鯖アプリのコーダーがJSON生成で数値か文字列値かを
明示的に区別してない（できてない？）みたいだから全部ForceIntでもいいんじゃないかな（適当
補強増設も対応したいのだけれども何処から弄れば良いですかね
うちは_OnReceivedSortie・parser共に通常連合夜戦と全部共通の処理にしてるから砲雷テーブルの作り直しで頭抱えてるんだけど
砲/雷撃戦の有無のflagがそれぞれの型式で違うから仕方なし。
3つのフラグでパース部分は切り替え
砲撃テーブルは敵連合かどうかで切り替えてる
api_at_eflagがある以上どうしようもない
ああapi_at_eflag使ってる形式とそうでないのがあるのも重要だね。
列挙型で判別みたいなのを思いつかなくもなかったけど
どうせ俺が色気出しちまうと後でまた修正が必要になった時、わけわからなくなるからな（ドヤッ
戦況情報ダメージ詳細窓とかとんでもないことになってるしな・・・
まずapi_df_list,api_damage,api_at_eflagから敵味方双方12隻編成と考えたダメージデータを作る。
敵側のダメージデータはインデックス調整の必要なし。
自軍は各戦闘apiごとにインデックス調整(+6)の必要あり。
第2艦隊が先攻する(S)と両連合(E)の2つのフラグをつかって、
1巡目: S & !E
2巡目: S & E
3巡目: !S
がそれぞれ真の場合はインデックス調整を行う。
というか今自分がゼロから作るならそうしてるな。
JSONの整合性を信頼してそれを確認するってのが豚さんのやり方だったから、できるだけ踏襲したいけど
まさかこんなにとっちらかったデータになるとは、、、、
使う要素をJSONから１つ１つ取り出す今の構造のメンテは面倒だけど、
ツールスレでの騒動みたいなエラーが出ないとか最後のマス前で飛ぶとか勘弁だし
いけるとこまでForceInt化とフラグ類で凌ぐしかないかな
ツールスレのあれって時間っぽい気もするね
START押す前の先読みとSTART押した後のレスポンスのシーケンスって違うんだよな
敵連合の随伴艦隊はダメージ計算してるけどスペースの都合上表示エリアは用意してない。
装備改修一覧の他には遠征の編成チェックとかも作ってる。
ttp://iup.2ch-library.com/r/i1767435-1484884649.jpg
サンクス
しかし、カスタマイズされすぎてて自分では参考にできねえ・・・
kcrdbからc#を勉強してるけど、どうにもわからん
受信スレッドと競合しないようにクローン作ってるとこ？
最低でもツールが展開した、同じような関数を全部手動で整理するくらいの手間は覚悟
興味あるものから学べたらなって思ったんだ
>>774
クローン作ってるとこです
クローンの必要性が分からなかった
>>775
自分流の機能を追加したいとかまでは難しいだろうから、
連合対応ぐらいまではしたいと思って、既存コードを流用しながら対応してるんだ
思ってた以上にkcrdbスレチェックしている人がいるんだな、なんだか嬉しい
敵が連合のとき、こちらが敵全体に砲撃するターンは第一艦隊どうしの砲戦になるんだっけ？
そのとき、こちらも連合だと敵も味方全体に砲撃してたっけ？
もうややこしくてまいった
攻略wikiの"連合艦隊の戦闘の流れ"にまとまってる。
ttp://wikiwiki.jp/kancolle/?%CF%A2%B9%E7%B4%CF%C2%E2#wd314cc2
オンオフボタンをメインフォームのツールバーに付けたせいでどんどんカオス化
UIって難しいな
こんなもん公開できんわと自己嫌悪に陥るあれな・・・あり過ぎて困る
自分が使いやすけりゃいいんだよ!
便利すぎてブラウザ単体に戻れる気がしない
1-6ラストや5-1逸れ時の誤撤退なんてのも
どれだけ機械の提案能力が進歩しても判断は人間が下すべきなんだぜ
「進軍」を隠す大破撤退防止機能と変わらん
まあむりか
クリックや送信まで手を出したらアカン
>>264からの一連の流れがしっかり理解できず、型を判定してStringだったら変換するらしいことまではわかったのですが
[JSONArrayElement.cs]にて
using System.Text.RegularExpressions;
をライブラリ追加し、そのままJSONArrayElementに
if (BaseJSONElement.JSONElementType.Str == baseJSONElement.Type)
{ Regex.Replace(Str, @"\D+", "");
Convert.ToInt32(Str);
result = ((JSONIntElement)baseJSONElement).Value;
}
としても「現在のコンテキストにStrという名前は存在しません」と怒られビルドできません。
”Str”部分に”((JSONStrElement)baseJSONElement)”だとビルドできるのですが今度は実際のテストで
「型'JSONParser.JSONStrElement'のオブジェクトを型'JSONParser.JSONIntElement'にキャストできません。」とエラーが出ます。
このあたりの実装方法について教えていただけないでしょうか・・・
ちゃんと変数定義して変換したら代入しなさいな
String str = ((JSONStrElement)baseJSONElement).Value;
str = Regex.Replace(str, @"\D+", "");
result = Convert.ToInt32(str);
テストに使っていた5-4一周エラー無く終了しました！ありがとうございます！
今日ついにクリック連打で慢心し轟沈艦を発生させてしまい、ずっと涙目で作業してました。
本当にありがとうございます。
運営も先制対潜が水上艦に当たったように見えるバグ出してるの見てちょっと安心した
とりあえず残機数がわかれば十分だし、
それくらいならスペース確保できると気づいた。
E3輸送ゲージボス戦でapi_formation[0]が文字列型になってた。これまでは自軍が通常艦隊の場合は数値型だったのになぁ。
ttp://i.imgur.com/rJNWkOn.jpg
※画面はハメコミ合成です
※開発中のため、実際の製品とは異なる場合があります
戦況が記録されていません.（大破進撃防止ウィンドウは機能しません）
↓
戦闘リザルト受信時に戦闘記録がありませんでした.
今回のE3潜水レベリング時に邪魔なので出ないようにしようと思ったんですが
1個目はStaticLog.MsgError()なので普通にコメントアウトでOK
2個目がthrow new UserExceptionなのでコメントアウトしても別のエラー
「戦闘記録がありません.」が出て、これもコメントアウトすると「種類 'KCRDB.UserException' の例外がスローされました。」
このウィンドウはどうやって消せばいいのでしょうか・・・
戦闘関係を全部他のに丸投げするのであれば
いっそのこと戦闘関係の処理の入り口の
_OnAfterSessionComplete_MapStartNext, SortieBattleResult, SortieDayBattle, SortieNightBattleの中身を空にすれば良い。
要するに戦闘関係のapiを処理しようとして起きてるエラーだから、そもそも処理しなきゃエラーも起きないってこと。
一番簡単なのは
if( a == null ) throw; a.method();
を
if( a != null ) a.method();
みたいにすること
戦闘記録がなかったらそれを参照するとこを全部飛ばすようにしなきゃいけない。
他の専ブラがエラーで落ちるのは if( a == null ) が真であっても a.method(); を実行するから。
KCRDBは参照するインスタンスが存在してるか徹底的に調べて、なかったら
自発的に止まってるからThreadExceptionで例外を止めても動き続けられる。
↑の対策するとエラーは出なくなるけど、陣形選択が出ない編成で
未対応の戦闘Jsonを処理できなかった場合に他の専ブラみたいに
大破艦がいても進撃選択で警告もエラーも出さないようになるから注意。
まあ元々連合に対処してないからどうしようもないが
今回はvs連合でもやられる。で運営がバグ出した
こんなん初めて見た
その場所はいじってないKCDRBだとFlipのLabelだよね
PictureBoxの描画失敗でしか見たおぼえがないんだけどLabelだとどんな条件でそうなるんだろ
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=32046&forum=7
これなんだろう？
ttp://jbbs.shitaraba.net/bbs/read_archive.cgi/netgame/12394/1455403389/#905
報告と同じくトラックでわろた
鯖限定不具合なのかこれ？
連合対応はどうにかできたが、改修レベルを装備名に反映させられない
ヒントでもいいので誰か教えて
前スレちゃんと見ていなかった・・・申し訳ない
戦闘のapiの処理と違ってよくわかっていないが、試行錯誤してみる
タプルこれ神かよと思ったら結局NuGetしないとならんのね
ずっとkcrdbの判定式のままだった大破判定を変えようと思うんだけど、四倍にして元のHPよりも低かったら大破でいいのかな？
{
return iNow * 4 <= iMax;
}
こんな感じでいいのかな
元のメソッドもう少し長い計算してるからなんか意図があるのかという気になった
22/87 = 0.2528... ≒ 0.25 で大破判定だけど
821の判定式だと 22*4 = 88 > 87なので大破判定されない。
return Math.Round(100.0*iNow/iMax) <= 25;
でいいじゃんって思うけど、
Math.Round(2*k+0.5) == 2*kとなるらしくて(参考 ttp://dobon.net/vb/dotnet/programing/round.html )
return (int)(100.0*iNow/iMax + 0.5) <= 25;
のように0.5を足して切り捨てることで四捨五入になる。
なお、このままだとiMax=0の時困るから
return iMax > 0 && (int)(100.0*iNow/iMax + 0.5) <= 25;
とすればOK。
22/87は大破じゃなくていいんだよね？
他に該当するものがないか調べてみたら
Prinz Eugen改がMaxHP63で、HP16まで減った場合16/63=0.2539...≒0.25 & 4*16 = 64 > 63となる。
だからHP16になったとき艦これ本体の表示が大破になってれば四捨五入方式が正解だし、
中破なら821のが正解と確認できる。
判定が微妙なものの候補はiNow=k+1, iMax=4k+3という組み合わせ。
>>822で言いたかったことって>>821の式があってるかどうかは別として>>821の式と元の式との違いの指摘だよね？
そういえばそんな妄言もあったな
>>821の式で問題ないみたいだからこれでいくわ
念のため安全サイドで判定してますって。
ちなみに明石修理タイマでも小破中破間の判定で似たようなことになってるよね。
なぜそうしてるのかは書いてない
修正入るまで100%の人が殆ど居なくなった前例を垣間見て
大破判定が変更された時の対策とかじゃなかったっけ
今さら気にしてもね
他に移るか引退するか…
最悪コード見てコピーすればいいしね
最悪5-4で大破進撃防止が動けばそれでいいわ
start2の艦娘固有ID上限値、いつの間にか変わってたのか
今までは500からが深海棲艦だったのが1500からに変わってすずやん改二と航はIDが503と508になってる。
TNX
直すのめんどいからこのままでいいか
正常に表示されてる
この辺ぽい
ttp://jbbs.shitaraba.net/bbs/read_archive.cgi/netgame/12394/1435653764/187
要素数見て自艦隊か敵艦隊か切り分けてるからまあ問題なかろ
出撃後どうなるかはみてみる
瑞雲とかLate系がいつのまにか43に変更されてる？
★とか》の処理もちょっとさわらないと
水上爆撃機のstypeが変わったのもイベより前のことだぞ
FLASH終了と艦これ終了どっちが早いか
ボイスがmp3で置いてある？ﾅﾝﾉｺﾄﾀﾞｶ
そのままだろう。
むしろ艦これを作り変えられるかどうかのほうが心配だね。
いろいろ覗かれるのもあるだろうし。
鯖に大きな負荷かけられないだろうし。
ブラウザ版廃止して
泥版と同じくAdobe AIR使ったスタンドアローン版へ移行という可能性が高い気がする
(flashは終わるけど、AIRは継続だし)
・五周年のタイミングに向けてフロントエンドのシステム更新を実施予定
・中身としては膨大化したシステムの整頓などで馴染んだ見た目はあまり変わらない
配列(数)やapi名変わったって丁寧なじょう・・・悠長化されてんだからエラー警告無効化してなけりゃ大丈夫でしょ
書き換え途中の中途半端で改修サボってたから変更きたら死ねる
まあエラー吐いて止まったりしなきゃいいのよ
しかし何ヶ所かに固定で記述あるけどチマチマ上がるとは豚さんも思ってなかったのかな。
保留してたのが来てしまって、テストせずにいたので味方に轟沈判定が…
と思っていた時期が私にもありました
E7甲終わらんはこれ
ギリギリまで粘って丙に切り替えるしかないか
掘りが終わってるのだけが救い
装備一覧以外使う場所無いから放置したままだわ
進撃前にダメコンの有無を確認できるようにしないといかんと切実に思うE7甲中
と甘い考えで実装準備だけやった
api_id < 1500で端折りデータか判定してたからapi_soukが無くて死んた
jsonしらべなきゃ
なるへそ
ちなみにKCMasterDataの追加判定でapi_fuel_maxの存在有無を見てる
うちのはまだ500以上対応してないからむしろ不具合でないのか
とりあえず
api_id < 1500 にしてたところを
objAt.ContainsKey("api_taik") で判定することにして回避
ゲーム画面側で通信待ち状態っぽく右下でぐるぐる回って
装備とか全艦娘とかグループウインドウのリストビューの更新を
一時停止にすると終わるってのがふえてきたけど皆さんはどうでしょうか？
うちもやけに遅くなったんでIEでやってみたらさくさく動いたから一覧系とかは表示からはずしたわ
まあ少しはましかなって程度だが
開発環境だったりツール類だったり、ゲームの実行環境だったり
一部ソフトのアクティベーションだったり
再構築が面倒なんでいやどす。
とりあえず2020年までこのままで。
もう何をどういじったのかさっぱり覚えてないがw
自分で改修はもうできてないけど・・・
FiddlerのAfterSessionCompleteはキューに溜めるだけにて
実際の処理担当は別スレッドで動くようにしたら今のところストレス感じてない
運営はなんでこんなの登録したんだ？
通常グラのマスターデータを直接書き換えちゃうと期間終了後に書き換え忘れとか書き換え間違いが発生する可能性があるし。
炒飯と同時期の瑞雲モードが登録されてないとは、師匠に報告せねば
よく見たらあったわ
api_id: 788 が炒飯長波で、その10個あとのapi_id: 798 に瑞雲日向改が登録されとるわい。
ユーザーのデータだけはそのままでそれ以外は通信内容含め一から整理して作り直して来るか
現状を好意的に見ると二期実装にリソースを割かれて現行の実装がグダグダになってると見ることもできるけど
多分前者じゃないかな
二期に合わせてデータは多少整理してくると思うけどあまり通信内容を削っても整合性の確保が難しくなるし
オワタな
flash→HTML5変換ソフト使ったグダグダ実装で
初期を思い出させるようなクッソ重いUIになりゃせんか心配w
あとはAPI次第よね
専ブラ使う必要ないほど公式が充実するのが一番いいけど。
しかしHTML5だとIEアウトじゃね?
不思議なくらい酷いツギハギっぷりだからなぁ
どうなることやら
あと新しい任務に対応できてなかったのも
対潜でエラーが出るのも何とか直した、つーか以前なおしたはずなのにまた出るようになって?
1-6航空戦マスでstage3がnullの時の対応もやろうとしたが
テストが終わる前に1-6攻略終わっちゃったのでちゃんとできてるか不明
なんでテストの時に限ってnullにならんのだｗ
先制対潜対応は先延ばしつーかミジンコには無理、出来ない
あとは穴対応したいがどこから手を付ければいいのやら
熟練度や改修はどうするか、あまり必要性は感じないな
あれ、UWPのWebView以外でEdgeって使えるんだっけ？
KCRDB
---------------------------
Error : [svdata=/object{api_data}/object{api_ship}/array[0]/object{api_kyouka}/array]の項目数が5ではありません.
---------------------------
OK
---------------------------
修正しなきゃ…
対潜上がるようになったからか
なお引数の数チェックははずしてある
無視できるもんじゃないわこれは
ExpandShipElmとかリストは暇出来たらでいいや
これも外部ファイルにしたららくなんだろうなぁと思いつつ
影響ないかと思ったけど、大破判定に絡むからちゃんと取り込まないと…
何に使ってるかはっきりしたらそれにあわせて手を入れなきゃいかんね・・・
try catch で５と７の両方を確認するようにしだけした。
どうもおま環っぽいので忘れて
本当によく考えられてるわ
Fiddler以外でファイルをD&Dで読んで表示してくれる奴が見つからない
ファイルの先頭のJSON以外を削ってやらないと解析してくれない奴ばかり
Fiddler重いんで軽い奴が欲しいんだが
整形するコマンドラインのexeを作って、
右クリックから「送る」で変換できるようにして
テキストエディタで開いてる。
そこまでせにゃならんのか…
いやまあ別になんか探せばいいんだろうけど。
めんどうなので作った。
jsonの整形自体はライブラリ使えば１行だし。
どういう感じにすればいいんだろう
static化して分離？
MainFormの引数化？
関連するクラスまとめて別ファイルにして読み込ませてるだけだけど
これだ
partialかな
排他共通化したりすると意外とパフォーマンス落ちた苦い思い出＠タブ
これなら割と簡単だったし
小さな画面で隅に表示させて他の作業しながら周回できるようにした
意外と捗る
一旦Listに突っ込んでToArrayしつつAddRangeするようにしたらだいぶ軽くなった
SuspendedLayout3つとResumeLayout3つで囲んで試してみたけど
やっぱり逐次AddとまとめてAddRange(list.ToArray())とで1.7〜2倍くらい時間差あるみたい
暇なときに見るか
と
var ta = new ListViewItem[list.Count];
for(var i = 0; i > ta.Length; i++)
{
ta[i] = _ShipDataToItem(list[i]);
}
this.listViewMain.Items.AddRange(ta);
とで比べてみたらLINQのほうが早くてなんか悲しくなった……
でも二倍にはならないな
どんな処理してるんだろう
for(var i = 0; i < ta.Length; i++)
だったわ
問題なきゃいいが
listまわりとか非同期にしたら待ち時間とか少しは軽くなるのかな
まあそりゃ重くなりますわ
1桁違うってならともかく。
配列いじって一艦隊に7隻
安定考えるなら前者だけど多分後者だよなぁ・・・
来年のHTML5移行時に変則編成にも柔軟に対応できてバグりにくいようなapiに一新してからやればいいのに
すごい工数かかりそうなんだよなあ、鯖側も通常海域、片聨合２つとと両聨合、聨合はそれぞれ水上、機動、輸送で
全部別々の戦闘処理してそうだし。
つぎはぎで作ってきてるから、まとめて修正したらあちこちで不具合がでそう。
多分払暁戦みたいに使い捨てのAPI作ると思う
どこ情報?
草w
後半海域限定なのも含めてイベ期間中の対応は自分では無理そうだな…
クリア後は掘りでも無い限りはつかわんという。
いじめかよ
もしそうならギリ対応できなくもないな
次スレ立ててくる
【悠長化】KCRDB専用スレ15【出荷済み】
ttp://jbbs.shitaraba.net/bbs/read.cgi/netgame/12394/1510930243/