したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | メール | |
レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。

改造・制作スレ part8

1：名無しさん＠桜花爛漫：2016/05/21(土) 22:17:05 ID:1hw1nxVw
改造・オリシナ制作などはこちらで。
過去に似たような質問があるかもしれないので、極力調べてから質問しましょう。

ヴァーレントゥーガまとめwiki　シナリオ製作講座
http://www28.atwiki.jp/vahren_ency/pages/411.html


改造・制作スレ
http://jbbs.livedoor.jp/bbs/read.cgi/computer/42292/1250722590/l50
改造・制作スレ part2
http://jbbs.livedoor.jp/bbs/read.cgi/computer/42292/1282244590/l50
改造・制作スレ part3
http://jbbs.livedoor.jp/bbs/read.cgi/computer/42292/1305281909/l50
改造・制作スレ part4
http://jbbs.livedoor.jp/bbs/read.cgi/computer/42292/1331214703/
改造・制作スレ part5
http://jbbs.livedoor.jp/bbs/read.cgi/computer/42292/1350187379/
改造・制作スレ part6
http://jbbs.shitaraba.net/bbs/read.cgi/computer/42292/1372172557/
改造・制作スレ part7
http://jbbs.shitaraba.net/bbs/read.cgi/computer/42292/1396009373/
665：名無しさん＠秋分：2017/10/09(月) 10:14:23 ID:???
複数の配列から配列をゲットする方法ってありますか？

例
@A→内部A00,A01,A02・・・・・A99
@B→内部B00,B01,B02・・・・・B99
・
・
・
・
・
@Z→内部Z00,Z01,Z02・・・・・Z99

と言う感じで配列があったとして、例えば今C56を取得した場合、B56、C55、C57、D56を追加で取得したいと言う場合です

666：名無しさん＠秋分：2017/10/09(月) 12:00:00 ID:???
ないです

667：名無しさん＠秋分：2017/10/09(月) 12:08:51 ID:???
配列ってのは文字変数のことで合ってる？
合ってるならindexとwhileループでマッチングすれば複雑にはなるけどできると思う
例えばの後の追加取得の法則性がよくわからないから例が書けないけど…

668：名無しさん＠秋分：2017/10/09(月) 14:16:51 ID:BzZJDMr6
疑似的に二次元配列に展開されている要素から上下左右の要素を取り出すのならば、
変数を分割せずに要素を全部一つの文字変数配列に放り込んでおいたほうが簡単なのでは、
各列の要素数が100個あるのならインデックス値を+100or-100してやれば上と下の要素にアクセスできますよ。

669：名無しさん＠秋分：2017/10/09(月) 14:24:07 ID:???
ああ上下左右だったか
何にしても>>668のやり方がベストかな

670：名無しさん＠秋分：2017/10/10(火) 09:37:48 ID:???
>>668
そこの問題点がありまして、文字変数を一定数以上連結すると非常に重くなる欠点が・・・
以前似たことをしようとして、spot5000個連結したらまず連結時に非常に重くなった問題ががが

671：名無しさん＠秋分：2017/10/10(火) 09:51:19 ID:???
それだけあるとどんな処理しても正直重そうな
いっそ開き直って「処理中ですからちょっと待ってね」なｍｓｇだすとか
重さ的に許容できる範囲内で実現可能な二案、三案を用意した方がいい気もするとか

672：名無しさん＠秋分：2017/10/10(火) 10:23:44 ID:???
>>671
500づつに分割してどこがhasしてるか確認して10の配列をelseifで探していけば問題なくいけました

問題はこの配列が10個で済むパターンならいいのですが、最終的なシナリオで数万クラスを想定しているので、それで回数かけてwhileするのは現実的じゃないので何らかの方法を考えていました

673：名無しさん＠秋分：2017/10/10(火) 18:27:49 ID:CTiGm3/w
以下のスクリプトで事前計算によりループの回転を100回未満に抑制できるはずです。

//変数@allに全要素を格納 A-Zの各列の要素は100個あるものとする
setv(@all,A00)
・
・
・
addv(@all,Z99)

//事前計算用変数
setv(@a,A00)・・・addv(@a,A99)
setv(@b,B00)・・・addv(@b,B99)
・
・
・
setv(@c,C00)・・・addv(@c,C99)

//インデックス値の推測
if( 1 == has(@a, @str) )
{
set(idx, 0)
}
else if( 1 == has(@b, @str) )
{
set(idx, 100)
}
else if( 1 == has(@c, @str) )
{
set(idx, 200)
}
・
・
・
else if( 1 == has(@z, @str) )
{
set(idx, 2500)
}

set(idx2, idx)

//変数@strの上下左右の要素を変数@getに格納する
clear(@get)
while( idx < idx2 + 99 )
{
index(@all, idx, @tmp)
if( 1 == equal(@tmp, @str) )
{
//両隣の要素を取得
set(tmpidx, idx)
sub(tmpidx, 1)
if( 0 <= tmpidx && tmpidx <= idx2 + 99)
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}
set(tmpidx, idx)
add(tmpidx, 1)
if( 0 <= tmpidx && tmpidx <= idx2 + 99)
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}

//上下の要素を取得
set(tmpidx, idx)
sub(tmpidx, 100)
if( 0 <= tmpidx && tmpidx < count(@all))
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}
set(tmpidx, idx)
add(tmpidx, 100)
if( 0 <= tmpidx && tmpidx < count(@all))
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}

break()
}

add(idx, 1)
}

674：名無しさん＠秋分：2017/10/10(火) 18:33:13 ID:CTiGm3/w
誤りがあったので訂正です。
以下のスクリプトで事前計算によりループの回転を100回未満に抑制できるはずです。




//変数@allに全要素を格納 A-Zの各列の要素は100個あるものとする
setv(@all,A00)
・
・
・
addv(@all,Z99)

//事前計算用変数
setv(@a,A00)・・・addv(@a,A99)
setv(@b,B00)・・・addv(@b,B99)
・
・
・
setv(@c,C00)・・・addv(@c,C99)

//インデックス値の推測
if( 1 == has(@a, @str) )
{
set(idx, 0)
}
else if( 1 == has(@b, @str) )
{
set(idx, 100)
}
else if( 1 == has(@c, @str) )
{
set(idx, 200)
}
・
・
・
else if( 1 == has(@z, @str) )
{
set(idx, 2500)
}

set(idx2, idx)

//変数@strの上下左右の要素を変数@getに格納する
clear(@get)
while( idx < idx2 + 100 )
{
index(@all, idx, @tmp)
if( 1 == equal(@tmp, @str) )
{
//両隣の要素を取得
set(tmpidx, idx)
sub(tmpidx, 1)
if( idx2 <= tmpidx && tmpidx < idx2 + 100)
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}
set(tmpidx, idx)
add(tmpidx, 1)
if( idx2 <= tmpidx && tmpidx < idx2 + 100)
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}

//上下の要素を取得
set(tmpidx, idx)
sub(tmpidx, 100)
if( 0 <= tmpidx && tmpidx < count(@all))
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}
set(tmpidx, idx)
add(tmpidx, 100)
if( 0 <= tmpidx && tmpidx < count(@all))
{
index(@all, tmpidx, @tmp2)
addv(@get, @tmp2)
}

break()
}

add(idx, 1)
}

675：名無しさん＠秋分：2017/10/10(火) 19:00:06 ID:???
>>674
ありがとう
でも最初の２６００の配列あるだけで相当重くなりません？

なんか他の原因あるのかな・・・

676：名無しさん＠秋分：2017/10/10(火) 19:48:21 ID:CTiGm3/w
>でも最初の２６００の配列あるだけで相当重くなりません？
ゲーム再開直後に文字変数配列を作成して保存しておけば毎回配列要素の作成をしなくてもいいですよ。

677：名無しさん＠秋分：2017/10/10(火) 20:39:25 ID:???
>>676
でなくて、その文字変数の配列があるってだけでやたら重いのは何か問題あるのかな・・・と

