ＳＲＣ意見交換掲示板Mk2 [One Topic All View / Re[1]: マップ上の特定ユニット・地点を取得するコマンドAct3 / Page: 0]

ＳＲＣ意見交換掲示板Mk2
(現在過去ログ55 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■5801 / inTopicNo.1)

　マップ上の特定ユニット・地点を取得するコマンドAct3

□投稿者/ コウ -(2008/02/26(Tue) 23:33:58) [ID:fqOTLlqC]

ツリー移動がてら、現時点のまとめとか。
あまり代わり映えしませんけど。

Appointコマンド
マップ上でプレイヤーによる座標、ユニットの選択を行う

書式１
Appoint [x y min max] [option]

書式２
Appoint x y min max type [direction] [option]

書式３
Appoint x y min max 線 x2 y2 [option]

書式４
Appoint x y min max 線 angle [option]

指定項目　　　　説明
x y min max　　(x, y)を中心として範囲[min-max]が選択可能。これらを省略すると選択範囲は
　　　　　　　　　マップ全体となります。（省略可）
type　　　　　　　"直" "拡" "扇L?" のいずれかを指定する。扇の場合はレベルを指定すること。
direction　　　　"上" "下" "左" "右"を選択可能。省略時は４方向の範囲を表示する。（省略可）
x2 y2　　　　　　線・移型マップ兵器の目標地点の座標を指定する。
angle　　　　　　線・移型マップ兵器の発射される角度を指定する。
option　　　　　　各種設定（省略可）

解説
optionには以下のものが指定可能です。
　ユニット選択　ユニットを選択する待機状態になります。
　　　　　　　　　選択したユニットのパイロットが対象パイロットに、
　　　　　　　　　ユニットＩＤが対象ユニットＩＤに設定されます。
　In 「array」　選択可能な対象を設定した配列名をarrayに指定します。
　　　　　　　　　x y min maxによる範囲指定が有効な場合は、範囲内で配列に設定されている
　　　　　　　　　もののみが選択対象になります。
　　　　　　　　　マップ地点選択の場合、x,y形式の値が配列に設定可能、
　　　　　　　　　ユニット選択の場合、ユニットＩＤ、パイロット名、パイロット愛称が設定可能。
　　　　　　　　　設定可能でない形式が設定されていた場合は無視されます。
　キャンセル可　マウスの右ボタンクリックを使ったキャンセルを可能にします。
　　　　　　　　　　キャンセル実施時は、マップ地点選択時はX(目標地点)とY(目標地点)に
　　　　　　　　　　空文字を返し、ユニット選択時は対象ユニットＩＤに空文字列を設定します。
　非同期　　　　選択直後にマップの再描画を行いません。（範囲が表示されたままになります）
　　　　　　　　　選択範囲の表示を消す場合はRedrawコマンドを実行してください　

コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待機し、
選択された座標をX(目標地点)とY(目標地点)に代入する。
optionにてユニット選択を指定した場合は、選択されたユニットのパイロット名を対象パイロットに、
ユニットＩＤを対象ユニットＩＤに代入する。

書式２はＭ拡・Ｍ直・Ｍ扇型マップ兵器の選択範囲を指定させる場合に使用します。
書式３，４はＭ線型マップ兵器の選択範囲を指定させる場合に使用します。
マップ兵器用の範囲のイメージについてはマップ攻撃に関する属性を参照してください。

以下は都合の良い方でお願いします。

配列を渡した際の参照先
１．配列のインデックス
２．配列の要素

書式４を選択した場合のmaxの有無
１．書式２，３とのフォーマット統一の為に維持
２．終端は座標で指定しているため排除

キャンセル選択時の挙動
１．空文字を返す
２．何らかの整数を返す

「ユニット選択」指定時に「キャンセル可」を指定しなかった場合の挙動
１．「キャンセル可」を無くして常にキャンセル可とする
２．選択対象がなかった場合、キャンセル可が無くてもキャンセル同様の動作をさせる
３．ユニットの存在しない座標を選択することで特異値を返す

引用返信/返信削除キー/

■5802 / inTopicNo.2)

　Re[1]: マップ上の特定ユニット・地点を取得するコマンドAct3

▲▼■

□投稿者/ ワヅキ -(2008/02/27(Wed) 00:56:21) [ID:fbiBr0VL]

2008/02/29(Fri) 21:19:21 編集(投稿者)

こんにちわ、あるいはこんばんわ、ワヅキです。

配列による事前登録案は、プレイヤー側が持つデータ量が爆発的に増える可能性もあるので、あまり賛成できません。
ですが、現状でコマンド案を支持し続けた所で面倒臭いだけなので、いちおー賛成という事で幾つか意見を。

＞コウさん

＞マップ地点選択の場合、x,y形式の値が配列に設定可能

この値の設定方法はＸとＹの値をカンマ区切り形式にしたものでしょうか？
それとも、List( x, y )で処理したみたいに"x y"のような形式にしたものでしょうか？
一応、先の文章を読めば把握はできるのですが、この一文だけで見ると分かりづらい気がします。

＞キャンセル選択時の挙動

値を返す場所が何処なのかが以前の文章を読み通しても明記されていないように思えるのですが。
で、もしも返す値が目標地点・ユニットＩＤに入る値だったとすれば、
目標地点の場合は整数を、ユニットＩＤの場合は空文字を入れる、なんていう風には出来ないのでしょうか？

整数値は０で。 If文の判定がし易いですし、座標もマップ範囲外ですし。

＞乾さん

＞ユニットの絞込み機能は、スペシャルパワーの対象選択の再現や
＞攻撃の対象ユニット選択の再現を行うために必要だと考えています。

