ようこそ、ぷっこ村へ。ししゃもだよ。
(・∀・)ノ
やってきました、コマンド講習会第3回。少しずつペースは掴めてきたかな？今回も頑張ってアハ体験しましょう!!アハ体験って死語？
前回のネコたんイリュージョンを別の方法で作ってみる
今回のお題
今回のお題ですが、作る仕掛け自体は、前回のネコを召喚して毛色をクルクル変えるっていうのと同じにしてみます。ただし、全く違う方法を使い、作りかたは状況や人によって変わるってところを勉強していきましょうー。
↑前回と同じ仕掛けです。手抜きじゃねーし!!召喚用の summon を除いて、仕掛けに使う主なコマンドは2つ。
- scoreboard … スコアを記録しておくコマンド
- data … NBTタグを見たり変えたりするコマンド
data は前回やったので、新しくおぼえるのは scoreboard ってコマンドだけです。簡単だね!! data コマンドとか NBT ってなんだっけ？な時は、前回の講習会資料をご覧あれー。
scoreboard をざっくり
スコアを保持するためのボードを作ったり、消したり、書き換えたりするためのコマンドです。スコアボード自体は、整数(符号付)をメモしておける黒板みたいなイメージかな？
ちなみに、値の範囲は-2,147,483,648～2,147,483,647です。10桁あるので、普通に使う分には足りると思うよ。整数オンリーなので小数点以下を扱いたい場合は、10倍するとかの工夫が必要になります。
基本の書き方
スコアボード自体をいじる場合
/scoreboard objectives 処理 スコアボード名
スコアボードを新しく作ったり、リストを取得したり等、スコアボード自体に手を加えたい場合です。scoreboard の後の部分に objectives を入れます。add, remove, list, setdisplay, modify があります。
スコアをいじる場合
/scoreboard players 処理 エンティティ スコアボード名
スコア自体をいじる場合、players を使います。和差積商等の基本的な計算の他、値を任意に書き換えたり、別のスコアボードと値を入れ替えたり等、他にも色々とできます。進行やフラグ管理に使えたり、RPGならMP用に使ったりなど、何に使うかはアイディア次第やね。
一例
/scoreboard objectives add Hoge dummy
Hoge って名前のスコアボードを作ります。dummy の部分は条件で、「特定のアイテム使用回数をカウントする」とかを決めます。dummy は何の条件も指定しないでコマンドでだけ値を変えるよってことです。
例えば、ニンジン棒を使った時にカウントしたいって時は、
minecraft.used:minecraft.carrot_on_a_stick
にします。まぁいずれやりましょう。
/scoreboard objectives setdisplay sidebar Hoge
Hoge を画面右に表示
/scoreboard players set @s Hoge 100
Hoge の値を 100 にセットする。
表示されてるスコアボードが邪魔!!
ちょっとした tips 。結構最初の頃困ったんですが、サイドバーとかに表示させてるスコアボードが邪魔で消したいんだけど……。
/scoreboard objectives setdisplay sidebar
で消えます。気付くのに時間掛かって、毎回スコアボード消したりしてたので同じ轍は踏まないでねー。て言うか、Wikiに書いてないよね？
実際に仕掛けを作る
準備
もう座学は沢山だ!!彼の文豪はこう言った!!書を捨てよ、コマンドをいじれ!!
と言うわけで、準備です。前回は13個のコマブロを積み上げましたが、今回はたったの4個。コレが最適化ってやつです。たった3回の講習会で最適化まで来ましたね、スゴイことなんで胸を張りましょう。ヤフー!!
いつも通り、一番下をインパルス、動力が必要にして、残りはチェーンで繋げておきます。そしたらネコたんを適量、柵の中に垂らしておきましょう。
後は前回と一緒、リピーターで繋いどいてねー。
使うコマンド
今回は以下のコマンドを使っていきます。
scoreboard objectives add S_Cat_Type dummy
scoreboard objectives setdisplay sidebar S_Cat_Type
↑まずは必要なスコアボードを準備します。1行目で S_Cat_Type ってスコアボードを用意しました。スコアボードとかタグは、被らない名前を意識しましょうね。この部分はコマブロに書き込まず、チャット欄で実行してね。2行目は値の変化を見るために表示するコマンドで、必要なければ実行する必要はありません。
execute as @e[type=cat,distance=..32] store result score @s S_Cat_Type run data get entity @s CatType
scoreboard players add @e[type=cat,distance=..32] S_Cat_Type 1
scoreboard players set @e[type=cat,distance=..32,scores={S_Cat_Type=11..}] S_Cat_Type 0
execute as @e[type=cat,distance=..32] store result entity @s CatType int 1 run scoreboard players get @s S_Cat_Typeコマブロに書き込んで実行するのはこれらの4行です。新しく store result ってのがありますね。これは run 以降で取得する値をぶち込むためにあります。取得に成功したら、取得した値を、失敗したら0を返してくれます。たぶん「？」なので、1行目を詳しく日本語訳すると、
実行者(コマブロ)の距離32以内にいる各々のネコちゃんを実行者とし、本猫の毛色の値(CatType)を取得し、スコアボードのS_Cat_Typeに取得した本猫の毛色の値を書き込む
って意味です。このなかの、「スコアボードのS_Cat_Typeに取得した本猫の毛色の値を書き込む」が store result です。
他に store success があって、こっちは取得に成功した回数を返します。単純に成否の判定に使えるけど、別の方法でいいし、正直使ったこと無いです。
と言うわけで、全体の流れですが、
1行目で、毛色の値を取得し、スコアボードに保存
2行目で、スコアボードの値に1を足す
3行目で、もしスコアボードの値が、存在しない毛色の値である11(0～10まででしたね)になってしまっていたら、0にセット。
4行目で、スコアボードの値を毛色に反映
と言う流れです。これらを実行してみると、あら不思議。前回と同じように毛色がコロコロ変わるじゃないですか!!なぜだ!?魔法なのか!?前回は13行もあったのに!!
やったね、まさにクラークの三法則の1つ、「十分に発達した科学技術は、魔法と見分けがつかない。」ってやつだね!!(適当)
これで立派な魔法使いの道を歩み始めたわけですよ。
store result 大事!!ゼッタイ!!
store result は便利で、後に続く部分を score にすれば、スコアボードをいじれるし、entity にすれば NBT をいじることができます。他にも、ボスバー、ブロックエンティティ(チェストとか)、ストレージがありますが、そのへんはおいおい。
特にストレージは便利です。ホットバーを丸ごと保存しておけたり、マイクラと全く関係ないNBTを保存したりできます。複雑なことをする時覚えましょうね。
最適化を考える
はい、今回もテーマを無事にこなしたので、ここからは時間が余ったr(以下略)
最適化について考えてみましょう。前回は同じ仕掛けを作るのに13行を必要としました。確認してみると
tag @e[type=cat,distance=..32,nbt={CatType:10}] add Type_10
execute as @e[type=cat,distance=..32,nbt={CatType:9}] run data modify entity @s CatType set value 10
execute as @e[type=cat,distance=..32,nbt={CatType:8}] run data modify entity @s CatType set value 9
execute as @e[type=cat,distance=..32,nbt={CatType:7}] run data modify entity @s CatType set value 8
execute as @e[type=cat,distance=..32,nbt={CatType:6}] run data modify entity @s CatType set value 7
execute as @e[type=cat,distance=..32,nbt={CatType:5}] run data modify entity @s CatType set value 6
execute as @e[type=cat,distance=..32,nbt={CatType:4}] run data modify entity @s CatType set value 5
execute as @e[type=cat,distance=..32,nbt={CatType:3}] run data modify entity @s CatType set value 4
execute as @e[type=cat,distance=..32,nbt={CatType:2}] run data modify entity @s CatType set value 3
execute as @e[type=cat,distance=..32,nbt={CatType:1}] run data modify entity @s CatType set value 2
execute as @e[type=cat,distance=..32,nbt={CatType:0}] run data modify entity @s CatType set value 1
execute as @e[type=cat,distance=..32,tag=Type_10] run data modify entity @s CatType set value 0
tag @e[type=cat,distance=..32,tag=Type_10] remove Type_10↓
execute as @e[type=cat,distance=..32] store result score @s S_Cat_Type run data get entity @s CatType
scoreboard players add @e[type=cat,distance=..32] S_Cat_Type 1
scoreboard players set @e[type=cat,distance=..32,scores={S_Cat_Type=11..}] S_Cat_Type 0
execute as @e[type=cat,distance=..32] store result entity @s CatType int 1 run scoreboard players get @s S_Cat_Type全然書き方が違ってますねー。面白い。よっぽどわけわかんない複雑な書き方じゃない限り、行数が少ない方が軽いです。まぁ当たり前ですね。じゃあ何でもかんでも短くなるようにしたらええんか？
最適化が必要か考えるのも最適化？
そもそも、短く書けば何でもええんかい？ってなると、病みコース直行な気がします。例えば、RPGマップを作る時に、全体を通して1回しか実行されないなら、別に13行だろうが、4行だろうが大した差はないでしょう。そんなもんに時間を割いて、謎の努力をする必要はないよねー。
でも、常時実行されるようなコマンドだったら、できるだけ短く、且つ軽い処理を考えないといけなくなってきます。マイクラは1秒間に20回パラパラ漫画の様に画面を更新するので、13行なら260行のコマンド実行、4行なら80行分ですね。さらに、対象が増えればその分ドンドン判定にリソースを持ってかれます。おい、そのデタパ、カクついてるじゃねーか!!
execute ならpositioned で座標を指定したり、セレクタなら nbt は使わず、predicate にするとか、dx,dy,dz を使うとかですね。
まとめ
今回は、scoreboard を使ってみて、同じ仕掛けでも作り方は無限大!!ってことが分かったと思います。
いずれはデタパを作る講習会まで辿り着きたいので、最適化の必要性については覚えておきましょうー。
それではこの辺で、お帰りの際はお気をつけて～(・∀・)ﾉｼ
なんかもう一行くらい削れそうな気がするんだよな……。
コメント