678：名無しさん＠寒露：十月十日は萌えの日：2017/10/10(火) 21:54:18 ID:CTiGm3/w
>>677
メモリーの使用量が増えると重くなるのは仕様なのでは、空いているアドレスを検索する処理がリソースを消費しているんじゃないですかね。
メモリーは最大で1.5GB程度まで使えることは確認していますけど、1GBを超えるくらいになると重すぎて実用レベルとはいえませんね。
使っていない、使い終わった文字列変数はclear関数で開放してやってメモリー使用を節約するくらいしかないと思いますよ。

679：名無しさん＠寒露：十月十日は萌えの日：2017/10/11(水) 14:44:58 ID:???
>>678
なるほど
１つだけの配列だと重くて、複数に分割すると軽いのはそこらへんも関係あるのかなきっと・・・

680：名無しさん＠寒露：2017/10/15(日) 17:46:24 ID:kTG8KCI.
setPowerHomeで勢力のHome設定を操作しているんですけど、COM勢力のspotの戦力配置に重みをつける方法はありますか。

681：名無しさん＠寒露：2017/10/16(月) 08:56:13 ID:DwLnCock
質問です。
皆様シナリオのMapを作る時どのようなツールを使用していらっしゃるのでしょうか？

個人的にはむなしい努力の地図の雰囲気がとても好きです。
本家VTも雰囲気好き

私も同じような地図作りたいんでツール教えてください。

682：名無しさん＠寒露：2017/10/16(月) 09:43:08 ID:???
本家付属ツール使いんさい

683：名無しさん＠寒露：2017/10/16(月) 12:48:34 ID:???
ワールドマップの事じゃないの？
もしそうなら俺はsaiで描いてるな

684：名無しさん＠寒露：2017/10/16(月) 16:41:18 ID:???
choiceについてですが、選択肢の数が流動的な場合、想定される選択肢の数を全部書くしか方法はないですか？

例
誰を仲間から外しますか？の場合
その時点で仲間である物が１〜２０人すべての可能性を想定する場合、選択肢１はselectで表現するにしても、choiceで表現する場合引数２〜２０個の全てのパターンが必要でしょうか？

685：名無しさん＠寒露：2017/10/16(月) 16:46:36 ID:???
空欄や名前をクリックしたら元にもどる等の挙動で妥協する予定はありませんので、選択肢の数を決める方向性でお願いします〜

686：名無しさん＠寒露：2017/10/16(月) 18:04:55 ID:???
妥協せずに一つずつ全部書くしかないと思う

687：名無しさん＠寒露：2017/10/16(月) 20:31:19 ID:???
ランシナの配下選択みたいに4､5程度の選択肢の複数ページに分ければパターン少なめで済むかも

688：名無しさん＠寒露：2017/10/16(月) 20:45:53 ID:SKENrydA
>>684
Great Europe Warの「部隊長一覧.dat」が割合そのまま使えそうな感じかな
文字数制限に引っかかったから自分で見てくれ

689：名無しさん＠寒露：2017/10/16(月) 21:37:49 ID:???
Boiにも似たようなキャラ選択があったな
あっちはキャラ数が多すぎて、小分けが顔あり、顔なし、ゲストの3枠だけでは手間が全く軽減されてない有様だけど…

690：名無しさん＠寒露：2017/10/17(火) 10:01:55 ID:???
「最後尾のキャラをチームから外します。よろしいですか？」

691：名無しさん＠寒露：2017/10/17(火) 14:24:02 ID:???
>>687>>689
それは初期の人数が決まってる場合にのみ有効なような・・・


>>690
最後尾が隠れてる状態になると外せるようにしたいので無意味ですね


>>688
調べてみます

692：名無しさん＠寒露：2017/10/17(火) 14:36:18 ID:???
>>691
場合分けと剰余演算でイケるイケる

693：名無しさん＠寒露：2017/10/17(火) 18:30:23 ID:???
>>691
おまえ毎回条件後出しにして揚げ足取ってないか？
他人にアイディア求めるならもう少しちゃんと説明しろよ
694：名無しさん＠寒露：2017/10/17(火) 18:49:08 ID:???
>>680
たぶんないんじゃないかな。隠し関数は知らないけど
ワールドイベントで部隊を動かしてやるほうが早いと思う

695：名無しさん＠寒露：2017/10/17(火) 19:00:37 ID:???
>>692
なるほど、〜以上なら１ページ、〜以上なら２ページ・・・って感じで割り算の数値ページ分だけ用意した後、余ったページを使うと言うのはいいですね

>>693
>>691はなると→なってもですね失礼しました

全想定のラインを細かく話さなきゃいけないならキリなくなるんで質問もできませんが・・・
最後尾のことでしたら、それを限定したはずし方になるのでそもそもの目的と大きく外れますし、元々choiceを用いてということを説明しています

696：名無しさん＠寒露：2017/10/17(火) 19:05:03 ID:???
>>694
結局どの仲間を外すかってことにchoiceが必要になってしまいそうなので、choice全通りとページ周りを両方試してみます
ワールドマップでの解雇となると、やはりプレイヤーが解雇「しない」という選択肢を取ってそのまま進めてしまうことを想定できちゃうので、無理そうですね

697：名無しさん＠寒露：2017/10/17(火) 19:17:50 ID:???
質問の要点をまとめるのは質問者の最低限のマナーだよ
キリなくなるから後出しジャンケンしますって回答者をbotか何かと勘違いしてない？っていわれても文句いえないぞ

698：名無しさん＠寒露：2017/10/17(火) 19:43:36 ID:???
>>692
綺麗にいけました、ありがとうございました〜

>>697
そのためchoiceを用いることと、人数の流動的な仲間を外すことという2点を要点として伝えました
それで足りないのであれば、どの程度をまとめればいいかわかりませんが、botとは考えていません
だからこそ出来る限り返事をしています


以上です
返事を下さった皆様ありがとうございました〜

699：名無しさん＠寒露：2017/10/17(火) 20:49:10 ID:???
ぶっちゃけ>>687で終わってるのに何も考えずに聞き返してる辺りがもう
自分で考える気あるのか
しかも質問の返答に対して無意味ですねとかSAN値0かよ

700：名無しさん＠寒露：2017/10/19(木) 11:32:22 ID:???
ユニットの「素早さ (speed) 」と実際の攻撃頻度がどう関係してるのか調べてみました。

戦闘時のゲーム速度は「普通」のまま。行動速度は標準値の unit_action_bdr = 4000 です。
attack = 1, defense = 0 で単発の接近攻撃だけ所有する実験ユニット同士に殴り合いさせて、経過時間とダメージで攻撃回数を数えました。時間は厳密に計ったわけではないです。

speed = 60 だと一分間（戦闘時間で３００経過）に４３〜４４回ぐらい接近攻撃します。

スライド速度が速い場合に攻撃回数が増えるか調べるため、
unit_sword_slide = 9 (12フレームで前進)
unit_sword_slide = 12 (9フレームで前進、標準はこれ)
unit_sword_slide = 50 (2フレームで前進)
で試しましたが、攻撃回数に違いはありませんでした。
スライドが速く終わっても、次の行動間隔までの待ち時間が長くなるだけです。

unit_sword_slide = 4 (25フレームで前進？)
前後にスライドするのに５０フレーム（２秒）必要だろうから、スライドが終わるまで次の攻撃を待つなら、一分間の攻撃回数は３０回になるはずですが、
実際には攻撃回数は４３回と変化しません。

unit_sword_slide = 2 (50フレームで前進？)
前後にスライドするのに１００フレーム（４秒）必要だろうから、スライドが終わるまで次の攻撃を待つなら、一分間の攻撃回数は１５回になるはずですが、
実際の攻撃回数は３０回でした。スライドが終わるのに丁度２秒かかってます。

スライド速度が極端に遅いと、行動間隔よりも長くなって、攻撃回数が減ることが確認できました。
ただ、スライド速度のパーセント指定の数値を極端に小さくした場合は、細かい距離が四捨五入されるせいか、スライド時間は計算通りにはならないようです。

スライド速度が影響しないように速くした条件で、speed だけ変えてみました。
speed = 70 だと一分間に５０〜５１回ぐらい接近攻撃します。
speed = 80 だと一分間に５７〜５８回ぐらい接近攻撃します。
speed = 90 だと一分間に６４〜６５回ぐらい接近攻撃します。
speed = 100 だと一分間に７１〜７２回ぐらい接近攻撃します。

