正直言いますと、スプライトの扱いが厳正になったのは残念でしたね。特に、大量のプログラムを書いている人には大打撃でしょうね。エラー直しも面倒ですし…。ならば、SPHARDとかの命令を作ったほうがよかった気が…。 『SPHARDの意味はコメントへ』

命令名：SPHARD 引数：0＝SPSETせずにSPOFSなどを扱ってもエラーにならない 　　　1＝SPSETせずにSPOFSなどを扱うとエラーになる 例：SPHARD 1 (初期設定はSPHARD 0です。ACLSを使うとSPHARD 0になる。)

個人的な意見では急に命令を追加するのは大歓迎だけど、急にプログラムのルールを変えるのは駄目だと思う。 せっかく作ったのにいきなりルールを変えられると対応が大変ですし、考えすぎかもしれませんが、またルールが変更されると考えるとどうしてもモチベーションが下がってしまいますね…

個人的にはこの仕様変更は賛成です。 仕様として本来はSPSETが必要だったのが、今までバグで不要だったと解釈しています。 残念ですが、そのバグを使ってたという事になるようです。

あるべき仕様がどちらかであるかと言えば、今バージョンなんだとは思います。 ウッディーさんの仰るような2モード制にすると、後々プチコン本体のメンテコストが嵩むというスマブ側の理屈もわかる。 でも、そのツケを全部ユーザに回したのは、やっぱり正しくないのではないかなぁ。 すでにメンテされなくなった公開キーもたくさんあるだろうし、作者以外でも簡単に適用できる何らかの回避方法を用意して、セットで提示するべきだったんじゃないかと思いますねえ。

確かに、命令の追加は全然嬉しいですが、プログラムの書き方を変えるのはよくないですね。新たなプログラムの書き方を追加するならOKですが、書き方の手段を減らされるのはマズイですね。

作っている状況や作る人の好みによっても変わると思いますが、私はエラーありの方が好きです。 必ずOPTIN STRICTする派です。 「楽に作れて後で苦しむ」か「作るときに手間をかけて後で楽をするか」の選択だと思ってます。 (エラーが厳しいのが後者) また、わざわざゲーム内でお知らせを流していた事からも分かるように、途中で仕様変更は相当苦渋の決断だったと思います。 決めた詳しい経緯は分かりませんが、エラーにしないともっと困った事が起こると判断したから、じゃないかなと推察しています。

あ、ただ既にリリースした作品の対応はメチャメチャ大変ですよね………(´Д`) そこは激しく同意です。 自分のはどうだろうと今ﾄﾞｯｷﾄﾞｷしてます………

うーん。本来はこの仕様が普通ですからね。ならば、初期設定はSPHARD 1にしておいたほうがいいですね。

いや、既に配布している作品の為にも初期状態はSPHARD 0がいいですね…。

でも、ACLSでSPHARD 0になるのはやめておきます。

OPTION STRICTで書く人だとスプライトも宣言前に使うっていうのが逆に気持ち悪かったかもしれませんね。

言葉では言い表せない気持ち悪さですか…。プログラムの整列感も大事ですからでしょうかね。インデントみたいな事ですかね。

SPSETを省略出来ることすら知らなかった私が言うのも何ですが、「：」を省略出来るようにしてまで１画面プログラムにこだわりのあるスマイルブームさんが決断したのですから、けいさんの言うように相当の理由があったのではないでしょうか。

ゆうしゃの冒険起動したらエラーになった… (厳密にはデフォルトコーススタートした直後)

私もSPSETを省略できるとは知りませんでしたが、縛りだと思えば楽しいと思いますｗ mark2では省略できませんでしたよね？forループからgotoで抜けちゃいけないみたいな内部的な理由で変わったのかなと思ったのですが、実際どうなんでしょう？

その理由は分かりません。確かにmkiiではSPSET宣言が必須でしたね。でも、個人的には宣言が不要のほうが扱いやすかったですね。

まずSPSETなしでスプライトを操作&表示はできるかって話ですけど。 できたらすみませんw

↑現在のバージョンでは予めSPSETしないと、SPOFS、SPANIMなどが使えません。

以前のSPSETしないでも他の命令が使えるというのがどちらかというとバグだったという話しなので、公式がその認識を早めに通知しておくべきだったんでしょうね〜。そうすれば元からそういう使い方をする人が減ってアップデートでも問題が起こりにくかったような気がしますね。

なぜか知らないけど省略できるから省略するよりは 仕様で保証された通りの安全な実装の方がいいと思いますし 今回の仕様変更は歓迎かな もし問題があるとしたらヘルプとかの使い方が間違ってたりして何が仕様で何がバグなのか手探りだった点ではないかと 公式の命令表や取説だけでもこまめにアップデートかけてほしいですねー この動作は保証外ですとかそういう点も丁寧に記述してくれるとありがたいです

ん？社長のtwitterでの発言は逆のように読めますが… 「大喜利作品でもエラーが出ることを承知の上で、それでも今回の仕様変更に踏み切った」と。 私が社長orウッディーさんのどちらかの意図を取り違えていましたらごめんなさい。m(__)m

>ウッディーさん、なおさん 私も確認してみました。なおさんの書かれてる通りだと思います。 もし今回仕様変更しなかったら、今度は次回の更新で仕様変更するはめになりそうだったから、被害が大きくてもまだ早めの方がマシ、と判断されたようですね。

あ、すみません。コメントの解釈が違っていました。これは本当に申し訳ありませんでした。