RandomMcSomethin / fallingleaves

MIT License
43 stars 20 forks source link

[Suggestion]: Sync wind direction with WilderWild #65

Open vico93 opened 5 months ago

vico93 commented 5 months ago

Recently, WilderWild (MR) added a interesting wind feature that will orient both wind particles and tumbleweeds direction, and since FallingLeaves also have an wind option i thought if would be possible to FL to orientate its leaves particles accordingly to WW wind (if installed, of course).

According to Lunade (that implemented this feature on WW) on FrozenBlock's Discord, he added a mixin for that on WW side, so theorically would be possible to FL pull the information to use on its end.

AViewFromTheTop commented 5 months ago

Wind itself is implemented through FrozenLib, and is just utilized frequently in Wilder Wild.

Fourmisain commented 5 months ago

I tried syncing the wind direction but am not sure if it really makes things better.

Wilder Wild wind seems a lot more subtle than Falling Leaves wind. I compared campfire smoke with some leaves and the smoke is barely affected while the leaves are flying by, which isn't exactly what one would expect. Here's a rough illustration of what I mean: illustration

Needs more testing/comparisons with other particles, I uploaded a test version if you wanna give it a shot.

P.S. Also tried using Wilder Wild wind directly, but it was way too slow even in rain - this can be tweaked of course, but I'm not sure if this approach would really help either.

vico93 commented 5 months ago

WilderWild's wind can be tweaked in config i think. Maybe adding a multiplier to the value read from WW/FrozenLib to make it more stronger in FallingLeaves side?

Fourmisain commented 5 months ago

I mean the values can be tweaked in code just fine, it's not a technical issue, it's a conceptual one. The leaves were always more on the fast moving side by design. Slowing them down doesn't look too great. The smoke just isn't moving that fast, by design, so you'll always have this discrepancy. (And changing the behavior of Wilder Wild is out of question.)

It might also not be an actual issue. I only looked at campfires for a minute and just thought it feels a bit odd. Arguably the screenshot above might not even be that "unrealistic", since leaves can curl and glide even when there's no wind.

So best thing is to just play with it and see how it feels. (And I'm currently not really playing Minecraft, which is why e.g. #49 is still on the waiting list.)

P.S. I just noticed I didn't even put in the wind coefficient which is why all leaves behaved the exact same - that surely added to it feeling odd. Here's an updated test version.

AViewFromTheTop commented 5 months ago

I personally didn’t want to make smoke and whatnot move too fast as there’s not really a simple way to make it spread out, on top of being a large change from Vanilla if I had made it more intense. Leaves moving faster than most other particles makes sense in my opinion. Also, would anyone be able to test this with Wind Charges and the Breeze? It should work out of the box but I just want to see if it realistically works.

Fourmisain commented 5 months ago

I personally didn’t want to make smoke and whatnot move too fast as there’s not really a simple way to make it spread out, on top of being a large change from Vanilla if I had made it more intense.

Yeah, that makes sense, I argued similarly against (fast) moving smoke and fireworks in #20. (Also, I didn't even realize we had a Wilder Wild dev here! 😄)

Also, would anyone be able to test this with Wind Charges and the Breeze? It should work out of the box but I just want to see if it realistically works.

Oh, do Wind Charges change FrozenLib wind? If so, that's super cool! I just tried it a bunch with some leaves and campfires but it didn't seem to have any effect, not any explosive effect that I could notice at least.

P.S. The changes in test version 2 were kinda wrong, the wind coefficient was already accounted for in the original wind speed, so I just reverted that change. Maybe the variance on those per-particle coefficients is too low, need to do some controlled tests.

AViewFromTheTop commented 5 months ago

I forgot to mention, I’m glad wind was moved to FrozenLib long ago because I’m aiming to move wind stuff into a separate mod that will be embedded into Wilder Wild, and still use FrozenLib’s system. Treetrain1 made a Wind Extension class which is how WW controls its specific stuff, and also impacts the main controller in FrozenLib. So regardless, this should work just fine after WW and Wind split into two mods as long as you’re strictly referencing FrozenLib for this. The split will very likely be some time after 1.21 releases, I haven’t started work on it yet.

AViewFromTheTop commented 5 months ago

Also, FrozenLib’s config has an option to turn off Wind client-side while on a server that doesn’t have FrozenLib installed. I’d keep that in mind as well. Do you have these changes on a branch by chance? I’m up to help out with this if possible.

Fourmisain commented 5 months ago

I've put it on the wilderwild branch, the code's very minimal. Note that the thing currently doesn't build without a physical FrozenLib jar. Wanted to depend on it via jitpack, but the build apparently broke over time. For one the jitpack.yml fails due to using an outdated install script, which is a simple fix*, but then it fails due to what looks like some mapping issue with Cloth Config or something...? The exact same happens when I try building it locally (and on GitHub actions as well). Tried to fix the build by downgrading to loom 1.6 ('+' defaults to 1.7-alpha) and updating the mappings but it didn't seem to help.

Wait, maybe it did? The GH action succeeded, so does a local build after running gradle clean build --refresh-dependencies, but the jitpack build still fails because... it doesn't find the build artifact? Hm... not sure how to fix that one.

* Actually, it looks like jitpacks defaults to running sdk install java 21.0.2-open;sdk use java 21.0.2-open now? Maybe the jitpack.yml could actually be deleted, though I guess it's still better to hardcore the Java version.

Fourmisain commented 5 months ago

k, fixed and PR'd.

Except jitpack likes to run into read timeouts right now, which is weird because locally it works just fine. Gonna rerun the build in a few hours.

Aaand I just now realize I could probably have used the modrinth maven thingamajig... Would you look at that, a working build.

AViewFromTheTop commented 5 months ago

I was just about to bring up Modrinth lol

AViewFromTheTop commented 5 months ago

i'm gonna see if i can just do the ww and wind split soon