ようこそぷっこ村へ、ししゃもです。
(・∀・)ノ
ようこそとか言いましたが、自分用のコマンド備忘録です。ダイアログってちょいちょい使うと思うんですが、結構雑に作られててバグが多いんですよね。しかもBEだとエンティティでダイアグラム風に説明した方が効果的で、無理に使わなくていいので、あまり気付かれず、且つ後回しになるので、まったく直らんのよね。

自分的にはストーリー系ではセリフまわりでは使うし、時々いただく案件では工数の関係でメインに使うんですが、クソバグで憤怒!みたいなことがままあります。
その中でも最高にイカレてるのが、execute if entity とか、execute unless entity とかやった後の run 以降で (@)initiator が機能しないこと。もともとダイアログはバグだらけ、仕様が穴だらけで、execute 自体がうまく動かない時期とかもありました。何か理由があるのか?そんなクソバグの回避用備忘録です。
dialogue の execute run 以降の (@)initiator バグについて
例えばNPCのボタンに↓みたいなコマンド持たせるじゃん?
ボタン名 initiator
execute if entity @e[family=unko] run dialogue open @s @initiator unko_daisuki
execute unless entity @e[family=unko] run tp @initiator ~~3~
execute run tell @initiator uuuuuuuunkono
execute if entity @e[family=unko] run tell @initiator うんこがいます
execute unless entity @e[family=unko] run tell @initiator うんこはいません
こういうのが全然動かない。逆に
ボタン名 @pとか
execute if entity @e[family=unko] run dialogue open @s @p unko_daisuki
execute unless entity @e[family=unko] run tp @p ~~3~
execute run tell @p uuuuuuuunkono
execute if entity @e[family=unko] run tell @p うんこがいます
execute unless entity @e[family=unko] run tell @p うんこはいません
セレクタを(@)pとかに変えて、こういうのは動く。うーん、この香ばしさ……。



画像のように、initiatorボタンでは反応しません。条件に合う、合わないで話しかけたプレイヤーへの挙動を変えることができないのはバグだと思うんだけど、バグじゃない説?
じゃあどうするのがええん?→ run より前に置いたらええねん
で、困るので代替案を何とかひねり出したのが以下
ボタン名 無理くり代替案
execute as @initiator at @s unless entity @e[family=unko] run tp @s ~~3~
こんな感じで run より前に(@)initiator が来て、(@)sにすると動きます。なんでやねん!?
じゃあこれで万々歳かと言うと全くそんなことはないです。
(@)pとかボタンでは tp 位置がNPCの上ですが、こっちでは自身の上になってます。まぁ、at (@)s を at @e[family=unko,c=1] にすればそもそも unless いらんので例としては悪いんですが、問題は実行主体がプレイヤー側に移ってしまうことです。これ、ダイアログを開くときが超絶面倒になるんよね。
単純に↓みたいなのがあるとするやん?
execute if entity @e[family=unko] run dialogue open @s @initiator unko_daisuki
これどんなNPCでも、とりあえず条件用のエンティティと、最後のシーン名変えたらええからミスが起きにくいのよね。対して
execute as @initiator at @s if entity @e[type=unko_a] run dialogue open @e[type=unko_b,c=1,r=8] @s unko_daisuki
上のような感じで open する対象をいちいち入れないといけないという、超絶ミスが起きやすい状態が生まれるわけです。しかもNPCが混んでると判定吸われとかもあるわけですよ(判定吸われは配置が悪いけど…)。
この例は一個だからいいけど、大体においてちゃんと遊べるなーみたいなアドオンを作る場合、ボタンも分岐も3つ4つあるのは当たり前で、しかも判定用のエンティティなんて、プロパティで分けてリソースの節約を図るんで、まぁ言わずもがなうんこみたいな汚い状態が量産されます。
{
"scene_tag": "return_main_base",
"npc_name": {"rawtext":[ {"translate":"entity.main_base_teleporter.name" } ]},
"text": {"rawtext": [ {"translate":"text.main_base7"}]},
"buttons": [
{
"name": {"rawtext":[ {"translate":"button.main_pink"}]},
"commands": [
"/tp @initiator @e[type=security_base_teleporter_main,c=1]",
"/execute as @initiator unless entity @e[type=security_base_teleporter_main] run dialogue open @e[type=main_base_teleporter,c=1,r=5] @s yet_main_pink"
]
},
{
"name": {"rawtext":[ {"translate":"button.mini_pink"}]},
"commands": [
"/tp @initiator @e[type=security_base_teleporter_mini_pink,c=1]",
"/execute as @initiator unless entity @e[type=security_base_teleporter_mini_pink] run dialogue open @e[type=main_base_teleporter,c=1,r=5] @s yet_mini_pink"
]
},
{
"name": {"rawtext":[ {"translate":"button.mini_blue"}]},
"commands": [
"/tp @initiator @e[type=security_base_teleporter_mini,c=1]",
"/execute as @initiator unless entity @e[type=security_base_teleporter_mini] run dialogue open @e[type=main_base_teleporter,c=1,r=5] @s yet_mini_blue"
]
}
]
},
一部例を挙げるとこのような、見にくくしょんぼりなオブジェクトが10個とか並ぶわけです。あ、毛根が……。でもしょうがないよ……。
まとめ
たぶんこの問題って困ってる方いると思います。一応は (@)initiator を run より前にすることで解決できますよ、と、備忘録を書きつつ、情報提供しつつ、あわよくばモジラの人とかが「ふーん、やばいじゃん(ハナホジ)」みたいに思って直してくれないかなー。という自分得記事でした。
それではこの辺で、お帰りの際はお気をつけて~(・∀・)ノシ
コメント