search

dorianpb / cem

Reimplementation of Custom Entity Models in Minecraft for the Fabric Modloader
GNU Lesser General Public License v3.0
122 stars 38 forks source link

[MISSING] CEM animations - "is_in_water" #37

Open MonsterTrex opened 2 years ago

MonsterTrex commented 2 years ago

I am using the latest version of CEM and the bug related to the CEM animations.

The mod should be detecting when a mob "is_in_water" but the mod never seems to be able to read that information and present it with the rest of the animation when this is put in. The other variable of "is_wet" does work, but obviously when I want to make a swimming animation for a mob, this doesn't suit them when it rains in the game.

I haven't came across any other issues with animations being coded into mobs so far. I will send updates when I do come across any bugs related to this (I am creating an animation resource pack and I wanted this to work through Sodium primarily, which is where this mod is of high value).

Java 17, MC 1.18.1, Windows 10/11

dorianpb commented 2 years ago

is_in_water checks if the entity's hitbox is fully submerged in water.

does it not work when the entity is fully submerged in water?

MonsterTrex commented 2 years ago

Ah I see! Yes that does work! However, that is not how the Optifine code seems to treat that behaviour - Optifine's CEM checks whether or not the entity is touching water at all (rain doesn't count, just water sources and flow blocks).

Is there anyway to maybe apply this behaviour alongside what you currently have? For instance, when the mob is fully submerged - is_in_water - one form of an animation can be triggered, where as when the mob is simply touching a water block (ie. not fully submerged, but floating atop of water like most mobs do when jumping into an ocean to follow you), another animation can be presented.

Bearing this in mind... I had an idea of trying something along the lines of is_in_water>=0.1, but to probably no-one's surprise, that does not work as I assume this is a yes/no sort of value. Following this idea, I tried to potentially combine the idea of is_wet&&!is_on_ground and that does actually work to the criteria of the creature being afloat of water... but this does mean that when a creeper is falling from a block or jumps off from a cliff while it's also raining, he will switch to a swimming animation...

So... any ideas how I could get around this problem? Are there any booleans that could detect rain? I can't find anything related to this. But thankyou for clearing this up to begin with! It'd be useful if there's a way to make the entity recognise rain defined by a separate boolean, that way I could have a "swimming" animation AND a "floating atop water" animation. Any help will be greatly appreciated...

Now to test whether or not Optifine recognises these boolean combinations the same way this mod does...

[edit]: Just tested these booleans within Optifine and they don't seem to like the is_wet&&!is_on_ground combination when put up next to is_in_water boolean... So I'm a bit puzzled at this point what to do as both versions interact differently with the booleans...

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.

dorianpb commented 2 years ago

could you elaborate on the differences between optifine's booleans and this nods booleans? how exactly are they different? I know you mentioned they behave differently but I'm having trouble understanding how... They should behave the same since they check the same attribute on the actual entity

MonsterTrex commented 2 years ago

To make it simple, Optifines CEM implementation of is_in_water checks whether or not the entity is touching a water block (whether that is a source blocks or not), in comparison to your implementation, which checks for if the entity is fully submerged under water.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.

Best-JelloBeanz commented 2 years ago

This sounds like a tough issue to crack, but then again I barely know simple code so everything code related is complicated to me

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.