乾さんの例にならえば、ＨＰが最大のユニットがいる座標を条件式とClearコマンドを用いて除外するものだと思っていました。
その為にClearコマンドがあるのだと思っていたのですが、間違いだったでしょうか？

引用返信/返信削除キー/

■5804 / inTopicNo.3)

　Re[2]: マップ上の特定ユニット・地点を取得するコマンドAct3

▲▼■

□投稿者/ コウ -(2008/02/28(Thu) 02:15:13) [ID:fqOTLlqC]

コウです。

> 配列による事前登録案は、プレイヤー側が持つデータ量が爆発的に増える可能性もあるので、あまり賛成できません。
> ですが、現状でコマンド案を支持し続けた所で面倒臭いだけなので、いちおー賛成という事で幾つか意見を。

配列もコマンドとやってることは大して変わりません。
コマンドであれば、SetAppoint 対象ユニットＩＤ、となるところが
配列の場合、Set 配列名[インデックス] 対象ユニットＩＤ、に変わるだけなので。

> ＞マップ地点選択の場合、x,y形式の値が配列に設定可能
>
> この値の設定方法はＸとＹの値をカンマ区切り形式にしたものでしょうか？
> それとも、List( x, y )で処理したみたいに"x y"のような形式にしたものでしょうか？
> 一応、先の文章を読めば把握はできるのですが、この一文だけで見ると分かりづらい気がします。

多次元配列（配列名[x,y]のような指定）での格納を想定していますが
参照先をインデックスにすべきか、要素にすべきかはユーザ側で判断し難い部分ですから
keiさんの都合の良い方で、と書いてあるわけです。

なお、これはユニットＩＤも同様で、参照先がインデックスになった場合の指定は
Set 配列名[対象ユニットＩＤ] ループのインデックス、となります。

> ＞キャンセル選択時の挙動
>
> 値を返す場所が何処なのかが以前の文章を読み通しても明記されていないように思えるのですが。
> で、もしも返す値が目標地点・ユニットＩＤに入る値だったとすれば、
> 目標地点の場合は整数を、ユニットＩＤの場合は空文字を入れる、なんていう風には出来ないのでしょうか？
>
> 整数値は０で。 If文の判定がし易いですし、座標もマップ範囲外ですし。

　キャンセル可　マウスの右ボタンクリックを使ったキャンセルを可能にします。
　　　　　　　　　　キャンセル実施時は、マップ地点選択時はX(目標地点)とY(目標地点)に
　　　　　　　　　　空文字を返し、ユニット選択時は対象ユニットＩＤに空文字列を設定します。
これでは不足ということでしょうか。

返り値自体については、ポリシーに関わる部分にあたるので、keiさんにお任せしようと思っていました。
とはいえ、提案自体は悪いことではないですし、マップ外選択を排除したことで0が使えるのも事実です。
キャンセル時の挙動案として「座標の場合は0、ユニットＩＤの場合は空文字を返す」を追加しましょう。

> ＞ユニットの絞込み機能は、スペシャルパワーの対象選択の再現や
> ＞攻撃の対象ユニット選択の再現を行うために必要だと考えています。
>
> 乾さんの例にならえば、ＨＰが最大のユニットがいる座標を条件式とClearコマンドを用いて除外するものだと思っていました。
> その為にClearコマンドがあるのだと思っていたのですが、間違いだったでしょうか？

ClearはSetで保持した内容を消去して、次にSetを実行した場合に備えるのが目的のコマンドですね。
もし選択対象にしたくないユニットが居た場合、そのユニット以外をSetで保存する形になります。

味方の中でＨＰが最大ではないユニットを抽出する場合、以下のような条件式で判別可能ですね。
ForEach 味方
If HP() < Info(対象ユニットＩＤ,最大ＨＰ) Then
配列名[対象ユニットＩＤ] 対象ユニットＩＤ
Else
Next

引用返信/返信削除キー/

■5806 / inTopicNo.4)

　Re: ここまでのまとめ

▲▼■

□投稿者/ あかんべえ -(2008/02/28(Thu) 22:29:03) [ID:u1PBTBjt]

　あかんべえです。

> コマンドの意義とか、そういう難しいことは一切考えてません。

　もしコウさんがツリーを立てなかったら、私が立ててました。「コマンドの意義」はそういう立ち位置から発言しています。

> 対象を細かく限定するための条件式を、判別式で実現するためには関数の呼び出しを含めればよい、とされていますが
> これがどういった処理の流れになるのか理解できませんでした。

　すみません、ＳＲＣの用語では　(誤)「関数」→(正)「戻り値を返すサブルーチン」でした。ここは元文も訂正しておきます。

> あと、少なくともポリシーに合わないので却下、という事態は無いんじゃないかと。

　どうしてですか。KeiさんがＳＲＣの設計思想を持って判断しないとは、考えられないのですが。

> 両案の違いは実質呼び出すタイミングだけですから、

　それ以外の「違い」についての書き込みだったのですけど。

> 書式を追加するのに反対、ということでいいんでしょうか？
>
> 乾氏の文章からは、マップ兵器の選択範囲を実現するための書式を提案していることしか読み取れませんでした。

　乾さんがどれだけ意識的であれ、別目的のリクエストになってしまう理由を書きました。
　検討にも値しない理由なのでしょうか？

引用返信/返信削除キー/

■5807 / inTopicNo.5)

　Re[2]: Re: ここまでのまとめ

▲▼■

□投稿者/ コウ -(2008/02/29(Fri) 01:22:11) [ID:fqOTLlqC]

ども、コウです。

>>コマンドの意義とか、そういう難しいことは一切考えてません。
>
> 　もしコウさんがツリーを立てなかったら、私が立ててました。「コマンドの意義」はそういう立ち位置から発言しています。

よくわからないです。
結局のところ、何をどうしたいのでしょうか？