「きのこたけのこ戦争」や「Brave of Island」では unit_action_bdr = 3500 になってるので、攻撃速度がどれだけ変わるかも調べてみました。
speed = 60 だと一分間（戦闘時間で３００経過）に４９〜５０回ぐらい接近攻撃します。
speed = 70 だと一分間に５７〜５８回ぐらい接近攻撃します。
speed = 80 だと一分間に６６回ぐらい接近攻撃します。

701：名無しさん＠寒露：2017/10/19(木) 11:33:16 ID:???
上記の調査結果から以下のことを推論しました。
戦闘時の内部カウンタは経過時間の１０倍らしいので、１分で３０００カウント、１秒で５０カウントです。
「unit_action_bdr の数値」÷「ユニットの speed 値」＝「間隔のカウント数」
のような関係がありそうです。
しかし、実際には unit_action_bdr = 4000, speed = 80 にしても、攻撃間隔は毎秒よりも微妙に遅くなるので、
「攻撃間隔＝間隔カウント＋２」ぐらいになってるのかもしれません。

この計算式を計測結果と比較してみました。
unit_action_bdr = 4000 の場合
speed = 60 なら攻撃間隔は 4000/60+2=69カウントなので、一分間に 3000/69= 43.5回攻撃します。
speed = 70 なら攻撃間隔は 4000/70+2=59カウントなので、一分間に 3000/59= 50.8回攻撃します。
speed = 80 なら攻撃間隔は 4000/80+2=52カウントなので、一分間に 3000/52= 57.7回攻撃します。
speed = 100 なら攻撃間隔は 4000/100+2=42カウントなので、一分間に 3000/42= 71.4回攻撃します。

unit_action_bdr = 3500 の場合
speed = 60 なら攻撃間隔は 3500/60+2=60カウントなので、一分間に 3000/60= 50.0回攻撃します。
speed = 70 なら攻撃間隔は 3500/70+2=52カウントなので、一分間に 3000/52= 57.7回攻撃します。
speed = 80 なら攻撃間隔は 3500/80+2=46カウントなので、一分間に 3000/46= 65.2回攻撃します。

だいたい理論値と計測値が一致するようです。
オリシナ作者がユニットごとの素早さを調節する際の参考にでもしてください。

702：名無しさん＠寒露：2017/10/19(木) 14:10:10 ID:???
ありがてえありがてえ

703：名無しさん＠寒露：2017/10/19(木) 17:44:29 ID:???
>>700 >>701
制作してからずっと思ってた謎が解けた
今年一番のありがとうを贈りたいよ

704：名無しさん＠寒露：2017/10/21(土) 11:14:54 ID:gIvx7CCw
遠隔攻撃の速度について調べてる際に、ゲームの描画速度について矛盾点に気づきました。過去ログには描画速度が 25 fps とあったので、フレームレートと内部カウンタは別に進んでる（フレームスキップする為とか？）のだと思ってましたが、よくわかりません。

wiki によると、直進型の遠隔攻撃で「speed は１フレーム毎に進むドット速度」とあります。したがって range = 500, speed = 100 なら最大射程まで到達するのに５００フレームかかるはずです。実際に見てみると、戦闘時の経過時間で５０（１０秒）でした。５００フレームで１０秒なら、１秒に５０フレーム (50 fps) となります。これだと、内部カウンタとフレームの進み具合は完全に一致します。

50 fps で動いてるとするなら、先の接近攻撃のスライド速度も正しいことになります。wiki によると、接近攻撃の slide_speed は「12なら９コマ、25なら４コマで敵に当たる。」とあります。例えば、unit_sword_slide = 2 ならフレームごとに 2% 前進するので、５０フレーム（１秒）で前進して、更に５０フレーム（１秒）で戻ります。前後にスライドするのに丁度２秒かかる訳で、これは実際に計測した攻撃間隔と一致します。

上記の wiki の記述が正しいとすると、描画速度は 50 fps ということになります。しかし、wiki 内の「関数（イベントの設定）」で wait の説明に「このゲームは25fpsですので１秒間waitするなら25とします。」とあります。もしかすると全体マップと戦場画面でフレームレートが違うのかもしれません。（全体マップでは 25 fps だけど、戦場では 50 fps になるとか。）あるいは、単に wiki に書く際にフレームと内部カウンタを混同してるのかもしれません。（speed は１フレームではなく、１カウント毎とか。）どなたか詳しい情報を持ってる方がおりましたら、教えて頂けるとありがたいです。

705：名無しさん＠寒露：2017/10/25(水) 21:56:12 ID:???
一撃で敵を倒しやすいインフレ・シナリオでは、敵が死んだ後もその場所を攻撃し続ける現象が発生します。本家シナリオでは気になりませんが、「Brave of Island」で人材を強化しまくって無双プレイしてると、敵が居ない所を２度３度と攻撃するのが目に付きます。

どうしてこうなるのか script を見てみると、context.dat の unit_search_bdr が関係してました。標準の unit_search_bdr = 100 だと１００カウント（２秒）ごとに標的を探すような感じです。「Brave of Island」ではこの値が unit_search_bdr = 160 と大きいので、敵が死んだ後に、誰もいない所をしばらく攻撃し続けます。試しに 50 に減らしてみたら、敵を倒す度に攻撃目標を切り替えてくれました。

無駄撃ちを避け、次々に敵を倒して爽快感を得たい場合は、unit_search_bdr の値を低くすると良さそうです。一方で、特定人材の攻撃力が強過ぎて、大群を片端から掃除してしまう、というのが嫌な場合は、unit_search_bdr の値を高くすることで、空撃ちを多くして、集団戦に弱くできます。「Brave of Island」のスクリプトは凝ってるので、参考になります。

706：名無しさん＠寒露：2017/10/26(木) 20:03:34 ID:???
こういうのほんと嬉しい

707：名無しさん＠寒露：2017/10/28(土) 10:47:56 ID:???
wiki にある「skill 構造体： missile 」のページの start_degree_type の説明で、「7: スキル発射方向をユニットの向きにします」とありますが、この説明は間違ってるような気がします。実際には「ユニットの向きにスキルを発射します」ではないでしょうか。本家シナリオのスクリプトで start_degree_type = 7 を使ってるのはソルジャー系の「シールド」で、盾は敵の方向ではなくユニットの向きに追随して動きます。

それに、start_degree_turnunit という後に追加された命令は「スキル発射方向にユニットの向きを変えます。」というものです。わざわざ新規に追加したのは、start_degree_type = 7 とは逆の効果にする為だと思います。

ただ、これは私がスキルを試してる際にそう見えただけで、本来の動作なのかはわかりません。とりあえず、他の開発者の経験を知りたくて書き込ませてもらいました。

708：名無しさん＠寒露：2017/10/28(土) 10:53:38 ID:???
>>707
日本語の問題だけども元からある説明とあなたの説明とでは前後が入れ替わってるだけでいってることは同じだよ

709：名無しさん＠寒露：2017/10/28(土) 16:19:14 ID:???
>>708
あなたのおっしゃる通りです。ご指摘ありがとうございます。

707番の投稿は無視してください。wiki の説明を私が誤読してました。「スキル発射方向を（標的の方向ではなく）ユニットの向き（と同じ）にします」ということですね。それなら実際の挙動通りで問題ありません。「スキル発射方向を（start_degree で標的の方向からずらした後で）ユニットの向き（として扱うこと）にします」みたいな誤解をしてました。本家シナリオで start_degree_type = 7 は start_degree と一緒に使わずに、単独で設定してるので、この場合だけ start_degree は無視されるんだと思います。

710：＜あぼーん＞：＜あぼーん＞
＜あぼーん＞

711：名無しさん＠寒露：2017/10/29(日) 10:00:19 ID:xXl2IxAQ
>>704
の投稿で、このゲームが 25 fps か 50 fps なのか質問した者です。
過去ログを調べると共に、実際にイベントも作って試してみました。結論から言うと、私が調べた限りでは、このゲームは戦闘中もそれ以外も 50 fps で、wiki 等に 25 fps と書かれてるのが間違いです。以下にその根拠を示します。

