itch.io

For what it’s worth, the build with the PNG included is also live now, since about an hour ago. It says “0.1.3” as version because I mistakenly left the “0” in place from another command yesterday.

I was able to push it with the correct version number just now, so that should update eventually. Edit: Quicker than expected.

I called this one “1.1.3+cursor-image” to distinguish it, but I’ll most likely use plain version numbers for future versions again.

Thanks. I know roughly why this happens: Sprite_Cursor is a Sprite_Picture so that Dynamic Pictures can be used to make it dynamic. It seems that VisuStella Picture Common Events assumes Sprite_Picture appears only under specific circumstances and/or never has a pictureId of 0. (I chose that ID specifically to avoid interference with other plugins, since for example in this case any other would risk turning the cursor into a button.)

Normally this would be easy to figure out and patch, but there are two reasons I don’t provide further support in this case:

• The plugin is not publicly available. I can’t efficiently debug something I don’t have access to.

  Their Terms of Use also explicitly forbid you from sharing it with me, as it has to be repurchased for each developer who works with it separately.

  (It’s fine to (privately) share my plugins within your team freely. I only care about how many entities publish games with them.)

• Second, as you can tell by the <computed> in the stack trace, VisuMZ plugins are obfuscated. That makes it, mildly put, difficult and/or cumbersome for other plugin creators to ensure compatibility.

  (I guess I care too much about providing a good product to do that. The obfuscation also hurts performance of the finished game.)

You’ll have to ask Team VisuStella about it. For what it’s worth, fixing it (assuming it’s the only incompatibility) shouldn’t take them more than ten minutes or so and would improve compatibility of their plugin in general, not just with R-Stick Mouse.

Ah, I forgot to include it in the latest version. There seems to be a delay with build processing in itch.io, so here’s the correct file (which you should save as img/pictures/RStick_Cursor.png):

That doesn’t explain the error you’re seeing, though. Do you have a stack trace? Maybe there’s an incompatibility with another plugin.

Thank you for the praise and patronage, much appreciated 😊

Yes, you can retrieve this info through my plugin’s API.

(() => {

  // Override the updateHelp method for Window_SkillType

  Window_SkillType.prototype.updateHelp = function() {

    const skillTypeId = this.currentExt();  // Get the skill type ID from the command

    const bcd = TS_Battle_Command_Descriptions.parameters.battleCommandDescriptions
        .find(bcd => bcd.skillTypeIds.includes(skillTypeId));

    if (bcd) this._helpWindow.setText(bcd.description);
    else this._helpWindow.setText("");  // Default empty text
  };

})();

I haven’t tested this, but it should work. It’s not necessary to include null/undefined checks for most properties in my plugins since I normalise them to always be populated.

Much appreciated 😊

