Diesel tool sounds - First Draft / Feedback desired #5955
Conversation
There was a problem hiding this comment.
First thing, Malk: These sounds are extremely loud and close to the player. I would suggest making the sounds maybe a quarter again as quiet to ensure they're not too disruptive to the player experience.
Second thing: The harvest detection you implemented for the drill/busszaw does not work particularly well between blocks of the same type. When breaking grass blocks just as a test, the drill seemed to keep puttering up and down and not actually hitting a stride and running. Within one block it worked great.
Third thing: All the drill sounds and the saw sounds except for the saw cutting sound great. However, the saw cutting sounds... very electronic? And might be better for the angle grinder only, and have something else for the sawblade. Maybe the sawmill?
There was a problem hiding this comment.
Why have all of this? Why not do something similar to how Once talking with Malk, I think this is probably not reasonable to do.handleTileSound(...) in ClientProxy.java works? That seems like it would both be easier and more effective, though I may be off my rocket and confused here.
made buzzsaw harvest sound depending on the installed saw blade gave previous buzzsaw harvest sound to grinder/rockcutter blades copied saw_full.ogg for the regular saw blade as a temporary placeholder
…s sound less like *checks notes* "cranking a mower" :D
|
to First: I put in a (hopefully temporary) static for you to control all the sounds volume with. I recon it's easier for you guys to adjust the volume until you find something you're comfortable with, then I can adjust the sounds themselves to that level. My original take was "loud noisy tool, use ear defenders when annoyed" to Second: after having cleared up what you mean (sound jumping up and down between quickly digged blocks), I added a fade sound after digging, which does sound much nicer imo. I had already mulled over doing that previously, but originally decided against it, because I wanted to KISS it to not make Blu groan harder than I assume this PR does anyways x) to Third: I agree about the saw. Had a hard time to find a good sound that does not sound "far away with echo, in a factory hall". I hanged it so the sounds depend on the ItemStack, not just the Item when fetched, so now the rockcutter and grinding disk have the grindy sound and the good old saw blade has a copy of the saw mill's saw_full.ogg as a temporary place holder. -> Experimenting, because I initially did not understand your description in "Second" correctly made me find a bug with a double sound when you start digging under specific circumstances, though. Have not nailed it down yet, though. |
some refactoring in NoisyToolSoundGroup corrected sound instance class names from Diesel* to Noisy*
|
fixed the bug ^_^ |
…now item & stack dependent (could lead to switching hand item to differently sounding stack of the same item, but keeping the sounds of the previous item) also makes switching between same-item hand items more distinct
…ther NoisyTool sounds
…em stack (ie. damage/fuel use) ultimatively creates a new ItemStack now it is 14 workarounds in a trench coat removed unnecessary public keywords in INoisyTool removed unnecessary formatter disable
fix: if the ItemStacks are not identical when checked in checkItemValid, but still considered the same, the ItemStack of the sound group updates
|
There's still a bit of the "jumpiness" I mentioned, but you're right that there is a lot less of it and it sounds less annoying. Not sure if there is a good way to fix it, with how the delays between block breaking works. For now, this seems... fine enough? I'll wait for Blu to weigh in on what she thinks about the PR, though. |
|
yea, I can understand that. I'm open to ideas there, but my ideas on "how to do this differently" basically boil down to "extend the digging sound beyond the point where the block breaks to bridge the gap", which probably sounds weird with the block breaking, but the digging sound still going, or "do button press hitscan stuff and check if the player continue digging, if he keeps the button pressed", which could maybe work nicely, but I also am not looking forward to working that into the state machine. And, jumpiness aside, my argument in favor of the current behaviour is "it does tell you clearly when you're digging and when you're not". Maybe the sounds themselves could be addressed to smoothe the jumpiness somewhat. But I'm taking a couple days to cleansy my ears' palate from listening to saw sounds for hours x) |
This works well enough, but it's like 13 workarounds in a trench coat.
I have some thoughts about how to do some things differently, but I figured a) perfect is the enemy of good and b) it's probably a good idea to get some feedback on this to see if just what the PR does is in the right vein
technical feedback of course welcome, too ^^
resolves #3262