Discuss Scratch
- Discussion Forums
- » 日本語
- » scratch2.0の提案
![[RSS Feed]](//cdn.scratch.mit.edu/scratchr2/static/__9c6d3f90ec5f8ace6d3e8ea1e684b778__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]")
![[RSS Feed]](http://cdn.scratch.mit.edu/scratchr2/static/__9c6d3f90ec5f8ace6d3e8ea1e684b778__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]"){kind=icon}
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
ブロックには数値型で返すものと文字列型で返すものの二種類があったと思います。(fine316さんが検証していたと思う。)コスチュームの件については、別問題として
また、「用途が分かりにくい」とはどの辺りが分かりにくいのですか。現状の場合の方が1番目のコスチュームの名前が2で、2番目のコスチュームの名前が1のときなどに、挙動が分かりにくいと思います。
()番目のコスチュームにする::looksを要望に追加済みです。https://scratch.mit.edu/discuss/post/2769777/ 参照。
※これを書いていて思いましたが、背景、音についても要るのかも
用途については、現に私は何に使うのかわかりませんでした。
固定値を指定できるブロックにはそのまま値を書けばよいので必要ありません。
この「一時的な変数化」が有効なものは限られており、見たところ以下（とそれのバリエーション）だけのようです。
コスチュームを [ v] にする
背景を [ v] にする
[ v] の音を鳴らす
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- apple502j
-
Scratcher
1000+ posts
scratch2.0の提案
青文字でapple502jによる返信です。追加賛成は、追加に賛成という意味です。
mochimochiking さんからの削除対象案についての検討
赤文字がコメントです。
制御カテゴリスプライトの他のクローンを削除 ::control//複雑で汎用性がない。[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
動きカテゴリ[ v] のクローン (1) 番目へ向ける ::motion//https://scratch.mit.edu/discuss/post/2760391/→仕分け済み
見た目カテゴリ
・加算合成機能//初心者には難しい
→賛成。異論なければ却下に移動したいと思います。[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
調べるカテゴリ<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。(プロジェクト名 :: sensing)//定数なので取得する用途不明→賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
イベントカテゴリ
音カテゴリ
演算カテゴリ<[文字列] に [文字] が含まれる ::operators>//汎用性なし→仕分け済み([] の(1) 番目の文字以外::operators)/汎用性なし→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。( [文字列] :: operators)/意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。(() ^ ()::operators)//XOR 比較的簡単に実装可能→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
変数カテゴリリスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
ペンカテゴリ[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→賛成。異論なければ却下に移動したいと思います。
賛成。他人のプロフィールのコメント削除はST却下。
・トピックへの投稿に画像のアップロード//cubeで十分
→賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
署名は、ディスカッションフォーラムの機能である。署名は、その人のすべての投稿の下部に追加される。署名は、BBCodeで記述できる。 署名を追加/変更/削除したい場合は、ディスカッションフォーラムのホームの一番下に行き、「Change your signature」を押す。署名の大きさは150pxまでである。これには、改行、画像を含む。- Japanese Scratch-Wiki 「署名」
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
橙色の文字はmochimochikingによる返信です。
mochimochiking さんからの削除対象案についての検討
赤文字がコメントです。
制御カテゴリスプライトの他のクローンを削除 ::control//複雑で汎用性がない。[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
動きカテゴリ[ v] のクローン (1) 番目へ向ける ::motion//https://scratch.mit.edu/discuss/post/2760391/→仕分け済み
見た目カテゴリ
・加算合成機能//初心者には難しい
→賛成。異論なければ却下に移動したいと思います。[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
調べるカテゴリ<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。(プロジェクト名 :: sensing)//定数なので取得する用途不明→賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
演算カテゴリ([] の(1) 番目の文字以外::operators)//汎用性なし→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。(() ^ ()::operators)//XOR→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
特に理由がないとあったため、削除でいいと思います。
変数カテゴリリスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
他にはどのような意見がありますか。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
ペンカテゴリ[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→賛成。異論なければ却下に移動したいと思います。
賛成。他人のプロフィールのコメント削除はST却下。
・トピックへの投稿に画像のアップロード//cubeで十分
→賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
undefined
- kaaramochi
-
Scratcher
1000+ posts
scratch2.0の提案
緑文字がかあらもちのコメントです。
橙色の文字はmochimochikingによる返信です。mochimochiking さんからの削除対象案についての検討
赤文字がコメントです。
制御カテゴリスプライトの他のクローンを削除 ::control//複雑で汎用性がない。[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
動きカテゴリ[ v] のクローン (1) 番目へ向ける ::motion//https://scratch.mit.edu/discuss/post/2760391/→仕分け済み
見た目カテゴリ
・加算合成機能//初心者には難しい
→賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
調べるカテゴリ<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。(プロジェクト名 :: sensing)//定数なので取得する用途不明→賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。
僕も同じ理由でいらないと思います。(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
演算カテゴリ([] の(1) 番目の文字以外::operators)//汎用性なし→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。(() ^ ()::operators)//XOR→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
変数カテゴリリスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
他にはどのような意見がありますか。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の三つは、実装されてもいいと思います。変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
汎用性がないように思います。リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
ペンカテゴリ[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
背景に直接書いているので、仕様変更しない限り無理だと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→賛成。異論なければ却下に移動したいと思います。
賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
・トピックへの投稿に画像のアップロード//cubeで十分
→賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingさんのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです(見やすくするために色を変更しました)。
制御カテゴリスプライトの他のクローンを削除 ::control//複雑で汎用性がない。[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
見た目カテゴリ
・加算合成機能//初心者には難しい
→賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？
http://rina.jpn.ph/~rance/directx8/05/img03.gifのようなものです。[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
調べるカテゴリ<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。(プロジェクト名 :: sensing)//定数なので取得する用途不明→賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。
僕も同じ理由でいらないと思います。(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
演算カテゴリ([] の(1) 番目の文字以外::operators)//汎用性なし→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。(() ^ ()::operators)//XOR→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
ぼくも累乗は汎用性があると思います。ここではビット演算の排他的論理和としてのブロックとして考えています。
変数カテゴリリスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/
→賛成。しかし議論中。
他にはどのような意見がありますか。(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の三つは、実装されてもいいと思います。変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
汎用性がないように思います。リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
ペンカテゴリ[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
背景に直接書いているので、仕様変更しない限り無理だと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→賛成。異論なければ却下に移動したいと思います。
賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
・トピックへの投稿に画像のアップロード//cubeで十分
→賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
確かに内部で行うことは管理上良いですね。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
undefined
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです（太字が今回追加）。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
※賛成→削除賛成に置き換えました。
制御カテゴリ
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
見た目カテゴリ
・加算合成機能//初心者には難しい
→削除賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？
http://rina.jpn.ph/~rance/directx8/05/img03.gifのようなものです。
却下でいいですか？
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。
上の二つは、却下でいいですか？
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。
却下でいいですか？
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
僕も同じ理由でいらないと思います。
却下でいいですか？
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
演算カテゴリ
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
ぼくも累乗は汎用性があると思います。ここではビット演算の排他的論理和としてのブロックとして考えています。
ビット演算は初心者向けではないので却下でいいですか？ https://scratch.mit.edu/discuss/post/2772010/ ～も参照
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
汎用性がないように思います。
却下でいいですか？
上の二つは、実装されてもいいと思います。
ペンカテゴリ
背景に直接書いているので、仕様変更しない限り無理だと思います。
却下でいいですか？
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
・トピックへの投稿に画像のアップロード//cubeで十分
→削除賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
確かに内部で行うことは管理上良いですね。
「自由にネットが使えない人たち」という意見に納得です。追加賛成にします。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
赤文字がinokingのコメントです（太字が今回追加）。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
※賛成→削除賛成に置き換えました。
制御カテゴリ
スプライトの他のクローンを削除 ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
見た目カテゴリ
・加算合成機能//初心者には難しい
→削除賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？
http://rina.jpn.ph/~rance/directx8/05/img03.gifのようなものです。
却下でいいですか？
[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。
[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。
上の二つは、却下でいいですか？
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(プロジェクト名 :: sensing)//定数なので取得する用途不明→削除賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。
却下でいいですか？
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。
僕も同じ理由でいらないと思います。
却下でいいですか？
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
演算カテゴリ
([] の(1) 番目の文字以外::operators)//汎用性なし→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。
<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
(() ^ ()::operators)//XOR→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
ぼくも累乗は汎用性があると思います。ここではビット演算の排他的論理和としてのブロックとして考えています。
ビット演算は初心者向けではないので却下でいいですか？ https://scratch.mit.edu/discuss/post/2772010/ ～も参照
変数カテゴリ
リスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
汎用性がないように思います。
却下でいいですか？
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
ペンカテゴリ
[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→削除賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
背景に直接書いているので、仕様変更しない限り無理だと思います。
却下でいいですか？
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
・トピックへの投稿に画像のアップロード//cubeで十分
→削除賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
確かに内部で行うことは管理上良いですね。
「自由にネットが使えない人たち」という意見に納得です。追加賛成にします。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
長くなるのでquoteはしません。
ホイールがないならその機能が使えないだけなので支障はないと思います。
とありますが、ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
ホイールがないならその機能が使えないだけなので支障はないと思います。
とありますが、ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
undefined
- MMGISS
-
Scratcher
1000+ posts
scratch2.0の提案
mochimochiking さんからの削除対象案についての検討
赤文字がinokingさんのコメントです（太字が今回追加）。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
灰文字がMMGISSのコメントです。
※賛成→削除賛成に置き換えました。
制御カテゴリ
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
メッセージを使うとスプライトの数だけスクリプトを新たに用意しなければならないので複雑になりメッセージで対処する案については反対。
見た目カテゴリ
・加算合成機能//初心者には難しい
→削除賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？
http://rina.jpn.ph/~rance/directx8/05/img03.gifのようなものです。
却下でいいですか？
複雑すぎる上、ブロックとしての実装が非常に難しそうなので却下賛成です。
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。
上の二つは、却下でいいですか？
いいと思います
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。
却下でいいですか？
いいと思います。変数を使用することで容易に代替できます。
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
僕も同じ理由でいらないと思います。
却下でいいですか？
いいと思います。変数を使用することで容易に代替できます。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
演算カテゴリ
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
ぼくも累乗は汎用性があると思います。ここではビット演算の排他的論理和としてのブロックとして考えています。
ビット演算は初心者向けではないので却下でいいですか？ https://scratch.mit.edu/discuss/post/2772010/ ～も参照
小中学生向けに作られたScratchの趣旨と合わないので却下賛成です。
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
汎用性がないように思います。
却下でいいですか？
上の二つは、実装されてもいいと思います。
ペンカテゴリ
背景に直接書いているので、仕様変更しない限り無理だと思います。
却下でいいですか？
いいと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
・トピックへの投稿に画像のアップロード//cubeで十分
→削除賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
確かに内部で行うことは管理上良いですね。
「自由にネットが使えない人たち」という意見に納得です。追加賛成にします。
追加賛成します。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
赤文字がinokingさんのコメントです（太字が今回追加）。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
灰文字がMMGISSのコメントです。
※賛成→削除賛成に置き換えました。
制御カテゴリ
スプライトの他のクローンを削除 ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
メッセージを使うとスプライトの数だけスクリプトを新たに用意しなければならないので複雑になりメッセージで対処する案については反対。
見た目カテゴリ
・加算合成機能//初心者には難しい
→削除賛成。異論なければ却下に移動したいと思います。
加算合成機能とは何ですか？
http://rina.jpn.ph/~rance/directx8/05/img03.gifのようなものです。
却下でいいですか？
複雑すぎる上、ブロックとしての実装が非常に難しそうなので却下賛成です。
[#f9f] 色を隠す ::looks//用途不明→提案内容の分かる方、説明お願いします。
[#f9f] 色を表示する ::looks//用途不明→提案内容の分かる方、説明お願いします。
上の二つは、スプライトの特定の色の部分だけ出したり消したりすることだと思います。コスチュームでなんとかなるのでいらないと思います。
上の二つは、却下でいいですか？
いいと思います
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(プロジェクト名 :: sensing)//定数なので取得する用途不明→削除賛成。異論なければ却下に移動したいと思います。
リミックス禁止に使用できる虞有。
リミックスするときに、そのプログラムを外せばいいだけだと思う。
僕もこのブロックはいらないと思います。
却下でいいですか？
いいと思います。変数を使用することで容易に代替できます。
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(スプライト数::sensing)//複数あるときに疑問→プロジェクト名同様、定数だと思います。用途不明。異論なければ却下に移動したいと思います。
僕も同じ理由でいらないと思います。
却下でいいですか？
いいと思います。変数を使用することで容易に代替できます。
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
演算カテゴリ
([] の(1) 番目の文字以外::operators)//汎用性なし→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。
<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
(() ^ ()::operators)//XOR→要不要説の両方あります。https://scratch.mit.edu/discuss/post/2803509/
特に理由がないとあったため、削除でいいと思います。
不要だと思います。 しかし、()の()乗は、汎用性があると思います。
ぼくも累乗は汎用性があると思います。ここではビット演算の排他的論理和としてのブロックとして考えています。
ビット演算は初心者向けではないので却下でいいですか？ https://scratch.mit.edu/discuss/post/2772010/ ～も参照
小中学生向けに作られたScratchの趣旨と合わないので却下賛成です。
変数カテゴリ
リスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
汎用性がないように思います。
却下でいいですか？
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
ペンカテゴリ
[このスプライト v] のペンを消す :: pen//重ね塗りのときに疑問→削除賛成。https://scratch.mit.edu/discuss/post/2796194/ の意見も見てください。異論なければ却下に移動したいと思います。
背景に直接書いているので、仕様変更しない限り無理だと思います。
却下でいいですか？
いいと思います。
その他 編集/実行
・スプライトどうしのレイヤー//初心者が困惑
→Scratch 3.0 への提案に入れています。https://scratch.mit.edu/discuss/post/2724537/ 2.0としては却下に移動したいと思います。
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
・トピックへの投稿に画像のアップロード//cubeで十分
→削除賛成。cubeuploadに限らず。
追加賛成。世の中には検閲を受けて自由にネットが使えない人たちがいるのです。トピック検索がなくなった検索アップデートもそれが原因です。
cubeは外部ツールなので、scratchにもそういうツールがあっていいと思います。
確かに内部で行うことは管理上良いですね。
「自由にネットが使えない人たち」という意見に納得です。追加賛成にします。
追加賛成します。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
ホイールがないならその機能が使えないだけなので支障はないと思います。現状でも例えばマイクやカメラで同様の状況が発生しています。
とありますが、ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
実際、私のPCにはマイクやカメラが付いていないため、これらが必須のプロジェクトは実行できません。
※Scratchの動作推奨環境 にマイクやカメラは書かれていません。ブロックのヘルプにはデバイスが必要と書かれています。
ちょっと事情は違いますが
「その他」の「拡張機能を追加」でも似たような状況です。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
ここまでで いったん提案リストをまとめ直し
削除対象案から仕分け済みのものを削除します。
編集がかぶると面倒なので、意見がある人はすぐに知らせてください。
削除対象案から仕分け済みのものを削除します。
編集がかぶると面倒なので、意見がある人はすぐに知らせてください。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
以下を却下された提案 に移動しました。
・加算合成機能
以下を異論のない提案 に移動しました。
・トピックへの投稿に画像のアップロード
以下を仕分け前の提案 に追加しました。
これまでの提案のまとめ
仕分け前の提案
制御カテゴリ
・クローンの限界の増加
動きカテゴリ
・なし
見た目カテゴリ
調べるカテゴリ
イベントカテゴリ
音カテゴリ
・用意されている音の種類の増加
演算カテゴリ
・かつとまたはの変換
変数カテゴリ
・「このスプライトのみ」に見た目上の区別
・クラウドリスト
・リストの名前変更
・他のプロジェクトとの変数共有
・ユーザーごとに保存される変数
・保存数するとリストの大きさが変わる仕様修正
ペンカテゴリ
・消しゴムの追加
定義カテゴリ
・ハットブロックの定義
・「再描画せずに実行」に見た目上の区別
その他 編集/実行
・スクリプトの検索機能
・自動保存のON、OFFの切り替え機能
・定義をスプライトを跨いでの使用可能
・一つ前に戻す（スクリプトの状態を）
・ペイントの日本語対応
・使用ブロック数を表示
・コメントをスプライトファイルに保存
・コスチュームにscratchblocksが使えるように
・バックパックに入れたものに名前やメモに付けることを可能に
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい
・Scratch 1.4のようなステップ実行
・一時停止
話す
・トピックの連続建て不可
・自分がオーナーのスタジオに投稿されたコメントの削除
・トピックへの投稿に画像のアップロード
・コメントの改行可能
・ブロックの前後での改行をなくす
・トピックのコメントで、ブロックと普通の文章を同じ行に書けるようにしてほしい // ブロックの前後での改行をなくす と同じ?
・sage機能(BBSなどにある機能で、レスしてもスレが上がらないという機能。要らないスレにいちいち注意しても無駄に上がるだけだがこの機能で改善される筈)
その他
・新着メッセージをメールで通知する機能
・アカウントの2段階認証
・ユーザーアイコンに.svgを使用できる
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする
・私の作品で、昇順/降順の切り替え可能
・サムネイルの設定機能
・オフラインエディタへの、アカウントからのバックパックのインポート
異論のない提案
話す
・トピックへの投稿に画像のアップロード
背景：https://scratch.mit.edu/discuss/post/2803849/
意見の分かれる提案
動きブロック
・x座標,y座標の右クリックでの変換
演算カテゴリ
却下された提案
制御カテゴリ
動きカテゴリ
見た目カテゴリ
・加算合成機能
理由：https://scratch.mit.edu/discuss/post/2808893/
調べるカテゴリ
演算カテゴリ
ペンカテゴリ
その他 編集/実行
・スプライトどうしのレイヤー
理由：https://scratch.mit.edu/discuss/post/2808893/
3.0で追加される提案
・加算合成機能
[#f9f] 色を隠す ::looks
[#f9f] 色を表示する ::looks
(プロジェクト名 :: sensing)
(スプライト数::sensing)
(()XOR()::operators)
[このスプライト v] のペンを消す :: pen・スプライトどうしのレイヤー
以下を異論のない提案 に移動しました。
・トピックへの投稿に画像のアップロード
以下を仕分け前の提案 に追加しました。
<TRUE::operators>//https://scratch.mit.edu/discuss/post/2670867/
<FALSE::operators>//https://scratch.mit.edu/discuss/post/2670867/（ステップ実行は既にありました）
これまでの提案のまとめ
仕分け前の提案 制御カテゴリ
・クローンの限界の増加
ターボモードを [オン v] にする ::control
<ターボモード ::control>
スプライトの他のクローンを削除 ::control
<大画面 :: control>
[このスクリプト以外のすべて v] を止める ::control
動きカテゴリ
・なし
見た目カテゴリ
横に () %伸びる ::looks
縦に () %伸びる ::looks
() 秒で大きさを () %にする ::looks
[白黒 v] の効果を (100) にする ::looks
このスプライトの色を [#000000] にする ::looks
このスプライトの [#000000] 色を [#ff0000] 色に変える ::looks
(コスチューム名 ::looks)
文字列 [文字列] を表示 ::looks//3.0のペンテキストでは最下の表示になるため
()番目のコスチュームにする::looks
調べるカテゴリ
<触れた色 ::sensing>
<[スプライト v] が表示されている ::sensing>
<[#f0f] 色が [sprite1 v] に触れた ::sensing>
(マウスホイールの速さ ::sensing)
(スプライトの [縦の大きさ v] :: sensing)
(スプライトの [横の大きさ v] :: sensing)
(スプライトの [面積 v] :: sensing)
([Sprite1 v] に触れた面積 :: sensing)
(マイクの音の高さ ::sound)
(押されたキー :: sensing)
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>
[] と聞いて待つ（初期値[100]）:: sensing
<[Shift v] キーが押された>
<[Backspace v] キーが押された>
<[Enter v] キーが押された>
(マウスホイールの移動量 :: sensing)
イベントカテゴリ
[Shift v] キーが押されたとき :: events :: hat
[Backspace v] キーが押されたとき :: events :: hat
[Enter v] キーが押されたとき :: events :: hat
[マウスホイール上 v] が押されたとき :: events :: hat
[マウスホイール下 v] が押されたとき :: events :: hat
音カテゴリ
・用意されている音の種類の増加
終わるまで [ v] の音を () 秒から鳴らす :: sound
[ v] の音を () 秒から鳴らす :: sound
(楽器::sound)
音の再生速度を () % にする::sound
演算カテゴリ
・かつとまたはの変換
<[文字列] に [文字] が含まれる ::operators>
([] の(1) 番目の文字以外::operators)
( [文字列] :: operators)
<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化
<[文字列] は大文字 ::operators>
(()の()乗::operators)
<[] と [] が大文字小文字を含めて同じ::operators>
(もし <> なら [] でなければ [] :: operators)
<TRUE::operators>//https://scratch.mit.edu/discuss/post/2670867/
<FALSE::operators>//https://scratch.mit.edu/discuss/post/2670867/
変数カテゴリ
・「このスプライトのみ」に見た目上の区別
・クラウドリスト
・リストの名前変更
・他のプロジェクトとの変数共有
・ユーザーごとに保存される変数
・保存数するとリストの大きさが変わる仕様修正
変数 [変数 v] を作る ::variables
変数 [変数 v] を [#f5f] にする ::variables
(1 v) 番目 [リスト v] を (1) ずつ変える ::list
リスト [リスト v] を [A~Z v] の順に置き換える ::list
変数 [ v] のx座標を () に、y座標を () にする ::variables
(変数 [ v] のx座標 ::variables)
(変数 [ v] のx座標 ::variables)
変数 [ v] の表示形式を [スライダー v] にする :: variables
(変数 [ v] の表示形式::variables)
[変数 v] のスライダーの最小値を (0) にする :: variables
[変数 v] のスライダーの最大値を (0) にする :: variables
([変数 v] のスライダーの最小値 :: variables)
([変数 v] のスライダーの最大値 :: variables)
<変数 [ v] がクリックされた :: variables>
リスト[ v]の中身をシャッフル::list
リスト [ v] のx座標を () に、y座標を () にする ::list
リスト [ v] の縦幅を () に、横幅を () にする ::list
ペンカテゴリ
・消しゴムの追加
定義カテゴリ
・ハットブロックの定義
(値ブロックの定義::custom)
<真偽値ブロックの定義::custom>・色や変数等の引数も定義に使用可能
・「再描画せずに実行」に見た目上の区別
その他 編集/実行
・スクリプトの検索機能
・自動保存のON、OFFの切り替え機能
・定義をスプライトを跨いでの使用可能
・一つ前に戻す（スクリプトの状態を）
・ペイントの日本語対応
・使用ブロック数を表示
・コメントをスプライトファイルに保存
・コスチュームにscratchblocksが使えるように
・バックパックに入れたものに名前やメモに付けることを可能に
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい
・Scratch 1.4のようなステップ実行
・一時停止
話す
・トピックの連続建て不可
・自分がオーナーのスタジオに投稿されたコメントの削除
・トピックへの投稿に画像のアップロード
・コメントの改行可能
・ブロックの前後での改行をなくす
・トピックのコメントで、ブロックと普通の文章を同じ行に書けるようにしてほしい // ブロックの前後での改行をなくす と同じ?
・sage機能(BBSなどにある機能で、レスしてもスレが上がらないという機能。要らないスレにいちいち注意しても無駄に上がるだけだがこの機能で改善される筈)
その他
・新着メッセージをメールで通知する機能
・アカウントの2段階認証
・ユーザーアイコンに.svgを使用できる
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする
・私の作品で、昇順/降順の切り替え可能
・サムネイルの設定機能
・オフラインエディタへの、アカウントからのバックパックのインポート
異論のない提案 話す
・トピックへの投稿に画像のアップロード
背景：https://scratch.mit.edu/discuss/post/2803849/
意見の分かれる提案 動きブロック
・x座標,y座標の右クリックでの変換
演算カテゴリ
( () + (0))//ブロック端にスペースがあると格段に動かしやすくなるのでは
却下された提案 制御カテゴリ
() 番目に作られたクローンを削除する :: control理由：https://scratch.mit.edu/discuss/post/2803849/
動きカテゴリ
[ v] のクローン (1) 番目へ向ける ::motion理由：https://scratch.mit.edu/discuss/post/2803849/
向きが (90 v) 度になったとき ::motion hat理由：https://scratch.mit.edu/discuss/post/2761553/
見た目カテゴリ
(画像効果 [幽霊 v] ::looks)理由：https://scratch.mit.edu/discuss/post/2763615/
・加算合成機能
理由：https://scratch.mit.edu/discuss/post/2808893/
[#f9f] 色を隠す ::looks理由：https://scratch.mit.edu/discuss/post/2808893/
[#f9f] 色を表示する ::looks理由：https://scratch.mit.edu/discuss/post/2808893/
調べるカテゴリ
(プロジェクト名 :: sensing)理由：https://scratch.mit.edu/discuss/post/2808893/
(スプライト数::sensing)理由：https://scratch.mit.edu/discuss/post/2808893/
演算カテゴリ
(()XOR()::operators)理由：https://scratch.mit.edu/discuss/post/2808893/
ペンカテゴリ
(ペンの太さ ::pen)理由：https://scratch.mit.edu/discuss/post/2763615/
(ペンの色 ::pen)理由：https://scratch.mit.edu/discuss/post/2763615/
(ペンの濃さ ::pen)理由：https://scratch.mit.edu/discuss/post/2763615/
<ペンが下りている ::pen>理由：https://scratch.mit.edu/discuss/post/2763615/
[このスプライト v] のペンを消す :: pen理由：https://scratch.mit.edu/discuss/post/2808893/
その他 編集/実行
・スプライトどうしのレイヤー
理由：https://scratch.mit.edu/discuss/post/2808893/
3.0で追加される提案<[]に[]が含まれる::operators>//3.0 で追加されるので 2.0 での追加要望はなし
Last edited by inoking (Sept. 2, 2017 14:34:06)
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
仕分け済みを削除し、コメントを一部追加しました。
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
灰文字がMMGISSさんのコメントです。
制御カテゴリ
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
メッセージを使うとスプライトの数だけスクリプトを新たに用意しなければならないので複雑になりメッセージで対処する案については反対。
見た目カテゴリ
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
旧ブロック (note::sensing) のことでしょうか。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
演算カテゴリ
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
変数カテゴリ
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
上の三つは、実装されてもいいと思います。
上の二つは、どんなときに使うんでしょうか。
上の四つは、そこまで汎用性があるでしょうか。
汎用性がないように思います。
却下でいいですか？
上の二つは、実装されてもいいと思います。
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。→ステップ実行は既にありました
追加賛成です。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
却下でいいですか？
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです（ここに記入させてもらいました）。
灰文字がMMGISSさんのコメントです。
制御カテゴリ
スプライトの他のクローンを削除 ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
[このスクリプト以外のすべて v] を止める ::control//複雑で汎用性がない。→複雑とは思いませんが汎用性がないのは同感です。https://scratch.mit.edu/discuss/post/2760391/ の意見も見てください。異論なければ却下に移動したいと思います。
このスクリプト以外のすべては汎用性があります。例:ゲームオーバー時の処理をする前に敵を止める など。「このスクリプト以外の～」に追加賛成。
メッセージを使えば済むと思う。
同感です。
メッセージを使うとスプライトの数だけスクリプトを新たに用意しなければならないので複雑になりメッセージで対処する案については反対。
見た目カテゴリ
このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
調べるカテゴリ
<触れた色 ::sensing>//複数あるときに疑問→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。
(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。
(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明→定数とは限りません。必要性については要検討
(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。
(押されたキー :: sensing)//複数あるときに疑問→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能→簡単かどうかは分かりませんが汎用性がないと思います。
(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
演算カテゴリ
([] の(1) 番目の文字以外::operators)//汎用性なし→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
( [文字列] :: operators)//意味不明→https://scratch.mit.edu/discuss/post/2769834/ 不要と思います。
<<> かつ <> かつ <> ::operators>//かつブロックの引数多数化 局所的→重くなるとのこと。https://scratch.mit.edu/discuss/post/2766375/ の意見も見てください。
そのような局所的な変更よりもアルゴリズムの改善のほうが高速化できると思います。
同感です。
変数カテゴリ
リスト [リスト v] を [A~Z v] の順に置き換える ::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch.mit.edu/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch.mit.edu/discuss/post/2800013/ についても考慮お願いします。
(変数 [ v] のx座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] のy座標 ::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
(変数 [ v] の表示形式::variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。
[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最小値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
([変数 v] のスライダーの最大値 :: variables)//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
<変数 [ v] がクリックされた :: variables>//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト[ v]の中身をシャッフル::list//複雑 Scratchは教育用であるため、なんでも用意するのはよくない→削除賛成。https://scratch.mit.edu/discuss/post/2760418/ の意見も見てください。異論なければ却下に移動したいと思います。
汎用性がないように思います。
却下でいいですか？
リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch.mit.edu/discuss/post/2800013/→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
その他 編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。
・一時停止//解除方法が不明
→再クリックでよいと思います。phosphorus 参照
あってもいいと思います。コマ送りもできればほしいと思います。
たしかに1.4のステップ実行のようなものはデバッグに役立ちますね。
ステップ実行を別項目として追加したいと思います。→ステップ実行は既にありました
追加賛成です。
話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
その他
・新着メッセージをメールで通知する機能//既存でよいと思う。
→削除賛成。異論なければ却下に移動したいと思います。
却下でいいですか？
・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
Last edited by inoking (Sept. 2, 2017 14:35:17)
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
私の作品で、昇順/降順の切り替え可能を削除し、代わりに自分の作品の検索機能を追加する方が役に立つと思います。
undefined
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
話の流れは変わりますが、ブロック名にも分かりにくいものがあります。
例えば、これらです。
例えば、これらです。
(コスチューム #)このように変えたほうがより初心者にわかりやすいと思います。
(( v) 番目\( [list v] \) :: list)
(() * (0))
(コスチュームの番号::looks)ただ、真ん中の物は現在の翻訳システムではできませんから改善が必要ですね。
([list v]の( v)番目:: list)
(() × (0)::operators)
undefined
- inoking
-
Scratcher
1000+ posts
scratch2.0の提案
話の流れは変わりますが、ブロック名にも分かりにくいものがあります。コスチュームの番号
例えば、これらです。(コスチューム #)このように変えたほうがより初心者にわかりやすいと思います。
(( v) 番目\( [list v] \) :: list)
(() * (0))(コスチュームの番号::looks)ただ、真ん中の物は現在の翻訳システムではできませんから改善が必要ですね。
([list v]の( v)番目:: list)
(() × (0)::operators)
→私は反対はしません。
list の( )番目
→私は反対はしません。
翻訳引数の順序は現状でも変えられるのではないでしょうか？
C:\Program Files (x86)\Scratch 2\locale\ja.po:
msgid "item %d.listItem of %m.list"
msgstr "%d.listItem 番目（ %m.list ）"
→
乗除を *, / で表すことはコンピュータを扱う上では至極一般的ですし、キーボードにもそう印字されています。
よって、今のままがよいと思います。
これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
つまり「子ども SNS」として遊ぶためのものではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
以前ファイルを変更したことがあったのですが、引数の型が違うと、順序を入れ替えた時に正しく翻訳されなかったです。
undefined
- youkaiwatch
-
Scratcher
1000+ posts
scratch2.0の提案
私はこのトピックすべてを把握しているわけではないので、もしかしたら既出かもしれませんが、
これらは個人的にあったら良いなと思うブロックです
全て何かしらの形で必ず代用可能なのは言語仕様上当たり前ですが
標準搭載されれば直接ベースで実行されるので早く・軽くなる利点があります
その他にも、他言語で搭載されている機能のため、他言語サポートも兼ねています
無くて損がないなら、あっても良いのではと思うブロックです
これらは個人的にあったら良いなと思うブロックです
([]match[string v]::operators) // regular expression. string:return strings only, number:return number only and other:return not strings and numbers.
[list v]forEeach(element)(index)(list){
}end::control // forEach method. element,index and list are arguments. these arguments change dynamically.
(item(1 v)(1 v)of[list v]::list) // 2-dimension array. return item of (x,y)
replace item (1 v)(1 v)of[list v]with[thing]::list // set any element for 2-dimension list use (x,y)
width(100)[% v]::looks // set width or height of costume. can select in 2 types. % or px.
height(100)[% v]::looks
(width::looks) // return width
(height::looks) // return height
全て何かしらの形で必ず代用可能なのは言語仕様上当たり前ですが
標準搭載されれば直接ベースで実行されるので早く・軽くなる利点があります
その他にも、他言語で搭載されている機能のため、他言語サポートも兼ねています
無くて損がないなら、あっても良いのではと思うブロックです
- mochimochiking
-
Scratcher
1000+ posts
scratch2.0の提案
私はこのトピックすべてを把握しているわけではないので、もしかしたら既出かもしれませんが、すみません、僕の英語力では
これらは個人的にあったら良いなと思うブロックです([]match[string v]::operators) // regular expression. string:return strings only, number:return number only and other:return not strings and numbers.
[list v]forEach(element)(index)(list){
}::control // forEach method. element,index and list are arguments. these arguments change dynamically.
(item(1 v)(1 v)of[list v]::list) // 2-dimension array. return item of (x,y)
replace item (1 v)(1 v)of[list v]with[thing]::list // set any element for 2-dimension list use (x,y)
width(100)[% v]::looks // set width or height of costume. can select in 2 types. % or px.
height(100)[% v]::looks
(width::looks) // return width
(height::looks) // return height
全て何かしらの形で必ず代用可能なのは言語仕様上当たり前ですが
標準搭載されれば直接ベースで実行されるので早く・軽くなる利点があります
その他にも、他言語で搭載されている機能のため、他言語サポートも兼ねています
無くて損がないなら、あっても良いのではと思うブロックです
([]match[string v]::operators)が型を判定するブロックか、正規表現に当てはまるか判定するブロックか、分かりませんでした。
あと、二次元配列を作成したときに、要素を削除したときの詰められ方も疑問です。
undefined
- youkaiwatch
-
Scratcher
1000+ posts
scratch2.0の提案
英語でやってる癖で英語で書いてしまいました（実際日本語でいいと思います）私はこのトピックすべてを把握しているわけではないので、もしかしたら既出かもしれませんが、すみません、僕の英語力では
これらは個人的にあったら良いなと思うブロックです([]match[string v]::operators) // regular expression. string:return strings only, number:return number only and other:return not strings and numbers.
[list v]forEach(element)(index)(list){
}::control // forEach method. element,index and list are arguments. these arguments change dynamically.
(item(1 v)(1 v)of[list v]::list) // 2-dimension array. return item of (x,y)
replace item (1 v)(1 v)of[list v]with[thing]::list // set any element for 2-dimension list use (x,y)
width(100)[% v]::looks // set width or height of costume. can select in 2 types. % or px.
height(100)[% v]::looks
(width::looks) // return width
(height::looks) // return height
全て何かしらの形で必ず代用可能なのは言語仕様上当たり前ですが
標準搭載されれば直接ベースで実行されるので早く・軽くなる利点があります
その他にも、他言語で搭載されている機能のため、他言語サポートも兼ねています
無くて損がないなら、あっても良いのではと思うブロックです([]match[string v]::operators)が型を判定するブロックか、正規表現に当てはまるか判定するブロックか、分かりませんでした。
あと、二次元配列を作成したときに、要素を削除したときの詰められ方も疑問です。
それぞれ適切な翻訳が或ると思いますが…
詰められ方は単純です（考えれば分かりますが）
例えば
［
［0,1,2,3,4］,
［5,6,7,8,9］,
］
のような二次元配列Aが存在します。（インデックスをスクラッチに合わせ1を始点とします）
A［1］［1］を消した場合は
［
［1,2,3,4］,
［5,6,7,8,9］,
］
当然、このような配列になります
Last edited by youkaiwatch (Sept. 4, 2017 04:54:59)