Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Hello I'm back lol.

I have a question about actors drawn in windows. In the caution section you warn that  'Window_Base.prototype.drawActorCharacter' won't  be affected. But what is the valid method to draw them? I have a couple of plugins that use drawActorCharacter and I'm not sure what I should be aiming to replace that with.

(1 edit)

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.

(1 edit)

Thanks again!

And the plugins I'm using are Yanfly Save Core and BM MV Shop

(2 edits)

The first link goes to Save Core (YEP), which doesn’t use the problematic method.
(Character sprites for saves work a bit differently and are already supported.)

BM MV Shop does clear the window, so the workaround is a little more involved but still very manageable.

YEP Shop Core appears to be paid, so technically it’s out of scope for free support.
That said, I thought of a way that may just work for all callers of Bitmap.prototype.clear and Bitmap.prototype.clearReact at once a bit earlier. I’ll test that with BM MV Shop and it’s pretty likely it’ll just work with the Yanfly shop plugin too.

I likely won’t have time to implement and test this this week, since I’ll be away over the weekend and a few days into next week. It’s pretty likely I’ll get it done at some point within this month, though.

Thanks a lot for your feedback, it makes development a whole lot easier!

Oh whoops, shop core was a typo (shop on the brain from the second link), save core is what I intended to put there. Sorry about that.

I'm really enjoying the plugin so far, currently using it for dynamic equipment, controlling character expression through switches during cutscenes, and a parallel process for making eyes blink.

I have run into one more piece of trouble, a couple of times the game has run into an error and crashed. I've taken a screenshot of the console when it happened.


I'm having trouble reproducing it reliably, currently my best lead is it happening when a section of tiles is changed using Shaz Tile Changer. Though it's not happening every time, only occassionally. Another detail is that immediately before one of these crashes, a dynamic layer change seems to fail (for example, swapping a piece of equipment but the character sprite doesn't reflect this) and moments later the crash occurs, which as far as I can tell so far seems to happen at the point where the Tile Changer plugin does its thing.

A more vague detail that might help point towards something. I'd managed to catch a save right before one of these and could reproduce it every time i loaded. Disabling the Tile Changer plugin stopped the issue, but when I reenabled it the crash no longer occurred on loading that save.

(3 edits)

It’s because I forgot to break; out of a backwards loop after shortening the array:

grafik.png

Hitting this depends on a bitmap load pending for I suspect at least two frames right before another change, which explains why this was inconsistent and how the tile changer could provoke it (by generating unrelated “network” load or by causing the game to update multiple times in a row to catch up with a short freeze).

I’ll include the fix alongside the target groups later today.

Edit: The fix and target groups are included starting in Ver. 1.3.2-RC.4, which is now online.

(1 edit)

This issue is fixed now also in stable version 1.2.2.

The release candidate contains additional revisions, so the next one will likely be version 1.3.3-RC.5+modifiers due to the patch level increase. Unless I find time to do a stable release directly.

Awesome, thanks!

BM MV Shop-compatibility (i.e. dynamic on-window character sprites) will be delayed a bit. I caught a cold 🤧

(3 edits)

Okay, new plan now that I’m better: First, I’ll work to get the stable release and demo ready and published. (This will catch up documentation with Modifiers, including ones that are animated even while fully applied like this.)

Afterwards, I’ll implement the in-Window sprites and (separately) hopefully also another small feature I had in mind. Note that in-Window Character sprites will most likely not be affected by the new Modifiers, but layer rules will work as normal.