itch.io

In my test, it seemed to play the skill animation and then a miss/evade motion on the target.
I just tried changing Game_Action.prototype.executeDamage instead, but got the the same result.

At least currently, it doesn’t look like something I’d be likely to figure out within an hour, so a ‘true miss’ implementation that doesn’t show the skill animation isn’t something I’ll attempt for now.

The ‘fake’ implementation was easier.

I also made one that reports those zero-damage hits as evaded instead, since it was a one-word difference.

Sounds doable, and like a good small request!

To clarify, which one would you prefer:

• Damaging actions that do 0 damage miss instead (true miss) or
• the target and text/visuals will act like there was a miss (fake miss)?

I haven’t looked at the code yet, so this is just in case either isn’t too complicated for a “sketch plugin”. It could make a difference in terms of side effects (like whether status effects are inflicted).

Please use the Requests and Feedback Thread as needed.

To ask for help with a plugin, please include the plugin name in the thread title, for example “[Picture Tasks] I found a bug!” (without quotes).

You can post plugin requests here. I may make the plugin if I can do so within an hour by hand.

Feel free to post any feedback or comments to existing plugins here if you don’t think they warrant a thread of their own!

No, that’s out of scope for this plugin.

Looking at the engine source, this should be the default behaviour if map and battle music or sounds (respectively) differ, though. It’s possible that another plugin in your project is interfering with that.

Try to deactivate just half of the other plugins.

If that “fixes” it then re-enable just half of those, otherwise disable just the other half. Continue narrowing it down until you’ve found an incompatibility, then see if it works with just that disabled. (Otherwise there are probably multiple incompatible plugins.)

You could also attach a screenshot of the plugin list you’re using and I can make some guesses. If you know a bit of JavaScript, you can also do a global search for TouchInput in your project to see which other plugins manipulate it.

That’s good to hear!

I’ll see to making a stable release when I have some time to. Shouldn’t change anything aside from documentation at this point.

I uploaded a release-candidate version that should be able to fix the flickering issue.
(It’s fine to use this in production, but there’s a possibility I may revise the added feature in a way that requires manual adjustment.)

If you turn on the new “Prevent Battle Flickers?” parameter, this should now prevent screen flickers and flashes. It’s off by default because there could in theory be unintended side-effects.

One caveat that I noticed is that the Actor stance seems to revert to the idle pose while the menu is open (when doing so from a turn-based Troop Page). I’m not sure if that’s intended behaviour that always happens when a blocking Page runs, or if there’s still an unresolved glitch.

I didn’t test with battle background image yet.
(Using the blurred map as background image in battle is managed a bit differently.)

I’ll try this in a few hours, since it’s currently still night here.
Loading the images right as the scene is created should fix it (in theory), as that should normally make SceneManager wait until assets are loaded.

You mean images displayed through “Show Picture”, right? I suspect the problem there may be that a different set of slots is used while the Party is in battle.

These should be displayed as normal within the Scene_Battle running in the background of the menu.
There could be unintended effects if SceneCustomMenu tries to display them too though, like animations being twice as fast.

I gave it a try and didn’t notice any glaring issues as-is: The battlers seem to appear correctly behind the menu and the battle didn’t proceed until the menu was closed. The battle also didn’t restart, as far as I could tell.

The battler sprites flicker for one frame when entering or exiting the menu. I think this is a general issue with Scene_Battle, as I can see it even without Live Menu enabled when exiting the custom menu (if I slow down the frame rate to make it more noticeable).
I’ll see if I can make the Scene_Battle load the current battler sprites once right when it starts, which in theory should fix this in general. That could cause a slight (likely unnoticeable) delay when entering battle otherwise, though, so I’ll make it optional.

You should otherwise be able to use the plugins together without issue already, but do let me know if you notice anything else!

Found it, thanks! (I am embarrassingly unfamiliar with the included DLC 🫥)

I’ll start looking into it, but it’s likely going to take a few days before I report back.

If you point me to the base plugin required by SceneCustomMenu, I’ll do some testing to see how well I can make them work together in battle.

