どうもです。

＞常の移動もキャラクタの動作指定で行わせてみてはいかがでしょうか
それだと、「方向キーによる移動」と「イベントによる移動」がダブってしまい、縦横方向に移動する際に二歩歩いてしまうんですよ…。主人公の動きを方向キーで動けないように制御できればよいのですが。

＞シフトキーを利用したりして制限を掛ければ
なるほど、それは名案かもしれません。後で実験してみます。

ご意見どうもありがとうございました。では。

主人公の動きを強制的に止めるにはキャラクタの動作指定で一時停止を使えばよさそうですがどうでしょう。
あとは方向キーの入力を全部キー入力処理＋条件分岐＋動作指定＋で行えばなるようになるのではないかと思います。

こんばんわ。
同時押しのタイミングがシビアなんでしょうね。
並列処理の間隔は1/60秒ですが、どのタイミングで入力したかによってシビアさも変動します。
並みの人間の指さばきでは厳密に同時押しするのは不可能ですので
ある程度ゆとりを与えないといけません。

こんな感じではどうでしょうか。
1ページ
（並列処理）
◆キー入力の処理:[0001]（4方向、入力を待つ）
◆スイッチの操作:[0001]をONにする

2ページ
（スイッチ1がONのとき、自動的に始まる）
◆ウエイト：0.0秒
　　〜#67〜
◆条件分岐:変数[0001]が0
　◆スイッチの操作:[0001]をOFFにする
:分岐終了
◆条件分岐:変数[0002]が0
　◆スイッチの操作:[0001]をOFFにする
:分岐終了

1個目のキーが押された瞬間からキッチリ1/60秒（1/30秒がいいかな？）の猶予を与え、
その間に2個目のキーが押されたら#67を実行します。

それから、この手のイベントで恒例の問題ですが
斜め移動中は階段などのイベントを素通りしてしまうので
足元を調べる作業が別途必要になります。

いろいろな場所に「一時停止」を組み込んでテストしてみましたが、ダメでした。

・別イベント（並列処理）に「一時停止」のみのイベントを作る
　主人公の動きが停止してしまう。
・キー入力の前に「一時停止」させ、その後にテク研に載っている斜め方向イベントを組む
　なぜか斜め移動しかしなくなりました。
・キー入力の前に「一時停止」させ、その後にテク研に載っている斜め方向イベント＋縦横四方向移動イベントを組む
　なぜか斜め移動してくれなくなりました。

でも、「一時停止」の案のおかげで惜しいところまで来ました。ありがとうございます。どうも、俺が「一時停止」についてあまり理解していないことを痛感いたしました。精進します。

すっぴぃさんと同時書き込みのようです。こんばんわ。

すっぴぃさんが書いてくださったイベントを実行したら、斜め移動しかしなくなってしまいましたが…。変数[0001]は、1ページ目と2ページ目の#67で共有をしているのでしょうか？

では。

1ページ目のキー入力で、「キーが押されるまで待つ」にチェックを入れ忘れていました…。すみません。ちゃんと動きましたよ！ありがとうございます。

やはり、「二つのキー入力間のタイムラグ」と、「キー入力による移動とイベントによる移動の衝突」が問題点であり、前者はウェイトを使って、後者は「自動的に始まる」に組み込むことによって解決させているみたいですね（自動的に始まるのときはキー入力を受け付けない）。しかし、階段を無視してしまうという原因も「自動的に始まる」で発生しているので、これはどうやって解決しよう…。「自動的に始まる」ではなく「一時停止」を使えば解決するかもしれませんが…。考えてみます。

一応、自分なりに、一番シンプルかなと思える方法でサンプル組んでみました。
要RPG_RT.exe（1.50）です。

http://www5.ocn.ne.jp/~noziko/naname.zip

上記のサンプルは、一時停止を使っていますが、一時停止を使って止めると、決定キーやキャンセルキーが効かなくなってしまいますね・・・。

#3の時点で1つ勘違いをしていたことがありました。
並列処理で動作指定の実行をすると「主人公から触れた時」のイベントが反応しませんが、
自動処理の場合はイベントの上にぴったり移動させたらちゃんと実行してくれることが分かりました。
それなら話は簡単です。足元にイベントがあるときに斜め移動をキャンセルするようにしてみます。

別のイベント
（並列処理）
◆変数の操作:[0003]代入,主人公のX座標
◆変数の操作:[0004]代入,主人公のY座標
◆指定位置のイベントIDを取得:(V[0003],V[0004]),[0005]
◆条件分岐:変数[0005]が1以上
　◆指定動作の全解除
　◆スイッチの操作:[0001]をOFFにする
　◆
:分岐終了

これはすべてのイベントに反応するようになっていますが、
もちろん場所移動イベントのIDだけをピンポイントに指定してもいいです。
本当は2ページ目に組み込みたかったのですが
なかなかいいタイミングで取得できないので別イベントに分けました。
だんだん不恰好になっていく（^^;

＞ノジコさん
サンプルをわざわざありがとうございます。動きは完璧でした。キー二回入力のタイムラグ対策もばっちりですね。キャンセルキーとエンターキーが働かないのは…自分なりに対策を考えてみましたが、以下のようにするのはどうでしょう。

◆（2つキー入力まで）
◆キー入力の処理：[0016:キー56]（Enter,Escのみ許可、待たない）
◆条件分岐：変数[0016:キー56]が5以上
　◆指定動作の全解除
　◆ウェイト0.1秒
　◆イベント処理の中断
：分岐終了
◆（ウェイト0.0秒×2〜二回目のキー入力処理）
◆キー入力の処理：[0016:キー56]（Enter,Escのみ許可、待たない）
◆条件分岐：変数[0016:キー56]が5以上
　◆指定動作の全解除
　◆ウェイト0.1秒
　◆イベント処理の中断
：分岐終了
◆（方向値の計算〜最後まで）

これで、Escキーは確実に認知され、Enterキーはほぼ確実に認知されます（たまに失敗する）。しかし、文章ウインドウ表示中に主人公が歩けたり、触れたときのイベントが発動しないなど、問題点もまだあります。

＞すっぴぃさん
どうもです。

＞並列処理で動作指定の実行をすると「主人公から触れた時」のイベントが反応しませんが、
＞自動処理の場合はイベントの上にぴったり移動させたらちゃんと実行してくれることが分かりました

それは知りませんでした。貴重な情報ありがとうございます。

試したところ、斜め移動中の触れたときのイベントも発動しました。コモンイベントを3個も組むとは、予想以上に大きいイベントになってしまいましたね…。
しかし、階段イベントで試したところ、移動後にもう一歩斜めに動いてしまいました…。よくよく考えると、普通に斜め移動しても2歩単位でしか動けませんが、これも新たな欠点でしょうか？
もう一つ。自動的に始まるのイベントの弊害ですが、斜め移動中は他のイベントの動きが止まってしまいますね。

どの方法も、一長一短あって、なかなか難しいですね。
別の方法で主人公を止めるようにして、サンプル2を作りました。
常に主人公にイベントを重ねて配置するようにしています。このイベントのグラフィックを、通行不可のマップチップにしてあるので、ストッパーの役割をしています。
この方法だと、決定キー、取り消しキーも完璧にききます。
ただ、どうも動きが怪しくて、たまに2歩歩いたりするんですよね。