>>対象を細かく限定するための条件式を、判別式で実現するためには関数の呼び出しを含めればよい、とされていますが
>>これがどういった処理の流れになるのか理解できませんでした。
>
> 　すみません、ＳＲＣの用語では　(誤)「関数」→(正)「戻り値を返すサブルーチン」でした。ここは元文も訂正しておきます。

正直、処理の流れがわかり難いので、実例と流れ図の提示をお願いしたい気分です。
基準が私自身になりますが、私が把握出来ないものをリクエストするなんて、珍妙なことは出来ません。

>>あと、少なくともポリシーに合わないので却下、という事態は無いんじゃないかと。
>
> 　どうしてですか。KeiさんがＳＲＣの設計思想を持って判断しないとは、考えられないのですが。

ここで決めたリクエスト内容が、そっくりそのまま反映されるわけじゃないからです。
最終的に仕様を決定するのは、実際に機能を組み込む人ですから。
それでも話し合ってリクエスト内容を検討してるのは、実装者に対しユーザが望む形を伝えるためでしょう。

そもそもリクエストしたところで、実装されるとは限らないわけで。
希望を伝えておき、実装者の出来る範囲で実現されれば幸運だ、くらいに考えておくべきではないかと。

>>両案の違いは実質呼び出すタイミングだけですから、
>
> 　それ以外の「違い」についての書き込みだったのですけど。

どっちにしろ、今までのＳＲＣでは例の無い特異な形式である以上、大した差はないと思います。

>>書式を追加するのに反対、ということでいいんでしょうか？
>>
>>乾氏の文章からは、マップ兵器の選択範囲を実現するための書式を提案していることしか読み取れませんでした。
>
> 　乾さんがどれだけ意識的であれ、別目的のリクエストになってしまう理由を書きました。
> 　検討にも値しない理由なのでしょうか？

書式を追加したところで、根本的な仕様に変更はありませんから、気にする必要はないでしょう。

引用返信/返信削除キー/

■5809 / inTopicNo.6)

　Re[3]: マップ上の特定ユニット・地点を取得するコマンドAct3

▲▼■

□投稿者/ ワヅキ -(2008/02/29(Fri) 20:59:43) [ID:fbiBr0VL]

こんにちわ、あるいはこんばんわ、ワヅキです。

＞配列もコマンドとやってることは大して変わりません。

先の文でウチが懸念していたのは、セーブデータの容量増加なのですが。
大まかな振る舞い自体に変化はないので、特に意見はないです。

＞多次元配列での格納を想定

参照先が要素の場合は Set 配列名[インデックス] 対象ユニットＩＤで、
インデックスの場合は Set 配列名[対象ユニットＩＤ] インデックスという事ですか？

インデックス格納の場合は値にインデックスを入れる意義がないので、
参照先は要素に絞ってしまっても良さそうなものですが、どうでしょう？

＞これでは不足ということでしょうか。

空文字や整数が片方だけに返るのか、両方に返るのかが分からなかっただけなんで。
ハナから両方に同一の値が返る仕組みだったみたいですね。回答どうもです。

＞ClearはSetで保持した内容を消去して、次にSetを実行した場合に備えるのが目的のコマンドですね。

自分の案(No5784)を基準に考えていたので、ちょっと混同していたみたいです。

引用返信/返信削除キー/

■5810 / inTopicNo.7)

　Re[2]: Re: ここまでのまとめ

▲▼■

□投稿者/ ワヅキ -(2008/02/29(Fri) 21:27:04) [ID:fbiBr0VL]

2008/02/29(Fri) 21:40:01 編集(投稿者)

書いてて格好悪いなあとは思いましたけど。

＞KeiさんがＳＲＣの設計思想を持って判断しないとは、考えられないのですが。

野暮な突っ込みですが、ＳＲＣの設計思想というのは具体的にはどういった事なのでしょうか？
自分の物差しで計れないものを議論の場に持ち込んでいるとは考えにくいので、是非とも説明をお願いします。

あと、Appointに条件式ないし配列を組み込み両案リクエストが罷り通るのであれば、
コマンド案も併記してください、という話にも飛躍する訳で……。

コウさんの言うとおり、判りやすい形式のものだけをリクエストするのがいいと思いますよ？

引用返信/返信削除キー/

■5813 / inTopicNo.8)

　Re[4]: マップ上の特定ユニット・地点を取得するコマンドAct3

▲▼■

□投稿者/ コウ -(2008/03/02(Sun) 21:54:24) [ID:fqOTLlqC]

ども、コウですよ。

> ＞配列もコマンドとやってることは大して変わりません。
>
> 先の文でウチが懸念していたのは、セーブデータの容量増加なのですが。
> 大まかな振る舞い自体に変化はないので、特に意見はないです。

HotPointだとセーブデータに残らないんでしたっけ？
処理が一つのラベル内で完結しない場合、セーブデータに変数が残ってしまうわけか。

まあ、大きな外部変数は使う都度クリアしてやればいいですし、コマンド式にした場合に
クリアの手間が省けるだけなら、ユーザが管理できる配列の方が利用価値は高いのではないでしょうか。
本体の挙動を考慮すると、コマンド式の方が実は都合が良いのかも知れない、とか思ったりもしますが。

> ＞多次元配列での格納を想定
>
> 参照先が要素の場合は Set 配列名[インデックス] 対象ユニットＩＤで、
> インデックスの場合は Set 配列名[対象ユニットＩＤ] インデックスという事ですか？
>
> インデックス格納の場合は値にインデックスを入れる意義がないので、
> 参照先は要素に絞ってしまっても良さそうなものですが、どうでしょう？

AskやForEach等の参照先が配列のインデックスなんですよ。
なので、振る舞いの統一感を考えると、インデックスを参照する形がいいのかな、と。