This should now be available in the release candidate (Ver. 1.2.0-RC.1) and requires Dynamic Characters Ver. 1.4+. (It should show a popup once if you try to use this without updating that.)

The feature is practically done, but I didn’t feel like testing it on Halloween, so for now it’s a release candidate that technically could see breaking changes to that feature. I think that’s unlikely, though.

Looking at its source code, I’d say there’s a very good chance it’s fully compatible outside of battle.
Make sure to load SceneCustomMenu after Live Menu and Pause, so that custom tiled backgrounds won’t be hidden behind the live backdrop.

It seems to require a base plugin that I don’t readily have, though, so I can’t actually test this right now.

Inside battles, unfortunately it resets its SceneManager._callCustomMenuFromBattle flag in a way that will glitch out when the battle is used as live background. This is likely patchable on my end, so please let me know if you’d like to open custom menus during battle.
(There could still be other glitches related to not blocking the battle processing in the right place. I’d have to properly test the plugins together to figure that out.)

Alternatively, I could easily add an option to not use a live background if a Scene_Battle is encountered on the scene stack.

Hm… looks like the Itch.io upload now has Steam DRM, which of course then fails to launch because I have “no licenses” there.

Please do tell me if anything I request would be disproportionally much work, though 😋

I can’t easily tell that apart as a user of the plugin in all cases, and some things I’d like to do probably aren’t useful in general. It’s still a bit off, but I’ll likely ask for some advice on customising the plugin for my projects at some point.

Thanks a lot for these fixes and the hotbar improvement!

I hadn’t thought about it, but it would be easy to support editing Character Tags from Dynamic Characters too 🤔 (Dynamic Actors just references the tags from the other plugin.)
I added it to my to-do list.

By “inventories” you mean current equipment, right? The normal party inventory is out of scope for this plugin.

For fusions where one of the Actors disappears, I think the “Add” mode would be more helpful, followed by removing the “Source” Actor.
I’d probably implement “Absorb” so that an equipment isn’t taken at all if the target slot isn’t empty. Maybe “Drain” would be a better name for it.

Runs better than the native version did most times I tried, interestingly enough. Nice work!

Done. (This turned out to be a small and unexpectedly easy patch.)

I missed the first line(s) while copying, sorry. This should be fixed:

// This likely doesn't look great on moving Events!
const phase = (x, y) => (x * 147 + y * 15) % 11 / 5.5 * Math.PI;
TS_Dynamic_Characters.parameters.modifierDefinitions.push(new TS_Dynamic_Characters.ModifierDefinition({
	name: 'bob-and-sway',
	bushDepth: 25, // This (by default) also turns on bush display for tile Events.
	anchorY: 50, // To rotate around the (vertical) centre, not the bottom.

	// Note that using a custom function for any "offset" will turn off offset rounding by default!:

	yOffsetVertical: function (t, { x, y }) {
		// The second argument above is a `Game_CharacterBase` instance, which (among many more) has `x` and `y` properties.
		// `this`, here, is the `ModifierDefinition` instance.
		return -3 * t * Math.sin(phase(x, y) + Graphics.frameCount / 20);
	},

	// You can also write this more concisely, but without `this`:
	angle: (t, { x, y }) => 5 * t * Math.sin(phase(x, y) + Graphics.frameCount / 15),
}));

The phase formula is totally arbitrary, I just wrote something to make it different based on which tile the event sits on. You may want to use a formula that changes much more slowly in space (and also use { _realX: x, _realY: y } instead of { x, y } to get fractional numbers, but that can still look wrong on a looping map sometimes).

You could gift it to me here on itch.io (“Give this Plugin as a gift” checkbox), that’s easier in terms of fees. (Just as disclaimer: This is a special case where I won’t charge any commission fee for establishing compatibility with a paid plugin, since I’m quite interested in supporting this for my plugins myself.)
Just make sure the plugin isn’t obfuscated or such first, please! Wouldn’t want you to spend that for nothing.

You can find private contact details on my support contact page or join my Discord if that’s convenient and DM me there.

