Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockmap Resource Pack Sound Overrides Not Functioning Correctly #353

Closed
YannDecelle opened this issue Dec 12, 2024 · 4 comments
Closed
Labels
bug fixed will appear in the next release

Comments

@YannDecelle
Copy link

Issue Summary:
Greetings. I am encountering an issue while customizing the mod via a resource pack when running it through the Sinytra connector. Specifically, certain sound overrides in the blockmap do not function as expected.


Details of the Issue:

  1. Resource Pack Sound Override Behavior:

    • The resource pack was created to modify block sounds within the mod. However, certain blocks and block tags are not responding to changes.
  2. Problematic Cases:

    • minecraft:grass_block: Attempts to override the sound for this block are ignored. Despite the changes in the resource pack, the block continues to use the mod's default sound configuration.
    • #minecraft:nylium: Overrides for the tag #minecraft:nylium do not work. However, directly targeting individual blocks within the tag (e.g., minecraft:crimson_nylium) functions as expected.
  3. Observed Behavior:

    • Blocks such as minecraft:grass_block and those within the #minecraft:nylium tag continue to produce the sounds specified by the mod, ignoring customizations defined in the resource pack.
  4. Working Cases:

    • When targeting blocks like minecraft:crimson_nylium directly (not via tag), the sound override behaves as intended.

Environment Information:

  • Mod Loader/Connector: Forge 47.3.12 + Sinytra Connector 1.0.0-beta.46.
  • Customizations: Custom resource pack

Request for Clarification and Assistance:

  • Is this behavior expected when running the mod through the Sinytra connector? Could the connector be interfering with the proper application of resource pack overrides?
  • Are there known limitations or constraints in the blockmap handling for certain blocks or tags (e.g., minecraft:grass_block or #minecraft:nylium)?
  • Is there a workaround or best practice for ensuring that tag-based sound overrides are recognized?

Thank you for your time and expertise. I look forward to your insights on resolving this issue.

@YannDecelle
Copy link
Author

Forgot to mention it does the same for fabric and forge with sinytra, and that both were in 1.20.1
Rolling back to PF 1.9.4 seem to fix the issue.

@Sollace
Copy link
Owner

Sollace commented Dec 12, 2024

Tags have lower priority than specific block ids. So if you have a sound mapping for a tag and a block within that tag, the sound for the named block will be used instead.

I'll have to see how I can possibly fix the overrides issue when it comes to resource packs. I did previously have the built in sounds loaded as a resource pack that people can enable/disable or change the order, but the built-in pack functionality in Quilt is buggy and I've had a lot of issues reported due to it so I've decided to revert back to having the sounds built into the mod instead.

@Sollace
Copy link
Owner

Sollace commented Dec 12, 2024

The load order was reversed (due to a previous issue).

After switching it around to the correct order it's now working correctly, the below resource pack properly changes leaves to wood and grass to stone when placed at the top of the list.

{
    "minecraft:grass_block": "stone",
    "#minecraft:leaves": "wood"
}

Note that what I said before will still apply after the update, so pale oak leaves will still have their own sounds as they specify one that takes precedence over the tag. You'd have to manually redeclare it like this:

{
    "minecraft:grass_block": "stone",
    "#minecraft:leaves": "wood",
    "minecraft:pale_oak_leaves": "wood"
}

@Sollace Sollace added bug fixed will appear in the next release labels Dec 12, 2024
@YannDecelle
Copy link
Author

Great !

Thanks for the fast answer !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fixed will appear in the next release
Projects
None yet
Development

No branches or pull requests

2 participants