【解決】選択肢表示中にセーブし、ロードでその場所に戻る方法

[ムノクラ]

ムノクラ様、いつも大変お世話になっております！
この度も大変親身なご回答をいただき心より感謝しております……！
（察しが悪いなんて滅相もないです、自分の質問を読み返すと情報の足りなさに冷や汗でした……本当に申し訳ないです）

今回、質問へ対する回答とお礼が遅れてしまいまして誠に申し訳ございません＞＜
ご提示いただきました改善策、
「選択肢にキャンセル時用の分岐を入れてラベルジャンプでロード時強制選択を回避する」というもの、
私もずっとキャンセル禁止を入れていて分岐は試してみたことがなかったので、
なんてシンプルで分かりやすい方法なんだ！　と感動し、
早速ご共有いただきましたサンプルを参考に拙作にも反映させていただきました。

すると無事、選択肢表示中にロードで戻ってくることが出来、
大喜び……だったのですが、
こちら何故か回避できる場合とできない場合が分かれてしまい……；；
（下記に画像を添付いたしております）

私の方で、
選択肢分岐内にある選択肢だからダメなのか？
はたまたイベントページ数や位置が問題なのか？
ラベルの貼り方がいけないのか？
などなど、何とか全てのパターンが「回避できた」になるよう、
条件を揃える努力をしてみたのですが、
結局１ケースしか「回避できた」にならず……。

そうなる原因や理屈が分かればその情報を含め、
改善する方法がないかとご相談できたかと思うのですが、
結局何が”できる”になり、何が”できない”になるのか、自分では判別できませんでした。

とても使いやすいアイディアかつ、１ケースは成功しているのに、
解決しました！　というご報告ができない結果になってしまい、
ムノクラ様には重ね重ね申し訳ないです……。

こういった結果になっている以上、
私のプロジェクトに何か原因があるのでは？　と思うのですが、
今の自分の知識では対処することができないので、
今回の件に関してはしぐれん様がご製作中とのことのプラグインの完成をお待ちしつつ、
ムノクラ様のアイディアを安定して実行する方法を探しつつ、
別の方法も模索しつつ……ということにさせていただこうと思います。

初心者の拙い質問に対しこんなにも親身になってご意見を下さり、
また拙作同様のプラグインまでご用意くださってサンプルをご製作くださった（しかも２回も……；；）
ムノクラ様には感謝の気持ちでいっぱいです。本当にありがとうございました。

ムノクラ様のアイディア、
「選択肢にキャンセル時用の分岐を入れてラベルジャンプでロード時強制選択を回避する」で
同じお悩みを解決できる方も大勢いらっしゃるのでは？　と思うのですが、
私のようなケースでも回避できる方法がお伺いできると大変有難いので、
こちらのスレッドは現状、【解決】をタイトルに追加しないまま置かせていただけますと幸いです。

これ以上ご迷惑をお掛けするのが心苦しく、
勝手にまとめの方向へ話を進めてしまいましたが、
もし他にも「選択肢表示中にセーブし、ロードでその場所に戻る方法」に
心当たりがございましたらご教示いただけますととても助かります……！
（また、ムノクラ様のアイディアが上手く作動しない場合の原因に心当たりのある方も……）

何卒、よろしくお願い申し上げます。

原因がわからないので、可能性を調べていくしかないですね…
（ちなみに、上記の方法をMV版で行ったらエラーになりました…）

こんな処理だとどうでしょうか？
（選択肢のキャンセルが禁止のケース、禁止じゃなくても良いかも知れないですが）

コード: 全て選択