「改造・制作スレ」の706(2010/05/22)に、開発者（ななあし様？）による「speed=1000だと１フレームに10ドット進みます。」との記述がありました。wiki の speed の説明は正しいということです。
「改造・制作スレ part3」の558(2011/11/15)に、開発者（ななあし様？）による「 戦闘開始から１フレーム毎にカウンタは１ずつ増えます。カウンタ１０ごとに制限時間が１減ります。」との記述がありました。普通速度では１分間で制限時間が３００減ることからして、１分間＝３０００カウント＝３０００フレームになります。戦闘中は 50 fps ということみたいです。

「改造・制作スレ part4」の403(2012/06/24)に、「intervalがないと恐らくintervalのデフォルト設定である5フレーム空けての発射になります。ヴァーレンは1秒25フレームなので、大体0.2秒後くらいに次弾が発射されることになります。」と書き込みがありますが、この回答者は開発者ではないので、不正確な可能性があります。
同じ人による「初段攻撃の発動間隔ということなら、実験したかぎりでは素早さ60のキャラでおよそ60フレーム(約2.4秒)になるようです。」との記述は、私の計測結果（unit_action_bdr = 4000 なら移動中の遠隔攻撃の間隔は素早さ60のキャラで75フレーム(約1.5秒)ぐらい）と合いません。そもそも、攻撃間隔については、同じ speed でも context 設定によって全く変わるので、どういう環境で計測したのかが不明では比較できません。

「改造・制作スレ part7」の635(2015/05/25)に、不明な回答者による「このゲームは標準速度だとだいたい１秒２５フレームなので750だと３０秒おきに判定されるという意味になります。」との記述がありました。isInterval 関数についての質問だったので、実際にゲーム内で以下のような単純な戦闘中イベントを作って試してみました。

battleEvent(timer_shake)

event timer_shake {
rif (isInterval(750)){
shake()
}
}

すると、１５秒ごとに画面が揺れました。そもそも isInterval という関数は、「戦闘カウントが数値で割り切れたら１が返ります。」という仕組みなので、１秒５０カウントだから７５０÷５０＝１５秒おきに発生する訳です。つまり、「１秒２５フレームなので」という根拠は見当違いですし、結論も間違っていました。どうも、この回答者は開発者ではなさそうです。

そうなると、wiki の各所にある 25 fps という記述自体の信憑性が怪しくなってきます。例えば、「wait(数値)」の説明に、「数値フレームだけウェイトします。このゲームは25fpsですので１秒間waitするなら25とします。」とあります。上記の定期的に画面を揺らすイベントに wait を追加して実験してみました。

event timer_shake {
rif (isInterval(750)){
shake()
wait(200)
shake()
}
}

wiki が正しければ、２００÷２５＝８で８秒間止まるはずです。しかし、実際には、揺れ始めてから４秒間止まって、再度揺れました。やはり、戦闘中（戦場画面）は 50 fps です。ついでに、ターン開始時に画面を２回揺らすイベントを作って実験してみました。待ち時間を wait(200) にすると、やはり４秒間止まります。ワールドマップ（戦略画面）でも、同じ 50 fps で動いてるようです。こうなると、wiki の説明自体が間違ってることになります。

どうして、いろいろな所に 25 fps という記述があるのか、理由は不明です。開発者が wiki の説明を書いてる訳ではないので、よく知らない人が掲示板等の誤った情報を参考にして、そのまま wiki に書き込んでしまったのかもしれません。あるいは、もしかすると「内部の座標計算やイベント処理は 50 fps でやってるけど、実際に表示する際は 25 fps で描画してる。」という事かもしれません。こればかりは開発者じゃないと確認しにくいです。（ゲーム画面を動画に撮って１フレームずつ動きを検証すれば判るかも？）とりあえず、他の人の反対意見が無ければ、wiki を訂正しようかと思います。

712：名無しさん＠寒露：2017/10/29(日) 10:29:20 ID:???
細やかな検証だね
私は支持するよ

713：名無しさん＠寒露：2017/10/29(日) 11:11:45 ID:???
>>711
自分の環境でデフォのバージョンは7.0ダウンロードした日17.8.29で40fpsだったよ
ここらあたりで上下してたから固定されてるっぽい
40fpsというのは外部ソフトでFPS表示と弓スピード100のレンジ500の同じ状況で検証
矢が出た瞬間停止録画開始と同時に停止解除、矢が消えたと同時に録画停止大体12秒ちょい計算上は12.5秒かかるはずだからまぁこんなものでしょう
昔のスクリプトでいじれるデータでのけてあるのが5.6あたりでそちらで試しても同じだったそれより前のバージョンはフリームのやつだったりHDDクラッシュでバイバイしてるからしらない
そっちで本当に10秒だとしたら環境で速度が変わってる可能性もあるしそれよりも前のバージョンだと違ったのかもしれない

後昨日いうかどうか悩んだけど多分自分はもう触れないだろうし最後に一つだけいっておくけども
最近ずっと独り言状態になってるけど前のごたごたで嫌われてるかもしれないから聞いても返ってこないかもしれないよ
714：名無しさん＠寒露：2017/10/29(日) 21:34:25 ID:???
>>713
検証実験ありがとうございます。他の人の実験結果は参考になります。おかげで「環境で速度が変わる」可能性を見落としてたことに思い至りました。

私は新参者で、過去にどんなごたごたがあったのかは知りませんが、最近は開発者が全く書き込んでませんね。ヴァーレントゥーガ作品群のファンとして、開発者やオリシナ作者の手助けになればと思って、いろいろ調べてます。


開発者（ななあし様）はゲームの動作速度について何 FPS かを明記してません。はっきりしてるのは「戦闘中の経過時間の表示がフレーム数の 1/10 である」という関係だけです。本家シナリオでの標準戦闘時間は５００なので、一回の戦闘は５０００フレームで構成されています。

ということは、FPS を知るには実際の戦闘時間を時計で測ればいい訳です。私の実験環境（効果音もBGMも無い、一番軽い状態）ではだいたい１分４０秒でした。つまり、経過時間５００で１００秒だから、５０００÷１００＝５０ fps という計算です。しかし、こうやって計測できる FPS は環境や動作状況によって異なります。ゲーム動画を撮ってみようかと、FPS表示する撮影ソフトを試してたら、４５ fps ぐらいまで遅くなりました。どうも、50 fps というのは理論上の最高値であって、実際のプレイ環境ではもっと下がるようです。

どうしてそうなるかというと、ヴァーレントゥーガにはフレームスキップ機能が無いからだと思います。パソコンが遅かったり、他に重いソフトが動いてたり、描画に時間がかかったり、ユニット数が多かったり、スキルのエフェクトが派手だったりすると、ゲームの動作速度自体が遅くなります。ゲームの中には重い処理を自動的にスキップ（コマ落ち）して、体感速度を一定に保とうという仕組みのもありますが、ヴァーレントゥーガはそのまま１フレームずつ着実に動かします。

要するに、戦闘中に重い処理があると、全体の動きがスローモーションになって、経過時間もゆっくりと進みます。戦闘時間は同じ 500 でも、終わるのに２分かかったなら、５０００÷１２０＝４２ fps ということになります。何年も前の古いパソコンで、派手な戦闘をしたなら、２５ fps しか出なかった、というのも十分考えられます。つまり、厳密に何フレームだから何秒という固定された関係にはなってません。だいたい１秒間に２５〜５０フレームぐらい進むけど、ゲーム内容やプレイする環境によって変動します。オリシナを作る際は戦闘経過時間（戦闘カウント、フレーム数）と実時間（秒）が一定しないことを考慮に入れる必要がありそうです。

715：名無しさん＠寒露：2017/10/29(日) 22:40:03 ID:???
まさかそうとるとはおもわなかったから本当に最後にいうけどあなたが嫌われてるっていう意味だよ
過疎なのか嫌われてるのかは知らないけど今までほとんど返答なしで答えなければwikiいじるぞっていうのはやめておいたほうがいいってことだよ

716：名無しさん＠寒露：2017/10/30(月) 08:07:12 ID:???
答えがないのは誰も答えを知らないからだろ

717：名無しさん＠寒露：2017/10/30(月) 09:13:56 ID:???
別に嫌ってないけどな
それどころかよくやると感心してたぞ
そういう風に喧嘩売るのやめなよ
そして答えてないのは語ることを持たないから

