【質問フォーム】
【重要！】 質問する前に必ず、過去に同じ質問がないか検索してください！
もし以下のケースで困った場合は、まずリンク先の文書内に答えがないか探してください。
・まずはこの中からお探し下さい → パーフェクトガイド
・バグかな？と思ったときは → よくある質問
・基本システムの設定方法が分からない場合 → 基本システム講座(by 藤田るいふ氏)
・イベントコマンドなどの仕様が分からない場合 → 公式マニュアル
※書き込む前に少なくとも1日2日は、自分で探したり挑戦する努力をしてみてください。
上記のことを全部やってもどうしても分からなかった場合だけ、以下のフォームから質問してください。
>> としこCさん、Masaqqさん、
としこCさんのエディターコモンの案と、Masaqqさんの透明マップチップの合わせワザでいこうと思います。
一時的にレイヤー４〜５を使って番号を振り分け、XY配列をcsvファイル出力or読み込みを活用しようと思います。
透明マップチップをそのまま使い続けるのはバグの元になりそうなので、csvファイルに直そうかと思います。
他のものも そうゆう方法もあるのかと目から鱗で、他の処で活用できそうで大変参考になりました。
お力添えいただいき、ありがとうございました。
マップイベントと主人公の相対座標(X,Y)を文字列化して
それと合致する部分を切り出すことで、返却値を取り出せそうです
一マスの文字列データ『（ X 、 Y ） 戻り値 \n 』
マップイベントXYが(5,6)
主人公ＸＹが（3,5）
当たり判定データ
(-3,5)3
(-2,-1)4
(0,1)3
とした場合、
相対座標（3,5）-(5,6)で (-2,-1)
文字列操作の「指定文字以降を切り出し」で
"(-2,-1)"以降の
「4\n(0,1)3\n」が切り出されて、※\nは改行
切り出された「4\n(0,1)=3\n」をそのまま数値に代入すれば、4だけ取得できます
反対に、設定しているマスを取得したい場合は、
一行ずつ切り出して括弧()の中の座標XYを取り出していくことになります
※0904_07:37修正
横から失礼します。
制作環境がよく分からない部分はありますが
とりあえずいくつかの案を挙げておきます
（勘違いや良い方法がなかったらスミマセン）
案1:UDBにタグ番号DBを作る
マップタグ番号が使えないとのことですが
ユーザDBにタグ番号と同じようなものを作ればよいのではないでしょうか。
（参考資料として画像添付）
※ただ、タイルが多かったりタイルセットを複数使っているとDB入力作業がしんどい。
案2:使ってないレイヤーと透明タイルを活用する
レイヤー3(Pro版なら4，5含む)の余りがあるなら、透明な専用のマップチップを
そのレイヤーに置いて判定処理用に使うのも手かもしれません。
（タイル設定は〇でなく↓設定にするなど配慮する）
案3:マップタグ番号の定義を棲み分けする
1桁目を従来の機能(0〜9)、2桁目を仰ってる数値(0〜3？)にする。
仮に、タグ番号37なら ÷10で 3 に、％10で 7 になります
棲み分けできるかどうかは使う数値の範囲とやり方次第
数値を変えて÷30と％30で出来る可能性もある
案4:XY配列に全座標のそのトリガー数値を入れる
主人公が踏んだ場所で判定できるなら
XY配列 データ番号:X座標、項番:Y座標とかに見立てて入れればよいかと。
（マップがあまりに大きいと処理時間とメモリ利用料域とかは増えそう）
以上になります
|
座標(XY)とその地点に入った時の返却値を返すなら、
私が書いたものを少し修正すれば可能ですが……、
特殊な当たり判定のマップイベントを別のマップでも複数作るなら、
座標と返却値の文字列を手書きで書き起こすのも手間ですね。
いっそのこと、ゲーム内にエディターコモンを作成すべきかも。
[1]ゲーム実行時に特定キーで設定用コモンを起動
[2]クリックした座標のイベントを原点にする（マップイベント名と、以降の計算用にXY座標を取得）
[3]0~9の数字キーを押して、返却値を設定
[4]座標をクリックすると、その座標（相対）と返却値を文字列変数に追加
[5]特定のキーで、DBをcsvファイル出力/csvファイルから読み込み
たとえば、返却値を(3)と設定した後に、原点マップイベントから(0,1)の座標をクリックした場合、
(0,1)=3
のような文字データを文字列に加算する。
同時に、設定中にマップ座標に合わせて設定値をピクチャ表示できれば、視覚的に分かりやすくなり設定ミスも防げます。
可変DBのタイプ内容としては、２つの文字列変数
・マップイベント名
・座標(XY)＆返却値のデータリスト
となり、
「タイプ内容設定」の「データID設定方法」から
「最初の文字列データと同じ」を設定しておけば、
マップイベント名でデータ内容を参照できるようになります。
当たり判定を処理するコモンイベントには、マップイベント名を引数にして、
・マップイベント名からマップイベントID取得（文字列操作の隠しコード実行）
・マップイベントIDからマップイベント座標(XY)取得（変数操作＋）
・マップイベント名から可変DBのデータリストを取得（DB操作）
以上の３つの情報を取得した上で、当たり判定処理を行うようにすれば、
マップイベント側は、自身のIDから取得できる自身のイベント名をコモンに投げるだけで、必要な値が返ってくることになります。
―――――――――――――
「ＩＤ」を直接使わず「マップイベント名」で参照するのは、これらのためです。
・マップイベントのコピペ並び替え（ID変動）
・別のマップでの流用
あと、正規表現を扱えると文字列操作が（特に置換操作で）短縮できると思います。
こんなところで、どうでしょうか？
としこCさん、早い回答ありがとうございます。
とりあえず試してみます。
やりたい事は画像のような感じです。
要はマップ上に主人公が立った時、こういった数値の並びを簡易な設定から
自動で取得できるようにしたいという感じです。そこで上げたのがXY配列で、対象が動かないのでマップイベントと主人公の距離を測る方法でなくてもいいという感じです。
また説明が分かりづらかったすみません。
|
XY配列を使うという説明に悩んでいるのですが……
判定がマス単位で、
「近づくと起動する」というのが「範囲内に入る」であれば、
比較的簡単につくれます。
中心座標にマップイベントを設置した上で、
マップイベントの常時実行から判定計算を行う。
増やしたい当たり判定を相対座標(例：1,-1)として文字列変数に記述しておき、
一行（一マス）ずつループで切り出して、
文字列変数から数値変数(XY)に代入変換したものを利用する。
取り出した相対座標と、
マップイベント座標と主人公座標の差(XY)を加算することで、
マスごとの主人公との距離になり
その、どれかが(0,0)になれば接触となる。
□□□□□
□■中■□
□□□□□
このような形であれば
-1,0
0,0
1,0
といった文字列で良い。
※マップイベント位置（中心）を当たり判定に加えない場合を想定して
※相対座標(0,0)も記述しておく
上記のような手段であれば、当たり判定の形を変える場合は、
文字列変数の中身を修正するだけですみます。
質問を読み違えていたらすみません。
どう実現したらいいか、よろしければアイデアや知恵をお借りできたらと思います。
■[やりたいこと]
近づくと起動するというコモンを作っています。
設定座標と主人公座標の距離を測って、返す値が大きくなったり小さくなったりすものです。
その設定座標の当たり判定の形を自由に設定したいという感じです。
イメージ図としては、中心値を一マス単位で自由な形に設定出来たらという感じです。
□□□□□□
□■□□□□
□■■■■□
□□■□□□
□□□□□□
■[やってみたこと]
距離を測るのではなく、XY配列に直接数値を入れてそれを取得するなど考えていますが、
ただ手動で設定するので、修正が入った時に全部やり直しになるというのがネックです。
行き詰っている点としては、なんとか自動化出来ないか？という点です。
中心となる部分を設定したら、後は自動で数値を返すようにならないか？という感じです。
四角であれば簡単ですが上記のような複雑な形だと、どう処理したものかと悩んでいます。
■［補足］
使用用途はマップの環境音などです。
なので基本、設定した中心座標が移動する事はありません。
ただマップタグ番号を取得する方法は、別処理と被ってしまうので使えません。
(1.)仕様について
【空イベント作成】で作成したイベントはマップ移動時に消失します
（※)注意イベントIDに割り当てられた内部変数はマップ移動後も保持
(3.)作成したイベントをマップ移動後も保持する方法
答え：可変DBに保存する
どのようなイベントを作成するかによって対処は変わります。
質問者のウディタ理解度も分からなければ、具体的に行いたいことが書かれていないと、下記のような長々とした仕様解説をすることになります。
だから、(３.)への答えは、苦しんで頑張ってマニュアルを読んで……としか。
作成されるイベントの、おおまかな分類：
(A)マップ内で作成するマップイベントの処理内容が同一か、否か
(B)イベントを移動させるか
(C)プレイヤーとの距離、条件により変化する移動を行うか（Bと異なる）
(D)Self内部変数を利用するか
主に必要となる処理は下記：（分類の理由もそれぞれの説明に）
『基本』
【空イベント作成】コマンドを実行するたびに、戻り値となる作成イベントIDを可変DBに保存。加えてマップ移動時には、「現在マップの作成済み空イベント保存」と「移動先マップの空イベント再作成」を行う
『可変DBの内容』
・生成したマップID
・割り当てられたイベントID
・生成時マップ退出時のイベントの座標XY
・イベントの種類（異なるイベントを作成する場合）
・イベントのSelf変数（異なるイベントの作成順が変わる場合は特に必須）
これらを要、不要に応じて実装すること
『マップ移動の検知』
(A)【変数操作＋】から【現在のマップ番号】の変更を常時並列コモンで監視。
（楽だけど1フレーム遅延、ただしトランジション暗転で隠せる）
(B)【場所移動】コマンドを直接呼ばず、コモンイベントを呼び出し、その中で場所移動コマンドの前後に空イベント管理の処理を置く
『空イベントの起動検知』
(A)マップ内の他のイベントorコモンイベントから並列実行で【変数操作+】その他「[起動]今フレームに決定/接触起動したマップEvID」を確認
(B)空イベントではなく、起動条件＆イベント内容が書かれたイベントをコピーする
（こちらは【<<DELETE_EVENT>>】ではなく【イベント一時削除】でのみマップ中の削除が可能）
『マップ内で異なるイベント処理を行うイベントを作成する』
(A)COPY複製元となるイベントそれぞれに記述
(B)マップイベントのSelf変数、可変DB側にSelf変数を用意し、イベントの種類を保存、マップイベント起動時にSelf変数を引数として、それぞれ呼び出す処理を切り替える
『作成したイベントに複雑な移動動作をさせる』
(A)複製元のマップイベントで、ページ毎に移動ルートをカスタムで設定
Self変数をページの条件にして、イベント作成時に変数呼出でマップイベントのSelf変数を代入
(B)並列実行から作成したイベントの動作指定を管理、プレーヤーとの距離を条件にイベント内容を実行する
(【■キャラ動作指定】ループによる移動指示では、起動条件【イベントと接触】が機能しない)
『マップイベントのSelf変数の初期化』
【空イベント作成】時には、Self変数が初期化されない。
（マップ移動時に作成イベントが自動で消去される場合も同様）
作成するイベントに種類があり、Self変数の用途が異なる場合、
初期化されていないSelf変数の値が、その種類のイベントが通常持ちえない数値だった場合に、誤作動の可能性がある。
作成イベントを削除する際には、Self変数の初期化は必須
―――――――――
これらを理解できない場合、
Masaqq様が書かれているとおり、【空イベント作成】を使わず、通常のマップイベントで対処する方が(!!安全!!)です。
ウディタ自体が壊れることは、おそらくありませんが、
【X番の変数呼出】や【コモンイベント呼出、イベントページ呼出】といった間接参照が意図しないタイミングで行われた場合に、エラー原因の特定に苦労することになります
少し日が経ってしまったので、ご覧になっているかわかりませんが…
端的に申し上げると、「少しだけ難しい方法ならあります」という回答になるかと思います。
まず、Masaqqさんが先に回答されているように、ウディタ単体でSteam Deckを判別する事はできません。
判別可能にするには、Steam Deckの判別が可能なアプリを同梱し、連携させる必要があります。
具体的には、いわゆる”ランチャー”アプリを自作し、「ゲーム起動前に判別させ、Steam Deckであることをゲームへ起動時引数を利用して反映させる」のが、比較的工数の少ない手法になるかと思われます。
起動時引数では、普段は”BasicData”から読まれているゲーム設定、DB、イベント、マップ情報のフォルダを変更可能です。
ランチャーでゲーム起動前にSteam Deckかを判別することで、そこから起動時引数を使用してGame.exeを起動することにより、”Windows用”と”Steam Deck用”のフォルダを切り替える事が可能になるでしょう。
＊起動時引数に関しては、公式マニュアルのこちらのページをご覧ください→ hhttps://silversecond.com/WolfRPGEditor/Help/01control.html#GAME_ARGV
ランチャーの判断基準となる情報の取得は、SteamSDKの利用がもっとも確実ですが、Steam経由で配信されていないSteam Deck対応ゲームでは、異なる手法での”推測”による判別も広く使われています。
Steam Deckかを”推測”するために必要な特徴に関しては、ネット上に十分な情報がありますが、これらを全項目の一致で判別させようとすると、少なからぬSteam Deckを弾いてしまうことに注意してください。
通常は変更されないであろう固有の環境変数名など、”ソフト面での特徴を複数利用する判別基準”を用いたほうが、比較的安全ではないかと思われます。
（改造している方が多いため、「構成するハードウェアのモデルを基準にすると、パーツ交換による改造がされた個体が弾かれてしまう」というような問題が考えられます）
最近では、チャットAIにプログラミングについて質問したり、アプリそのものを作成させる事も可能になっています。
簡単とまでは言えませんが、印象よりも実装のハードルは幾分低くなっているのではないかと思います。
ご回答、ありがとうございます！！
迅速かつ的確なご回答とご助言、本当に助かりました。
仕様であること、またその背景のご推察ふくめて理解いたしました。
仕様ではないと思い込み、このままドツボにはまるところでした。
その仕様も前提としてうまく利用していけるようにいたします。
通常のマップイベントでの対処についても、
丁寧にご教示いただきありがとうございます。
非常にわかりやすい画像までいただき、重ねて感謝申し上げます。
現在実装したい機能については頂いた助言をもとに実装したいと思います。
ありがとうございました！！！