Scratch への提案

hirayuu1414

#109を再掲します。

inoking wrote:
調べるカテゴリーはほぼ固まったかと思われるのでイベントカテゴリーに行きます。
みなさんへ：
仕分けがすむまで、新規の提案はなるべくしないようにお願いします。
また、仕分けについての意見の際は過去の議論をふまえてコメントをお願いします。
1
[Shift v] キーが押されたとき :: events :: hat
[Backspace v] キーが押されたとき :: events :: hat
[Enter v] キーが押されたとき :: events :: hat
2
・https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2839913/
<>のとき::events hat//クラウド変数やマウスのクリックなどのスプライト内部でわかっていないことが対象 
3
中が見られたとき::events hat
ここで、
1:
<[Shift v] キーが押された>
などが異論なしなのでこれも同様ですね。

3:
<中を見ている::sensing>
が却下されているのでこれも却下ですね。

よって、2 についてのみお願いします。

2についてのみ話してください。

kouryou118103

2
・https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2839913/
<>のとき::events hat//クラウド変数やマウスのクリックなどのスプライト内部でわかっていないことが対象 

に

<(変数) = [0]>

とかは入らないので形を変えたほうが良いと思います。

Ke0

？？？
どういうことですか？<変数=0>が入るようなブロックを指しているのではないのですか？

kouryou118103

#124
ハットブロックは「イベント」なのでプロジェクト内部で変更されたものが入っているのはおかしいということです。
————————————–
　例）
　

　[変数 v] を [0] にする

————————————–

abee

#125
実装できないわけではありません。実際に、Scratch派生のSnap!にはそのブロックがあります。

kouryou118103

#126
ありがとうございます。

<>のとき::events hat

には

<(変数) = []>

などがScratchでも入るということのようなので
#123を撤回します。

inoking

イベントの待ちについては旧トピック #8858 ～ #8878 辺りで話しましたが、厳密には、代用はできません。
つまり、2 のようなパターンは追加を検討する余地があります。

しかし、参照先をたどっていくと
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2839913/
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2761553/
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2751087/ となり
私は2017年の時点で以下のように書いています。

inoking wrote:
イベントによる検出は、特殊な出来事（イベント）が発生したことを検出するために使うのが通例で
実際 Scratch でも「キー、背景、音量、タイマー、ビデオモーション、メッセージ」の検出時となっています。
通常の条件判断のように使うのは違和感があります。

内部事象もイベントとして登録する考え方もありますが
自分自身が分かっている情報をイベントでとらえるのは不要という考え方です。
このため
「クラウド変数やマウスのクリックなどのスプライト内部でわかっていないことが対象」
としています。

これを前提とするなら
任意の条件式を入れられるものではなく、よって、以下となるでしょう。

inoking wrote:
現状のドロップダウンに選択肢を追加するほうがよく
具体的に何を選択肢に入れるかが出てこないと何とも言えないと思います。

Snap! の例は技術的には実現できるということで
Scratch とはコンセプトが違うのであくまでも参考です。

yui0321 · Scratch への提案 削除 *Last edited by yui0321 (Feb. 16, 2022 10:26:54)*

削除

Last edited by yui0321 (Feb. 16, 2022 10:26:54)

Ke0

今それを話し合っているところです。

syokaki

僕は

<>のとき :: events hat

に反対します。なぜなら、代用可能でかつ初心者を混乱させる(ブロックの種類が増えるうえ条件が空欄のため)からです。
メッセージや今までのブロックで十分代用できると思います。

inoking

<<> かつ <>>

などでも空欄なので、空欄だからというのは理由にならないでしょう。

yuzupon1133-sub

inoking wrote:
<<> かつ <>>
などでも空欄なので、空欄だからというのは理由にならないでしょう。

何をするのかわからないブロック、ですかね、、、
「<>かつ<>」はググればANDのことだってわかるけど、
「<>のとき」は一見真偽値を入れるということは分かっても「何に使うかピンとこない」

rilakkuma4

#133

その理論で行くと、

[ v] を送って待つ

なども一見メッセージを送ることは分かっても何に使うかピンと来ないのでそれも理由にならないと思います。
確かにググれば出てきますけど、もし実装されればググると出てくるようになると思います。
inokingさんが言っている通りScratchのコンセプト的に合っているか…という問題は生じてしまいますが。

yuzupon1133-sub

Scratchのエディターを開いた時は

[メッセージ1 v] を送る

このように表示されるので、この「メッセージ」というのを検索すれば出てきます。

Ke0

仮に真偽値を入れられたとして、それが発動するケースって稀ですよね。
日時の指定ができたりはするかもですが、そういった「独立した変数」のようなものを感知する際には有用だと思います。
あってもいいかな…どうかな…

yuzupon1133-sub

というか、ずっとtrueの場合はどうなるんです？？

yuzupon1133-sub

<<> ではない>のとき::events hat
ずっと

end

絶対に止まらないプログラムの完成〜

Ke0

それは別にいいでしょう。既存の

[タイマー v] > (0)のとき

でも同じことになりますが。

Last edited by Ke0 (Feb. 17, 2022 14:02:39)

abee

Scratchのイベントは、条件が真になったときに1回だけ発火し、次に発火するためには一度偽になってから再び真になる必要があります。

Last edited by abee (Feb. 17, 2022 14:02:48)

yuzupon1133-sub

ということは

[ v] キーが押されたとき

は頻繁に作動しますが、trueとfalseを繰り返しているのでしょうか。
だとしたらキーが押されているのにfalseになるのは不自然です。

Discuss Scratch