I should be able to check whether it’s possible within a day or two, and I suspect I can finish this, if it is reasonably possible, within two or three weeks.

This part here:

@template T 
@typedef {((
    this: ModifierDefinition,
    t: number,
    character: Game_CharacterBase,
) => T) & { [CONSTANT]?: T }} Varying

is probably crashing the plugin when it loads, since it’s just a JSDoc comment (it’s used with other comments to enable type checks in the editor) but the part that makes it a comment is missing here as far as I can tell.

You can remove these lines entirely. The rest should then start working.

Not unless someone buys me the plugin (as it’s paid), but even then I can’t guarantee it. It depends on whether I can reliably check for its custom scene (if it uses one) and somewhat on how that plugin is implemented.

I assume the current issue is that the 3D scene doesn’t become ‘live’ as menu background? If it’s an actual crash, then I might be able to fix that problem from the error message and stack trace alone.

To be honest, it would have been a better idea to adjust the decodeParameters implementation so that you could write those functions directly in “Text” entry mode there in the plugin parameters.

I’ll make a note to do that when possible, will likely have it trigger on values that begin with ( or function. (That will still be precompiled only once then, so no eval overhead.)

Still no ETA for this or characters-on-windows-support, since I’m still not in good shape to code anything complicated, unfortunately.

Sorry for the late response: I was on vacation for a week.

Animated modifiers are not exposed in the plugin parameters, since I felt it was easier to define them in JavaScript. I thought I had published documentation for this, but it looks like I was mistaken… I’ll try to fix that properly when I’m able to.

Let me know whether this is enough for now: In JavaScript, you can call for example

TS_Dynamic_Characters.parameters.modifierDefinitions.push(new TS_Dynamic_Characters.ModifierDefinition({
	name: 'bob-and-sway',
	bushDepth: 25, // This (by default) also turns on bush display for tile Events.
	anchorY: 50, // To rotate around the (vertical) centre, not the bottom.

	// Note that using a custom function for any "offset" will turn off offset rounding by default!:

	/** @type {Varying<number>} */
	yOffsetVertical: function (t, { x, y }) {
		// The second argument above is a `Game_CharacterBase` instance, which (among many more) has `x` and `y` properties.
		// `this`, here, is the `ModifierDefinition` instance.
		return -3 * t * Math.sin(phase(x, y) + Graphics.frameCount / 20);
	},

	// You can also write this more concisely, but without `this`:
	/** @type {Varying<number>} */
	angle: (t, { x, y }) => 5 * t * Math.sin(phase(x, y) + Graphics.frameCount / 15),
}));

to create the bottle animation, where Varying is

/**
 * This is the type definition for modifier varying functions.
 * You can copy it into your own plugin to get type annotations.
 *
 * @template T
 * @typedef {((
 * 	this: ModifierDefinition,
 * 	t: number,
 * 	character: Game_CharacterBase,
 * ) => T) & { [CONSTANT]?: T }} Varying
 */

. This looks complicated, but basically it means is that, in the record you pass into the ModifierDefinition constructor here, you can use either a constant as value for properties where the type is annotated with {Varying<…>} (… is any other type), which is what’s available through the plugin parameters, or you can use a Function (which disables certain optimisations for that modifier, to enable continuous animation).

The first parameter t is how “eased-in” the modifier currently is. The second parameter is the Character (Event, Actor or Vehicle) the modifier is being calculated for. I use only its position above, so I immediately spread it into x and y. Note that the annotations are optional, so just

TS_Dynamic_Characters.parameters.modifierDefinitions.push(new TS_Dynamic_Characters.ModifierDefinition({
	name: 'bob-and-sway',
	bushDepth: 25,
	anchorY: 50,

	// Note that using a custom function for any "offset" will turn off offset rounding by default!:

	yOffsetVertical: function (t, { x, y }) {
		return -3 * t * Math.sin(phase(x, y) + Graphics.frameCount / 20);
	},

	angle: (t, { x, y }) => 5 * t * Math.sin(phase(x, y) + Graphics.frameCount / 15),
}));

in a plugin loaded after Dynamic Characters would have the same effect.

You can find the full list of properties that can be animated this way in ModifierDefinition‘s initialize method. (Their norm is a VaryingDefault.) Note that for tone: ColorTone and blend: BlendColor, you’d have to instantiate those types similarly and use function values as property values there.

You likely won’t find a compatible solution by any other developer then.

Their obfuscation hides the API of their original features, which means nobody else can interface with them with reasonable effort. Your best chance is to ask VisuStella about adding this feature directly or as another plugin.

(This is also why I don’t guarantee compatibility with them for any of my plugins.)

I put this on my plugin idea pile (more like a skill that allows gear swaps while using up a round), but it would probably take quite a while for me to get around to that. Your players can quickly restart the game by pressing F5, if that helps.

I don’t think (un)equipping skills is a vanilla feature. Which plugin are you using for that?

No, that’s not related to this plugin’s function.

This plugin can only cause the menu to run the map or battle scene in the background, and provides an optional alternative pause function to make up for that. In the case of battle scenes, any plugin that allows opening another scene in battle must also make the battle scene resumable (which isn’t trivial, so it’s rarely done. Battle Core VisuStella MZ has this feature I believe, but it’s implemented in a way that causes bad glitches when combined with my plugin here. I’d hook it to provide better support for the combination, but can’t do so due to the obfuscation there).

The most compatible way to implement this would be to add the necessary Window_s and logic directly to the Scene_Battle, but I’m not aware of any plugins that do this.

You can activate it at any time with a(n e.g. “Script” Command) call to TSC_RStick_Mouse.startVirtualInput(). It’s fine to call this every frame.

Similarly, TSC_RStick_Mouse.endVirtualInput() will hide the virtual cursor on the next sprite update, and it’s fine to call that every frame too.

Oh, most likely it gets called before the game state is initialised. I updated it with a more reliable fix for that.

You may also want to check that the current scene isn’t a menu, if the player can open one while the Switch is ON.

Edit: Typos.

I don’t have specific support for that right now, but you can edit new_pollGamepads to add this feature:

Directly above dx = dx * speed;, add the following:

// Edit: Keyboard arrow controls
if ($gameSwitches && $gameSwitches.value(12345)) { // Replace with your Switch ID.
  if (Input.isPressed('left')) dx -= 1;
  if (Input.isPressed('right')) dx += 1;
  if (Input.isPressed('up')) dy -= 1;
  if (Input.isPressed('down')) dy += 1;
}
// End of edit.

This is untested, but I’m confident it’ll work.
(Flipping a sign here or there may be necessary.)

Note that this will use the main directional input to move the cursor, which means the L-stick and D-pad should also work. If you’d like the input to be distinct, I recommend (dynamically, if there’s a collision) binding a custom intent in Input.keyMapper and checking for that in the snippet above instead.

I’ll see what (and when) I can do 🙂

Hopefully it’ll happen within this year still.

I think if it’s about adding an icon next to the cursor, rather than changing the cursor itself, it’s possible to implement that in a clean way here 🤔

I hadn’t really thought about this. I’ll look into it eventually, but one issue is that my pixel- and Command-based hit test is much more expensive in terms of performance than the tile-based lookup that MouseSystemEx does.
That’s fine if the code runs only once per click, but to update the cursor each (interactive) frame, it’s likely a bit too expensive without further optimisation.

I can’t give you an estimate for when this will be available right now. In theory it’s not difficult, but I haven’t been able to work much at all on new plugins or features lately.

I noticed that whether an item is greyed out in the menu doesn’t change as you gain the necessary ingredients from crafting something else. That should probably be fixed.

How much can the information window content be customised?

Please let me know if something like that happens 😅

This plugin here is expected to be a little heavier than my other ones (since its hooks run for each Character and -Sprite), but that still shouldn’t be noticeable unless there are VERY many Events on a Map or you have many rules that target many Events’ base image(s).

Thank you! 😁

That’s not a use of this plugin I had expected, but I suppose making them as robust and unobtrusive as possible is working out well.