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

Fallback with dynamic binding based on other mapping #1

Open
BlayTheNinth opened this issue May 30, 2024 · 0 comments
Open

Fallback with dynamic binding based on other mapping #1

BlayTheNinth opened this issue May 30, 2024 · 0 comments
Labels
needs discussion This may be considered in the future and I'm open to hear more opinions on this.

Comments

@BlayTheNinth
Copy link
Member

keyCompressOne = Kuma.createKeyMapping(new ResourceLocation(CraftingTweaks.MOD_ID, "compress_one"))
        .withDefault(InputBinding.key(InputConstants.KEY_K, KeyModifiers.of(KeyModifier.CONTROL)))
        .withContext(KeyConflictContext.SCREEN)
        .build();

keyCompressStack = Kuma.createKeyMapping(new ResourceLocation(CraftingTweaks.MOD_ID, "compress_stack"))
        .withDefault(InputBinding.key(InputConstants.KEY_K))
        .withContext(KeyConflictContext.SCREEN)
        .build();

keyCompressAll = Kuma.createKeyMapping(new ResourceLocation(CraftingTweaks.MOD_ID, "compress_all"))
        .withDefault(InputBinding.key(InputConstants.KEY_K, KeyModifiers.of(KeyModifier.SHIFT)))
        .withContext(KeyConflictContext.SCREEN)
        .build();

In this case, I would want compress_one and compress_all to fallback to the mapping from compress_stack + their respective modifiers if they have to be virtual. Otherwise, on Fabric this would currently result in compress_stack being configurable but the others being stuck on K, which would be confusing.

Maybe something like

.withVirtualFallback(() -> keyCompressStack.getBinding().withModifiers(KeyModifiers.of(KeyModifier.SHIFT)))
@BlayTheNinth BlayTheNinth added the needs discussion This may be considered in the future and I'm open to hear more opinions on this. label May 30, 2024
@BlayTheNinth BlayTheNinth moved this to 📝 Planning in Issues Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion This may be considered in the future and I'm open to hear more opinions on this.
Projects
Status: 📝 Planning
Development

No branches or pull requests

1 participant