また、その他のイベントで不具合が出ます。
イベント開始条件が、主人公から触れたときの場合、動作しない場合もあります。
文章表示中も動いてしまうので、スイッチなどで制御する必要があるでしょう。

要RPG_RT.exe（1.50）です。

http://www5.ocn.ne.jp/~noziko/naname2.zip

いつもありがとうございます。
サンプルを見させていただきました。

主人公を斜め移動させたところ、45°の方向に動かなくなってしまったのですが…。これは仕様でしょうか？

透明イベントを主人公の位置に置くというのはよいアイデアですね。（実はこのアイデアは、今日ある方からメールをいただいて、それで初めて知りました。残念ながら俺が組んだところ、失敗してしまいました…。もう少しで完成？）透明イベントがやはり最終的な解決案になるのかな？しかし、透明イベントがストッパーになるというのは驚きですね。

ではでは。

肝心の斜め移動が、うまく作動しなくなってしまってますね。
これは、指定動作の全実行が入っているためです。
指定動作の全実行が無ければ、スムーズに動くはずです。
一応、ファイルのほうも、更新しておきます。

ちゃんとスムースに斜め移動しました。あとの問題点は、一度に二歩動いてしまう現象ですね…。

意外に斜め移動は難しい…。

斜め移動中にイベントが止まるのはアクション系やシンボルエンカウントでは致命的ですね。
この場合はやはり並列処理で実現するしかないでしょう。

2歩移動するのはウエイトを長くすることで防げます。
標準速なら0.1秒止めても大丈夫のようです。（1歩目が多少もたつきますが）

キャラクターの動作指定での一時停止を挟むタイミングを変えればウェイトを挟まなくても大丈夫そうです。
処理が一巡するたびにキーを管理する変数に0を代入します。
その直前に方向キーを管理している変数すべてが0の場合を条件分岐で設定してその中に一時停止を入れればいいのです。
移動動作自体はほぼ完璧ですが問題はイベントに向かって決定キーを入力しても方向キーと同時押しなければ（イベントと主人公の座標がかさなっていなければ）認識してくれない点です。

#17のおおざっぱなソースです。
◆キー入力の処理：[0001:キー判定.1](上下方向)
◆キー入力の処理：[0002:キー判定.2](左右方向)
◆条件分岐：変数[0001:キー判定.1]が1
　◆条件分岐：変数[0002:キー判定.2]が0
　　◆キャラクターの動作指定：主人公，下に移動
　　◆
　：分岐終了
：分岐終了
◆注釈：
◆注釈：途中省略
◆注釈；
◆条件分岐：変数[0001:キー判定.1]が4
　◆条件分岐：変数[0002:キー判定.2]が3
　　◆キャラクターの動作指定：主人公，右上に移動
　　◆
　：分岐終了
：分岐終了
◆条件分岐：変数[0001:キー判定.1]が0
　◆条件分岐：変数[0002:キー判定.2]が0
　　◆キャラクターの動作指定：主人公，一時停止
　　◆
　：分岐終了
：分岐終了
◆変数の操作[0001〜0002]代入，0
◆
こんな感じです。
決定キー関係も完成してからソースを送ろうかと思ったのですが、これ以上はちょっと無理そうなので一応投稿します。
結果的に連続投稿になってしまいました。
申し訳ありません。

私の作ったサンプルの、2歩歩いてしまう現象ですが、他のイベント（プライオリティタイプが下のイベント）に重なったとき、問題が発生するようです。2歩進んで、そのイベントを踏み越えてしまう現象です。
これは、ストッパー用のイベント（通行不可のイベント）の上に、他のイベント（通行可のイベント）が重なったとき、通行不可の設定が無効になってしまうために起きる現象です。通行不可の設定が無効になるため、ストッパーとしての役割を果たせず、2歩歩いてしまうわけです。
この現象を防ぐためには、ストッパーのイベントＩＤを大きなものにしておく必要があります。複数のイベントが重なったときの通行設定は、最もイベントＩＤの大きなものが、採用されるからです。
他のイベントを設置し終わった後、ストッパー用のイベントをコピーして、複製を作ってやれば、イベントＩＤの大きなものが出来ます。その後で、いらないストッパーを削除すればいいと思います。
ちなみに、通行可のイベントを設置するとき、プライオリティタイプを上にすることによって、ストッパーとかぶるのを防ぐことも出来ます。

＞すっぴぃさん
斜め移動したときに他のキャラがとまってしまうのは、アクションゲーム等では使えませんね。ローグ系RPGでは使えそうですが。

主人公の動きを止める手法としては

・一時停止
・自動的に始まるイベントを組み込む
・「通行不可」のマップチップ（「通常キャラと重ならない」ではない）を常に主人公の上に重ねる

が考えられますね。どれが一番優秀であるかは一概には決められませんが。

■kidさん
どうもです。

実験してみましたが、どうも最初の一歩封印ができませんでした…。どちらの変数も0の状態の条件分岐を、キー入力の直後に持っていった場合、幾許か楽になりました。しかし、それでもほぼ同時押ししないと最初の一歩は防げないみたいです。（ノジコさんが以前おっしゃった方法を融合させるとうまくいくかもしれませんが。）

決定キーの欠点は、少々辛いですね…。おそらく「一時停止」が悪さをしているのでしょう。うーむ。

■ノジコさん
イベントIDが問題ですか。なるほど。あとで実験してみます。しかし、新たに他のイベントを設置する際に、いちいちイベントをつくりなおさなければなりませんね。作り漏れのないようにしなければならないというのは少々辛い気もします。

以下の案は、ある方からメールでくださったやり方ですが、今のところ欠点はないようです。（ただ、マップチップを多少改造して、透明チップを二つつくらなければなりませんが。）みなさんの意見をお願いします。

マップイベント
マップイベント1ページ目
　　グラフィック：透明（通行不可のチップ）
　　イベント出現条件：なし
　　イベント開始条件：定期的に並列処理
　　イベント実行内容：
　　　　◆現在の位置を記憶
　　　　◆イベントの位置を設定：このイベント, （記憶した場所）

マップイベント2ページ目
　　　　グラフィック：透明（通行可のチップ）
　　イベント出現条件：スイッチ[8方向]がON
　　イベント開始条件：定期的に並列処理
　　イベント実行内容：
　　　　◆現在の位置を記憶
　　　　◆イベントの位置を設定：このイベント, （記憶した場所）

コモンイベント
　　イベント開始条件：定期的に並列処理する、スイッチはなし
　　イベント実行内容：
　　　　◆スイッチ[8方向]をOFFにする
　　　　◆（#67の通り、ただし二つのキー入力間にウェイト0.0秒を挟む）
　　　　◆スイッチ[8方向]をONにする

多少2つのキーを押すタイミングがちょっとシビアですが、これはノジコさんの案を融合することにより解消できそうです。
いかがでしょうか。

■kidさん2
EnterとEscのみ許可する別のキー入力を作って、その変数が5以上のときに、一時停止させずに動作指定解除＋わずかなウェイトとすると、Enterもうまく認知されるようです。

うわあ、5連続投稿だ…。

