アツマールとか
もうちょっと内容ごとに日記を小分けしようと思いつつも、
なんだかめんどくさくなってきたのでまとめて更新。
[キャラクターメイク]プラグインはほぼ完成してますが（とはいってもまだちょくちょく最適化してます）、
まだちょっと公開は先になりそうです。
一応、動作確認ついでに久しぶりにプラグインのサンプルゲームを更新したいと思ってます。
今度の公開先はアツマールで。
これで媒体ごとにどんな動作をするか確認できるかと思います。
アツマールに[使われているプラグインランキング]なんて出たんですね。
恐る恐る私のプラグインを検索してみたところ、いくつかヒットしました。
ありがたいことです。
ですが、これはプラグイン名と説明文が一致して、初めて同じプラグインと判定されるみたいです。
私のプラグインの場合、わかりやすいと思って説明文にバージョンを表記しているので、
バージョンごとに別プラグインとしてカウントされちゃってますね。
うーむ、説明文からバージョン表記消すべきなのか・・・
まあ、今更手遅れか・・・
なんだかめんどくさくなってきたのでまとめて更新。
[キャラクターメイク]プラグインはほぼ完成してますが（とはいってもまだちょくちょく最適化してます）、
まだちょっと公開は先になりそうです。
一応、動作確認ついでに久しぶりにプラグインのサンプルゲームを更新したいと思ってます。
今度の公開先はアツマールで。
これで媒体ごとにどんな動作をするか確認できるかと思います。
アツマールに[使われているプラグインランキング]なんて出たんですね。
恐る恐る私のプラグインを検索してみたところ、いくつかヒットしました。
ありがたいことです。
ですが、これはプラグイン名と説明文が一致して、初めて同じプラグインと判定されるみたいです。
私のプラグインの場合、わかりやすいと思って説明文にバージョンを表記しているので、
バージョンごとに別プラグインとしてカウントされちゃってますね。
うーむ、説明文からバージョン表記消すべきなのか・・・
まあ、今更手遅れか・・・
スポンサーサイト
プラグインの更新
下記のプラグインを更新しました。
オリジナルサブメニュー
サブメニューを追加したり削除したり無効化したりする機能を追加しました。
いつものことですが、前バージョンのセーブファイルには対応していません。
プラグインを更新したらニューゲームで始めてください。
オリジナルサブメニュー
サブメニューを追加したり削除したり無効化したりする機能を追加しました。
いつものことですが、前バージョンのセーブファイルには対応していません。
プラグインを更新したらニューゲームで始めてください。
キャラクターメイク進捗状況
先々週スクリーンショット張った時点でもろばれでしたが、
ツクールＭＶ版【キャラクターメイク】プラグイン作ってます。
ようやく色変更できるようになりました。
しかも、細かく色指定ができます。
何気にツクールＭＶのキャラクター生成より高性能！
ただ、やっぱり色変更を行うとグラフィック生成に時間かかりますね。
とりあえず、ブラウザでテストプレイした限り、約１秒といったところ。
とはいっても、顔グラ、歩行グラ、戦闘グラの合計であり、そのうち半分以上が戦闘グラです。
これ以上の軽量化は難しいので、これが許せる人向けですね。
VXAce版も似たようなスクリプトはありましたが、中身はだいぶ違います。
今回はキャラクター生成のみで、名前変更や職業変更などの機能はありません。
まあ、そのあたりは自作していただくということで。
めんどくさいデータベースの設定もありません。
フォルダ内のファイルを自動で読み込んでリストを作るので、
パーツを追加すれば使用できるパーツが増えます。
装備変更によるグラフィック変更には対応予定。
完成度80%といったところですが、肝心のスマホでのテストプレイにまだ手を付けていないので
そこでどれだけ躓くかといったところ・・・
ツクールＭＶ版【キャラクターメイク】プラグイン作ってます。
ようやく色変更できるようになりました。
しかも、細かく色指定ができます。
何気にツクールＭＶのキャラクター生成より高性能！
ただ、やっぱり色変更を行うとグラフィック生成に時間かかりますね。
とりあえず、ブラウザでテストプレイした限り、約１秒といったところ。
とはいっても、顔グラ、歩行グラ、戦闘グラの合計であり、そのうち半分以上が戦闘グラです。
これ以上の軽量化は難しいので、これが許せる人向けですね。
VXAce版も似たようなスクリプトはありましたが、中身はだいぶ違います。
今回はキャラクター生成のみで、名前変更や職業変更などの機能はありません。
まあ、そのあたりは自作していただくということで。
めんどくさいデータベースの設定もありません。
フォルダ内のファイルを自動で読み込んでリストを作るので、
パーツを追加すれば使用できるパーツが増えます。
装備変更によるグラフィック変更には対応予定。
完成度80%といったところですが、肝心のスマホでのテストプレイにまだ手を付けていないので
そこでどれだけ躓くかといったところ・・・
新規プラグインと更新
下記のプラグインを更新しました。
アクティブタイムバトル ATステート
ご報告いただいた不具合を修正しました。
それから新しいプラグインを公開しました。
半透明化ステート
アクティブウィンドウ強調表示
どちらも作成中のプラグインの副産物ですが、なかなか面白いものができたなあと思ってます。
アクティブタイムバトル ATステート
ご報告いただいた不具合を修正しました。
それから新しいプラグインを公開しました。
半透明化ステート
アクティブウィンドウ強調表示
どちらも作成中のプラグインの副産物ですが、なかなか面白いものができたなあと思ってます。
プラグイン更新と競合問題
下記のプラグインを更新しました。
不具合修正
アニメーション画像先読み
他多数
[不具合修正]は新たに見つかった不具合と、入れ忘れてた不具合を追加しました。
[アニメーション画像先読み]は先週の日記に書いた通り、バージョン1.5への対応です。
他多数 と省略されてるものは、後で書く競合問題への対処です。
そういえば先週、バージョン1.5で追加された
「イベント実行時にイベント中に使う画像ファイルを先読み込みする」機能について書きました。
これってよく考えたらちょっとした問題がありますね。
もしも「条件によって表示されるアニメーションまたはピクチャが変わる」ようなイベントを作った場合、
イベント中にあるアニメーション画像またはピクチャ画像を上から順にすべて読み込んでしまいます。
極端に表示が遅くなるようなことはありませんが、
メモリの圧迫や後に使う画像やＳＥ等の読み込み速度低下につながります。
これの回避策はスクリプトを使った直接指定しかないです。
コモンイベントを使っても、コモンイベント先で使う画像も読み込むため、回避策にはなりません。
せめて公式プラグインによる任意で実装にすべきだったんじゃないかなーと思います。
今週スクリプトを作っていて、ふとある競合が発生しました。
私もJavaScriptはMVから触り始めた人間なので、こんな競合が起こるとは思ってもみませんでした。
スクリプトの競合についてのお話なので、スクリプト組んでない方には関係ないお話です。
さて、下記のような二つのプラグインがあったとしましょう。
プラグインA
プラグインB
変数 this._a と this._b は初期化してあるものとします。
ほぼ同じような内容ですが、
プラグインAは問題ないのですがプラグインBは競合が起こる可能性のあるプラグインだったりします。
普段プラグインを作っている方々、プラグインBのダメなところがわかるでしょうか？
では実際動作させた場合どうなるか試してみましょう。
プラグインAを導入した場合、
ウィンドウの update が呼び出されるたびに this._a が+1されます。
問題ありません。
プラグインBを導入した場合、
ヘルプの update が呼び出されるたびに this._b が+1されます。
問題ありません。
プラグインAとプラグインBを導入した場合、
ヘルプの update が呼び出されるたびに this._a と this._b が+1されます。
問題ありません。
では何が問題なのか？
実はプラグインBの後にプラグインAを導入した場合、
ヘルプの update が呼び出されるたびに this._b だけが+1されます。
逆にすると競合が起こるのです。
なぜこんなことが起こるのか？
簡単にまとめるなら、ツクール側のスクリプトに Window_Help.prototype.update が無いからです。
なぜそれがないと競合が起こるのか？
その原因はプラグインBの１行目にあります。
１行目では Window_Help.prototype.update を別の変数に入れてます。
ですが、 Window_Help.prototype.update はないので何が入れられるかというと、
上位クラスである Window_Base の update が変数に入れられます。
ここで呼び出される Window_Base の update は
プラグインAによって再定義される前の update です。
そうなると、プラグインBの _Window_Help_update.call(this) では
プラグインAで再定義される前のものが常に呼び出されることになります。
なので this._a が+1されないわけです。
Rubyでは起こらない競合なので、こんなことが起こりうるとは思ってもみませんでした。
逆にしないと起こらないため、知らないうちに自分が作っているプラグイン同士で競合が起こる
なんてこともあるわけです。
公式が配布しているプラグインではどう対処しているのだろうと思って調べてみたら、
そちらの作者の方々も対処しておらず、プラグインBのような書き方をしてました。
この調子ではほとんどのプラグイン作者が対処していないことでしょう。
ではどのようにスクリプトを組めばいいのか？
普通に上位クラスの update を呼び出すだけでは、
別のプラグインで Window_Help.prototype.update を再定義していた場合、
そのプラグインと競合が起きてしまいます。
そのどちらにも対応するためには、おそらく下記のようにするのが良いかと思われます。
プラグインB
Window_Help.prototype.hasOwnProperty('update') で
Window_Help クラスに update があるかどうかを調べられます。
ある場合は別プラグインで書き換えられた Window_Help.prototype.update を入れて呼び出す、
なければ上位クラスの Window_Base.prototype.update を呼び出す、
これで両方に対応できます。
正直、これはＭＶプラグイン作者にはもっと知られてないとまずいレベルだと思います。
というわけで、心当たりのある方はすぐに対処を！
不具合修正
アニメーション画像先読み
他多数
[不具合修正]は新たに見つかった不具合と、入れ忘れてた不具合を追加しました。
[アニメーション画像先読み]は先週の日記に書いた通り、バージョン1.5への対応です。
他多数 と省略されてるものは、後で書く競合問題への対処です。
そういえば先週、バージョン1.5で追加された
「イベント実行時にイベント中に使う画像ファイルを先読み込みする」機能について書きました。
これってよく考えたらちょっとした問題がありますね。
もしも「条件によって表示されるアニメーションまたはピクチャが変わる」ようなイベントを作った場合、
イベント中にあるアニメーション画像またはピクチャ画像を上から順にすべて読み込んでしまいます。
極端に表示が遅くなるようなことはありませんが、
メモリの圧迫や後に使う画像やＳＥ等の読み込み速度低下につながります。
これの回避策はスクリプトを使った直接指定しかないです。
コモンイベントを使っても、コモンイベント先で使う画像も読み込むため、回避策にはなりません。
せめて公式プラグインによる任意で実装にすべきだったんじゃないかなーと思います。
今週スクリプトを作っていて、ふとある競合が発生しました。
私もJavaScriptはMVから触り始めた人間なので、こんな競合が起こるとは思ってもみませんでした。
スクリプトの競合についてのお話なので、スクリプト組んでない方には関係ないお話です。
さて、下記のような二つのプラグインがあったとしましょう。
プラグインA
var _Window_Base_update = Window_Base.prototype.update;
Window_Base.prototype.update = function() {
_Window_Base_update.call(this);
this._a++;
};
Window_Base.prototype.update = function() {
_Window_Base_update.call(this);
this._a++;
};
プラグインB
var _Window_Help_update = Window_Help.prototype.update;
Window_Help.prototype.update = function() {
_Window_Help_update.call(this);
this._b++;
};
Window_Help.prototype.update = function() {
_Window_Help_update.call(this);
this._b++;
};
変数 this._a と this._b は初期化してあるものとします。
ほぼ同じような内容ですが、
プラグインAは問題ないのですがプラグインBは競合が起こる可能性のあるプラグインだったりします。
普段プラグインを作っている方々、プラグインBのダメなところがわかるでしょうか？
では実際動作させた場合どうなるか試してみましょう。
プラグインAを導入した場合、
ウィンドウの update が呼び出されるたびに this._a が+1されます。
問題ありません。
プラグインBを導入した場合、
ヘルプの update が呼び出されるたびに this._b が+1されます。
問題ありません。
プラグインAとプラグインBを導入した場合、
ヘルプの update が呼び出されるたびに this._a と this._b が+1されます。
問題ありません。
では何が問題なのか？
実はプラグインBの後にプラグインAを導入した場合、
ヘルプの update が呼び出されるたびに this._b だけが+1されます。
逆にすると競合が起こるのです。
なぜこんなことが起こるのか？
簡単にまとめるなら、ツクール側のスクリプトに Window_Help.prototype.update が無いからです。
なぜそれがないと競合が起こるのか？
その原因はプラグインBの１行目にあります。
１行目では Window_Help.prototype.update を別の変数に入れてます。
ですが、 Window_Help.prototype.update はないので何が入れられるかというと、
上位クラスである Window_Base の update が変数に入れられます。
ここで呼び出される Window_Base の update は
プラグインAによって再定義される前の update です。
そうなると、プラグインBの _Window_Help_update.call(this) では
プラグインAで再定義される前のものが常に呼び出されることになります。
なので this._a が+1されないわけです。
Rubyでは起こらない競合なので、こんなことが起こりうるとは思ってもみませんでした。
逆にしないと起こらないため、知らないうちに自分が作っているプラグイン同士で競合が起こる
なんてこともあるわけです。
公式が配布しているプラグインではどう対処しているのだろうと思って調べてみたら、
そちらの作者の方々も対処しておらず、プラグインBのような書き方をしてました。
この調子ではほとんどのプラグイン作者が対処していないことでしょう。
ではどのようにスクリプトを組めばいいのか？
普通に上位クラスの update を呼び出すだけでは、
別のプラグインで Window_Help.prototype.update を再定義していた場合、
そのプラグインと競合が起きてしまいます。
そのどちらにも対応するためには、おそらく下記のようにするのが良いかと思われます。
プラグインB
var _Window_Help_update = null;
if (Window_Help.prototype.hasOwnProperty('update')) {
_Window_Help_update = Window_Help.prototype.update;
}
Window_Help.prototype.update = function() {
if (_Window_Help_update) {
_Window_Help_update.call(this);
} else {
Window_Base.prototype.update.call(this);
}
this._b++;
};
if (Window_Help.prototype.hasOwnProperty('update')) {
_Window_Help_update = Window_Help.prototype.update;
}
Window_Help.prototype.update = function() {
if (_Window_Help_update) {
_Window_Help_update.call(this);
} else {
Window_Base.prototype.update.call(this);
}
this._b++;
};
Window_Help.prototype.hasOwnProperty('update') で
Window_Help クラスに update があるかどうかを調べられます。
ある場合は別プラグインで書き換えられた Window_Help.prototype.update を入れて呼び出す、
なければ上位クラスの Window_Base.prototype.update を呼び出す、
これで両方に対応できます。
正直、これはＭＶプラグイン作者にはもっと知られてないとまずいレベルだと思います。
というわけで、心当たりのある方はすぐに対処を！
製作中のプラグインと1.5のお話
先週には製作中のプラグインのスクリーンショットくらいは出せるかと思ったのに、
エラーに次ぐエラーで起動すら無理でした。
新しい試みをしているとか言っておきながら、エラーのたびにそれを破棄して
さらに別の試みをするといったことを３回くらい繰り返して
ようやく最低限の機能が動くようになったくらいです。
とりあえず、現在出せるスクリーンショットはこれくらい。
詳細はまた今度！（見ればわかるけど・・・
ツクールＭＶのバージョン1.5が公開されました。
画像処理関連で大きな変更があったようです。
場合によっては「画像がうまく表示されなくなった」なんてこともあり得ますので注意しましょう。
私も↑のプラグインで画像表示がおかしくなりました（泣
さて、スクリプト的には画像を扱う ImageManager クラスで大きな変更があったようです。
他もほぼこの変更に合わせての変更ぽいです。
この ImageManager クラス、今までは読み込んだ画像をキャッシュに入れるだけのお仕事でしたが、
今回なにやら reserve やら request といった機能が追加された模様。
まだ詳しくは調べてませんが、見た限り reserve はツバ付け、request は事前読み込みぽいですね。
どうも今回のパッチで、キャッシュに入れておく画像の容量にある程度の上限が設定されたようで、
上限を超えたら古いファイルを削除していく機能が盛り込まれたようです。
で、 reserve は画像に専用のIDをつける機能らしく、
このIDがついた画像は削除されないようにツバ付けするものっぽいです。
request はリクエスト、つまり呼び出された画像を順番に読み込んでいく機能のようです。
あらかじめ画像を読み込んでおくことで、途中で読み込みが発生しないようにするものかと思われ。
（今まではloadを使ってましたが、こっちだと同時に読み込み開始してしまいます）
これを使って、イベント実行時にイベント内で使う画像を先に読み込む機能も追加されてます。
実は私も「アニメーション画像先読み」プラグインでアニメーションのみ同じようなことやってたり。
なので、こちらのプラグインは半分くらい用途を失いました。
まだ戦闘で使うアニメーション画像の先読み機能は実装されていないようなので、
そちらのみに機能を絞ったバージョンも出さないといけませんね。
こちらの機能は公式が実装する可能性は低いでしょう。
というのもこの機能には欠点がありまして、普通にプレイする分には軽量化プラグインになるわけですが、
ある使い方をするとメモリを圧迫してしまいます。
とはいっても、この欠点を知っていてさらにこのプラグインが入っていることを知らなければ
やってみようとは思わないことなので、問題ないはずです。
でも公式は常に最悪のケースを想定しないといけないので実装できない、
私のようなアマチュアだからこそ作れる機能だと思ってます。
他にもBitmapクラスやらSceneManagerクラスでいろいろと変更されてますが、
私にはよくわかってないし、長くなったので今回はここまで。
エラーに次ぐエラーで起動すら無理でした。
新しい試みをしているとか言っておきながら、エラーのたびにそれを破棄して
さらに別の試みをするといったことを３回くらい繰り返して
ようやく最低限の機能が動くようになったくらいです。
とりあえず、現在出せるスクリーンショットはこれくらい。
詳細はまた今度！（見ればわかるけど・・・
ツクールＭＶのバージョン1.5が公開されました。
画像処理関連で大きな変更があったようです。
場合によっては「画像がうまく表示されなくなった」なんてこともあり得ますので注意しましょう。
私も↑のプラグインで画像表示がおかしくなりました（泣
さて、スクリプト的には画像を扱う ImageManager クラスで大きな変更があったようです。
他もほぼこの変更に合わせての変更ぽいです。
この ImageManager クラス、今までは読み込んだ画像をキャッシュに入れるだけのお仕事でしたが、
今回なにやら reserve やら request といった機能が追加された模様。
まだ詳しくは調べてませんが、見た限り reserve はツバ付け、request は事前読み込みぽいですね。
どうも今回のパッチで、キャッシュに入れておく画像の容量にある程度の上限が設定されたようで、
上限を超えたら古いファイルを削除していく機能が盛り込まれたようです。
で、 reserve は画像に専用のIDをつける機能らしく、
このIDがついた画像は削除されないようにツバ付けするものっぽいです。
request はリクエスト、つまり呼び出された画像を順番に読み込んでいく機能のようです。
あらかじめ画像を読み込んでおくことで、途中で読み込みが発生しないようにするものかと思われ。
（今まではloadを使ってましたが、こっちだと同時に読み込み開始してしまいます）
これを使って、イベント実行時にイベント内で使う画像を先に読み込む機能も追加されてます。
実は私も「アニメーション画像先読み」プラグインでアニメーションのみ同じようなことやってたり。
なので、こちらのプラグインは半分くらい用途を失いました。
まだ戦闘で使うアニメーション画像の先読み機能は実装されていないようなので、
そちらのみに機能を絞ったバージョンも出さないといけませんね。
こちらの機能は公式が実装する可能性は低いでしょう。
というのもこの機能には欠点がありまして、普通にプレイする分には軽量化プラグインになるわけですが、
ある使い方をするとメモリを圧迫してしまいます。
とはいっても、この欠点を知っていてさらにこのプラグインが入っていることを知らなければ
やってみようとは思わないことなので、問題ないはずです。
でも公式は常に最悪のケースを想定しないといけないので実装できない、
私のようなアマチュアだからこそ作れる機能だと思ってます。
他にもBitmapクラスやらSceneManagerクラスでいろいろと変更されてますが、
私にはよくわかってないし、長くなったので今回はここまで。
