Describe the bug
Some animated textures have desynched frames that overlap with emissive plugin enabled.

To reproduce
Steps to reproduce the behavior:

1. Enable MoreMcmeta and the emissive plugin
2. Enable an appropriate resource pack with animated textures on items (i.e. soul lanterns)
3. Place the item in a world and watch the animations
4. Disable the emissive plugin and repeat the previous step
5. Notice the difference in animations

Expected behavior
Animated texture frames rendering the same with or without the emissive plugin.

Screenshots or videos
Emissive plugin disabled

Emissive plugin enabled

Which Minecraft versions does this bug affect?
1.20.2

Mod loader
Which mod loaders does this bug affect?

• Forge
• Fabric
  Forge was not tested.

Mods list
What mods are you using?

Resource pack
What resource packs are you using? Please link to them or attach them to this issue.
Spryzeen's Visible souls
https://www.curseforge.com/minecraft/texture-packs/spryzeens-visible-souls
The soul lantern in this pack is the most prevalent example I've seen to demonstrate this issue.

Additional context
I also tested this using shaders with Iris and the results were the same.
Other objects such as sculk shriekers have the same issue with packs that affect them, but were not tested for this submission.
I did this barebones enough to rule out my long list of normal mods and resource packs interfering with my testing.
This problem does not occur when using MoreMcmeta on its own, but the emissive plugin being enabled makes it occur.

This happens because MoreMcmeta controls the animation of the base texture, but not the animation of the overlay when the suffix is .mcmeta. MoreMcmeta updates the animations it controls on every tick to support GUI animations, while vanilla only updates animations on ticks when the player is in the world, which causes them to desynchronize.

I have a fix for it, but I need to test it to make sure there weren't other subtle issues introduced. When it's fixed, you'll need to update MoreMcmeta core, not the emissive plugin, because it's an issue with OptiFine .properties compatibility.

MoreMcmeta core v4.4.3, which contains a fix for this issue, has been released. It will take a few minutes for CurseForge to approve the files. Thanks for reporting; please report any issues you encounter with the new version.

For other people looking at this issue: this fix only applies to OptiFine .properties files. To synchronize overlays that use .moremcmeta files, both the base texture and the overlay need to have their animations defined in .moremcmeta files, not .mcmeta files. OptiFine .properties files are already treated as a special case, meaning a fix like this makes sense so that older packs work out of the box. Since this has always been a requirement for .moremcmeta-based overlays, and adding a special case for this doesn't fit with the MoreMcmeta API's metadata pipeline, the current behavior will not be changed for .moremcmeta files.

Thank you, I just tried it and it's working great so far. 👍

I just found a side effect to that change, specifically full block animation speed.
Testing using this pack: https://www.planetminecraft.com/texture-pack/radiant-pack/

4.4.2 block animation speed

4.4.3 block animation speed

Other textures like lanterns, 2D inventory items, etc. all seem to be working just fine. It's full blocks the gained an animation speed boost.

This pack is using fractional frame times (like the iron block's frame time is 3.3). Only integers are supported; I'm guessing vanilla rounds while MoreMcmeta defaults to 1. I'll need to check vanilla's default behavior to determine whether rounding should be introduced for MoreMcmeta.

It was working fine until the 4.4.3 change to fix the emissive desync.
I'll wait patiently for whatever solution you think works best.

Before 4.4.3, the overlay was using a vanilla animation, so vanilla was converting 3.3 ticks to 3 ticks. With the change in 4.4.3 to make the overlay use a MoreMcmeta animation, MoreMcmeta ignores the fractional value and just uses 1 for the default. It's an existing issue, but it wasn't noticeable until you tried a resource pack with a MoreMcmeta animation that uses fractional frame times.

MoreMcmeta core v4.4.4, which fixes the fractional default frame time issue, has been released. Please report any other issues you encounter in the new version.

Block animation speed seems to be closer to the original, but something is up with the animation frames. The line of "shimmer" that passes over the blocks have a dark-to-light flicker effect on them each frame.

Here's the original 4.4.2 animation (before the 4.4.3 speed-up)

Here's the 4.4.4 animation with the aforementioned artefact.

I noticed this as well, but I saw the flashing on both 4.4.2 and 4.4.4, so I assumed that was intended. I'll need to take a closer look if you aren't seeing it on 4.4.2. I think the effect can be disabled by turning off interpolation.

Do you see the flashing effect when you remove Sodium and other mods on 4.4.2? Sodium does make changes to vanilla animations, so I'm curious if whatever they're doing is related. If that's the case, then it's a discrepancy between Sodium and vanilla animations, rather than an issue with MoreMcmeta.

I have a feeling Sodium and vanilla handle animation transparency differently. By default, the way vanilla handles transparency in animations is kind of wonky, and you can see artifacts like this. MoreMcmeta matches vanilla's method unless you enable smoothAlpha and/or translucent overlay transparency to fix it. Perhaps Sodium's implemention fixes the issue by default.

I think you're right about Sodium/Indium/etc. likely being the reason for the change on my end. I just did some testing of 4.4.2 and 4.4.4 with and without Sodium and its related mods. Here's my results:

4.4.2 without Sodium mods

4.4.2 with Sodium mods

4.4.4 without Sodium mods

4.4.4 with Sodium mods

I can see the flashing behavior on 4.4.2 with just MoreMcmeta and the emissive plugin, but it disappears as soon as I installed Sodium, Indium, and the Fabric API. On 4.4.2, the overlay animation is being controlled by vanilla and not MoreMcmeta, so the flashing behavior seems intended by the author of the resource pack. Sodium appears to be removing interpolation or updating the animations at a lower frequency to improve performance, which causes the flashing effect to not appear.

I was able to stop the flashing by changing the interpolate setting to false in the .mcmeta files for the iron block overlay. If you see the flashing without Sodium on 4.4.2, then MoreMcmeta 4.4.4 is working as intended by matching vanilla behavior.

{
  "animation": {
    "interpolate": false,
    "frametime": 3.3
  }
}

Thanks for confirming. I tested different animation settings, and it seems like Sodium/Indium/Fabric API aren't respecting the interpolate parameter for this animation. I'm not sure why because the interpolation for the prismarine texture still appears to be working. It looks like Sodium re-implements vanilla animations, so I'm assuming it's Sodium. In any case, this wouldn't be considered an issue with MoreMcmeta because it's behaving as the pack author intended.