#24の方法でも、私の案と同様の理由で、踏み越え現象が起きるのでは、ないでしょうか？
イベントをストッパーに使う方法では、イベントが重なったときの問題は、今のところ、イベントＩＤを調整するしか、回避する方法が無いように思います。（逆に配置するイベントの方を工夫して、回避することも可能ですが）

上記のやり方でも、斜め移動中は触れたときのイベントを無視してしまいます。
しかし、ノジコさんのやりかたでは、普通の上下左右方向の移動で、触れたときのイベントの飛び越え現象がおきてしまうのですが。#24のやりかたでは、イベントIDを調整しなくても上下左右方向の飛び越え現象はありません。

踏み越え現象の回避ですが、これは、単に上下左右の動作指定を無くしてやれば、いいだけですね。つまり、斜め以外は、自分で歩かせるということです。
管理人さんがテストして、踏み越え現象が起きなかったのは、多分、管理人さんの移動設定が、そうなっているからでしょう。

この方法だと、主人公から触れた時もちゃんと動きますし、会話イベントの最中も、ちゃんと止まってくれますね。ただし、斜め移動時以外は・・・。

ノジコさんのやりかたで、上下左右をはずしてみたのですが、こんどは上下左右に動けなくなってしまいましたが…。

やはり最大の問題は、斜め移動時の触れたときの「イベント対策」ですね。

欠点をまとめると、

■一時停止
　・決定、キャンセルキーがうまく働かなくなる。
　・触れたときのイベントが発動しない。
■自動的に始まるイベントを組み込む
　・斜め移動時に他のイベントがとまってしまう。
■「通行不可」のマップチップ（「通常キャラと重ならない」ではない）を常に主人公の上に重ねる
　・触れたときのイベントが発動しない。

とりあえず、最新のサンプルです。
かなりシンプルになりました。
斜め移動時以外の問題は、起きないと思います。

http://www5.ocn.ne.jp/~noziko/naname3.zip

どうもです。
だんだんイベント内容が削られて、逆に#67に近くなりましたね。やはり斜め移動は一筋縄ではいかない…。

文章中に斜め移動してしまうのは…イベント発動中に斜め移動を無効にすれば解決できそうですね。ただ、他の全てのイベントにそれを埋め込むのは酷な作業だと思います。

「イベントから触れたとき」のイベントが、無限ループしてしまうんですが…。（斜め移動すれば脱出できる。）

#24の案を以下のように改良しました。

・マップ上におくイベントのIDを0001にした。
・新たなスイッチを使って、キー入力間隔を0.1秒まで許容にした（ソースはとりあえず省略）
・すっぴぃさんが#9でおっしゃった、イベントID取得イベントを導入した。大きいほうのIDが優先されて取得されるという事実を利用し、2以上のIDなら一旦スイッチ[八方向]をOFFにした。

これで、斜め移動中も触れたときのイベントが発動します。

ただ、「イベントから触れたとき」が無限ループになりますが。

余談ですが、「イベントから触れたとき」はそのイベントを
主人公から離さない限り実行され続けます。
ですので、正常な動作で問題はないと思います。

あ、勘違いしてました。
言い訳すると、「通常キャラの下」＋「イベントから触れたとき」というイベントを組んだことがなかったので、知りませんでした。

イベントＩＤの取得で踏み越え現象を止める方法は、私も考えたんですが、ひとつ問題があって・・。プライオリティタイプ上のイベントと重なると、身動き取れなくなってしまうんですよね。
これは、プライオリティタイプ上の場合、ストッパーを無効にする働きが無いためですが、一応、キー入力が無いときでも一瞬ストッパーをはずしてやることで解決は出来ます。
ただ、この場合、タイミングよくストッパーが外れているときに、キー入力があった場合、2歩歩いてしまわないかと思ったのですが、実験してみたところ、そんなことも無い様子。今のところ、最も良い状況ですね。

余談ですが、主人公の動きを止める方法をもうひとつ。
ダミーのチップを作っておき、イベントの通行設定を×にしておき、チップセットの変更で、動きを止める。
でも、この方法も、イベントの踏み越え現象がおきるので、ダメなんだけど・・。
その代わり、他のイベントもいっしょに止められるので、別のことに使えるかもしれませんが・・。アクションＲＰＧで、一時敵の動きを止めるとか。
さらに余談ですが、一時停止を使って止める方法。厳密には、一時停止で止めているのではないようですね。
向き固定やアニメ再開、透明度アップなど、他の命令でも止まりますから。
おそらく、動作指定を繰り返し、し続けることで、キー入力や他の動作指定をキャンセルし続けているのではないかと思いますが、定かではありません。

ID取得イベントをキー入力の前に組み込むことにより、コモンイベント1個で済ます方法をメールで教わりました。ID2以上（他のイベントが存在する状態）で、この斜め移動コモンイベントを中断させます。いまのところ動作は完璧です。

> プライオリティタイプ上のイベントと重なると、身動き取れなくなってしまうんですよね。
実験したところ、そのような問題は発生しなかったのですが…。

> ダミーのチップ
なるほど、このような案もありますね。しかし、いちいちチップを書かなければならないので、実用性は低いですね。
他のキャラの動きを止めるならば、「自動的にはじまる」でもいけそうですね。

> 一時停止
一時停止そのものが主人公の動きを止めているのではなく、なんでもよいから動作指定の繰り返しでとめている、ということですね。以前行った「動作指定関係の解析」で、「動作指定」の一時記憶を溜めているという現象がありましたが、おそらく一時記憶を溜めている間は主人公が動かないのでしょうか。（そうすると、「動作を繰り返す」のときのみ動きが止まる、という点の説明がつきませんが。）

#27のやり方で、欠点がみつかりました。
やはり、ノジコさんのやり方と同じように文章表示中に斜め移動できてしまう点です。
うむむむ。

いやー、メッセージ表示中はスイッチでコモンイベントを止めるしかないと思います。
標準ウインドウを使っている人には、少し面倒ですけど、ナナメ移動させるぐらいだったらウインドウもピクチャーで半透明とかしてる確率の方が高くないですか？　だったらウインドウ表示をコモンイベントで処理するはずですので、そこにスイッチのON/OFF入れるだけですから、手間にならないと思いますよ。

>実験したところ、そのような問題は発生しなかったのですが…。
多分、イベントの組み方が違うせいでしょうね。前のやり方に戻した部分もあったし。

>（そうすると、「動作を繰り返す」のときのみ動きが止まる、という点の説明がつきませんが。）
動作を繰り返すように設定した場合、そのイベントが実行されている間は、繰り返し、動作指定が行われるのでしょう。
他の動作指定が行われるか、イベントが終了すると、繰り返しが終わるのだと思います。

あと、こちらの方では、イベントＩＤで他のイベントと重なっているか検知する方法を使うと、イベント上から、斜めに抜けられないという状態になりました。（イベント上では、移動処理が動かないようにしてあるので、当たり前ですが）
イベント上から、斜めに移動できるようにする場合、他のイベントと重なっているかいないかで、処理を変えないといけないですね。

とりあえず最新版。ここまでてこずるとは、思わなかった・・・。

http://www5.ocn.ne.jp/~noziko/naname4.zip

