Scratch への提案

gccxnondx

#2901

inoking wrote:
このエッセイは読みましたか？

に対しては答えないのですか?
また、そのエッセイが客観的な証拠になっているのではないでしょうか。

Last edited by gccxnondx (May 9, 2026 05:08:20)

Zirconium_Tungstate

define a <boolean>

a <[true v]::custom>//ドロップダウンから選ぶor真偽値型ブロックを入れる

このように、真偽値の定義で直接真偽を決める機能が欲しいです

inoking wrote:
意見の分かれる提案
(中略)
・https://scratch.mit.edu/discuss/post/2670867/
<TRUE::operators>
<FALSE::operators>
#549 より
(後略)

true,falseを直接決めるブロックは、“代用可能”“追加しても初心者が混乱する”などの意見があります。
確かに、“もし真なら”などと書かれていたら初心者が混乱しそうな上、#545のようにメインループ内で使う機会はほぼないと思います。
ただ、#545のように定義では呼び出し先から指定したいということはよくあると思います。
なのでこのように定義内で選べる(もちろん通常通り真偽値型ブロックを入れても動く)ようにすれば、真偽値型引数を使う人しか見れなくなり、ブロックパレットになどの“誰でも見る部分”に何も増えないので初心者の混乱はほぼ起こらないと思います。

Doctor_Fe wrote:
(#545)
#550
⑥について、もちろん、メインループ内の分岐に置く意味はあまりないでしょう。
しかし、定義を使うときは別です。呼び出し側から定義内の分岐先を指定したいことが多々あります。
そして、「定義の呼び出し時の状態(変数の値、スプライトの状態など)」ではなく、「定義の呼び出し元(どこから呼び出したか)」が分岐先の変更の理由になることもあります。
定義の引数について、ある場所からは必ずtrueで、別の場所からは必ずfalseに指定する事があるということです。
そういう時には、真偽値ブロックは非常に役に立ちます。
(後略)

shidaken

プルダウンにしなくともラベルを使えば代用できるのではないでしょうか。

定義 真偽値1:(T/F)審議値2:(T/F2)

Last edited by shidaken (May 11, 2026 10:24:42)

arugakuseidesu

提案です。
コスチュームの編集画面で図形や画像を（丸の図形で例えます）
ドラッグするときに、その丸が青色だったら、中心を表す十字の色がかぶっているので、非常に見にくいです。
なので、十字のところの色だけを色反転にすることを提案します。

kaki_jp

#9204
移動するときにのみそのパーツの色を変えれば対処可能(もちろん変更前の色は控えておく)ですが、どうでしょうか。

arugakuseidesu

kaki_jp wrote:
#9204
移動するときにのみそのパーツの色を変えれば対処可能(もちろん変更前の色は控えておく)ですが、どうでしょうか。

画像でベクターにしちゃうと厳しいですね…(編集しました）
ビットマップにしたらできなくもない..が、めんどくさい！！！（
あと、画像がグラデーションだったら無理な気がする.

Last edited by arugakuseidesu (Today 08:17:56)

kaki_jp

#9206
無理矢理ですが、

という風に、その画像の上(の真ん中ら辺)に青色でないパーツを置けばできそうです。
Cubeupload初めてなので不慣れです…

Last edited by kaki_jp (Today 08:27:09)

arugakuseidesu

学タブの規制のせいで見れない…鍵マークがかかってる
けど何となく伝わりました！！
ありがとうございます！！！

roomba0811

止まった時のイベントプログラム
turbowarpはすでに拡張機能である

when green flag clicked

これの止まる版

5656godzilla

#9209
却下された提案にあります

didhfi

音楽のブロックで音階を選択したときにその音がなるようにしてほしい　前までそうだったんだけどなぜか消えてスプリクト演奏を作るのがやりにくくなった　

あとは、クラウド変数が最近使えないから直してほしい

あとは、音声合成が最近ラグいから直してほしい

Last edited by didhfi (Today 11:33:18)

didhfi

kaki_jp wrote:
#9174
逆にBANの理由を明確にしてしまうと垢BANの回避につながってしまうのでは？

どういうことですか？

kaki_jp

#9212
文の通りです。

kaki_jp

#9211
1つ目別にそこで鳴らなくても良いと思います。地道にセッティングすればいいだけです。
2つ目、3つ目いちいち提案しなくてもいずれ直ります。気長に待ちましょう。

didhfi

kaki_jp wrote:
#9212
文の通りです。

具体的にどのように回避されるのですか？

sansyokudango_-000--

#9215
現に横行しているものを挙げると、
「スパム防止コード」などです。
これら規制回避の禁止行為が他の場面でも増える事を危惧しています。

omokai-f

kaki_jp wrote:
(#9214)
1つ目別にそこで鳴らなくても良いと思います。地道にセッティングすればいいだけです。

didhfiさんは、「スプリクト演奏を作るのがやりにくくなった」と言っています。
「地道にセッティングすればいいだけです。」という代替案は「スプリクト演奏を作るのがやりにくくなった」という問題を解決していません。

それとも、「やりにくくなった」ことを、やりやすくしてほしいという提案は、Scratchへの提案として適切ではないという事ですか？（これはシンプルに疑問です。「代用可能である」ということだけで、却下理由になってしまうのでしょうか。）

Ke0

代用可能ならば即ち却下というわけではありませんが、（とても簡単に代用できる場合を除くと、）多くの場合において却下理由に用途や拡張性が限定的であるという理由も内包されています。
過去の代用可能とされて却下された提案を見ればわかってくると思います。

Discuss Scratch