Skip to content

feat: add entity explosion resistance option - #1254

Open
Like4Schnitzel wants to merge 2 commits into
FallingColors:mainfrom
Like4Schnitzel:main
Open

feat: add entity explosion resistance option#1254
Like4Schnitzel wants to merge 2 commits into
FallingColors:mainfrom
Like4Schnitzel:main

Conversation

@Like4Schnitzel

Copy link
Copy Markdown

Implements #1253

Since the mod does just spawn regular minecraft explosions I figured the best way to reduce their damage is giving mobs and players resistance. On explosion spawn, it checks the approximate explosion radius for any living entities and gives them resistance at the configured level for 1 tick.

To prevent possible abuse to parry other incoming damage the caster is excluded from this resistance. If somehow other players want to abuse the 1 tick of resistance they configured to get then more power to them. They get invulnerability from the damage anyway.

If the config option isn't set it shouldn't change the behavior of the mod at all compared to how it has been.

@IridescentVoid IridescentVoid left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will argue that this is absolutely not the right approach to balancing explosion. Having a cap on explosion power in the config and fixing/having config for pehkui's explosion scaling would be a lot better.

  • Giving resistance is very abusable: it look like I can have an unbound circle perform microexplosions that overlap my player hitbox to give myself permanent resistance. It is possible to make those explosions entirely harmless, just possibly annoying (which extreme sound muffler + sodium extras fixes).
  • Entity detection is very coarse, with an approximated cuboid size ignoring blocks in the way and, since it is a cuboid, we will always have false positives or false negatives.
  • If we are to limit damage to entities specifically, we should do damage reduction directly in explosion logic, rather than piggybacking off the vanilla effect. This fixes explosion abuse in (1) and allows much finer control of explosion resistance, and fixes the wording akwardness in the config value's label.
    • However, implementing this correctly probably requires a few mixin injects which can be tricky to get right. While doable, limiting explosion power overall is just a cleaner solution since it requires no mixins and no jank.

private int artifactCooldown = DEFAULT_ARTIFACT_COOLDOWN;

@ConfigEntry.Gui.Tooltip
private int entityExplosionResistance = DEFAULT_ENTITY_EXPLOSION_RESISTANCE;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing lang file entries for config options on fabric

builder.pop();

builder.push("Misc");
entityExplosionResistance = builder.comment("How much entities should resist explosion damage, where the reduction is Value times 20%")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: grammar. also see main comment

Suggested change
entityExplosionResistance = builder.comment("How much entities should resist explosion damage, where the reduction is Value times 20%")
entityExplosionResistance = builder.comment("How much explosion resistance entities should have in 20% increments")

@github-project-automation github-project-automation Bot moved this from 📋 Backlog to 🏗 In progress in Hex Casting Aug 13, 2026
@Like4Schnitzel

Copy link
Copy Markdown
Author

This should be much less clunky now. I am unsure where exactly the helper class should go and how to word the option description but besides that it should be fine?

@object-Object object-Object left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! Thanks for the contribution, but unfortunately I don't think we're interested in this feature as currently implemented - it still seems too invasive, and kind of just fundamentally an unintuitive/janky feature for Hex Casting to support.

Rather than scaling the damage done by explosions, would it be acceptable for your use case to just limit the maximum explosion power? This would be much simpler to implement and maintain - no mixins, just changing two hardcoded 10.0 constants in OpExplode to instead reference a config value.

You might also be interested in this recent change that added the ability to scale pattern media costs via the server config, which will be included in the next release for 1.20.1: #1041

I'd also note that Explosion is far from the most powerful way to deal damage with Hex Casting - for example, Greater Teleport allows you to teleport any non-boss entity into a kill box anywhere in the same dimension, and Impulse allows you to deal unlimited amounts of damage at a linear media cost by accelerating an arrow. Fundamentally, Hex Casting is just a very difficult mod to balance relative to other mods, and doing so is not a primary goal of the project.

Finally, if scaling damage done by Hex Casting's explosions is still the only viable solution for your use case, we encourage you to write a small addon to implement this feature via mixins - we maintain a Hex Casting addon template at https://github.com/FallingColors/hexdummy to make the setup process as easy as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🏗 In progress

Development

Successfully merging this pull request may close these issues.

3 participants