ところで、文章表示中に、斜めに動いてしまう件は、イベント開始時にスイッチをｏｆｆにすることで解決するくらいしか、思いつきません。まあ、そう面倒でもないので、このくらいは、いいんじゃないでしょうか。特に会話ウィンドウを、イベントでコントロールしている場合は、そのイベントの中に組み込んでしまえばいいので楽です。

#27でのやり方にしろ、ノジコさんのやり方にしろ、文章中に斜め移動をしてしまう問題を解決する案ができました。（かなり無理やりな案ですが。）

・ほぼ全てのマップイベントの最初で、「斜め移動封印」というスイッチをONにする。また、最後で「斜め移動封印」をOFFにする。
・「斜め移動封印」がONのときに、斜め移動の処理を行わないように条件分岐させる。

これだと、ものすごい手間はかかりますが、一応文章表示中の斜め移動は防ぐことが出来ます。

しかし、もっとよい解決策がありそうな気がするので、もう少し詮索してみます。

■SKさん
見事にかぶってしまいましたね…。

> 標準ウインドウを使っている人には、少し面倒ですけど、ナナメ移動させるぐらいだったらウインドウもピクチャーで半透明とかしてる確率の方が高くないですか？

そうですか？とりあえずシステムとして斜め移動を導入したい、と思っている人は結構いると思いますが…。

■ノジコさん
サンプルをいつもありがとうございます。早速見させていただきます。

サンプル見させていただきました。

やはり、イベントごとにスイッチを使って管理する、といった方法をとっておられましたね。この方法しかないのでしょうかね…。

右の武士以外のイベントは、全て文章中に斜め移動できてしまいますね…。

> イベント上から、斜めに抜けられないという状態になりました
こちらでも確認いたしました。マップに、プレイヤーに気づかれないような透明イベントをおくような場合は致命的な欠点になりかねませんね。また新たな問題点が…うわあ。

> 特に会話ウィンドウを、イベントでコントロールしている場合は、そのイベントの中に組み込んでしまえばいいので楽です。
「とりあえず斜め移動だけ導入しよう」と考えている人も結構いると思いますが…。どうなんだろう。

> イベント上から、斜めに抜けられないという状態になりました
ボクだったら、その点は無視しちゃいます。
それをクリアしようとしてイベントを複雑化させることのほうが、使い勝手を悪くさせることになりかねないような。
「1つのシステムだけを取り入れる」場合、構造のシンプルさは大切な要素だと思います。　つまり、その問題と構造問題を比較すると、ボクは構造問題の方が大きいと感じます。

>とりあえず斜め移動だけ導入
どうなんだろう・・・・。
システム的なバランスを考えると、斜め移動させる人なら他の部分もこだわりそうな気がしたのですが。

ああそういえば、スイッチで斜め移動イベントをON/OFFさせるなら、重なったイベントから斜めに抜けることも簡単にできますね。
もちろんスイッチのON/OFFという手間は掛かりますが、これはもう仕方ないような。　ツクールはスイッチと変数を楽しむものと・・・。

>「とりあえず斜め移動だけ導入しよう」と考えている人も結構いると思いますが…。どうなんだろう。

これについては、主人公の一歩前にイベントがある場合は、斜め移動を禁止する、という方法もありますね。
当然、前にイベントがあると、会話時でなくても斜め移動できなくなりますが・・。でも、とりあえずやりたいという程度なら、それでも良いと思います。
どうしても、常に斜め移動が出来ないと困る、という人は、多少の面倒があっても、スイッチで制御してもらうということで。


> イベント上から、斜めに抜けられないという状態になりました

一応、前回のサンプルで、回避するようにスイッチで切り替える仕組みにしましたが、ウェイト0.1秒を入れないと、イベントに触れたとき感知しないという状態なので、なんか微妙です・・・。
もっと、良い方法は、無いものか・・・。

■SKさん
確かに、ある程度妥協も必要ですね。
スイッチON/OFFを全てのイベントに導入したり、透明イベントかどうかをIDで判別する方法も考えられそうです。
しかし、何かもっとスマートな解決法がありそうで、悔しいです。

■ノジコさん
> 当然、前にイベントがあると、会話時でなくても斜め移動できなくなりますが
つまり、透明イベントが見えない壁のようになってしまうのでしょうか。ううむ。
#27の案（実はSKさんの案）とノジコさんの案が今のところ一番有力だと思うので、とりあえずこれらのうちのどちらかか、ブレンドされたものがテク研にのることになりそうです。

スイッチON/OFFが最も適切な気がします。
会話だけでなく、他のイベント実行中にも動作を止めなければならない場合もあるでしょうし（オリジナルメニューなど）、イベントと重なったときの問題も、スイッチで解決するのが最も簡単でしょうから。
どちみち、コモンイベントをスイッチで動かすようにするのなら、会話も同じスイッチで制御してしまうのが、分かりやすいのではないでしょうか。

やはりスイッチがベストの解決策ですか…。

> 他のイベント実行中にも動作を止めなければならない場合もあるでしょうし
そうですね。斜め移動できてしまうのは、文章だけではないはずですから。イベント開始前にスイッチで封印してやれば、とりあえず全ての命令において斜め移動を封印することができますね。

> 会話も同じスイッチで制御してしまうのが
たとえばONのときは斜め移動、OFFの時は文章表示、といった感じでしょうか。


あとで、テク研に載せる案をテキストファイルとしてUPしてみることにします。

>たとえばONのときは斜め移動、OFFの時は文章表示、といった感じでしょうか
書き方が悪かったです。。。
要するに、会話の時にも同じスイッチで斜め移動を封じることができるので、という意味です。

いやー、ナナメ移動でここまで長引くとは。
でもこうして話し合いながらやると、楽しいですし、バグも事前に解決できていいですねー。

> いやー、ナナメ移動でここまで長引くとは。
> でもこうして話し合いながらやると、楽しいですし、バグも事前に解決できていいですねー。

そうですね。議論で50レスも伸びたのは史上初です。記念に特別なログとして取っておこうかとおもいます。


取りあえず、掲載案を作りました。まだ手を加える余地はあるかも。
http://star.s9.xrea.com/otherfiles/rpgm2k/eight.txt

おつかれさまです。
>[キーが押されていない]をONにする
ところの条件分岐は、最初のキー入力受付より上になければならないような気がします。　これはイベントが一巡して最初に帰ってきた段階でキーが押されているかどうかを判定するためのもの（要するに停止していて最初の1歩目なのかどうかを判別するもの）ですので、キー入力の後に入れると少し効果が薄れるのではないでしょうか。

>ノジコさんによる解決案：次の一歩先のイベントの存在を判定して、
>イベントがあるなら斜め移動を禁止させる。ただし、「通常キャラの
>下」イベントが壁のようになってしまう。

と、ありますが、これ私の案では、無いですよ。
私の最新サンプル（naname4）では、イベントの上も、スムーズに斜め移動できます。

と、言うわけで、たぶん最終版。

http://www5.ocn.ne.jp/~noziko/naname5.zip