一応、要素には要素で使い道はあると思いますが、インデックスに比べ存在意義は薄いですね。

> ＞これでは不足ということでしょうか。
>
> 空文字や整数が片方だけに返るのか、両方に返るのかが分からなかっただけなんで。
> ハナから両方に同一の値が返る仕組みだったみたいですね。回答どうもです。

うーむ、あれだと分かり難いですかね。
分かり難いということであれば、もうちょっとわかり易い文章を考えてみますが。

引用返信/返信削除キー/

■5814 / inTopicNo.9)

　マルチレス

▲▼■

□投稿者/ あかんべえ -(2008/03/04(Tue) 02:04:08) [ID:D2Nqg0Ap]

コウさん:
> >>コマンドの意義とか、そういう難しいことは一切考えてません。
> >
> > 　もしコウさんがツリーを立てなかったら、私が立ててました。「コマンドの意義」はそういう立ち位置から発言しています。
>
> よくわからないです。

　議長として、出された意見を一言で却下するのはやめてほしい、ということです。

> 正直、処理の流れがわかり難いので、実例と流れ図の提示をお願いしたい気分です。

　たとえば、「道路」の座標のみを選択する場合、ふつうは、

　Appoint Where (Info(マップ, X(該当座標), Y(該当座標), 地形名) = "道路")

だけで十分ですが、あえてサブルーチンでやるのなら、まずコマンド側で

　Appoint Where (Call(判別サブルーチン) > 0)
として、サブルーチンでは、
　判別サブルーチン:
　If Info(マップ, X(該当座標), Y(該当座標), 地形名) = "道路" Then
　　Return 1
　EndIf
　Return 0

となります。ちなみに、事前登録案の場合は、

　Set 登録用配列
　Set index
　For ix = 1 to マップX最大値
　　For iy = 1 to マップY最大値
　　　If Info(マップ, ix, iy, 地形名) = "道路" Then
　　　　登録用配列[index] = ix & "," & iy // （注）
　　　　incr index
　　　EndIf
　　Next
　Next
　Appoint In 登録用配列

となります。見ての通り、条件式コマンド案のほうが簡明で、特にサブルーチンなしで十分のとき、違いは大きいです。オプションの仕様だけを考えれば事前登録案のほうが「分かりやすい」けれども、実際に記述するときには逆転するのですね。

（注）：　コウさんの案をこのように解釈しました。私案では右辺が「List(ix, iy)」になります。
　強く主張するわけではありませんが、議長案は、(1)","が入ると文字列になり、SRC内部処理で文字列解析し数値に戻すことになり、実行時間がかかる　(2)代入式が少しめんどう　という欠点があります。対して長所は、リストに慣れていない人も多いということでしょうね。

> 書式を追加したところで、根本的な仕様に変更はありませんから、気にする必要はないでしょう。

　これは「初期の機能が削除されるのではないから、追加の影響は気にする必要はない」というご意見ですね？
　しかし、リクエストにあたって留意すべきことは、初期の機能の維持以外にもいろいろあります。仕様の整合性、使う人に誤解されないか、乾さんの言葉では、「理解しやすさ」、「順序だった作りこみ」なのか、など。
　書式の過半がマップ攻撃関係で、その上マップ攻撃での演出まで再現するとなると、何のためのコマンドかも理解できない仕様だと思いますよ。

ワヅキさん:
> 野暮な突っ込みですが、ＳＲＣの設計思想というのは具体的にはどういった事なのでしょうか？

　たとえば、Keiさんが、別途イベントコマンドを組まねばならないオプションをどう考えるか、どんな仕様を初心者のSRC修得の壁だと判断されるだろうか、あるいは、「データ量が爆発的に増える可能性」をどう評価されるだろうか、といったことです。

> コマンド案も併記してください、という話にも飛躍する訳で……。

　それも有力かと思いますよ。
　この間の意見の違いのポイントだと思うので、もう少し言います。
　複数の案が出たとき、両案併記は有力な解決策だと思います。特に、両案にそれなりの長所が示されたときには、議論を切り上げても良いだろうと。もちろん続けても良いのだけど、ほとほどにして次へ移るべきかと。
　逆に言えば、乾さんにしろコウさんにしろ、対立案をあえて排除したいのなら、それなりの理由の開示と説得性が必要だと思っています。

引用返信/返信削除キー/

■5819 / inTopicNo.10)

　Re[3]: マルチレス

▲▼■

□投稿者/ コウ -(2008/03/05(Wed) 02:09:25) [ID:fqOTLlqC]

コウです。

> 　議長として、出された意見を一言で却下するのはやめてほしい、ということです。

却下ではなく、取捨選択してるだけなんですけどね。
利点のある意見は全て拾い上げて、取捨選択は実際ソースを書く人へ任せる、では何のための話し合いかわかりませんし。
それこそ何をリクエストしてるのかわからなくなってしまうでしょう。

> 　たとえば、「道路」の座標のみを選択する場合、ふつうは、
> （中略）
> 　見ての通り、条件式コマンド案のほうが簡明で、特にサブルーチンなしで十分のとき、違いは大きいです。
> 　オプションの仕様だけを考えれば事前登録案のほうが「分かりやすい」けれども、実際に記述するときには逆転するのですね。

つまり、繰り返し処理自体は本体任せにして、指定された範囲内の座標・ユニットを総当りする、ということですか。
確かに事前登録式より簡潔になるケースも多そうです。
しかし、ご自分でも書かれていましたが、事前登録式の方が柔軟性は高いわけですし、どちらか一方を選ぶとするなら
私は事前登録式を選びます。
それでも併記すべし、というなら併記するのもやぶさかではございません。

ただ、条件式案の文面はそちらで書いて頂けますか。
細かい部分まで考慮されているようですから、私が書くより理解しやすいものになるでしょう。