718：名無しさん＠寒露：2017/10/30(月) 10:12:58 ID:???
とりあえず一人やたら因縁つけてる奴がいるのは分かった

719：名無しさん＠寒露：2017/10/30(月) 14:02:17 ID:???
正直、同じレベルの検証ができないからありがとう以上の言葉を持てないんだよ
俺はこうやっていろいろ試して解明してくれてるのは非常に助かってるし嬉しいと思ってる

720：名無しさん＠寒露：2017/10/30(月) 15:41:24 ID:???
返答なし=嫌われてるってすごい理論だな
wikiって誰でも編集できることに意味があるんだから正しい情報に書き換えるのは別にいいでしょ
前のごたごたも何のことだか分からないし独り言状態ってぽつぽつ反応やお礼があるんだが

721：名無しさん＠寒露：2017/10/30(月) 16:48:26 ID:???
前のゴタゴタがすぐ上のことなら、自分の気に食わない人を同一人物と決めつけて、それに対する自分の意見を総意とする人がいるのはやだな
このスレは質問も検証も基本的に有意なことだと思うし、是非色々試して欲しい

722：名無しさん＠寒露：2017/10/30(月) 23:19:36 ID:???
加入ユニットに関して質問です

addUnitを使ってユニット加入イベントを作りたいのですが、領土１・その領土のキャパが１部隊という状態で、スクリプトを使って人材ユニットを陪臣でない状態で部隊に加入させる方法はないでしょうか？
どうしても陪臣でない状態で加入させたいと考えています

723：名無しさん＠寒露：2017/10/31(火) 04:11:14 ID:hT6ogIMA
>>722
非人材ユニットを領地に追加。これに部隊リーダーだった人材1をメンバーとして追加してさらに人材2を追加。
この部隊のリーダーユニットを削除してやればできるのでは。

724：名無しさん＠寒露：2017/10/31(火) 21:25:19 ID:???
>>723
addPower(POWER)
addUnit(MASTER,SPOT)
addUnit(DUMMY,POWER)
addUnit(NAKAMA,DUMMY)

storeLeaderOfPower( POWER , @aaa)

set(idx,0)
while(idx<count(@aaa)){

index(@aaa,idx,@aaa_get)
msg(&idx&の&@aaa_get&)
if(isTalent(@aaa_get)==0){
msg(加入)

addUnit(@aaa_get,MASTER)
}

add(idx,1)
}

changeMaster(MASTER)


こんな感じでやりましたが、加入の後のaddUnitが動かないですね
加入は表示されるので、通ってはいるみたいですが
間違ってる部分あったらごめんなさい

725：名無しさん＠寒露：2017/10/31(火) 21:29:06 ID:???
あ、厳密にはうごいてるみたいですが、DUMMYが人材じゃないためにMASTERの下に別のDUMMYが加入してしまうみたいです（キャパ１なのでよく見えてなかった)

また、そのあとにaddUnit(NAKAMA,MASTER)も試しましたが陪臣になりました

726：名無しさん＠寒露：2017/10/31(火) 21:57:32 ID:???
DUMMYがclass構造体ならそりゃ別のがaddunitされるよ

addPower(POWER)
addUnit(MASTER,SPOT)
addUnit(DUMMY,POWER)
storeLeaderOfPower( POWER , @aaa)
addUnit(NAKAMA,@aaa)
(以下略)

これでどう

というかそのよくわからないwhileは何ぞ
他のユニットがいるところで弄る想定なの？

727：名無しさん＠寒露：2017/10/31(火) 21:59:42 ID:???
>>726
unit DUMMY
{
name = 陪臣ダミー
}

こんな感じですね
classではないです
talentじゃないという意味で人材じゃないと言いました

728：名無しさん＠寒露：2017/10/31(火) 22:00:59 ID:???
whileに関しては別の領地を新しく発生させてみても同じだったので、まあこれでいいかな？って感じです
いじるの自体はどこででもOKです。最終的にSPOTが１つであれば問題ありません

729：名無しさん＠寒露：2017/10/31(火) 22:03:28 ID:???
連投すいません

addPower(POWER)
addUnit(MASTER,SPOT)
addUnit(DUMMY,POWER)
storeLeaderOfPower( POWER , @aaa)
addUnit(NAKAMA,@aaa)
(以下略)

これも試してみましたが、addUnitの部分で結局別のDUMMYがMASTERの下についちゃいますね

730：名無しさん＠寒露：2017/10/31(火) 22:06:45 ID:???
じゃあわからないな
ごめんよ

731：名無しさん＠寒露：2017/10/31(火) 22:11:11 ID:???
いえいえ、ありがとうございます
やってるうちに何かみつかったり、他の方の回答で解決するかもなので、もう少しがんばってみます！

732：名無しさん＠寒露：2017/10/31(火) 22:24:28 ID:???
>>723の解釈を間違ってないか
DUMMYにMASTERとNAKAMAを追加してDUMMYを消すのでは

733：名無しさん＠寒露：2017/10/31(火) 22:37:30 ID:???
>>732
DUMMYをMASTERに追加してみましたが、マスターなので追加できないみたいです

changeMasterは念のためやってるだけですね

最終手段はNAKAMAを全部タレント属性抜きにしてそもそも陪臣にならないようにするぐらいですが、その他のデメリットがヤバい感じです

734：名無しさん＠寒露：2017/10/31(火) 23:05:37 ID:???
やってるうちに不具合っぽいものを見つけたのでご報告

talentでないユニットにマスターをやらせて、そのマスターをそのまま別勢力の人材下に加入させると、何故か陪臣になりました

735：名無しさん＠寒露：2017/11/01(水) 00:30:01 ID:E6zj026E
人材ユニットを追加する部隊リーダー人材がマスターであるときも考慮しないといけなかったのか。
だとすると、人材ユニットを追加する部隊のリーダーがマスターであった場合は、ダミーの人材ユニットを適当な領地に追加してこれにマスターを引き継がせます。
さらに非人材のダミーユニットを人材ユニットを追加する部隊がいる領地に追加します。
このダミーユニットの部隊にマスターとメンバーにする人材ユニットの順で追加します。
この部隊からリーダーユニットを削除したあとで勢力マスターを元の人材に戻します。
マスターを代行させていたダミーの人材ユニットを適当に邪魔にならない領地に飛ばします。
この方法でいけませんかね。
ただし、ダミーのユニットが処理の過程で発生するのでメンバーが最低二つは空きがないとだめですけど。たしか溢れたメンバーは削除されていたはず。

736：名無しさん＠寒露：2017/11/01(水) 00:33:06 ID:E6zj026E
>>735訂正
>このダミーユニットの部隊にマスターとメンバーにする人材ユニットの順で追加します。
正しくは
>このダミーユニットの部隊にマスターだった人材とメンバーにする人材ユニットの順で追加します。

>>733
その解釈でアタリです。

737：名無しさん＠寒露：2017/11/01(水) 00:36:16 ID:E6zj026E
>>736の訂正。
レス番は733ではなく732に対してです。連ミスごめん。

738：名無しさん＠寒露：2017/11/01(水) 01:20:03 ID:???
>>735
ありがとうございます
早速やってみました

addPower(POWER)
addSpot(DUMMYSPOT,POWER)
addUnit(TALENTDUMMY,DUMMYSPOT)
showSpot(DUMMYSPOT)
changeMaster(TALENTDUMMY)
addUnit(NOTALENTDUMMY,SPOT)
addUnit(MASTER,NOTALENTDUMMY)
addUnit(NAKAMA,NOTALENTDUMMY)
storeUnitOfPower(POWER,@POWER_units)
set(idx,0)
while(idx<count(@POWER_units)){
index(@POWER_units,idx,@POWER_units_get)

if(isTalent(@POWER_units_get)== 0){
//NOTALENTDUMMYのみが該当
eraseUnit(@POWER_units_get)
}

add(idx,1)
}
removeSpot(DUMMYSPOT)
changeMaster(MASTER)


このままだとマスター（マスター）・ナカマ（陪臣）という部隊になります
changeMasterをコメントアウトすると、非人材ダミー・マスター・ナカマという部隊になります
eraseUnitをコメントアウトすると、非人材ダミー・ナカマの部隊とマスターの部隊に分かれました

