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

[Feature] Allow graceful and dynamic handling of block IDs. #475

Open
4 tasks done
Continous opened this issue Oct 18, 2024 · 2 comments
Open
4 tasks done

[Feature] Allow graceful and dynamic handling of block IDs. #475

Continous opened this issue Oct 18, 2024 · 2 comments
Labels
Status: Backlog Issue/PR is not currently being worked on. Type: Compatibility Issue with compatibility Type: Enhancement A request for a new feature or enhancement to be added.

Comments

@Continous
Copy link

Pre-Request Checklist

  • I have checked that I am on the latest version of Terra.
  • I have searched github for similar features requests, including closed
    ones, and found none.
  • I believe this is within the scope of Terra.
  • This feature request is for all of Terra, and isn't something that
    should be implemented by a pack or addon.

Feature Description

Allow Terra config modpacks to fallback to a valid block when an invalid block is referenced, and/or allow config packs to reference blocks conditionally based on their validity.

What Problem Does This Solve?

Currently, a terra config pack must presume a select set of blocks. If a config is intending to represent a wide breadth of mods, they must either provide a plethora of config variants, or require a user to have the full breadth of mods installed, or worse have the user modify the pack themselves. Otherwise a crash occurs.

A Solution You'd Like

Terra should provide a fallback block parameter for config developers to define a block onto which any failed references can fall back to. Terra should default this to something sensible otherwise (maybe based on vanilla biome tags?)

Additionally, it'd be nice to allow config developers to conditionally refer to blocks within a new BLOCK: context where a fallback and a desired block can both be declared. An example:

- mod:block
- minecraft:block

The given example could also allow a fallback cascade. IE it fails from top to bottom as a list.

Alternative Solutions

  1. Theoretically you could just hardcode a fallback block and call it good. It wouldn't be pretty imo, but it would work.
  2. Allowing pack developers to check if a block is present then leaving it up to them on how to inject the blocks.
  3. Potentially, if config packs could have their own add-on config packs, you could just have each mod have it's own add-on config pack. Though, this doesn't really solve the problem of missing blocks causing crashes.
@Continous Continous added Status: Pending Issue/PR is currently awaiting approval by a moderator. Type: Enhancement A request for a new feature or enhancement to be added. labels Oct 18, 2024
@duplexsystem
Copy link
Member

I discussed this at one point, I think its a great idea, but I dont have the bandwidth to work on it right now.

@Continous
Copy link
Author

I discussed this at one point, I think its a great idea, but I dont have the bandwidth to work on it right now.

That's entirely reasonable. I mostly wanted to submit the issue to keep track of it myself.

@astrsh astrsh added Status: Backlog Issue/PR is not currently being worked on. Type: Compatibility Issue with compatibility and removed Status: Pending Issue/PR is currently awaiting approval by a moderator. labels Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Backlog Issue/PR is not currently being worked on. Type: Compatibility Issue with compatibility Type: Enhancement A request for a new feature or enhancement to be added.
Projects
None yet
Development

No branches or pull requests

3 participants