There is a commented-out debugOnly plugin parameter definition in the source code, below the usual header. You can copy that below the one for slotKeys__ (mind the start of the lines, you’ll have to replace // with *) and set it to OFF.

That said, this will most likely break something and/or introduce glitches in practice. This plugin really doesn’t have enough safeguards to use it in production.

In theory you can adjust the checkStop function to block normal behaviour of the function keys (though I’m not sure you can prevent a reload on F5 that way) and change onKeyUp to check for the function keys instead of the slot keys.

Overall though, this is all unsupported. If you were looking for a quicksave/quickload plugin to use in a released game, I wouldn’t recommend mine unless you can edit it yourself to avoid glitches. I can request a refund in case this isn’t what you were looking for.

Thank you for tagging this piece of art swiftly and accurately – it was hard to miss appearing in every “ai-generated” sub-tag all at once.

I’m also very grateful for learning about the Ink plugin this way, that’s going to save so much work for myself and friends 😁👍

The 'attack' and 'guard' skills can differ depending on the actor. That’s why I didn’t just use 1 and 2 there for their ID.

It’s only an extension point in the engine for plugins though, so you can’t change this in the editor by default. There’s a WeaponSkill.js plugin floating around that makes use of this, for example. (I’d link the original page but I’m not sure where it is from.)

You’re using VisuMZ_1_BattleCore to set up the menu, right?
Due to its obfuscation and lack of public API, I don’t support its custom features directly.

That said, you can load your code as separate plugin after mine, to make it easier to update my code:

'use strict';

// Untested, but very likely to work.
const oldGetActorCommandHelp = TS_Battle_Command_Descriptions.getActorCommandHelp;
TS_Battle_Command_Descriptions.getActorCommandHelp = function (commandData) {
  if (commandData && commandData.symbol === 'singleSkill') {
    const object = $dataSkills[commandData.ext];
    const help = object && object.description;
    if (typeof help === 'string') return help;
  }
  return oldGetActorCommandHelp.apply(this, arguments);
};

You don’t need to look up the _list entry because commandData should be exactly that object already. It’s also a good idea to avoid accessing the window through SceneManager._scene, as another plugin may reuse Window_ActorCommand in a different scene or under a different property name.

Thank you for your patronage and for sharing your issue and solution!

I just read the bug description on your game’s page. Have you used the Event Searcher to ensure the Switch is set only in that one Event?

No, that is not a bug or glitch in RPG Maker. It’s functioning correctly in those regards.

This is most likely a mistake in your own Event scripts (or their activation condition, or the order of Pages in a Map Event), which by its nature can’t be fixed by generic plugins.

Important update:
NW.js versions newer than v0.72.0 may be incompatible with Windows 7 and 8/8.1.
Please see https://support.google.com/chrome/a/answer/7100626 and https://nwjs.io/blog/ for information.

As long as your game doesn’t connect to the Internet, it’s most likely safe to use v0.72.0 of the runtime in order to support these systems. I’ve added this information to the instructions.

Please note that for Linux systems, the most recent runtime without known issues is still recommended.

Important update: I now recommend the 32-bit version of NW.js for Windows.
It’s marginally slower, but has better system compatibility and lower memory requirements than the x64 version.

For Linux, please continue to primarily use the 64-bit version, as not all modern Linux systems still come with the required 32-bit libraries.

Yes, anything that uses “Show Picture…” should work without issue.

If you still notice anything at all that seems amiss, let me know and I’ll look into a fix as soon as possible.

MogHunter’s MenuBackground, VisuMZ CoreEngine’s backgrounds* and SumRndmDde’s Menu Backgrounds are all unaffected by this plugin, as they use different mechanisms to load and display the menu background(s).

* as far as I can tell. The VisuMZ series of plugins is obfuscated, which is why I generally don’t add specific compatibility tweaks for them and don’t guarantee any level of compatibility with them in particular.

Your best bet would be to see if you can implement the background changes with one of those plugins alone, or alternatively to write a small plugin that displays a Picture sprite in the background of menus.

It may also be possible to use my Live Menu and Pause plugin to get the desired effect (as it can keep the map scene active without filter), but this would require at least some Event scripting to show/hide the background and may not always be perfectly in sync.

Your English is fine, perfectly understandable.

It depends on how the other plugin is implemented. If it uses the Sprite_Picture/Game_Picture mechanism to show the image, then it’s most likely compatible, but that’s just one way to display a static background image in a scene.

If the plugin is public and free, feel free to link to where it’s available here and I’ll check. (It’s not a problem if it’s in a different language.)

Currently (as of NW.js 0.88 and 0.89), there seems to be an issue where the process may sporadically not exit at least when playtesting, which prevents further playtests until RPG Maker MV is restarted.

NW.js 0.80 is reported to not have this problem. Certain versions in-between may work fine too - I recommend using the most recent version that is unaffected by this issue.

Thank you for your support!

I’m a bit too busy with other things to make an extensive example project right now, but this functions pretty much exactly like layers in most image editing programs (with “Normal” blend mode).

Just make sure to set the base image that you use in RPG Maker as ‘Targets:’ here and any additional layers as ‘Add Layers:’ and they will show up as long as their condition is fulfilled. (With no further changes, this is always the case for a given rule.)

You can find the equipment conditions in the ‘Actor conditions…’: Flip the filter to ON/true for armour or weapons (if both are ON then both must match!) and add any armours or weapons to ‘armours’ or ‘weapons’, respectively. (You’ll get a picker dialogue for almost everything, so no need to note down ID numbers.)

You can also set conditions based on note tags instead, by creating one in the ‘w/ note tag’ fields instead of specifying individual equipment or types, but generally I think it’s easier to use the picker.

You won’t need anything more for basic dress-up, but for example for hairstyles you can use variables. (Pictures don’t react to Actor tags added through Dynamic Chracters, but you can still use the tag system to show or hide layers dynamically based on other conditions. You can use this if your conversation sprites have different poses that aren’t fully determined by the base image, for example.)

There are a few more features that can save you some work over time, so make sure to explore the available parameters and the hints near the start of each help text as it’s convenient to you.

Thanks for the suggestion! I’ll add a link to the page for convenience.

There ended up being a decent amount of necessary adjustments 😅

It should be working perfectly now, though.
Let me know what you think!

This plugin hasn’t been tested with MV yet, but aside from the plugin command, there’s a good chance it is compatible already.

I’ll likely get around to backporting it soon-ish.

Please don’t stress out over it, but thank you, any amount really helps.

Battler Flipbooks Core can be used for free, so please first make sure it works for what you’d like to use it for. (There is an option to not pay anything after you use the “Download now” button on this page.)

If you’re satisfied, you can use the button again and enter the amount that feels right to you.
If you decide on an amount that would be enough to purchase one of my paid plugins, I recommend making that purchase instead, since that way you’ll get another useful plugin 🙂

(It really is fine to do this, since my compensation doesn’t depend at all on which one you choose if you enter the same amount.)

And just to make sure there’s no misunderstanding: You don’t need a GitHub account to use the template. First click on Battler_Flipbooks_LAYER.js, then on this button above the file content to download it to your computer:

You can then save it in your plugins/ folder and edit it with any plaintext editor if you need to make changes.

Thank you for your purchase! Please let me know how it works for you, especially if there’s anything you think could be improved.

The combined-rules plugin is now available: Dynamic Actors

I admittedly gave you a safe estimate on when I’d get this done, but it also just turned out to be much less work than expected. I guess I can thank past-me for good API design 😅

Enjoy, and let me know if there are any problems or features you’d like to see added.

-whoops, self replied-

I think what you describe is fully supported. I’m still making it a little more versatile than that so it’s useful for many kinds of games, though. (It’s really not much effort at all.)

Rules can influence later rules through the tag system, so it’s pretty easy to set up variations of a rule. You likely will have to use one rule per variation, though, unless you extend the plugins, and if something is at once in front of and behind something else that will need two rules too.
It’s possible to hide the base layer and replace it with a different one, so weight changes and different poses shouldn’t be a problem.

The default character portrait drawn onto the message box and menu unfortunately isn’t affected by my plugins. (It’s not really a Sprite normally, which makes it difficult to work with.)
If you add a (modified) Sprite_Picture sourced from a Game_Picture to the Scene_Status, or to the window directly, that will be affected though! Here’s the one I use in Live Menu and Pause (for the pause screen Picture):

class Sprite_Pause extends Sprite_Picture {
	/** @override */
	initialize() {
		super.initialize(0);
	}

	/** @override */
	picture() {
		return pausePicture;
	}

	/** @override */
	updatePosition() {
		super.updatePosition();
		// Because I don't use the standard Picture container.
		// (See `Spriteset_Base.prototype.createPictures`.)
		this.x += Math.floor((Graphics.width - Graphics.boxWidth) / 2);
		this.y += Math.floor((Graphics.height - Graphics.boxHeight) / 2);
	}
}

pausePicture is just a standard new Game_Picture() that I called .show(…) on to set it up. In theory you can make that a constant in a plugin if there are no changing parameters. The load order doesn’t matter vs. mine, since I hook into the Sprite_Picture and Game_Picture prototypes without changing the instances.

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 should probably mention that here even if it costs me half the sales: Since one week after I published this plugin, there is now official DLC for RPG Maker MZ that has a lot of feature overlap and also covers other actor appearances like side-view sprites.

I haven’t used it and the Steam page doesn’t show the plugin settings, though, so I can’t comment on how easy it is to make use of.

(For anyone stopping by: This was out of genuine concern, but ultimately a non-issue.)

I agree. For now I’ve created it as placeholder file in my project repository, though I’m probably too busy with other things to work on it soon.

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.

I received confirmation (hours ago) that the detection has been removed, so if you get a malware alert from Microsoft Defender, please update its signatures to the newest version.

Windows Defender may detect this (zipped) as Wacatac.B!ml.

This is an extremely common false positive. The !ml suffix stands for “machine learning”, so this is another case of unreliable AI being used 😮‍💨

I’ve already sent in a false-detection report to Microsoft for the file, but processing may take a while as higher priority support is paywalled and unavailable to single users. Update: They took about five hours, that’s okay in my book.

Here’s the (clean) VirusTotal scan of the archive: https://www.virustotal.com/gui/file/400037bcc0578f272a080e8baef5db6885200f561e7a0d728f3b07d8f58a1a95/detection

I was able to publish the example plugin earlier than expected: https://tamschi.itch.io/battler-flipbooks-core/devlog/692886/layer-example-plugin

This is a small script that only shows damage animations, but it can be modified to play animations for other events.

(If this already solves your problem, I would greatly appreciate a small support payment, as creating polished plugins like Battler Flipbooks Core takes a lot of work. Only if you can spare it, of course.)

Hello (and sorry for not replying earlier. I’m currently away from home, so I can’t check back quite as often)!

I’ll try explain it in a way that translates well. My answer also depends on whether you are able to write JavaScript plugins.

This “Core” here takes care of loading, running and displaying animations, but it doesn’t know when to start or shorten animations. At least one “Layer” is needed, which triggers animations based on the flow of battle.
(I broke this into multiple parts to make it more affordable, as for many games, just one or two Layers are needed.)

If you’d like to use a premade Layer (without writing JavaScript), I recommend Occasional Battler Flipbooks in most cases. This Layer allows you to have attack, damage, miss, evade and K.O. animations, among others. It can’t distinguish different attacks or damage types, however. It also can’t use contextual parameters like the damage amount. Please check the video on the page to see if this fits your use-case.

To also (or only) add frame-based entrance and idle animations, I recommend Battler Entrance Flipbooks. This Layer starts a single animation along with the battle and can also delay the start of battle until after the entrance animations.

Layers stack, so if you use both, then “occasional” animations can interrupt the idle animation, which then resumes once the “occasional” animation is over. You can see an example of this in the video for Battler Flipbook Sound Effect Events, which is an “Add-In” that adds sound effects to any Layer. You can keep using the default sound effect system too, of course.

I can’t offer translations for the help text, since I can’t afford a professional translation. Machine translation usually doesn’t work well with this kind of technical text.
However, if it would be helpful, I could try to machine-translate the parameters and their descriptions starting around the end of next week. I would be very thankful if you could point out errors, in that case.

If you know how to write your own plugins in JavaScript, you could also create your own Layer plugin instead of using one of mine.

Layers usually have one parameter where rules are entered, like this:

@base TS_Battler_Flipbooks_Core

@param rules
@text Rules...
@desc Animation rules for actors and enemies. The first full match is used.
@type struct<FlipbooksRule>[]
@default []

(The parameter definition of FlipbooksRule and nested structs is included in Battler Flipbooks Core’s source code and must be copied into each Layer.
Most Layers change it somewhat since they have additional conditions or effects.)

Then, in JavaScript, you can parse the parameters and instantiate the runtime like this:

'use strict';

const core = TS_Battler_Flipbooks_Core;

const parameters = PluginManager.parameters(NAME_OF_THE_LAYER_PLUGIN);
core.decodeParameters(parameters);

class MyRule extends core.FlipbooksRule {
    // Custom conditions can be added here.
}

// Hydrate rules from decoded parameter objects:
parameters.rules = parameters.rules.map(dpo => new MyRule(dpo));

// Using a derived runtime with its own name improves error messages:
class MyRuntime extends core.FlipbooksRuntime { }

// Create the runtime instance:
const runtime = new MyRuntime({
    rules: parameters.rules,

    // Other options. I normally have these in parameters, but this are okay defaults:
    enableHomeOverride: false, // Use `true` to use "Home override..." function!

    // These make the Layer work better with some other plugins:
    compatibilityTweaks: true,
    spriteSizeTweak: true,
    spriteSizeTweakUsePoseForPointer: true,
    spriteActorUpdateAppearTweak: true,
    spriteActorUpdateDisappearTweak: true,
});

Then, you can apply the rules at any time (normally in a hook) by calling runtime.apply(battler, {}), which will start applicable animations.

This here is (roughly) what runs the animations in Battler Entrance Flipbooks:

const api = window.MyPlugin = {
    ...core.makeHook(() => api, BattleManager, function setup() {
        const result = api.oldSetup.apply(this, arguments);

        for (const battler of BattleManager.allBattleMembers()) {
            runtime.applyRules(battler, {}); // <- You can pass named parameters here.
        }

        return result;
    }),
};

core.makeHook is a helper function I use to let other plugins easily change my hooks. You can hook an engine function plainly instead like this:

const oldSetup = BattleManager.setup;
BattleManager.setup = function () {
    const result = api.oldSetup.apply(this, arguments);

    for (const battler of BattleManager.allBattleMembers()) {
        runtime.applyRules(battler, {}); // <- You can pass named parameters here.
    }

    return result;
};

(This is quite minimal, but enough to run idle animations. I can make a starter project for layers around the end of next week and upload it here under a permissive license.)

No, keep that. The code just stores the function from before it’s turned off.

This is a general JavaScript thing, if you replace a function you just replace it at that location (‘property’), but the function instance itself can still remain referenced elsewhere if the reference had been copied beforehand.

In this case, the backup reference is stored as PressTurnBattleSystem_removeStatesAuto and .call calls it as if it was a method of the first parameter, with the remaining parameter(s).

Yes, I wrote this so you can place it where you define CheckAllBattlersStates now and it will work. Just replace that entire assignment.

The reason I grabbed the original Game_Battler.prototype.removeStatesAuto there is so that if another plugin hooks that, its logic will still run if this one is applied later. That may avoid compatibility issues in some cases.

The turn end function works perferctly now, thank you!

For the message, it works if you add these two lines (separately) to CheckAllBattlersStates:

BattleManager._logWindow.displayChangedStates($gameTroop.members()[i]);
BattleManager._logWindow.displayChangedStates($gameParty.members()[i]);

If you’d like to simplify CheckAllBattlersStates a bit, this version of it also works:

var PressTurnBattleSystem_removeStatesAuto = Game_Battler.prototype.removeStatesAuto;
function CheckAllBattlersStates() {
    for (const battler of $gameTroop.members().concat($gameParty.members())) {
        for (const state of battler.states()) {
            if (state.autoRemovalTiming === 2) {
                if (battler._stateTurns[state.id] > 0) {
                    battler._stateTurns[state.id]--;
                }
            }
        }
        PressTurnBattleSystem_removeStatesAuto.call(battler, 2);
        BattleManager._logWindow.displayChangedStates(battler);
    }
}

(Feel free to use this with or without giving credit, I really just refactored what you already had for the most part here.)

Right, please don’t overtax yourself on this. In any case: Thank you for fixing this so far!

The timing looks mostly correct now. The turn-end-removal states tick down only on the own teams turn end though.
Having it happen for all battlers on either turn end would be a lot more convenient, since it would allow me to time out the statuses just before the team acts again (like in Shin Megami Tensei: Liberation Dx2).

I can easily fix that on my own end, though, in case you prefer the current behaviour.

Since this is otherwise working now, I noticed another bug (maybe): The state removal message doesn’t appear for turn-end removals. I believe I can messily patch this on my end, but it may be worth looking into solving that more properly, too.