どうやら非人材部隊に所属した時点で陪臣になっているという問題があるようです

理解が間違ってたらごめんなさい

739：名無しさん＠寒露：2017/11/01(水) 19:31:47 ID:???
>>715
これは申し訳ありませんでした。
wikiをいじってはいけないとは知らなかったので、情報が不正確なら訂正した方がいいと思ってました。しかし、私は軽率で間違うことが多いので、wikiに関しては慎重な方にお任せします。

その他の閲覧者へ
こういう掲示板のマナーには疎いもので、私の行動を不快に感じた方にはあやまります。他に問題がありましたら、寛容な方は今後ともご指摘ください。
私の実験は、私が試した範囲内での観測結果に過ぎないので、推測や結論が間違ってるかもしれません。実際のゲーム内の動作とは異なる可能性があるので、あくまで参考レベルに留めてください。


スキルを試す為に何度も戦闘させてて感じたのですが、守備側（COM勢力）が、戦闘開始直後から迎撃してくる時と、初期位置で待ち構えてる時があります。実験条件を同じにする為には、毎回どちらか一方に固定したいので、どういう条件で挙動が変わるのかを調べてみました。

まず第一に、マスターの好戦値（kosen）が高いほど迎撃します。（マスターが存在しない勢力なら、その勢力に設定された好戦値）
マスターの kosen 値を指定しない場合、40回攻め込んで、迎撃してきたのは 21回でした。（５割ぐらい）
マスターの kosen = 100 にした場合、40回攻め込んで、迎撃してきたのは 31回でした。（８割ぐらい）
マスターの kosen = 80 にした場合、40回攻め込んで、迎撃してきたのは 26回でした。（６割ぐらい）
マスターの kosen = 50 にした場合、40回攻め込んで、迎撃してきたのは 16回でした。（４割ぐらい）
マスターの kosen = 30 にした場合、40回攻め込んで、迎撃してきたのは 12回でした。（３割ぐらい）
マスターの kosen = 10 にした場合、40回攻め込んで、迎撃してきたのは 3回でした。（１割ぐらい）
サンプル数が少ないのか乱数分布のせいか、うまく比例しませんが、だいたい kosen 値に依存してます。

kosen 値が 100 でも迎撃しないことがあるのは、btl_counter が関係してるみたいです。kosen = 100 にした上で、btl_counter = 80 だと、50回攻め込んで、迎撃してきたのは 41回でした。試しに btl_counter = 50 に減らすと、50回攻め込んで、迎撃してきたのは 30回でした。更に btl_counter = 20 に減らすと、50回攻め込んで、迎撃してきたのは 11回でした。シード値によって乱数にばらつきがあるのか、他にも要因があるのか、試行回数を増やしても正比例しませんが、迎撃する確率に差があるので、第二の条件は btl_counter と言えます。

それなら、btl_counter が高ければ kosen が低くても迎撃するのかと、kosen = 1, btl_counter = 100 でどうなるか試してみましたが、50回攻め込んで、迎撃してきたのは 3回でした。迎撃しやすいのは、kosen と btl_counter の両方が高い場合のようです。それで、kosen = 100, btl_counter = 100 にしたら常に迎撃するようになりました。

740：名無しさん＠寒露：2017/11/01(水) 19:32:21 ID:???
あと、戦力値も比較してるようで、守備側の戦力値が、攻撃側の半分以下だと、好戦値に関係なく迎撃しません。半分より少しでも上回ると、迎撃するようになります。また、守備側の戦力値が極端に低い場合は、戦闘開始直後に逃げ出します。どのくらい少なければ逃げるかも、マスターの好戦値に依存していて、前衛同士なら、kosen = 100 なら 4.3倍、kosen = 70 なら 3.2倍、kosen = 50 なら 2.2倍、kosen = 30 や 10 なら 2倍、ぐらいの戦力差で開幕逃亡するみたいです。好戦値が極端に低い場合でも、戦力差が２倍以下なら逃げませんが、２倍を少しでも上回ると逃げるようになります。ただ、前衛と後衛で微妙に違うし、判定基準はわかりませんでした。

また、攻撃側の戦力値が、守備側に比べて btl_intercept のパーセント未満なら、kosen に関係なく迎撃します。btl_intercept の値が大きいほど、少しでも戦力差があれば迎撃します。btl_intercept の値が小さいほど、少ない戦力で攻めても待機します。例えば、標準では btl_intercept = 50 なので、攻撃側の戦力が半分未満なら、攻撃側は必ず迎撃してきます。これは戦闘開始後に双方の戦力値が変動した場合も、適用されるみたいで、部隊を少しずつ退却させていくと、攻撃側の戦力値が半分を切った時点で、待機してた守備側が迎撃に転じます。

とりあえず、COM に必ず迎撃してきて欲しい場合は、kosen と btl_counter の値を両方とも 100 にして、攻撃側の戦力値を守備側の４倍以下にすればいいです。逆に、COM にその場で待機しといて欲しい場合は、kosen を -1 にして、攻撃側の戦力値を守備側に対して btl_intercept ％以上にすればいいです。kosen を下げると戦力差で逃げ出しやすくなりますが、攻撃側の戦力値を守備側の２倍以下にすれば逃げません。戦力値と逃亡の関係は btl_retreat_coe の２番目の値が怪しいのですが、どういう仕組みなのかわかりませんでした。

btl_counter や btl_intercept は全ての戦いに反映されるので、実験目的以外で変更すると、予想外の影響があるかもしれません。オリシナ作者が勢力に個性を出したい場合は、好戦値で調節するといいです。本家シナリオの設定値を見てると、ななあし様が種族や勢力の特徴をよく考えてるなあ、と感心します。

741：名無しさん＠寒露：2017/11/01(水) 21:16:13 ID:???
ちゃんと投稿できたか見てたら、内容に書き間違いを発見しました。
(誤) 標準では btl_intercept = 50 なので、攻撃側の戦力が半分未満なら、攻撃側は必ず迎撃してきます。
(正) 標準では btl_intercept = 50 なので、攻撃側の戦力が半分未満なら、守備側は必ず迎撃してきます。
投稿前にもっとよく見直すべきでした。何遍もミスしてすみません。

742：名無しさん＠寒露：2017/11/02(木) 23:01:25 ID:???
また740番の訂正です。自分で条件を書いといて結論に含めるのを忘れてました。戦力差４倍は逃亡させない条件で、迎撃してもらうには２倍未満にしないといけないんでした。
(誤) COM に必ず迎撃してきて欲しい場合は、kosen と btl_counter の値を両方とも 100 にして、攻撃側の戦力値を守備側の４倍以下にすればいいです。
(正) COM に必ず迎撃してきて欲しい場合は、kosen と btl_counter の値を両方とも 100 にして、攻撃側の戦力値を守備側の２倍未満にすればいいです。
他にもミスしてるかもしれませんが、気付いたら訂正します。

743：名無しさん＠寒露：2017/11/03(金) 23:03:48 ID:???
今まで不明だったパラメータを検証してもらえるの有り難い

744：名無しさん＠寒露：2017/11/06(月) 22:53:47 ID:???
うーむ、すごい検証数だ。お疲れ様です

745：名無しさん＠寒露：2017/11/07(火) 00:16:53 ID:???
ユニットを出し過ぎて大規模戦闘をし過ぎるとクラッシュする対策はないでしょうか
確か死んだユニットにも何かデータ割り当ててたと思うのですが、それを無効にしたりなど出来ませんか

746：名無しさん＠寒露：2017/11/07(火) 19:49:23 ID:???
参考までに聞きたいのですが、ユニット出しすぎって何体くらいでなりましたか？

747：名無しさん＠寒露：2017/11/09(木) 20:52:33 ID:???
>>745
自分は本家シナリオや「きのたけ」で召喚しまくっても、ユニット数の制限で出せなくなる事はあっても、クラッシュはしませんでした。それで不思議に思って、召喚しまくる実験をしてみました。