さすがに、「イベントの位置を設定」でストッパーを退けるのは、横着なので、スイッチ式にしました。（元々そうすべきだったんですが・・・）
一応、試した範囲では、スムーズに動きます。イベントの上を斜め移動しても、挙動不審になりません。（若干違和感はあるが・・・）もちろん、イベントの上からの斜め抜けも出来ます。
イベント構造は、シンプルだと思います。
スイッチによる移動システム停止を行えば、他イベント処理時に動くことは無いはず。

問題点は、斜め移動時に主人公から触れたとき発生するイベントに重なったときの判定が、タイミングに頼ってるっぽいところがあること。ウェイト0.0秒をはずすと、反応しなくなりますので。（ただし、ウェイト0.0秒を入れれば、実験した限りでは、100％反応しました。）

■SKさん
たしかにその通りでした。修正しておきました。
ご指摘ありがとうございます。

http://star.s9.xrea.com/otherfiles/rpgm2k/eight.txt

■ノジコさん
> 私の案では、無いですよ
#45で述べていたと思ったのですが…。

サンプルを見させていただきました。毎度ご苦労様です。

「通常キャラの下/上」イベントで、斜め移動でスムースに抜けることができました。

一部のイベントは文章中に斜め移動できてしまうのですが…。武者と同じスイッチを使えば防げますかね。

> タイミングに頼ってるっぽいところがあること
うちでも100%成功しました。おそらく大丈夫なんじゃないでしょうか。

ノジコさんの案を考慮に入れて、修正を加えたいと思います。

遅まきながらノジコさんの案をやってみました。
いや、とてもいいと思います。
ボクのよりスムーズに動くので快適ではないでしょうか。
ただ、キー入力2回目の条件分岐は不要だと思います。
実際に条件分岐を削除してキー入力だけにしても同じように動きましたが・・・。
コモンイベントを使わず、マップイベント1つで済んでしまうのは便利ですね。

あと、ノジコさんの案ですが、
途中に「イベントＩＤ」が1の条件分岐がありますよね。
もちろん、斜め移動イベントと重なっているかどうかを判定しているワケですけど、せっかくなので斜め移動イベントのＩＤが何番でも構わないようにしてはどうでしょうか。　１番に限定しなくても良くなれば、製作中のゲームなどにも組み込みやすいと思います。
斜め移動イベントを最初は停止させておき、イベントＩＤを（別の変数に）取得しておけば簡単にできますので。

だいぶいい感じになってきましたね。しかしまた新たな伏兵の登場です。
ノジコさんの案、タイミングが関係するかもということで移動速度を変えて試してみました。
移動速度3以下のときは「主人公から触れたとき」「イベントから触れたとき」が共に反応しないようです。
それから2歩続けて動く現象が見られました。
移動速度5以上のときはイベントの取得は完璧です。
ただ、「決定キーが押されたとき」のイベントに乗ると斜め移動がキャンセルされ、四方向に動きます。
移動速度によって微調整が必要なようです。

>#45で述べていたと思ったのですが…。

これは、会話時にも動いてしまうのを防ぐ方法として書いたんです。会話中（＝一歩前にイベントがあるとき）は、斜め移動を禁止するということですね。


>ただ、キー入力2回目の条件分岐は不要だと思います。

条件分岐を無くすと、1回目のキー入力が、上書きされてしまうので、２回やる意味がなくなってしまうと思うんですよ。
ウェイト0.0秒が２つ入っていて、その前でも後でも、キー入力されていれば、有効と見なすので、最初の一歩の同時押し判定が、若干ゆるくなると思うのですが、どうでしょうか。このあたりは、微妙な感じですが。


>せっかくなので斜め移動イベントのＩＤが何番でも構わないようにしてはどうでしょうか。

これは、実は、実験済みで、問題があったので、やめました。
何番でもいいようにすると、他のイベントと重なったとき、状況によって反応が変わってしまうので。つまり、ストッパーのＩＤと、下に置いてあるイベントのＩＤ、どちらが大きいかによって、「主人公が触れたとき始まる」イベントが反応しなくなったりといった。
そのあたり、もっと研究して、完璧に動くようになれば、その方が良いと思いますが・・。


すっぴぃさん

やはり、タイミングの問題が出ますね。これは、速度ごとに最適な調整ポイントを見つけないとだめかな・・・。
とりあえず、標準速の場合は、ＯＫということかな・・・。

SKさんの案とノジコさんの案のいいとこ取りをして融合させようと思ったのですが、どうもうまくいかないようなので、このままではノジコさんの案そのままになりそうです。まだ分かりませんが。

> コモンイベントを使わず、マップイベント1つで済んでしまうのは便利ですね
それは一つのメリットですね。しかし、途中で何かしら変更したくなったときには、少し不便かもしれませんが。一部をコモンイベント化して呼び出す、という方法も考えられますね。

> 移動速度によって微調整が必要なようです
うーん、これは…。妥協でいいような気がしますが…。

> 会話中（＝一歩前にイベントがあるとき）は、斜め移動を禁止するということですね。
わかりました。ところで、決定キーを押したときのイベントに対しても、「システム停止」スイッチを使えば文章中に斜め移動せずに済むと思うのですが、何か問題点があるのでしょうか？上記サンプルではそれがなく、文章表示中に斜め移動できてしまうので…。

いろいろいじくって分かったこと：
ノジコさんのやり方のように、途中でウェイト0.0秒×2を入れるなどして「隙間」を作ってやらないと、触れたときのイベントがうまく認識されないようです。

速度調整機能付き版

http://www5.ocn.ne.jp/~noziko/naname6.zip

１ページ目の最後の部分と、２ページ目の最初の部分に、調整のためのウェイトを入れるようにしました。
もっとも、この機能を有効にするには、移動速度調整のための変数に、ちゃんと正しい値を入れておかなければいけませんが。
一応、ちゃんと動いているようですが・・・。


>決定キーを押したときのイベントに対しても、「システム停止」スイッチを使えば文章中に斜め移動せずに済むと思うのですが、何か問題点があるのでしょうか？

これは単に、入れるのがめんどくさくて、サボっただけです。ちゃんと入れておけば、大丈夫です。

まだ調整不足でした・・・。
2歩歩きが、防げてないので、もうちょっとウェイトの調整が必要のようです。
ウェイトの調整だけで、防ぎきれるのかな・・・。

サンプル見させていただきました。

キー入力を3回も行うとは…。最初の一歩封印だけでこんな工夫まで及ぶとは思いませんでした。

速度を二倍速にしたとき、「通常キャラの下」＋「決定キーで始まる」イベント上で斜め移動が出来なくなってしまいましたが…。

> ちゃんと入れておけば、大丈夫です
了解しました。


更新しました。ノジコさんの案を全面的に取り入れました。（ただし、速度関係はまだ。）
http://star.s9.xrea.com/otherfiles/rpgm2k/eight.txt

キー入力を3回は、意味があるかどうか分かりません。より厳密になるかな？　というくらいで、実際の操作感に変わりは無いでしょう。

naname6、一応更新しておきました。さらに、ウェイトを調整して。まあ、あんまり移動速度を落とすのは、やめた方がいいかもしれません。

＞速度を二倍速にしたとき、「通常キャラの下」＋「決定キーで始まる」イベント上で斜め移動が出来なくなってしまいましたが…。
これは、早すぎて処理がおっつかないということなのかな？　だとすると、回避するのは・・・。