指定項目　説明
expression　（ここの文面をお願いします）

> （注）：　コウさんの案をこのように解釈しました。私案では右辺が「List(ix, iy)」になります。
> 　強く主張するわけではありませんが、議長案は、
> 　(1)","が入ると文字列になり、SRC内部処理で文字列解析し数値に戻すことになり、実行時間がかかる
> 　(2)代入式が少しめんどう　という欠点があります。対して長所は、リストに慣れていない人も多いということでしょうね。

参照先をインデックスにした場合は
登録用配列[ix,iy] = ここは数値なり文字列なりを適当に入れればいいでしょう
こうなりますかね。
要素がほぼ無意味になりますが、何か使い様はあるでしょう、きっと。

ただ、インデックスを参照する場合でも","が文字列として扱われるなら、リスト形式にするべきなんでしょうが。

>>書式を追加したところで、根本的な仕様に変更はありませんから、気にする必要はないでしょう。
>
> 　これは「初期の機能が削除されるのではないから、追加の影響は気にする必要はない」というご意見ですね？
> 　しかし、リクエストにあたって留意すべきことは、初期の機能の維持以外にもいろいろあります。
> 　仕様の整合性、使う人に誤解されないか、乾さんの言葉では、「理解しやすさ」、「順序だった作りこみ」なのか、など。
> 　書式の過半がマップ攻撃関係で、その上マップ攻撃での演出まで再現するとなると、何のためのコマンドかも理解できない仕様だと思いますよ。

現状、範囲表示に多様性のあるものがマップ兵器だけなんで、そう見えるでしょう。
もし他にもマップ上で特殊な範囲をとるものがあれば、それにも対応するところなんですがね。

そもそも書式を分けているのは、option内に指定項目があるのは好ましくないのでは、という単純な理由からです。
optionだと以下のような記述になってしまいますし。
Appoint x y min max ユニット選択キャンセル可線 angle 非同期
※x y min max angleには適当な数値が入る
確かに、指定項目の数・種類毎に書式が増えるのは拙いので、何か良い解決策があればよいのですが。

引用返信/返信削除キー/

■5827 / inTopicNo.11)

　条件式オプション　文面案

▲▼■

□投稿者/ あかんべえ -(2008/03/09(Sun) 19:23:59) [ID:lK4yOgry]

　ども、あかんべえです。条件式オプションの文面案と追加意見です。

「Where expression」　expressionには判別式を記入します。expressionに合致した目標だけが選択対象になります。

　expressionで使うために、以下の新設キーワードをリクエストします。
(1)　「X(該当座標)」, 「Y(該当座標)」　　判別中の目標候補地点の座標を返します。
(2)　「該当パイロット」, 「該当ユニットＩＤ」　　それぞれ、判別中の目標候補地点にいるユニットのメインパイロット名またはユニットＩＤを返します。ユニットがいなければ空文字を返します。

注：Appointコマンドを二分割し、かつ、設定値を限定する案（乾さんの案）の場合、上の(1)(2)を二つのコマンドに割り振り、「ユニットがいなければ空文字を返します。」を削除してヘルプに記載します。

---------

　ただし、今回のコウさんの「どちらか一方を選ぶとするなら私は事前登録式を選びます」との発言を、それまでのご発言以上に重く受け止めています。
　この件で私の発言してきた理由には、「意見の主張」という面もあったけど、両案の特質と設計思想上の問題への理解を訴え、「事前登録案がかんたんだと思ってリクエストしたけど、実際にはめんどうだった」などの後悔を残したくなかったことのほうが大きかったからです。

　事前登録案を主案とし条件式オプション案を一段下に扱い、「議論参加者から以下の対案がありました」などの表記を加えてもらってもかまいません。
　また、他の方から改めて、両案の特質を踏まえた上で事前登録案のみを支持する意見が出された場合、条件式オプション案の撤回も考えています。

　

引用返信/返信削除キー/

■5828 / inTopicNo.12)

　Re[4]: マルチレス

▲▼■

□投稿者/ あかんべえ -(2008/03/09(Sun) 21:14:24) [ID:lK4yOgry]

　あかんべえです。

> ただ、インデックスを参照する場合でも","が文字列として扱われるなら、リスト形式にするべきなんでしょうが。

　私が書いたのは、「x,y形式」で値を参照する場合についてです。インデックスの場合は、文字列じゃなく多次元配列として扱われるでしょうね。

>>　書式の過半がマップ攻撃関係で、その上マップ攻撃での演出まで再現するとなると、何のためのコマンドかも理解できない仕様だと思いますよ。
>
> 現状、範囲表示に多様性のあるものがマップ兵器だけなんで、そう見えるでしょう。

　どういう理由であれ、そう見えることは問題かと。
　また、一つでも「多様」でも、追加的機能が書式化されている例はありません。
　既存コマンドと比較してもらえばわかると思いますが、オプションに入れることだけでも破格の待遇と言えます。これが、せいいっぱいかと。

> そもそも書式を分けているのは、option内に指定項目があるのは好ましくないのでは、という単純な理由からです。
> optionだと以下のような記述になってしまいますし。
> Appoint x y min max ユニット選択キャンセル可線 angle 非同期

　このような仕様は、PaintPicture コマンドの「右回転」「左回転」オプションとして実装されています。オプションの種類が多く、複数指定可ということも Appoint
と共通しています。
　なので、少し複雑になるのは確かだけど絶対避けるべきというほどじゃない。複数書式による複雑化、コマンドへの誤解の危険を考えれば、デメリットの大きさがまるで違うと思います。

