Caethyril's MZ Plugins

these are all so great

Hi! :LZSproud:
I'm making animated water with 6 frames, but MZ only allow you to use 3 frames for animated tiles.

I tried using to add Cae_TileAnimExt to add more frames to the tileset, but it doesn't seem to be a feature. It would really appreciate if you implemented it as there are no plugin that work with MZ that lets you do this :0

That would be a lot more work. TileAnimExt just changes how the tile index updates. For what you're asking, I think the plugin would need to load additional tilesheet(s) and either patch MZ's tilemap shader (advanced) or add new child sprites to the tilemap for each one (easier but less efficient).

I have no plans to try either approach, but I notice you've made a thread for it here:

I believe I found a bug with Cae_OnUseEffects.



I have two different skills with the following notetags. Skill A has the first, while Skill B has the latter ->

<target filter: return target !== user && target.hp > 1;>

<target filter: return target !== user && target.mp > 0;>

Skill B will not allow the caster of the skill to be targeted, but it will allow anyone with an MP greater than 0 to be targeted.

Skill A will not allow the caster of the skill to be targeted, but it will allow anyone to be targeted, regardless of their HP total. Even if their HP is NOT greater than 1 (i.e. they have exactly 1 HP), they are still a viable target.


I think, for some reason, "greater than" does not work with HP. Either that, or my brain is exhausted for the day and cannot see why my logic is flawed.

Note: The notetag: <target filter: return target !== user && target.hp !== 1;> DOES work, and will not allow a target that has exactly 1 HP, which is functionally the same as the above target filter for Skill A, provided the skill has a scope of alive allies. Just strange that the "greater than 1" logic won't work.

:kaohi: @Niniann - the problem is that you've used > in these JS tags, which closes the tag early. There is a brief, easy-to-miss warning against this in my plugin's help section, just after the list of available notetags:
As-is, your tags are being interpreted as:

• <target filter: return target !== user && target.hp >
• <target filter: return target !== user && target.mp >

In JavaScript, a number is "truthy" if it's non-zero, so these allow non-user targets with non-zero HP/MP respectively.

Instead, try:

• <target filter: return target !== user && 1 < target.hp;>
• <target filter: return target !== user && 0 < target.mp;>

@caethyril Thank you, as always, for the very informative reply. :)

I should have caught that message in the help section. I did consult the plugin's help, but I admittedly CTRL+F'd right to the target filter section.

Thank you again for taking a look at my message here and helping out. It is greatly appreciated :).

Hello again, caethyril! I am back with another request for assistance :).

My co-dev and I have been working on trying to implement a mechanic for a few days now and we feel like we almost have it, but are stumped at the moment.

Basically, we are making a barrier effect that when it explodes (the State is removed by damage), the barrier plays an animation and deals damage to the enemy that attacked.

We modified one of our custom popup displays in Cae_OnUseEffects to the following code (this popup is for displaying a Weakness text popup on an enemy when it is weak to element 2):

if (this.elements().contains(2) && target.elementRate(2) > 1 || user.elementRate(2) > 1 && target.isStateAffected(160) && value >= target.getStateDisplay(160)) {
return true;
} else {
return false;
}

Everything after the || in the if statement is newly created for this specific mechanic. What this now does is also display a Weakness text popup on an enemy when it attacks a target that has the barrier State (State 160) and the damage they deal is higher than the current total of the barrier (i.e. the barrier would "explode"), if the enemy is weak to element 2 (which is the element type of damage the explosion does).

What the issue we're having is, is that the Weakness text popup is being displayed on the target being attacked, where in this case we want it on the target doing the attacking (and taking the explosion damage it is weak too).

Do you have any ideas on how to make this possible within a custom popup?

I realize it may be asking alot, as it's not a bug with the plugin, just something we are trying to figure out.

For clarity's sake, the barrier effect is being created with the Visustella AntiDmgBarriers plugin, though I don't think it'll be necessary to mess with that in any way. Everything is working except for getting the popup onto the enemy doing the attacking.

Thank you in advance whether you decide to offer assistance or not, your plugin has been incredible for our game and your assistance with using it has been as well.

Cheers :).

Hi again! :kaohi:

Unfortunately that'd require a bit of restructuring for my plugin to handle as-is, because currently it:

1. Only determines custom popup data for 1 target at a time (it's not stored on the battler, ack).
2. Only determines custom popup data for target(s), not the user/subject.

I would consider implementing the barrier explosion as a forced action. That might cause other problems, though, because (for some reason) by default forced actions clear the existing action queues of both the current subject and the new, forced subject. I know that Yanfly's Battle Core for MV implements a forced-action queue to help with that...maybe VisuStella's Battle Core carried that over to MZ?

Thank you for the quick and informative response!

We have attempted to make it work with a forced action, and while that does accomplish what we're trying to do, it comes with the problem of the forced action resets the "time until next action" bar for the battler. Ultimately we decided it's not intuitive (or fun) for the shield explosion to reset an actor's turn bar every time passive explosion damage would occur.

I appreciate the idea though!

Thank you for taking a look at our post here. What we'll probably end up doing is changing the element type of the explosion to a non-elemental damage type so weakness popups won't be applicable and roll with it from there.