> 早すぎて処理がおっつかないということなのかな
1/2倍速でも同じ現象がおきました。おそらく処理速度ではなく、ウェイトに関係するものだと思われますが、よくわかりません。

あら捜しばかりで申し訳ありませんが、移動速度を1/2倍速にしたら、こんどは最初の一歩封印ができなくなってしまいましたが…。

新たなる伏兵が…。

・イベントの上から改めて斜め移動を行おうとすると、最初の一歩が封印されない。
・「通常キャラの上/下」イベントを斜め移動で通過する際、主人公の向きが変わる。
具体的には、上下向きが左右向きになる。

これくらいなら許容かもしれませんが。

意外と厳しいですね、ウェイトによる調整は。
とりあえず、標準速なら、大体動くという感じで・・・。

まだ未解決の問題はありますが、以下が最終案でよいのかな？
他に意見が出るかもしれませんので、もう少し待ちます。
http://star.s9.xrea.com/otherfiles/rpgm2k/eight.txt

>イベントの上から改めて斜め移動を行おうとすると、最初の一歩が封印されない。

まったく封印されていないわけではないんですけどね。
斜めに抜けられるときもあります。この辺は、不安定ですね。
まあ、今のところ100％とは、いきませんが、とりあえず、実用にはなるかな・・。
ゲームパッドで動かすと、結構快適に動きます。

稀に成功することを確認しました。
まあ、この辺は「仕様」ということで…。

大変なことが判明しました。
並列処理でも「指定動作の全実行」を使えば主人公から触れたときに開始するイベントを取得することができます。
私の固定観念から並列処理ではイベントの取得ができないと発言したことが大混乱を招く結果となってしまいました。
皆様本当に申し訳ありませんでした。

一応サンプルを組みました。
http://suppy1632.hp.infoseek.co.jp/game/na.lzh
これまでとの違いは同時押しを一度判定したら繰り返し処理で斜め移動モードに移行するようにした点です。
これでウエイトの邪魔を入れずに指定動作を実行することができます。
それと2番目の問題点に関連して主人公に通行不可チップを重ねる方法の他に、四方向に透明の壁を配置する方法を収録しています。
最初はどちらもOFFになっていますのでキャンセルキーを押して選択してください。

今回は大変なご迷惑をお掛けしました。これからは発言の前にしっかりと調べることを心がけます。

おはようございます。

サンプル見させていただきました。完璧な動きですね…。しかも、現在分かっている不具合を全て解消してしまったとは。お見事です。

> 並列処理でも「指定動作の全実行」を使えば主人公から触れたときに開始するイベントを取得することができます。
おそらく、「指定動作の全実行」をしているあいだはウェイトがかかっているのと同じ状態になっているものと思われます。その隙に触れたときのイベントが実行されたのかな？

> 皆様本当に申し訳ありませんでした
いやいや、お気になさらずに。

> 2番目の問題点に関連して〜四方向に透明の壁を配置する方法
二番目の問題（最初の一歩封印失敗）も完璧ですね。いやはや脱帽です。スクリプトの量もさほど変わらないみたいなので、こちらを採用して、テキストファイルを更新しておくことにします。（なんだかすごいスピードで書き換わっていくような気がする。）どうもありがとうございました。

ううむ、しまった・・・。
「指定動作の全実行」を使えば、一歩一歩処理されることは、分かってたんですが、そうすると、斜め移動がうまくいかないので、やめてたんですよね。もっと、ちゃんと検討すべきでした。
並列処理の中で、さらに繰り返し処理するというのが、ちょっと盲点だったな・・・。

さて、本題ですが、実はですね。まだ、完璧ではないんです。
私の方式でもすっぴぃさんの方式でも同じなんですが、「主人公から触れたとき」のイベントをすりぬけてしまう現象です。
上下左右いずれかの方向から、イベント上に進入し、移動し終わる前に、斜め方向へ移動すると、すり抜けます。
速度を落とすと、より顕著ですが、標準速でも起こります。
上下左右も動作指定で制御すればいいかなと思いますが、まだ検証してません。

斜めすり抜け現象…。
標準速では確認できませんでしたが、速度が遅ければ起こりうる問題ですね。次から次へと難題が…。
現在、すっぴぃさんのサンプルを元に、四方向ストッパー個別にON/OFF切り替えを行うことによって、解決できるかどうかテストしています。

上下左右もイベントに組み込んだら、イベント踏み越え現象がおきました。#20台の再現です。あああ。

すいません、しばらく自分のことしてました。
一応、まだ解決を見ていないようですので、ボクが作ったものをアップしてみますね。
参考になるかどうか分かりませんが、よろしければどうぞ。
ちなみに、斜め移動のシステムは、マップイベントひとつです。
試した部分は、
・速度に関係なく主人公から触れたときのイベントが実行されること
・斜め移動がキレイに始まること
　（速度が落ちると、キー入力がシビアになるようですが）
・イベントと重なった状態からでも斜め移動で抜けれること
この３点です。
また、斜め移動システム用のイベントIDは何番でも構いません。
会話などの時にスイッチを入れなくても、斜め移動は動作しません。
２ページのマップイベント1つで動くので、シンプルだと思います。
特に利用者が設定すべきことは、２ページ目の一番下にある
イベントの位置設定で、そのマップで邪魔にならないところを指定するくらいです。　壁の中とかにすればいいでしょう。

http://www.neogaia.com/Project2.lzh

サンプル見ました。
この方法だと、「主人公から触れたとき」がちゃんと認識されますね。
でも、なんでだろう？　このへんの、振る舞いの違いが、よく分からないんですよね・・・。

それから、やはり斜めすり抜け現象は、起きますね。
もう、いっそのこと「主人公から触れたとき」は、あきらめるという手も・・。

ノジコさん＞
なるほど、そういう問題もあったんですねー。
よく読んでなかったです。
一応、すり抜け問題が起きないようにしてみました。
大した変更はしてません。　スイッチが1個増えました。

振る舞いの違い＞
ボクのイベントでは、主人公の下に何らかのイベントがあれば斜め移動を中断しています。　そのため、重なったイベントが実行されます。

失礼、DLは上記と一緒です。

あ、度々すいません、色々と問題が噴出してきましたので、ボクのやつはちょっと忘れておいてください。。。
明日の朝には、修正したものをまた持って来たいと思います。

SKさんどうもありがとうございます。（どうやらサンプルを作っていないのは俺だけみたいなので、肩身が狭い思いです…。がんばろうっと。）

> 明日の朝には、修正したものをまた持って来たいと思います
楽しみに待っております。


> この方法だと、「主人公から触れたとき」がちゃんと認識されますね。
> でも、なんでだろう？　このへんの、振る舞いの違いが、よく分からないんですよね・・・。
なんででしょうねぇ（汗）？これの分析も行ってみたいと思います。おそらく、以前俺が述べたとおり、「ウェイト」と「指定動作の全実行」が関わっているものと思われます。SKさんのサンプルは、スイッチを2つ使って、段階的に斜め移動処理を終了させている（斜め移動し終わった後も、そのページをもう一回実行している。）ようなので、これがウェイトと同様の効果を生んでいるんじゃないかな、と思いました。どうなんだろう…。

改良版をUPしました。
http://www.neogaia.com/Project2.lzh