　それと、「angle」が関係するのは「線」だけです。他のオプションは「direction」です。
　そもそも、Appointコマンドにとって「direction」は必要なのでしょうか。これまでこの点の議論がなさすぎるように感じています。
　乾さんから提示された理由は「マップ攻撃動作の再現」です。この正否判断は結局、「Appointコマンドがそこまで再現する必要があるのか」という論点に帰着すると思います。
　しかしコウさんは、コマンドの目的議論には関心を示しておられない。だとすれば、どのような理由で「direction」が必要と考えておられるのでしょうか？

　少し先回りして言えば、私自身は「あれば使えるかもしれない」という以上の理由を思いつくことができません。
　この程度の理由では、上記デメリットとのバランスはとうてい取れないと思います。
　また、現状、SRCには「方向」関連の機能は全くないこともあります。導入するなら「ユニットの向き」や方向限定武器属性などベーシックな機能が先で、Appointでの方向関連機能の導入は突出しすぎと判断しています。

引用返信/返信削除キー/

■5833 / inTopicNo.13)

　Re[5]: マルチレス

▲▼■

□投稿者/ コウ -(2008/03/13(Thu) 23:49:31) [ID:fqOTLlqC]

コウです。

> 　ただし、今回のコウさんの「どちらか一方を選ぶとするなら私は事前登録式を選びます」との発言を、それまでのご発言以上に重く受け止めています。
> 　この件で私の発言してきた理由には、「意見の主張」という面もあったけど、両案の特質と設計思想上の問題への理解を訴え、
> 「事前登録案がかんたんだと思ってリクエストしたけど、実際にはめんどうだった」などの後悔を残したくなかったことのほうが大きかったからです。
>
> 　事前登録案を主案とし条件式オプション案を一段下に扱い、「議論参加者から以下の対案がありました」などの表記を加えてもらってもかまいません。
> 　また、他の方から改めて、両案の特質を踏まえた上で事前登録案のみを支持する意見が出された場合、条件式オプション案の撤回も考えています。

条件式だけだと、事前登録式で出来ることが、出来なくなっちゃうんじゃないかなーと思うわけです。
ですから、どちらか一方を選ぶなら、と書いたわけで。
可能ならば両方使えるのがベターなんで、併記ではなく両案纏めてしまいましょう。

>>現状、範囲表示に多様性のあるものがマップ兵器だけなんで、そう見えるでしょう。
>
> 　どういう理由であれ、そう見えることは問題かと。
> 　また、一つでも「多様」でも、追加的機能が書式化されている例はありません。
> 　既存コマンドと比較してもらえばわかると思いますが、オプションに入れることだけでも破格の待遇と言えます。これが、せいいっぱいかと。

私は問題とは思いません、で終了してしまいますわな。

しかし、破格とか精一杯とか、どうにも妙な表現をしますね。
あくまでリクエストでしかないのに、扱いの重みまで断定されてしまうとは。

>>そもそも書式を分けているのは、option内に指定項目があるのは好ましくないのでは、という単純な理由からです。
>>optionだと以下のような記述になってしまいますし。
>>Appoint x y min max ユニット選択キャンセル可線 angle 非同期
>
> 　このような仕様は、PaintPicture コマンドの「右回転」「左回転」オプションとして実装されています。
> 　オプションの種類が多く、複数指定可ということも Appoint と共通しています。
> 　なので、少し複雑になるのは確かだけど絶対避けるべきというほどじゃない。
> 　複数書式による複雑化、コマンドへの誤解の危険を考えれば、デメリットの大きさがまるで違うと思います。

私としては、書式が増えたからといって、複雑化するとも誤解を招くとも思えないんですよね。
限られた数人しかレスしないので、他の多くの人がどのように考えているのか、さっぱりわかりませんし。

> 　それと、「angle」が関係するのは「線」だけです。他のオプションは「direction」です。
> 　そもそも、Appointコマンドにとって「direction」は必要なのでしょうか。これまでこの点の議論がなさすぎるように感じています。
> 　乾さんから提示された理由は「マップ攻撃動作の再現」です。この正否判断は結局、「Appointコマンドがそこまで再現する必要があるのか」という論点に帰着すると思います。
> 　しかしコウさんは、コマンドの目的議論には関心を示しておられない。だとすれば、どのような理由で「direction」が必要と考えておられるのでしょうか？
>
> 　少し先回りして言えば、私自身は「あれば使えるかもしれない」という以上の理由を思いつくことができません。
> 　この程度の理由では、上記デメリットとのバランスはとうてい取れないと思います。
> 　また、現状、SRCには「方向」関連の機能は全くないこともあります。
> 　導入するなら「ユニットの向き」や方向限定武器属性などベーシックな機能が先で、Appointでの方向関連機能の導入は突出しすぎと判断しています。

方向に関しては、現状すでにマップ兵器の方向決定時に表示されているから、ですかね。
本体で実現されている機能を盛り込むことに特段の理由が要るんでしょうか。

angleは、座標指定が可能ならば要らないかなー、と思うので削ってしまおう。

引用返信/返信削除キー/

■5834 / inTopicNo.14)

　現在のまとめ

▲▼■

□投稿者/ コウ -(2008/03/14(Fri) 01:12:55) [ID:fqOTLlqC]

　「Where (条件式)」を追加する場合の前提条件
(1)　「X(該当座標)」,「Y(該当座標)」　判別中の目標候補地点の座標を返します。
(2)　「該当パイロット」,「該当ユニットＩＤ」　判別中の目標候補地点にいるユニットのメインパイロット名または
　　　ユニットＩＤを返します。ユニットがいなければ空文字を返しますす。

Appointコマンド
マップ上でプレイヤーによる座標、ユニットの選択を行う

書式１
Appoint [x y min max] [option]

書式２
Appoint [x y min max] In array [option]

書式３
Appoint [x y min max] Where (expression) [option]

