Bunbungomatarou wrote:

…。まあ別に難しかったら却下してOKです。

ずっと

end

x座標を () 、y座標を (0) にする
x座標を () にする

tabakenn wrote:

では、「カスタムブロックパレット」というのはどうでしょう。（ちょっと分かりづらいところに隠すのは必須ですけど）

自分がいらないなーというブロックをどこかに追いやったり、順番を変えてしまったりできる感じです。

「定義内変数」「定義の値返し」「ハットブロックの定義」が実装されれば、独立な関数を作れるので、それを追加することもできます。

バックパックのように全プロジェクト共有です。

tabakenn wrote:

クッキー使用ではなく、
クラウド変数の個人バージョンという解釈で合っています。

クッキーや復活の呪文、リミックス直ちに保存など、既存の案はクラウド変数でのランキングなどに対応できません。また、クラウド変数でセーブを再現するというのは、前書いたとおり実用的でないと考えています。

griffpatch さんのプロジェクトの例が出ましたが……
スクラッチの参照数は対数正規分布にだいたい従うと思います。つまり、griffpacth さんのような参照数が多いプロジェクトはごく一部であり、そこの容量が巨大になるからといって、サーバーのストレージスペースを一気に消費する訳ではないと思います。

ここらへんを見てみたのですが、クラウドショックは単にチャットなどの悪用を防ぐためだけのように思えます。（サーバーの容量については言及されていないので）
よって、クラウドショックはサーバーストレージの制約によるものではないと信じています。

These new limits were put into place to prevent abuse of the cloud variables system that was causing it to be unreasonable to maintain, scale, moderate, and support financially.

Wiki や Google 翻訳はおかしいので手動翻訳 wrote:

これらの新しい制限は、
維持、拡張、管理、財政的なサポートに無理を生じさせていたクラウド変数システムの乱用を防ぐために設けられました。

Jinenjo_000 wrote:

私も、以前傾向には毎日全然違う作品が表示されていた記憶がありますから、それと比較すると
現在の傾向の変化の小ささに違和感を覚えています
一時期傾向の作品が頻繁に入れ替わっていたのは、そのときたまたま順位の変動が激しかっただけ、
そして現在傾向が変わっていないように見えるのは、1～19ページ目までの作品の順位がたまたま変動しなかっただけ、
というのがinokingさんの認識ですか？

griffpatch wrote:

略
Since cloud cars could no longer be used for high score tables or storing achievements, do you think there will be score in new scratch 3 blocks for implementing this kind of functionality in a more scalable controllable way? For example, achievements want to be recorded per user, but not accessable by other scratchers, so this is like a local cloud variable or list for that scratcher? Couldn't be used for chat rooms, and could be set to only save very periodically as it only needs to persist between sessions not in real time.
略

• 各プレイヤーのためのローカル変数やリスト（今回の僕の提案と同じですね…）
  
• リアルタイムゲームを作るために、生存期間が短いクラウド変数（つまり、チャットを作ることはできない）
  

チャット対策も大きな目的ですが、それだけなら文字種制限だけで十分で、文字数制限までする必要はありません

なぜ「クラウド変数でのランキングなどに対応できない」のですか？
ハックとか言い出したらキリがありません。

• 復活の呪文形式（セーブコードについてみんなで話し合う場所1 でも結論は出ていない。最もハックされやすい）
  
• クッキー方式（クッキー改ざんという新たな脆弱性が生まれる）
  
• 今回の提案（クラウド変数とおなじ仕組みを使うので新たな脆弱性は生まれない）
  

• パレットのカスタム定義を編集や削除したときの、他のプロジェクトでの挙動。
  
• カスタム定義がリミックスされたときの挙動。
  

tabakenn wrote:

いまいち納得できないので、英語フォーラムで聞いてみるべきですか？

文字数制限がなければ、簡単にチャットを作ることができます。特にアルファベットではより簡単だと思います。

• 復活の呪文形式（セーブコードについてみんなで話し合う場所1 でも結論は出ていない。最もハックされやすい）
  
• クッキー方式（クッキー改ざんという新たな脆弱性が生まれる）
  
• 今回の提案（クラウド変数とおなじ仕組みを使うので新たな脆弱性は生まれない）
  

tabakenn wrote:

制限以前は10個、ユニコード全部（65536 utf-16サロゲートペアなしのときと想定）と10240桁入ったらしいので、
10240log(2, 65536) * 10 = 1638400 bit / 個
117,181,797個（全共有数）* 1638400 bit = 24.0TB

今は、
256log(2, 10) * 10 = 8504 bit / 個
117,181,797個（全共有数）* 8504 bit = 124.5GB

プレイヤー変数

⬜︎クラウド変数（サーバーに保存）
⬜︎プレイヤー変数（ユーザごとにサーバーに保存）

inoking wrote:

・セーブコードなどの方式で実現可能。
・何でも便利であるべきではない（#1 からリンクされている #3983 とも関連）。
・そういう機能がほしいなら作品側で工夫すべき。

inoking wrote:

クラウドと同じ仕組みなら、クラウド変数と同様に改ざんは可能です（現在クラウド変数の脆弱性はそこまで問題にはなっていません）。

taakenn wrote:

256log(2, 10) * 10 = 8504 bit / 個
117,181,797個（全共有数）* 8504 bit = 124.5GB