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.