指定項目　　　　説明
x y min max　　(x, y)を中心とした範囲[min-max]が選択可能
　　　　　　　　　これらを省略すると選択範囲はマップ全体となります（省略可）
array　　　　　配列名。選択可能な対象を設定した配列名を指定可能
　　　　　　　　　x y min maxが有効な場合、範囲内かつ配列に設定されているもののみ選択対象となる
　　　　　　　　　マップ地点選択の場合は x,y 形式の値、
　　　　　　　　　ユニット選択の場合はユニットＩＤ、パイロット名、パイロット愛称が設定可能
　　　　　　　　設定可能でない形式が設定されていた場合は無視される
expression　　選択可能な対象を限定するための条件式を指定可能。条件式は括弧で囲む
　　　　　　　　　x y min maxで設定された範囲内、もしくはマップ全体の各マス・ユニットをチェックし
　　　　　　　　　条件式 expression が成り立つとき選択可能な対象として設定されます
　　　　　　　　　　　　条件式は式の値が 0 でなければ成り立ちます
option　　　　　各種設定（省略可）

解説
コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待機し、
選択された座標をX(目標地点)とY(目標地点)に代入する。
optionにてユニット選択を指定した場合は、選択されたユニットのパイロット名を対象パイロットに、
ユニットＩＤを対象ユニットＩＤに代入する。

書式２では事前に選択可能な対象を配列に登録することが出来ます。

書式３では選択可能な対象を限定するための条件式を設定することが出来ます。
条件式の中では、 X(該当座標)、Y(該当座標) もしくは該当パイロット、該当ユニットＩＤを使うことで
座標及びユニットの情報を取得することが可能です。

　optionには以下のものが指定可能です。
ユニット選択　　　ユニットを選択する待機状態になります。
　　　　　　　　　　選択したユニットのパイロットが対象パイロットに、
　　　　　　　　　　ユニットＩＤが対象ユニットＩＤに設定されます。
キャンセル可　　マウスの右ボタンクリックを使ったキャンセルを可能にします。
　　　　　　　　　　キャンセル実施時は、マップ地点選択時はX(目標地点)とY(目標地点)に
　　　　　　　　　　空文字を返し、ユニット選択時は対象ユニットＩＤに空文字列を設定します。
非同期　　　　　　選択直後にマップの再描画を行いません。（範囲が表示されたままになります）
　　　　　　　　　　選択範囲の表示を消す場合はRedrawコマンドを実行してください　
拡 [(方向)]　　　　指定したマップ攻撃と同じ選択範囲を表示します。
直 [(方向)]　　　　指定したマップ攻撃と同じ選択範囲を表示します。
扇L? [(方向)]　　　指定したマップ攻撃と同じ選択範囲を表示します。扇はレベル指定が必要です。
　　　　　　　　　　　方向　　上下左右が選択可能。省略時は４方向の範囲を表示する（省略可）
　　　　　　　　　　　　　　　全体を括弧で囲むことで複数指定も可能（例 (上左右)）
線 (x y)　　　　　Ｍ線属性と同じ範囲を取ります。中心座標からx yまでの範囲を表示します。

以下はKeiさんの都合の良い方でお願いします。

配列を渡した際の参照先
１．配列のインデックス
２．配列の要素

配列の参照先が座標だった場合の指定形式
１．リスト（" "半角スペースで区切る）
２．多次元配列（","カンマで区切る）

書式４を選択した場合のmaxの有無
１．書式２，３とのフォーマット統一の為に維持
２．終端は座標で指定しているため排除

キャンセル選択時の挙動
１．空文字を返す
２．何らかの整数を返す
３．座標選択時は0、ユニット選択時は空文字を返す

「ユニット選択」指定時に「キャンセル可」を指定しなかった場合の挙動
１．「キャンセル可」を無くして常にキャンセル可とする
２．選択対象がなかった場合、キャンセル可が無くてもキャンセル同様の動作をさせる
３．ユニットの存在しない座標を選択することで特異値を返す

引用返信/返信削除キー/

■5835 / inTopicNo.15)

　Re[2]: 現在のまとめ

▲▼■

□投稿者/ あかんべえ -(2008/03/15(Sat) 21:19:31) [ID:ccW3dXzs]

　あかんべえです。

　「現在のまとめ」案、大筋、了解しました。個人的には依然、「方向」機能には消極的ですが、この案で取りまとめるのに異存ありません。
　以下は、おもに文面についての意見です。

> ２．配列の要素

　「配列の要素の値」とするのが正確かと。

> 配列の参照先が座標だった場合の指定形式
> １．リスト（" "半角スペースで区切る）
> ２．多次元配列（","カンマで区切る）

　ここは意味が読み取りにくいと思います。私もよくわからなかったのですが、
　「１．」は、「選択候補データを値に入れる場合、"x, y"形式の替りにリスト形式"x y"を採用してもよい」という意味、
　「２．」は、「選択候補データをインデックスに入れる場合、座標は多次元配列[x, y]を採用する」という意味、
この解釈でよろしいでしょうか？

> 書式４を選択した場合のmaxの有無
> １．書式２，３とのフォーマット統一の為に維持
> ２．終端は座標で指定しているため排除

　これは消し忘れでしょうか？　書式４は存在してないみたいですので。

引用返信/返信削除キー/

■5845 / inTopicNo.16)

　まとめのまとめ

▲▼■

□投稿者/ コウ -(2008/03/22(Sat) 00:52:53) [ID:fqOTLlqC]

コウです。
ボチボチ終了かなーと。

>>２．配列の要素
> 　「配列の要素の値」とするのが正確かと。

ではそのように。