陣営ごとのユニット制限を btl_unitmax = 1000 に増やした上で、敵ユニットに範囲攻撃を使わせて、召喚されたユニットを一気に掃除することで、ユニット数の制限に関わらずに、大量に召喚することができます。（掃除しないと、表示されてるユニット数が制限を越えた時点で、それ以上の召喚ができなくなる。）召喚し続けると Vahren.exe のメモリー消費量が増えて行き、ユニット数が多過ぎるとゲームが落ちました。終了時に OS のエラー通知が無かったので、アプリケーション側で状況を見て自ら正常終了した感じです。

次に実験データを例示し、最後に私の結論を載せます。メモリー消費量はタスクマネージャーの数値ですが、微妙に上下するので厳密ではありません。戦場のオブジェクトやエフェクト、BGM、効果音、顔絵などで、実際のゲームではもっと消費が増えるはずです。スキルやエフェクトによる違いは試してないので、それらがユニット数に影響するかはわかりません。

748：名無しさん＠寒露：2017/11/09(木) 20:53:27 ID:???
[ 最新の v7.00 2017-10-12版 ]
敵は１ユニット、自軍は８ユニットで 1000 * 8 = 8000ユニット召喚しました。メモリー消費量は、召喚前は 332,748 KB、召喚終了時は 1,315,692 KB でした。(1315692 - 332748) / 8000 = 122.7 なので１ユニット当たり 123 KB ぐらいです。

敵は１ユニット、自軍は８ユニットで 1400 * 8 = 11200ユニット召喚しました。メモリー消費量は、召喚前は 326,152 KB、召喚終了時は 1,701,876 KB でした。ユニットを召喚するたびに増えるメモリー量は 123 KB で一定してます。

敵は１ユニット、自軍は８ユニットで 1440 * 8 = 11520ユニット召喚しました。メモリー消費量は、召喚前は 326,228 KB、召喚終了時は 1,741,600 KB でした。

敵は１ユニット、自軍は８ユニットで 1450 * 8 = 11600ユニット召喚しようとすると、途中で落ちました。召喚できるユニット数の限界は 11500 ぐらいのようです。

敵ユニットを１体から８０に増やしてみました。敵は８０ユニット、自軍は８ユニットで 1420 * 8 = 11360ユニット召喚しました。メモリー消費量は、召喚前は 336,484 KB、召喚終了時は 1,732,724 KB でした。

敵は８０ユニット、自軍は８ユニットで 1430 * 8 = 11440ユニット召喚しようとすると、途中で落ちました。初期配置ユニットが多いと、召喚できるユニット数が減るようです。

味方ユニットも８体から８０に増やしてみました。敵は８０ユニット、自軍も８０ユニットで 141 * 80 = 11280ユニット召喚しました。メモリー消費量は、召喚前は 345,092 KB、召喚終了時は 1,731,812 KB でした。

敵は８０ユニット、自軍も８０ユニットで 142 * 80 = 11360ユニット召喚しようとすると、途中で落ちました。陣営や召喚かに関係なく、戦場に登場した累計ユニット数に限界があるようです。

[ v7.00 の古い 2017-08-28版 ]
敵は１ユニット、自軍は８ユニットで 1000 * 8 = 8000ユニット召喚しました。メモリー消費量は、召喚前は 326,920 KB、召喚終了時は 558,408 KB でした。古いバージョンの方が、明らかにメモリー消費量が少ないです。

敵は１ユニット、自軍は８ユニットで 1400 * 8 = 11200ユニット召喚しました。メモリー消費量は、召喚前は 326,832 KB、召喚終了時は 650,632 KB でした。(650632 - 326832) / 11200 = 28.9 なので１ユニット当たり 29 KB ぐらいです。

敵は１ユニット、自軍は８ユニットで 1440 * 8 = 11520ユニット召喚しました。メモリー消費量は、召喚前は 326,912 KB、召喚終了時は 659,420 KB でした。古いバージョンでは、ユニットを召喚するたびに増えるメモリー量は 29 KB で一定してます。

敵は１ユニット、自軍は８ユニットで 1450 * 8 = 11600ユニット召喚しようとすると、途中で落ちました。メモリー消費量が少なくても、同じように落ちるので、メモリー不足はクラッシュの原因じゃないです。

敵ユニットを１体から８０に増やしてみました。敵は８０ユニット、自軍は８ユニットで 1430 * 8 = 11440ユニット召喚しました。メモリー消費量は、召喚前は 330,204 KB、召喚終了時は 660,548 KB でした。新バージョンだと落ちたのに、古いバージョンだと、最後まで召喚できました。

敵は８０ユニット、自軍は８ユニットで 1440 * 8 = 11520ユニット召喚しようとすると、途中で落ちました。最大数は微妙に違いますが、古いバージョンでも、累計ユニット数には限界がありました。

味方ユニットも８体から８０に増やしてみました。敵は８０ユニット、自軍も８０ユニットで 142 * 80 = 11360ユニット召喚しました。メモリー消費量は、召喚前は 331,240 KB、召喚終了時は 661,620 KB でした。やはり、古いバージョンの方が少し多くユニットを出せます。

敵は８０ユニット、自軍も８０ユニットで 143 * 80 = 11440ユニット召喚しようとすると、途中で落ちました。80 + 80 + 11440 = 11600 なので、累計ユニット数は 11500 ぐらいまでみたいです。

[ 開発版の v6.85v 2017-06-16版 ]
敵は１ユニット、自軍は８ユニットで 1440 * 8 = 11520ユニット召喚しました。メモリー消費量は、召喚前は 329,340 KB、召喚終了時は 661,108 KB でした。

敵は１ユニット、自軍は８ユニットで 1450 * 8 = 11600ユニット召喚しようとすると、途中で落ちました。メモリー消費量や限界は 2017-08-28版と同じようです。

[ 正式版の v6.90 2017-03-27版 ]
敵は８０ユニット、自軍も８０ユニットで 142 * 80 = 11360ユニット召喚しました。メモリー消費量は、召喚前は 331,492 KB、召喚終了時は 662,436 KB でした。

敵は８０ユニット、自軍も８０ユニットで 143 * 80 = 11440ユニット召喚しようとすると、途中で落ちました。メモリー消費量や限界は 2017-08-28版と同じようです。

749：名無しさん＠寒露：2017/11/09(木) 20:54:30 ID:???
実験の結果、最新版(2017-10-12) の問題点を発見しました。ユニット・データのメモリー消費量が古いバージョンに比べて４倍もあります。古いバージョンは１ユニットごとに 29 KB ぐらいだけど、最新版では１ユニットごとに 123 KB ぐらいです。したがって、ユニットを大量に出したいなら、最新版(2017-10-12) を使わない方がいいです。64-bit OS ならともかく、メモリー空間が狭い上に共有されてる 32-bit OS では、ユニット数の限界が来る前に、メモリー不足で動かなくなります。古いバージョンでも１ユニットに 29 KB もメモリーを使ってるのは謎です。数値データだけならもっと少ない筈なので、ユニットごとに画像データを保持してるのか、あるいは不要になったスプライトを解放してないのかもしれません。context や class の設定を変えたり、画像の大きさを変えたりしてみましたが、特に違いはありませんでした。

どうも、「死んだユニットにも何かデータ割り当ててる」のではなく、死んでもデータが丸ごと残ってるような気がします。その証拠に、スクリプトでは死亡ユニットのデータも取得できますし、死亡ユニットにスキルを使わせることもできるみたいですし、死体が消えずに残る不具合（沈んだユニット画像の上端が残る）もあります。スクリプトでユニットを取り除いた場合も、単に死亡扱いになるだけで、データは残ってました。ユニット数の限界に関しては、バグでは無いので、開発者に対応してもらうのは難しいように思います。

とりあえず、オリシナ作者ができる大規模戦闘時のクラッシュ対策としては、戦場に登場する累計ユニット数を 11500 ぐらいまでにするしかありません。守備側の初期配置数や援軍、攻撃側の出撃数や増援、それに双方が召喚する、全てのユニット数の合計です。無限召喚スキル（遠隔攻撃から召喚への連鎖）は、召喚数自体は設定できませんが、スキル使用間隔と連射数から、戦闘時間内に出せる数が決まります。予め、どれだけのユニットが戦場に出てくるかを計算して、その合計が限界以内に収まるようにすれば、クラッシュを避けれるでしょう。

750：名無しさん＠寒露：2017/11/10(金) 06:36:19 ID:???
これはかなり参考になるデータ
ありがたいです