[多分大丈夫な点]
・イベントに重なるとその場で停止してイベント内容を実行する
・イベントから重なった状態で斜め移動開始できる
・イベントすり抜け問題が起きない
・重なった時、停止せずに実行するイベントに対応（スイッチ使用）
・斜め移動用イベントのIDは何番でも良い（多分）

[出来なかった点]
・停止せずに実行するイベントに重なった状態から斜め移動開始できない？
・停止せずに実行するイベント通過時、稀に1歩だけ斜め移動できない

要するに、重なったときに停止することにばかり気を取られていましたが、停止せずに突き抜ける場合に対応しました。
普通は停止しますので、メッセージ表示などで毎回スイッチON/OFFを組み込む必要はありません。　その代り、停止しなくても良いイベント（上を通過すると音が鳴る等）であれば、そのイベントの最後にスイッチONを入れる必要があります。（ONだけです）

[なぜ斜め移動が停止するのか]
主人公がイベントに重なった場合、ページ1に戻るようになっています。　ページ1ではキー入力が"入力待ち"になっているので、そこまで行ってイベントは停止します。
「触れたとき」イベントは「自動実行」と同じ扱いなので、再度キー入力を受け付けるには、「触れたとき」イベントが終了する必要があります。
上を通過する場合は「スイッチ：斜め移動中3」をONにすることで、ページ3が実行され、その後ページ2に切り替わり斜め移動を継続します。

どうもありがとうございます。さっそく見させていただきました。

> ・イベントすり抜け問題が起きない
この件に関してなんですが、主人公を低速にすると、斜めすりぬけが出来てしまったのですが…。主人公がイベントに向かって歩いている最中に、別の斜め方向を押すと生じます。
今俺が考えている通過防止機構は、イベントに重なる際に一旦斜め移動を停止させ、ウェイトをかけるというものですが、なかなかうまくいきません。

> ・斜め移動用イベントのIDは何番でも良い（多分）
これは大きなメリットですね。


イベント実行中の斜め移動防止機構が新しくなりましたね。斜め移動を停止させるのに、スイッチが不要になったのがとてもいいですね。「キー入力待ち」にして、事実上ウェイト状態にしているという点が素晴らしいですね。ところで、キー入力待ちならば、後のキーコードの条件分岐が不要だと思うのですが…（実際、はずしても動作したようです。）。

> 「触れたとき」イベントは「自動実行」と同じ扱いなので、再度キー入力を受け付けるには、「触れたとき」イベントが終了する必要があります。
これは知りませんでした。いやはやタメになりました。

斜め抜け、やはりおきますね。でも、ＳＫさんのは、おきにくくは、なっているようです。
すっぴぃさんのは、２倍速でもすり抜け成功してしまいましたが、ＳＫさんのは、標準速でも稀にしか成功しませんでした。
標準速ですりぬけしなくなれば、なんとか、実用になるかな・・・。

標準速での斜めすり抜けは確認していませんが（というか、キー入力に修練がいるので出来ないのですが）、稀にしかできないならいいんじゃないでしょうか…。テク研に載せるときは、「すり抜けてしまうこともあるので要注意」と書くつもりです。

すり抜け現象に関しては、割り切ってどちらかにしたほうが良いと思いますよ。
わずかでもすり抜ける可能性があれば、結局、「どうしてもすり抜けたら困るイベント」には、使えないですから。
すり抜け現象が、防ぎきれないなら、すり抜けが起きるのは、仕様としておけばよいと思います。
対処法として、「主人公から触れたとき」を使わない、あるいは「主人公から触れたとき」は、主人公に重ならない設定にして、必ずぶつかって止まるようにする、などの対処法を書いておけば、良いでしょう。
その代わり、イベントは、なるべくシンプルに、使いやすいものにした方が、良いと思います。

もし、すり抜けが、完全に防げるなら、イベントが、もっと複雑になっても良いと思いますが、これは、可能なのかどうか・・・。

> 割り切ってどちらかにしたほうが良いと思いますよ。

そうですね。100%防がなければ、まったく防いでいないのと一緒ですからね。「現在、すり抜け現象を防ぐ方法は見つかっていないので、万が一すり抜けても大丈夫なように、ゲームを作れ」とでも書いておきます。

>対処法として、「主人公から触れたとき」を使わない、あるいは「主人公から触れたとき」は、主人公に重ならない設定にして、必ずぶつかって止まるようにする、などの対処法を書いておけば、良いでしょう。

触れたときで、通常キャラの下のイベントでも、幅一キャラ分の細い通路の途中におけば、大丈夫なのではないでしょうか。

> もし、すり抜けが、完全に防げるなら、イベントが、もっと複雑になっても良いと思いますが、これは、可能なのかどうか・・・。

あと少しで解決しそうな気がするのですが…。悩ましいですね。もう時間がたちすぎた気がするので、とりあえず明日あたりに不完全版として更新したいと思います。（SKさんの最後の案を採用することにします。）まだこのスレッドが終わったわけではありません。

>触れたときで、通常キャラの下のイベントでも、幅一キャラ分の細い通路の途中におけば、大丈夫なのではないでしょうか。

はい。対処法は、色々あると思います。
おっしゃるとおり、そもそも斜めに移動できない場所に設置するとか、並列処理で、座標を管理して、主人公が決まった座標に来たら、発動するようにするとか。
そういう対処法を書いておけば、問題ないと思います。たぶん・・・。

間が悪いですがサンプルを改良しました。
http://suppy1632.hp.infoseek.co.jp/game/na.lzh

すり抜けを防ぐために縦横移動もイベントで管理するようにしました。

これにより主人公を止める必要があるのは一歩目の1/30秒間だけになったので一時停止を復活させてみました。
決定やキャンセルを受け付けない問題は無視できるレベルだと思います。

他のイベントを実行するとき移動を停止させるにはイベントの最初でスイッチ2をonにする必要があります。
「触れたとき」のイベントに関しては動作実行の直後に足元のイベントIDを調べてスイッチ2をonにする手もあります。
実行中のイベントが終了するとコモンイベント２が動いて自動復帰します。
しかし並列処理で文章表示をする場合にはシステム自体を止めなければなりません。

どうもです。サンプルありがとうございます。これは…動きが完璧ですね。今のところ不具合は見つかっていません。
まさか一時停止が復活するとは思っていませんでした。一時停止の解除のタイミングを合わせると、ちゃんと他のイベントが実行されるのですね。びっくりです。

他のイベントを実行するときに、斜め移動システムをとめるためにスイッチを使わなければならないのはやや不便ですね…。これは、SKさんの案を融合させて、スイッチなしで実現できるかもしれません。つまり、キー入力の処理で「キーが押されるまで待つ」にチェックを入れたものを導入すれば、うまくいくかもしれません。

ところで、今はじめて気がついたのですが、移動を指定動作で制御すると、敵とエンカウントしないんですね。

>他のイベントを実行するときに、斜め移動システムをとめるためにスイッチを使わなければならないのはやや不便ですね…。これは、SKさんの案を融合させて、スイッチなしで実現できるかもしれません。つまり、キー入力の処理で「キーが押されるまで待つ」にチェックを入れたものを導入すれば、うまくいくかもしれません。
あ…、今やってみたところうまくいきました。最初に試した時は失敗したのですが。
ともかく上のURLに修正版を上げなおします。