◆ラベル：Select1
◆変数の操作：#0001 V1 = -1
◆文章：なし, なし, ウィンドウ, 下
：　　：私を旅に連れて行ってくれる？
◆選択肢の表示：はい, いいえ (ウィンドウ, 右, #1, -)
：はいのとき
  ◆変数の操作：#0001 V1 = 1
  ◆
：いいえのとき
  ◆変数の操作：#0001 V1 = 2
  ◆
：分岐終了
◆条件分岐：V1 = -1
  ◆ラベルジャンプ：Select1
  ◆
：分岐終了

あとは、スクリプトに
console.log('処理1だよ')
とか
文章の表示
を入れて、どのタイミングにどの処理がされているのか調べるとなにかわかるかも…

コード: 全て選択

◆ラベル：Select1
◆変数の操作：#0001 V1 = -1
◆文章：なし, なし, ウィンドウ, 下
：　　：状況1：\v[1]
◆文章：なし, なし, ウィンドウ, 下
：　　：私を旅に連れて行ってくれる？
◆選択肢の表示：はい, いいえ (ウィンドウ, 右, #1, -)
：はいのとき
  ◆変数の操作：#0001 V1 = 1
  ◆
：いいえのとき
  ◆変数の操作：#0001 V1 = 2
  ◆
：分岐終了
◆文章：なし, なし, ウィンドウ, 下
：　　：状況2：\v[1]
◆条件分岐：V1 = -1
  ◆文章：なし, なし, ウィンドウ, 下
  ：　　：状況3：\v[1]
  ◆ラベルジャンプ：Select1
  ◆
：分岐終了
◆文章：なし, なし, ウィンドウ, 下
：　　：状況4：\v[1]

あとは、同時に他の並列処理が動いているなら、それが影響している可能性もあるので、虱潰しに状況毎にどのように処理がされているのか調べていくしかないかと思います。

何と言っても、文章表示中にセーブができるだけで、デフォルトの想定外の動作でしょうから…

追記

頂いた画像を見て気づいたのですが、選択肢が入れ子（選択肢を選んだ中に選択肢になっている…◆が一番左にない箇所）になっているのが原因ではないでしょうか？
入れ子の外側でセーブされるとかの条件になっている可能性があるかも…と思いました。
選択肢の中に選択肢を作成せず、選択肢の項目で変数を入れ、次の条件分岐で変数で表示する選択肢を変化させるような処理にすれば、セーブされる場所が変わるような予感がします。
（未実験ですいません…明日にでも追加調査するつもりです）

[ムノクラ]

「イベントは実行が始まると、最後まで実行されるのが前提」というのを、どこかで目にした記憶があります。
（どこでだったかは定かでないのですが、トリアコンタン氏か神無月サスケ氏かとんび氏か…技術に精通している人だった気がします）

で、宝箱の処理順を変更して実験したのですが、そのとおりで処理の途中でセーブしても、ページの最後まで実行したものがセーブされています。

恐らく、選択肢のキャンセルの分岐の方が例外（MVで同じことをやったらエラーになりました…それはそれでどうなんだ…）のようです。

で、1イベント内に1つの選択肢だと動くというのが結論で、それ以上を回避するには「コモンイベントを駆使するしか無い」という感じでした。

サンプルイベント「OK:1-3コモンイベント」が最も現実的な解っぽいです。

色々な実験をしたサンプルを付けるので、見てみてください。

sample20210428.zip

(14.12 KiB) ダウンロード数: 3 回

[Plasma Dark]

まず、このケースでは選択肢のキャンセルタイプ:分岐を使わないようにしましょう。
並列処理によるセーブ、ラベルジャンプと組み合わせるとバグります。
（そもそも並列処理によるセーブがバグの元なので、本当に必要かどうかも検討してください）

キャンセルタイプ:分岐を使わず、分岐終了の後にラベルジャンプを置く方法ならうまくいくんじゃないかと思います。

[Plasma Dark]

以下、バグる理屈の説明です。長くなるので興味がある方だけ読んでください。

Game_Interpreterの処理を追うとわかりますが、追いにくいコードなので、下記のような構造のイベントで説明します。

コード: 全て選択

0 118 ラベル1
1 102 選択肢の設定（キャンセル時の処理 分岐）
2  402 選択肢1
3   選択肢1を選んだ場合の処理
4  402 選択肢2
5   選択肢2を選んだ場合の処理
6  403 キャンセル
7   キャンセルした場合の処理（ラベルジャンプ ラベル1）
8 404 分岐終了

左端の数字はイベントコマンドのindex、102, 402, 403, 404はコマンドコード（イベントコマンドを一意に表す数値）です。
ツクールMV/MZのイベントでは、index（Game_Interpreterインスタンスの持つ_index）を加算していき、それに対応するコマンドを上から順番に実行していきます。

選択肢が表示されている状態では、index=1に設定された選択肢の設定処理は既に終わり、Game_Interpreterインスタンスの_indexは2になっています。
選択肢2を選んだり、キャンセルした場合にはindex=3の処理は実行されませんが、これはコマンドコード402で、選択肢の選択結果をもとに処理をスキップするからです。
選択結果はGame_Interpreterインスタンスの_branchに、ネストの深さごとに設定されます。

_branchは{}で初期化され、例示したイベントのindex=1（選択肢の設定）でプレイヤーが選択肢1を選んだとしたら、 _branch[0]=0 で設定されます。
キャンセルタイプが分岐の場合、キャンセルしたら _branch[0]=-2 になります。

コマンドコード403では、この_branch[indent]の値が0以上であったらスキップするという処理が書かれています。（つまり、キャンセルではなく何らかの選択肢を選択した場合、キャンセルの分岐内に書かれた処理はスキップする、という意図でしょう）

では、例示したイベントで選択肢を表示したまま並列処理でセーブし、ロードした場合に何が起きるか考えてみます。
選択肢の表示状態は Game_Message インスタンスに依存しますが、ツクールMV/MZではこれをセーブデータに含まないため、ロード後に選択肢は表示されていません。
しかし、マップの持つイベントの実行状態（Game_Interpreter インスタンス）はセーブされます。
_index=2の状態でロードされ、402, 403のコマンドコードで _branch[0] の値を見て各分岐の処理をスキップするかどうか判断します。
ところが、選択肢の選択結果が存在せず、 _branch = {} で初期化された状態のままなので、 _branch[0] は undefined です。
402では、自分の選択肢番号（選択肢1 = 0, 選択肢2 = 1）と _branch[indent] が一致していない場合にスキップしますので、これらはスキップされます。

403では、先程説明した通り、 _branch[indent] が 0 以上であった場合に処理をスキップします。
undefined >= 0 は偽ですので、スキップされずにキャンセルの分岐処理が行われる、というわけです。

では、キャンセル分岐内からラベルジャンプでイベントの先頭に戻り、再び選択肢を表示してセーブ＆ロードするとどうなるでしょう。
実は、ラベルジャンプの処理は、分岐を挟んでしまうと _branch[indent] の値を null で初期化します。
そして、jsにおいて null >= 0 はなんと真なので、キャンセルの分岐処理をスキップしてしまいます。
（冗談みたいですが、null >= 0 が true になるのは仕様です。nullは大小比較の場合、内部的に+0に変換して比較されます）
https://tc39.es/ecma262/#sec-tonumber
https://tc39.es/ecma262/#sec-abstract-relational-comparison

Game_Interpreterの状態が変わる（_branch[indent]がundefinedからnullに変わる）せいで、同じ場面でセーブしたのにロード後の挙動が変わってしまうのはバグと言えばバグですが、並列処理でイベント中にセーブすることを想定していないのでしょう。
そもそも並列処理は人の脳で把握するには難しい領域なので、この問題だけ対処しても他で何か起きる可能性はあります。
並列処理の使用は必要最低限に留めておくことを推奨します。

[ルンタッタ・ワクテッカ]

「イベントは実行が始まると、最後まで実行されるのが前提」というのを、どこかで目にした記憶があります。
（どこでだったかは定かでないのですが、トリアコンタン氏か神無月サスケ氏かとんび氏か…技術に精通している人だった気がします）

で、宝箱の処理順を変更して実験したのですが、そのとおりで処理の途中でセーブしても、ページの最後まで実行したものがセーブされています。

恐らく、選択肢のキャンセルの分岐の方が例外（MVで同じことをやったらエラーになりました…それはそれでどうなんだ…）のようです。

で、1イベント内に1つの選択肢だと動くというのが結論で、それ以上を回避するには「コモンイベントを駆使するしか無い」という感じでした。

サンプルイベント「OK:1-3コモンイベント」が最も現実的な解っぽいです。

色々な実験をしたサンプルを付けるので、見てみてください。
sample20210428.zip

ムノクラ様、いつも大変お世話になっております……！
御礼と返信が遅くなりまして誠に申し訳ございません。

昨日に引き続き、丁寧かつ詳細なご助言誠にありがとうございます！
サンプルでも本当に細かくご検証くださっていて……；；
その上、わざわざ拙作と同じ選択肢内容にしてくださっているのに申し訳なさと有り難さで胸がいっぱいでした。
ムノクラ様のお気遣いのお陰で内容が更に理解しやすくなり、
オススメいただいていました「OK:1-3コモンイベント」と同様の方法で
完璧に希望通りの「選択肢表示中にセーブし、ロードでその場所に戻る」を達成することができました。

ムノクラ様のご指摘通り、
MZにおいては
・1イベント内に1つの選択肢だと動く（ラベルジャンプを使用することでロード時に再度選択肢が表示できる）
という仕組みのようですね。

私も選択肢内選択肢がいけないのでは？　というところまでは考えていたのですが、
選択肢内選択肢でなくてもNGなケースがあったため（恐らくこちら側のミスが原因……？）頭から抜け落ちており、
ご指摘のお陰で初心者でも扱いやすいムノクラ様の素晴らしいアイディアを活用させていただくことができ、
重ねて重ねて……感謝の気持ちでいっぱいです！！！
（同じようなことを何度も言っていてすみません……）

Plasma Dark様のご助言を踏まえまして、
選択肢キャンセル処理は”分岐”（その中にラベルジャンプを入れて選択肢表示へ戻す）ではなく、
”禁止”にして選択肢用の変数を用意し、
条件分岐で選択肢が選ばれていない状況の場合はラベルジャンプ、
という形で実装させていただきました。

奇しくも最初にムノクラ様がご用意くださった
サンプルのアイディアがそのまま流用でき、
そちらについても心より御礼申し上げたいです。

そもそも、一個人の勝手な希望を叶えるためにここまで根気強く、
しかも温かくお付き合いをいただけたことに
本当に、本当に重ねてお礼を申し上げたいです。
ムノクラ様、誠にありがとうございました……！！

Plasma Dark様にお礼をお伝えした後、
同じようなことを実現できないかな～と考えている方用に
簡単にではありますが、どのようなやり方なら掲題の
「選択肢表示中にセーブし、ロードでその場所に戻る」を実現できるのかをまとめて
このスレッドは【解決】とさせていただければと思います。
繰り返しになりますが、ご助言本当にありがとうございました！

[ルンタッタ・ワクテッカ]

以下、バグる理屈の説明です。長くなるので興味がある方だけ読んでください。

Game_Interpreterの処理を追うとわかりますが、追いにくいコードなので、下記のような構造のイベントで説明します。

コード: 全て選択

0 118 ラベル1
1 102 選択肢の設定（キャンセル時の処理 分岐）
2  402 選択肢1
3   選択肢1を選んだ場合の処理
4  402 選択肢2
5   選択肢2を選んだ場合の処理
6  403 キャンセル
7   キャンセルした場合の処理（ラベルジャンプ ラベル1）
8 404 分岐終了

左端の数字はイベントコマンドのindex、102, 402, 403, 404はコマンドコード（イベントコマンドを一意に表す数値）です。
ツクールMV/MZのイベントでは、index（Game_Interpreterインスタンスの持つ_index）を加算していき、それに対応するコマンドを上から順番に実行していきます。

選択肢が表示されている状態では、index=1に設定された選択肢の設定処理は既に終わり、Game_Interpreterインスタンスの_indexは2になっています。
選択肢2を選んだり、キャンセルした場合にはindex=3の処理は実行されませんが、これはコマンドコード402で、選択肢の選択結果をもとに処理をスキップするからです。
選択結果はGame_Interpreterインスタンスの_branchに、ネストの深さごとに設定されます。

_branchは{}で初期化され、例示したイベントのindex=1（選択肢の設定）でプレイヤーが選択肢1を選んだとしたら、 _branch[0]=0 で設定されます。
キャンセルタイプが分岐の場合、キャンセルしたら _branch[0]=-2 になります。

コマンドコード403では、この_branch[indent]の値が0以上であったらスキップするという処理が書かれています。（つまり、キャンセルではなく何らかの選択肢を選択した場合、キャンセルの分岐内に書かれた処理はスキップする、という意図でしょう）

では、例示したイベントで選択肢を表示したまま並列処理でセーブし、ロードした場合に何が起きるか考えてみます。
選択肢の表示状態は Game_Message インスタンスに依存しますが、ツクールMV/MZではこれをセーブデータに含まないため、ロード後に選択肢は表示されていません。
しかし、マップの持つイベントの実行状態（Game_Interpreter インスタンス）はセーブされます。
_index=2の状態でロードされ、402, 403のコマンドコードで _branch[0] の値を見て各分岐の処理をスキップするかどうか判断します。
ところが、選択肢の選択結果が存在せず、 _branch = {} で初期化された状態のままなので、 _branch[0] は undefined です。
402では、自分の選択肢番号（選択肢1 = 0, 選択肢2 = 1）と _branch[indent] が一致していない場合にスキップしますので、これらはスキップされます。

403では、先程説明した通り、 _branch[indent] が 0 以上であった場合に処理をスキップします。
undefined >= 0 は偽ですので、スキップされずにキャンセルの分岐処理が行われる、というわけです。

では、キャンセル分岐内からラベルジャンプでイベントの先頭に戻り、再び選択肢を表示してセーブ＆ロードするとどうなるでしょう。
実は、ラベルジャンプの処理は、分岐を挟んでしまうと _branch[indent] の値を null で初期化します。
そして、jsにおいて null >= 0 はなんと真なので、キャンセルの分岐処理をスキップしてしまいます。
（冗談みたいですが、null >= 0 が true になるのは仕様です。nullは大小比較の場合、内部的に+0に変換して比較されます）
https://tc39.es/ecma262/#sec-tonumber
https://tc39.es/ecma262/#sec-abstract-relational-comparison

Game_Interpreterの状態が変わる（_branch[indent]がundefinedからnullに変わる）せいで、同じ場面でセーブしたのにロード後の挙動が変わってしまうのはバグと言えばバグですが、並列処理でイベント中にセーブすることを想定していないのでしょう。
そもそも並列処理は人の脳で把握するには難しい領域なので、この問題だけ対処しても他で何か起きる可能性はあります。
並列処理の使用は必要最低限に留めておくことを推奨します。

Plasma Dark様、この度はご助言を誠にありがとうございます！
また、DarkPlasma_DashSpeed.jsを始めとする数々の素晴らしいプラグインを利用させていただいています。
お礼がこの場を借りてのものになり誠に恐縮なのですが、いつも本当にお世話になっております。

そして今回、対処法だけでなく詳しいご解説までいただけ大変感激しております。
かなり専門的な領域のお話だったので私のような素人が理解しきれているのかは疑問なのですが、
とにかく選択肢キャンセルを分岐にしてラベルジャンプはとても危険、ということは胸に刻みつけました！
処理は”禁止”にして、ご助言に従い選択肢分岐後にラベルジャンプを入れる形で実装いたします。

イベント中にセーブは想定されていない動きなので危ない……というお話は目にしていた上で
特に問題が出ていなかったのでナァナァにして使い続けてしまっていたのですが、
今回Plasma Dark様のご指摘を受けツクール側の複雑な処理に混乱を与えてしまうかもしれない
可能性の高いものなのだな、と流れとして知ることができ、非常に勉強になりました。

今後はできるだけ負担をかけないような方法を心がけつつ（どこまでできるのかという不安はありますが……）
危ない橋を渡っていることを重々承知の上制作していければと思っております。
ツクールについてまだまだ知らないことが沢山あるので、
今回Plasma Dark様のお話が伺えたのは本当にラッキーでした……！
繰り返しになりますが、この度は誠にありがとうございました！

[ルンタッタ・ワクテッカ]

【選択肢表示中にセーブし、ロードでその場所に戻る方法】

＜前提＞

拙作では、トリアコンタン様ご製作のプラグイン、
PictureCallCommon.jsを利用し、
イベント中でもコモンイベント経由でメニューが開ける状態にしています。

これは「選択肢によってストーリーが変化する」要素が作中に存在しているので、
会話の最中や選択肢表示中でもセーブ可にすることで、
プレイヤー様の負担を減らしたいという目的から行っていることです。

しかし、ツクールMZでは、
選択肢表示中にセーブ、そしてそのデータをロードすると、
選択肢選択後のメッセージに自動で進んでしまう仕様になっている模様です。
（※詳細なことは分からないですが、少なくとも見た目上はそのような動きになりました）

これでは選択肢でセーブする意味がなくなってしまいますが、
ムノクラ様がこちらの問題を回避する方法を発見して下さりました

以下、いただきましたご助言を簡単にまとめておりますので、
同じことに悩んでいる方の参考になれば幸いです！
まとめている者もツクール初心者なため、
お見苦しい部分や拙い部分は適宜お好みの形にご調整をお願いいたします 。


＜対処法＞

まず、選択肢が選ばれていないのに勝手に展開が進んでしまう状況を避けるために、
下記画像のような仕組みを用意します。
私はコモンイベントに作っていますが通常イベントでもやり方は同じです。



画像だけでは伝わりにくいと思うので、１つ１つ説明させていただきますね。
（それでも分かりにくいかもですが……なんとか耐えてください！）

この仕組みを作るために必要なものは２つです。
①ラベルとラベルジャンプ
②この選択肢専用の変数

そして、＜選択肢の表示＞で決められるキャンセル時の処理を”禁止”にしてください。



あとは、１枚目の画像赤線の位置にラベルとラベルジャンプ、
画像緑線の位置に変数の操作と、その変数を元にした条件分岐を入れればOKです。

これで選択肢表示中にセーブをし、ロードしても、
勝手に処理が進んで選択肢が表示されないことはありません。
（たぶん……今のところ……ツクール側に変更があって仕様が変わるということがなければ……）

理屈は最初に申し上げた
選択肢が選ばれていないのに勝手に展開が進んでしまう状況を避ける
というものまんまと思われるのですが、
・用意した変数が選択肢にちゃんと答えているか？　というのを判定してくれて
・ラベルとラベルジャンプが答えていない場合、選択肢再表示の動きをしてくれる
役割になっているという理解でおります。（恐らく……）
なので、変数の数値は選択肢に答えたか？　の判定ができるものなら何でもOKなはずです。

また、選択肢のキャンセル処理は禁止にする、
そして選択肢冒頭へ戻すラベルジャンプは選択肢分岐終了後に配置、
というアイディアはPlasma Dark様のご助言を参考にさせていただきました。
イベント中にセーブを実行するというイレギュラーな動作を行うとき、
ツクール上でどのような処理が行われているのか？　なぜ危険なのか？　
本トピック１４レス目の書き込みで解説をしてくださっているので、
興味のある方は是非ご一読をお勧めいたします。


＜補足：選択肢内選択肢を使用したい場合＞

中には、選択肢分岐の中に更に選択肢が出てくる、
選択肢内選択肢を使用したい方もいらっしゃるかと思います。（私もそうでした）

しかし、ムノクラ様のご実験の結果、
選択肢内選択肢を使用すると、先にご紹介した対処法が使えなくなることが分かりました。
この対処法は、1イベント内に1つの選択肢だと動くもののようです。

なので、１イベント内選択肢１の状態を保てるよう、
コモンイベントを利用するのがオススメとのことです。





ツクールに慣れている方には簡単な処理かと思いますが、
少し前の私なら言われてもちんぷんかんぷんだった気がするので、
念の為に参考用の画像を貼らせていただきます

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以上です。
私の方で勝手に行っている処理で、
もっとこうした方が楽だよ～！　という部分多々あるかと存じますので、
更なるご助言のある方がいらっしゃいましたら引き続きご投稿いただけますと幸いです。
このまとめは「これぐらい雑でも一応動くんだ！」程度に見てもらえると嬉しいなと思っております！笑

最後に、素晴らしいアイディアの提供者であり、
素人の質問に根気よくお付き合い下さったムノクラ様と、
より良い回避法のためにご意見をくださいましたPlasma Dark様に
心よりのお礼を申し上げます。本当にありがとうございました！

[sally]

横から失礼します。

ふとした思いつきですが、
選択肢の表示を別途コモンイベントにさせて、表示する選択肢を変数で管理すればラベルジャンプを使わないようにできませんか？

まず、選択肢が表示される段階で自動実行にした選択肢コモンイベント実行用のスイッチをオン、表示させたい選択肢の変数を代入した後にイベントを終了させます。

するとコモンイベントが自動実行されるので、変数で条件分岐して選択肢を表示。
選択肢を選んだらスイッチをオフにするか次の選択肢用の変数を指定することで、
選択肢が選ばれなかった場合は元の選択肢に戻り、
選ばれていたら選択肢が出ないか次の選択肢に進めることが可能です。
自動実行がまずいようであれば並列処理にしてもよいですが、アクターの移動などができてしまうので、そこは別途操作禁止の処理を作る必要があります。

この方法でしたら、ロードで選択肢の選択結果スキップをされても関係なく、変数で管理された選択肢が出てくるかと思います。

これのメリットは選択肢in選択肢にも対応できることで、
デメリットは管理が面倒なことです。
選択肢が多い場合は処理を軽くするためにも別途、地域や番号でコモンイベントを作成し振り分けた方がよいでしょう。
例えば50ごとに
コモンイベント:選択肢1～50、51～100
などと作成して、最初に呼び出す選択肢判別コモンイベント内で振り分けるなどですね。

ご参考頂けましたら幸いです。