>>配列の参照先が座標だった場合の指定形式
>>１．リスト（" "半角スペースで区切る）
>>２．多次元配列（","カンマで区切る）
>
> 　ここは意味が読み取りにくいと思います。私もよくわからなかったのですが、
> 　「１．」は、「選択候補データを値に入れる場合、"x, y"形式の替りにリスト形式"x y"を採用してもよい」という意味、
> 　「２．」は、「選択候補データをインデックスに入れる場合、座標は多次元配列[x, y]を採用する」という意味、
> この解釈でよろしいでしょうか？

さいです。
ちょっと書き換えてみました。

>>書式４を選択した場合のmaxの有無
>>１．書式２，３とのフォーマット統一の為に維持
>>２．終端は座標で指定しているため排除
> 　これは消し忘れでしょうか？　書式４は存在してないみたいですので。

こちらはミスですね。
削っておきます。

以下は文面。

　「Where (条件式)」を追加する場合の前提条件
(1)　「X(該当座標)」,「Y(該当座標)」　判別中の目標候補地点の座標を返します。
(2)　「該当パイロット」,「該当ユニットＩＤ」　判別中の目標候補地点にいるユニットのメインパイロット名または
　　　ユニットＩＤを返します。ユニットがいなければ空文字を返しますす。

Appointコマンド
マップ上でプレイヤーによる座標、ユニットの選択を行う

書式１
Appoint [x y min max] [option]

書式２
Appoint [x y min max] In array [option]

書式３
Appoint [x y min max] Where (expression) [option]

指定項目　　　　説明
x y min max　　(x, y)を中心とした範囲[min-max]が選択可能
　　　　　　　　　これらを省略すると選択範囲はマップ全体となります（省略可）
array　　　　　配列名。選択可能な対象を設定した配列名を指定可能
　　　　　　　　　x y min maxが有効な場合、範囲内かつ配列に設定されているもののみ選択対象となる
　　　　　　　　　マップ地点選択の場合は x,y 形式の値、
　　　　　　　　　ユニット選択の場合はユニットＩＤ、パイロット名、パイロット愛称が設定可能
　　　　　　　　設定可能でない形式が設定されていた場合は無視される
expression　　選択可能な対象を限定するための条件式を指定可能。条件式は括弧で囲む
　　　　　　　　　x y min maxで設定された範囲内、もしくはマップ全体の各マス・ユニットをチェックし
　　　　　　　　　条件式 expression が成り立つとき選択可能な対象として設定されます
　　　　　　　　　　　　条件式は式の値が 0 でなければ成り立ちます
option　　　　　各種設定（省略可）

解説
コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待機し、
選択された座標をX(目標地点)とY(目標地点)に代入する。
optionにてユニット選択を指定した場合は、選択されたユニットのパイロット名を対象パイロットに、
ユニットＩＤを対象ユニットＩＤに代入する。

書式２では事前に選択可能な対象を配列に登録することが出来ます。

書式３では選択可能な対象を限定するための条件式を設定することが出来ます。
条件式の中では、 X(該当座標)、Y(該当座標) もしくは該当パイロット、該当ユニットＩＤを使うことで
座標及びユニットの情報を取得することが可能です。

　optionには以下のものが指定可能です。
ユニット選択　　　ユニットを選択する待機状態になります。
　　　　　　　　　　選択したユニットのパイロットが対象パイロットに、
　　　　　　　　　　ユニットＩＤが対象ユニットＩＤに設定されます。
キャンセル可　　マウスの右ボタンクリックを使ったキャンセルを可能にします。
　　　　　　　　　　キャンセル実施時は、マップ地点選択時はX(目標地点)とY(目標地点)に
　　　　　　　　　　空文字を返し、ユニット選択時は対象ユニットＩＤに空文字列を設定します。
非同期　　　　　　選択直後にマップの再描画を行いません。（範囲が表示されたままになります）
　　　　　　　　　　選択範囲の表示を消す場合はRedrawコマンドを実行してください　
拡 [(方向)]　　　　指定したマップ攻撃と同じ選択範囲を表示します。
直 [(方向)]　　　　指定したマップ攻撃と同じ選択範囲を表示します。
扇L? [(方向)]　　　指定したマップ攻撃と同じ選択範囲を表示します。扇はレベル指定が必要です。
　　　　　　　　　　　方向　　上下左右が選択可能。省略時は４方向の範囲を表示する（省略可）
　　　　　　　　　　　　　　　全体を括弧で囲むことで複数指定も可能（例 (上左右)）
線 (x y)　　　　　Ｍ線属性と同じ範囲を取ります。中心座標からx yまでの範囲を表示します。

以下はKeiさんの都合の良い方でお願いします。

配列を渡した際の参照先
１．配列のインデックス
２．配列の要素の値

配列に座標を格納する場合の指定形式
１．前項１の場合、多次元配列[x,y]（","カンマで区切る）
２．前項２の場合、リスト[x y]（" "半角スペースで区切る）

キャンセル選択時の挙動
１．空文字を返す
２．何らかの整数を返す
３．座標選択時は0、ユニット選択時は空文字を返す

「ユニット選択」指定時に「キャンセル可」を指定しなかった場合の挙動
１．「キャンセル可」を無くして常にキャンセル可とする
２．選択対象がなかった場合、キャンセル可が無くてもキャンセル同様の動作をさせる
３．ユニットの存在しない座標を選択することで特異値を返す

引用返信/返信削除キー/

■5864 / inTopicNo.17)

　Re[1]: マップ上の特定ユニット・地点を取得するコマンドAct3

▲▼■

□投稿者/ コウ -(2008/04/08(Tue) 23:40:53) [ID:fqOTLlqC]

ども、コウです。

ちと間が開きましたが、リクエスト掲示板に書き込んできました。

ご意見頂いた方々、ご協力ありがとうございました。

解決済み!

引用返信/返信削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

HOME HELP 新規作成新着記事トピック表示検索新着情報過去ログ

- Child Tree -
- Antispam Version -