fspace
リアクションスコア
302

タイムライン 新着アクティビティ 投稿 プロフィール

  • Database Cleanup Toolのチュートリアル動画を見ていて誤解する人がいるとヤバそうだなと思ったので注意喚起。

    これを使えばデータの挿入、削除、並び替えがノーリスクでできると思う人がいるかもしれませんが、これはあくまでもそれらを補助してくれるツールであって、どんな場合でも完璧に整合性をとってくれるわけではありません。特にスクリプトやプラグインを多用している場合には、『すべて手動でやるよりはマシ』くらいのものだと思います。

    以下、具体的に対応できない(あるいはできなさそうな)ケースについて。
    fspace
    fspace
    5. スクリプト内にIDを記述している場合

    ごく単純なケースについては対応しているようですが、少し書き方を変えるだけでおそらく検出できなくなります。スクリプトからどのデータが参照されているかを検出するには、データフロー解析と呼ばれるそれなりに高度な解析が必要で、おそらくやっていないと思いますし、やったとしてもあらゆるケースに対応するのは実質不可能です。
    fspace
    fspace
    6. その他対応しているかどうか不明なケース

    単にチュートリアル動画で扱われていなかっただけですが、ダメージ計算式中の変数vの参照や、プラグインパラメータやMZのプラグインコマンドが構造的(選択するとサブウィンドウが開くタイプ)になっているケースに対応しているのかどうかは不明です。そもそもプラグインパラメータやMZのプラグインコマンドは本来自分で設定しなくてもプログラムで解析できるはずなので、このあたりはちょっと手抜きっぽいですね。
    fspace
    fspace
    改めて動画見なおしたら、構造的なプラグインパラメータとMZプラグインコマンドのケースは対応してるっぽいですね。ただ構造的にパラメータ名を指定しないようなので、idみたいな同じ名前で別の種類のデータを参照している構造体が複数存在すると死にそう……。
    粒子系エフェクト実験中 その4
    3d.gif
    • Like
    Reactions: ufo_1122
    fspace
    fspace
    2D版。3Dと比べると重なりづらいのであまり白くならず弱い感じ。パラメータ次第かも
    2d.gif
    粒子系エフェクト実験中 その3
    3d.gif
    fspace
    fspace
    2D版。前回、速度として加えていたノイズを加速度に変えただけなのだけど、こっちは3Dと似た感じになる不思議
    2d.gif
    粒子系エフェクト実験中 その2
    3d.gif
    fspace
    fspace
    ちなみに2D版はこんな感じ。やってることはあまり変わらないはずなのに、崩れ方が中途半端なせいで残念な感じに……
    2d.gif
    粒子系エフェクト実験中(&アニメGIF投稿テスト)
    particle_test.gif
    fspace
    fspace
    動画貼り付けられない上に1.5MB程度の画像もはじかれるのつらすぎる……
    fspace
    fspace
    あと非ログイン時は変換されたサムネイルのみでアニメーションしないっぽいですね
    公式サイトで配布されてるUniteのアドオン軽く見てみたんですが、アドオンというかただのUnityのエディタ拡張ですね、コレ。アドオンの意義とは……。公表されている範囲の仕様を見る限りでは、MV/MZのプラグインの1割も移植できないんじゃないかと予想してたんですが、もしかすると想像以上に酷いのかも。

    あとゲーム中にUniteのロゴ表示必須になってますね。
    プラグインのサブフォルダについてv1.3.2で修正され、既存のプラグインは変更なしでサブフォルダに配置できるようになったみたいです。

    ただし、v1.3.0の挙動(というかバグ)に合わせて対応を行ったプラグインは逆に動かなくなっているので修正が必要です。

    データから修正されなかったのは残念なとこですが、心配していた最悪の方法でもなく、無難な感じの修正になってました。
    先日書いたプラグインのサブフォルダ周りの話、もう少し詳細に書いておいた方がいいんじゃないかと思ったので説明。



    コアスクリプトではプラグイン名は次の二つの用途で使われています。

    1. プラグインファイルの配置場所(パス)の特定
    2. プラグインを一意に識別する識別子

    1はプラグインを読み込むscript要素を生成するのに必要で、2はプラグインが自身のプラグインパラメータを取得したり、プラグインコマンドを設定するのに必要です。2の用途ではプラグイン側が示した識別子とデータ中の識別子の一致が必要なため、プラグインはデータに設定される識別子を予め知っている必要があります。
    • Like
    Reactions: げれげれ
    fspace
    fspace
    なので、それぞれに対応する要素を用意してやればうまくいくはずです。

    変更前:{ "name": "foo/MyPlugin", ... }
    変更後:{ "path": "foo/MyPlugin.js", "id": "MyPlugin", ... }
    fspace
    fspace
    なお、ここで2の用途に関してはプラグインのファイル名を利用する必要は特になく、プラグインファイル内で指定した値を利用した方がファイル名に依存せずに済みます。つまり、プラグインコメントに、

    @pluginid com.example.MyPlugin

    のように書いて、

    { "path": "foo/MyPlugin.js", "id": "com.example.MyPlugin", ... }

    のようにデータを持っていた方がリネームなんかができて便利になります。
    fspace
    fspace
    ちなみに、プラグイン名には上記以外にもうひとつ用途があります。何かと言うと、エディタに表示する際の名前です。一般に、プラグインのファイル名には英語が使われますが、エディタ上の表示まで英語にする必要は特にないので、

    @pluginname オレのプラグイン

    のようにプラグインコメントに書いて表示を変えることも可能だと思います。
    プラグインのサブフォルダ機能、不具合だったのか単なる検討不足だったのかはわかりませんが仕様変更を検討しているみたいです。imgやaudio同様、利用者側が素材を整理するための機能になる模様。

    プラグイン開発者は現在の仕様に無理やり合わせてサブフォルダ対応させると、後で再修正が必要になる可能性があるので注意です。
    fspace
    fspace
    なんだか書いた後で、うなぎおおとろさんのプラグインと同じ方法で対応するんじゃないかと不安になってきた……。

    きちんとデータから、

    { "path": "foo/MyPlugin.js", "id": "MyPlugin", ... }

    みたいな形で修正されてほしいところです。

    欲を言えば、@pluginId com.example.MyPluginみたいな感じでIDの指定もさせてほしい。
    • Like
    Reactions: panda
    プラグインのサブフォルダについて実験した結果。

    1. パラメータの取得やプラグインコマンドにはサブフォルダを含めたパスを指定
    2. @base@orderBefore@orderAfterにはサブフォルダを含まないプラグイン名を指定

    1よりプラグインは自身の配置されたサブフォルダを知っている必要があるので、プラグイン利用者がプラグインを整理するための機能ではなさそう。

    一方、2よりサブフォルダで分けてもプラグイン名被りは依然として問題を起こすので、名前空間的に使えるわけでもなさそう。

    イマイチ意図が……。
    @munokura さん

    タイムラインに返信できないのでこちらに。

    今のところMZ用の受付ページはありません。

    大量のMV→MZ変換依頼を請けたくなかったのと、Fsがある程度完成してからにしたかったのとで、先延ばしにし続けてる状態です。そのうち対応するつもりではいますが、今はMVの依頼だけで忙しい(そしてそれ故にFsの製作が進まない……)のでもうちょっと先になりそうです。
    任意のプラグインコマンドの引数に無理やり変数やスイッチの値を指定するプラグイン、ツクールの仕様上あまりうまくやる方法がなくて、つくったものの出来が微妙なのでこっそりと置いときます。今後メンテするかどうかは考え中。


    プラグインコマンドの引数に変数の値を指定するために、スクリプトコマンド経由で呼び出すという話が元々あって、それよりはわかりやすいかと思って書いたんですが、やっぱりプラグインコマンド自体が直接対応するのに比べて無駄な処理が多いんですよね……。
  • ロード中…
  • ロード中…
  • ロード中…
トップ