>ところで、今はじめて気がついたのですが、移動を指定動作で制御すると、敵とエンカウントしないんですね。
こ、これはまた新たな問題が…
自作エンカウントしかないのかなぁ。幸いこのイベントの中で歩数を取得することは可能ですが。

すり抜け不具合を修正しました。
多分、すり抜けは起こらないと思います。
エンカウントに関しては、何もしてません・・・。

http://www.neogaia.com/Project2.lzh

ボクの方は、一応この辺りで終わりたいと思います。
（何か修正したい衝動に駆られたらまた現れます）
とても勉強になりました。
みなさまありがとうございました。
完成版の掲載を楽しみにしています。

■すっぴぃさん
サンプルありがとうございます。
逆に、斜め移動をとめないで効果音だけ鳴らすイベント（触れたとき）をおいてみたのですが、これも大丈夫でした。

エンカウントに関しては、おそらく自作エンカウントで対処するしかないと思います。斜め移動するかぎり、「動作指定」は絶対必要ですから。

■SKさん
サンプルありがとうございます。
すり抜け現象はおきませんでした。
ところで、SKさんのサンプルに問題点が見つかってしまいました…。
「イベントに向かって移動→斜め移動」とすると、つまり、すりぬけを試みようとすると、斜め移動が失敗してしまいました。
また、効果音だけ鳴らすイベント（椅子）で、時々動きが止まってしまうこともありました。

> ボクの方は、一応この辺りで終わりたいと思います
お疲れ様でした。こんなに長く議論に付き合ってくれて、どうもありがとうございました。


さて、ここまで総合的に見て、すっぴぃさんの最終案が最も優れいていると思われるので、それを掲載したいと思います。（SKさんはじめ、サンプルをいままで作ってくださった皆さんごめんなさい…。）kidさん、ノジコさん、すっぴぃさん、SKさん、どうもありがとうございました。

（改良案の受付がストップしたわけではないですよ。）

久しぶりに、イベント組みなおしてみました。（なんか、タイミングが悪かったですが）
今までに出た情報を総合して、なるべくシンプルに、簡単になるように作ったつもりです。

一応、こちらで実験した限りは、以下の点は、問題ありませんでした。

２歩あるきしない
イベント踏み越え現象が起きない
斜めすり抜け現象が起きない
主人公から触れたときを認識する

また、以下のような特徴があります。
決定キーで始まるイベントの場合、スイッチを切り替えたりしなくても、文章表示中に動かない（主人公から触れたとき、イベントから触れたとき、のイベントの場合は、文章表示中に動いてしまう。スイッチをオフにすることで停止できる）
コモンイベントだけで出来る
動作指定の一時停止で止めているので、マップの下準備がいらない

ただし、エンカウントは、しない


http://www5.ocn.ne.jp/~noziko/naname7.zip

どうもです。

動作は今のところOKですね。しかも、スクリプトがスマートになりましたね。

> 主人公から触れたとき、イベントから触れたとき、のイベントの場合は、文章表示中に動いてしまう。スイッチをオフにすることで停止できる

うーん、それはちょっと残念です。工夫すればできるかもしれません。

もう少しいじってみたいので、テク研での公開は先送りになります。

よく考えたら、もう一週間も議論していたのですね。

割と簡単に、触れたときイベントのための、斜め移動停止スイッチを不要にすることができました。
コモンイベント「移動システム」の最後、「◆以上繰り返し」の上において、

◆変数の操作：[0001:主人公X座標], 主人公のX座標
◆変数の操作：[0002:主人公Y座標], 主人公のY座標
◆指定位置のイベントID取得：(V[0001],V[0002]), V[0003]
◆条件分岐：変数[0003:イベントID]が0以外
　◆スイッチの操作：[0002:移動システムの作動]をOFFにする
　◆スイッチの操作：[0003:移動システムの一時停止]をONにする
　◆
：分岐終了

を加えただけです。もしかしたら、何か不具合があるかも…。

言い忘れました。
多少、最初の一歩を斜め移動させるのがシビアになりましたね。でも、これくらいなら許容範囲でしょうか。

>多少、最初の一歩を斜め移動させるのがシビアになりましたね。でも、これくらいなら許容範囲でしょうか。

はい。確かにシビアになりましたね。ゲームパッドでテストしてたんで気づかなかったですが、キーボードだとシビアです。ちょっと改良の必要があるかな。


>主人公から触れたとき、イベントから触れたとき、のイベントの場合は、文章表示中に動いてしまう。スイッチをオフにすることで停止できる
>うーん、それはちょっと残念です。工夫すればできるかもしれません。

そうですね。でも逆に、必ず止まるより、スイッチで切り替えられた方が、いいこともあるかもしれませんよ。
それから、イベントＩＤを調べて、移動システムの作動を止める方法ですが、これだとイベントの上から、斜め抜けが出来ないのではないかと思います。

> これだとイベントの上から、斜め抜けが出来ないのではないかと思います。
ほんのわずかだけウェイトがかかりますが、斜め抜け出来ました。

最初の一歩の斜め移動をより緩和させるために、入力されるまで待つキー入力を入れたりして実験しています。しかし、決定キーの挙動が謎です。ウェイトを増やしすぎると、決定キーが認知されなくなってしまいますね。

> そうですね。でも逆に、必ず止まるより、スイッチで切り替えられた方が、いいこともあるかもしれませんよ。
うーん、どうなんでしょう。イベント実行中に、主人公をとめて欲しいときのほうが圧倒的に多いと思うのですが…。SKさんのやりかたのように、逆に止めないイベントにスイッチを導入する仕組みが作れないかどうか考えています。

ノジコさんのものを改造させてもらいました。

http://star.s9.xrea.com/otherfiles/rpgm2k/naname.zip

改造した点
・イベントIDを取得するようにした。
・最初の一歩（斜め移動）を緩和した。

しかし、「スクリプトの短さ」が犠牲になってしまいました…。

サンプル見ました。
良いんじゃないでしょうか。問題は、大体片付いたようですね。
あとは、エンカウントか・・。
これは、自作しないとしょうがないので、自作エンカウントの簡単な作り方でも、テクニック集に付け加えておくとか・・。

上記サンプルは、すっぴぃさんのものと機能はほぼ同等ですが、スクリプトの短さにおいて勝っています。#102が最終案になりそうです。

> 自作エンカウントの簡単な作り方でも、テクニック集に付け加えておくとか
そうですね。「徐々に確率が上がるイベント」と組み合わせれば、エンカウントはそんなに苦労しない…、はずです。フィールドなどにおける、エリアの設定がやや苦労しそうですが。

関係ない話ですが、二度押しダッシュのイベントを改造して、触れたときのイベントを発動させるようにさせるために、このスレッドが非常に役立ちました。「一時停止」などを駆使しました。


エンカウントに関してなんですが、エンカウントは別のテクニックに載せるということで、とりあえず明日は八方向イベントのみ掲載したいと思います。エンカウントについては後でじっくり考えます。アクションRPGに組み込みたいと考えている人もいるでしょうし、そういう人にとっては、エンカウントは不要ですから。