That’s a good idea, but I don’t think I’ll be able to do so before the holidays/new year. For what it’s worth, the risk of incompatibility should be very small:
This plugin installs only transparent hooks, so it doesn’t undo or hide any previous plugin’s features.
It also doesn’t extend any engine classes or instances with new properties, doesn’t call functions with additional arguments or new argument types, and creates no globals other than the TS_Dynamic_Pictures one, so there should be no risk of ‘hard’ collisions.
(I always use a WeakMap to manage instance-attached state.)
As far as interference with this plugin goes, check if the other plugins do any of the following:
- change
Sprite_Picture.prototype.updateBitmap(a lot) - change
Sprite_Picture.prototype.loadBitmap(a lot) - change how
Bitmapinstances are constructed and loaded (a lot)
Dynamic Pictures doesn’t change these directly, but it needs the string from Game_Picture.prototype.name to flow into ImageManager.loadPicture relatively verbatim in cases where you use more than one layer.
It also needs to create a deferred Bitmap and manually put that into 'pending'/'loading' and then 'loaded' state. This should work unless the Bitmap logic is entirely rewritten by another plugin (which I haven’t seen so far).
For example the Yanfly series of plugins is compatible. I assume the VisuStella MZ series is structured somewhat similarly (though of course I can’t check due to the obfuscation there).
If you still notice an incompatibility or any kind of issue, please let me know so that I can fix that for everyone. I’ll keep an eye on my emails over the holidays.