751：名無しさん＠寒露：2017/11/10(金) 16:13:02 ID:???
メモリ的な限界は予想できてなかったのでうれしい

752：名無しさん＠寒露：2017/11/10(金) 17:16:04 ID:???
いや、メモリ的な限界が１番考えられただろ
その限界がどこまでかいまいちわからんかったのが問題だったわけで
それにしてもありがてえ検証だ

753：名無しさん＠寒露：2017/11/14(火) 17:00:11 ID:5622DLwA
setStatus(unit,move,hoge)が上手く動きません
talent=offのユニットだとうまく動かないでしょうか？それともほかの原因がありますか？

754：名無しさん＠寒露：2017/11/14(火) 17:27:13 ID:5622DLwA
少し気になって実験したのですが

unit notlnt
{
talent = off
name = ノータレ
}

setv(@aaa,notlnt)
msg(&notlnt&)→notlntと出力される

setv(@wanko,notlnt)
//この勢力にnotlntが存在するとする
storeUnitOfPower(pow,@bbb)
set(idx,0)
while(idx<count(@bbb)){
index(@bbb,idx,@bbb_get)

msg(&@bbb_get&)→notlntに当たった場合ノータレと出力される

if(@bbb_get == @wanko){

msg(同じものだよ！)→notlntが存在するはずなのに@wankoに合致するものがない
}

add(idx,1)
}

どういった問題を解決すればいいでしょうか・・・

755：名無しさん＠寒露：2017/11/14(火) 17:29:42 ID:???
連投すいません
目的としては、データベースとして使用しているtalent=onのユニットのステータスをtalent=offのユニットに移行するという目的です
データベースのmprecの数値でunitの種類を特定し、addUnitして追加したユニットにその他ステータスを落とし込むというのをやりたいと思っています

756：名無しさん＠寒露：2017/11/14(火) 17:55:36 ID:???
さらにすいません
>>754の
誤；msg(&notlnt&)→notlntと出力される
正：msg(&@aaa&)→notlntと出力される
でした

757：名無しさん＠寒露：2017/11/14(火) 19:54:34 ID:???
unit構造体で定義された人材じゃないユニットを後からスクリプトでどうこうしようとするととんでもなく厄介だった記憶がある
dead_eventに疑似死亡イベント(レベルリセットして隠し領地に移動とか)を仕込んだ人材とかにした方が楽じゃないだろうか

758：名無しさん＠寒露：2017/11/14(火) 20:15:02 ID:???
>>757
talentなユニットだと困ることがあるのであえて外しています
具体的にはaddUnitした際に陪臣になってしまうことがやりたいシステムに致命的な邪魔になってしまうので

先日色々やってみましたが無理だったので、talentを外す方向で対応しました

とりあえずstoreUnitOfPowerとかで取得したユニットとして使えばマトモに使えて、setvで直接文字列突っ込んだのは使えないって感じになってますね

で、ユニットを外して入れ直す際のやり取りが

１・talent=onのダミーユニットを隠しspotに入れる
２・talent=offのユニット（以下メインユニット）のステータスを取得してダミーユニットに性能をコピー
３・メインユニットをeraseUnitで全部消す
４・メインユニットを再び発生させる、この際ダミーユニットを参照
５・ダミーのステータスを取得してメインユニットに反映

で、setLevelがこれまたダミーユニットにうまいこと反映しないみたいで、これはaddLevelを1づつするしかないのかな

759：＜あぼーん＞：＜あぼーん＞
＜あぼーん＞

760：名無しさん＠寒露：2017/11/15(水) 20:42:51 ID:???
>754
unit 構造体の名前（notlnt）と、ユニットの名前（ノータレ）の使い分けが難しいです。

wiki によると、setv は文字変数に文字列を代入します。
>> setv(@wanko,notlnt)
この行では @wanko に構造体の名前として「notlnt」を代入してます。

その一方で、storeUnitOfPower は「ユニットの識別子」を文字変数に代入します。そして、unit/classの識別子における文字変数要素とは name で指定した文字列のようです。
>> index(@bbb,idx,@bbb_get)
この行では @bbb_get にユニット名として「ノータレ」を代入してます。

>> if(@bbb_get == @wanko){
「notlnt」と「ノータレ」は異なるので、この比較で合致しない訳です。setv(@wanko,ノータレ) として、ユニット名で探したらどうでしょうか。

761：名無しさん＠寒露：2017/11/16(木) 16:52:33 ID:???
>>760
なるほど、全角文字をスクリプトでも使えるのですね
ちょっとそれ念頭においてやってみます

色々目からウロコでした、ありがとうございます〜

762：名無しさん＠寒露：2017/11/25(土) 21:04:37 ID:???
ユニットが遠隔攻撃しながら前進＆後退するのが嫌で、スキルの減速率を大きくしたり（slow_per = 1 で９９％減速するはず）、地形の影響を大きくした（consti = 1 で移動力が２０％になるはず）のですが、じわじわ動くようにはなりませんでした。

それで不思議に思って調べたのですが、移動速度には最低値があるみたいです。２種類のユニットの移動力をそれぞれ 1 と 50 にしても同じ速さで動きますが、1 と 51 は微妙に違います。移動速度の最低は 50 と思われます。それなら最高値もあるのかと、移動力を上げて試してみました。移動力 1250 と 2000 は同じ速さで動きますが、1240 と 2000 は微妙に違いました。移動速度の最高は 1250 ぐらいです。

まとめると、地形やスキルの影響で変化した後の移動速度は０（完全に停止）か５０〜１２５０の間になるようです。動きが速すぎると当たり判定が難しそうですが、遅すぎるのも駄目とは意外でした。

763：名無しさん＠寒露：2017/11/29(水) 16:10:18 ID:???
どなたかお知恵をお借りしたいのですが、無敵突進スキルを作る方法ってありませんか？
光の目の「幽鬼の浸透」を流用できればよかったのですが、私の勘違いでなければ、
chargeスキルだとslideしても無敵になってくれない（進路上の攻撃にボコボコにされる）ように見えます
nextでmissileスキルに渡してslideさせたら今度は動いてくれませんし、バフをかけることもできませんし…
charge使いたいのは助走の有無を判定したいからなので、missileでもそちらの代替ができるなら構いません
どなたか解決法をご存知ありませんでしょうか

764：名無しさん＠寒露：2017/12/01(金) 19:05:50 ID:???
>> 763
chargeスキルで実現する方法をいろいろ考えてみました。

Ａ）高速移動で避ける。
光の目の「幽鬼の浸透」のスクリプトを見ても、どうやって無敵にしてるのか判りませんでした。とりあえず、スライド速度を、敵の発射する魔法・矢・弾よりも速くすれば、スライド中に攻撃されても避けれそうです。ただし、長距離を高速でスライドする必要があるので、思ってる動きと違うかもしれません。

Ｂ）バリアーを張る。
本家シナリオのリリスが敵の攻撃を相殺しながらスライド移動します。敵の攻撃に属性を付ければ、遠隔攻撃・魔法攻撃だけなら相殺で無効にできるでしょう。しかし、接近攻撃は防げなさそうです。

Ｃ）分身を送り出す。
敵陣をゆっくり往復したいなら、本体はスライドさせずに、攻撃モーションだけ動かす手もあります。「image = @@」にすれば自分のユニット画像になるので、resize_s と resize_s_start で途中から速度をマイナスにして、発射した画像が戻ってくるようにできます。その間、本体は攻撃位置で停止させておけば、分身がスライドしてるように見えそうです。分身は矢・弾と同じ扱いなので、敵に攻撃されません。ただし、本体は普通に攻撃を受けます。

Ｄ）回復しまくる。
敵から攻撃されることを前提にして、受けたダメージを直ぐに回復すれば、無敵と同じになります。「attack_us = 7」で自分を命中対象に変えてから healスキルに繋ぐと、敵を攻撃しながら自分を回復できます。ただし、一撃で死ぬような攻撃（即死・大ダメージ）には対処できません。また、回復量の数値がユニットの頭上に湧き上がるのは奇妙に見えるかもしれません。

どの案にも問題がありますが、参考になれば幸いです。

掲示板管理者へ連絡 無料レンタル掲示板