Dynamic Characters MV + MZ

Right, that’s a tricky one since it basically assumes that the Bitmap is already in memory. Looking at the code… I think the help text may be wrong and it may just work anyway in most cases 😅

I think I misinterpreted how the save file dialogue works when I first implemented this.
I also wasn’t able to test this directly since the engine doesn’t use this function.

If it doesn’t work, what I’d do is something like this:

class Sprite_WindowCharacter extends Sprite_Character {
    initialize(character, x, y) {
        super.initialize(character);
        this.x = x;
        this.y = y;

        // If the positioning is wrong, then change
        // `this.anchor.x` and `this.anchor.y` here.
    }

    updatePosition() { /* Do nothing. */ }
}

Window_Base.prototype.drawActorCharacter = function(actor, x, y) {
    // This (tracking the sprites separately) may be unnecessary.
    let actorSprites = this._actorCharacterSprites;
    if (!actorSprites) actorSprites = this._actorCharacterSprites = [];

    const sprite = new Sprite_WindowCharacter(actor, x, y);
    actorSprites.push(sprite);
    this.addChild(sprite); // Could also be `addChildToBack` and (in MZ) `addInnerChild`, maybe.
};

// This should work for windows that *don't* use `this.contents.clear()`.
// For windows that do, the respective caller has to be hooked to remove the character sprites.

And I think that should basically patch that method to use real, asynchronously-loaded and dynamic character sprites. The downside is that they’ll appear in front of text.

If you tell me which plugins these are that use this function (and if they’re free), then I could look into implementing this workaround into Dynamic Characters as optional feature. No promises on the success though.

Note though that you can already select any number of targets for a single rule and can copy/paste the target list all at once with Ctrl+C/Ctrl+V while “Targets:” is highlighted. Does that work for you?

I’ll hold off on adding wildcards until you reply, since I’d rather avoid adding a feature that may perform quite badly.

Thank you for the praise and consideration ☺️

I hadn’t really thought fully through the combination… but yes, this is feasible, if not quite as flexible as each plugin separately. (You could combine these approaches, of course, also on the same sprite(s).)

I assume you use Pictures for example as Actor talk sprites in cutscenes, and may also have Actors that appear as Events while not in the party?
The latter isn’t supported all that well by Dynamic Characters directly, but a controller that combines them can use the broader Actor condition implementation from Dynamic Pictures and apply them to both…
I should be able to give you a choice on whether to apply a rule to all Characters or only the specified Actors in the party, so that you can still use combined Actor character spritesheets if your Actors don’t appear as Events.

I won’t have to do much testing or new UX design (for the plugin parameters) for this, so I can give you a rough ETA of two weeks. I can’t fully guarantee this estimate due to some life stuff I have going on, but at least from a technical point of view, I don’t expect any obstacles.

I currently don’t have a plugin that adds bitmap composition to side-view battlers. (Dynamic Pictures only works on Sprite_Pictures showing Game_Pictures, usually shown with the “Show Picture…” command.)

The main reason is that the games I’m contributing to don’t use the side-view battle mode. If your game uses a Picture to represent the player character(s) and/or enemy, then Dynamic Pictures would work for that. Otherwise, a plugin layering battler bitmaps is needed.

The cleanest way to tie my plugins together is through their JavaScript APIs. I could make a plugin (at no extra charge) that specifically targets Actors and sets up those rules in both Dynamic Pictures and Dynamic Characters at once. It doesn’t sound like that would fit your use-case, though.