I've seen talk around in the Forge discord in the snapshots, but nothing since release, now that we have a finalised outline of what Mojang wanted to implement for this system.
I don't have the time myself to do a PR, but I figured I'd put all my thoughts here in case someone else wanted to, otherwise it'd just get lost in the vast messages of Discord.
The new DamageType system has both pros and cons. Being that it is a data-driven system, we can now tweak damage-related functionality from a datapack, which opens up a few options.
The way in which Mojang went about it however, leaves much to be desired.
So I'm just going to quick-fire off some suggested actions on Forge's behalf.
As for the actual implementation, that can come as a separate PR/issue/something I suppose?
Extensible Enums w/ OOP callback
DamageType has 4 functionality-defining properties. 3 of these are enums. This is problematic for modders for very obvious reasons.
It does however present us with some potential opportunities for modders.
DamageScaling
This is an enum that determines how the damage dealt might scale with the difficulty of the world.
Its options are:
NEVERWHEN_CAUSED_BY_LIVING_NON_PLAYERALWAYS
My suggestions:
- Make DamageScaling extensible.
- Add a callback method in DamageScaling
shouldScale(DamageSource source), and patch/redirect DamageSource#scalesWithDifficulty to use this callback instead of a switch, with defaulted vanilla functionality for the existing options
DamageEffects
This is an enum for the SoundEvent played when the player takes damage. Why it's an enum at all and not just a SoundEvent is baffling.
Its options are:
HURTTHORNSDROWNINGBURNINGPOKINGFREEZING
My suggestions:
- Make DamageEffects extensible.
- Add a callback method in DamageEffects
getHurtSound(DamageSource source), and patch/redirect Player#getHurtSound to use this callback instead of a hardcoded return from DamageEffects#sound, defaulting as a fallback to the original method for vanilla/ease of use
DeathMessageType
This is an enum that determines whether the death message from the attack should be varied based on the context (I.E. if an attack was a mob pushing a player over a cliff, etc)
Its options are:
DEFAULTFALL_VARIANTSINTENTIONAL_GAME_DESIGN
My suggestions:
- Make DeathMessageType extensible.
- Add a callback method in DeathMessageType
@Nullable getCustomDeathMessage(DamageSource source, LivingEntity victim), and patch/inject into the head of DamageSource#getLocalizedDeathMessage calling it, early-returning the method if the returned component is not null.
Forge DamageType tags
Vanilla adds a number of tags for DamageType in DamageTypeTags. They're definitely lacking some flexibility however.
I propose forge adds its own tags, the same as it has for most other tag categories.
My suggestions (with default-included DamageTypes):
- IS_MAGIC (Defaults:
MAGIC, INDIRECT_MAGIC)
- IS_ENVIRONMENT (Defaults:
IN_FIRE, ON_FIRE, LAVA, HOT_FLOOR, DROWN, STARVE, DRY_OUT, FREEZE) (Also maybe? LIGHTNING_BOLT, CACTUS, STALAGMITE)
- IS_PHYSICAL (Defaults:
CACTUS, FALL, FLY_INTO_WALL, SWEET_BERRY_BUSH, STALAGMITE, FALLING_BLOCK, FALLING_ANVIL, FALLING_STALACTITE, STING, MOB_ATTACK, MOB_ATTACK_NO_AGGRO, PLAYER_ATTACK, ARROW, TRIDENT, MOB_PROJECTILE, FIREBALL, UNATTRIBUTED_FIREBALL, WITHER_SKULL, THROWN)
- NO_FLINCH (Defaults: None). Patch out GameRenderer#bobHurt to skip the hurt animation if LocalPlayer#lastDamageSource is tagged with this. This allow for damage sources to inflict damage without flinching the screen (particularly useful for fast-damage)
- IS_TECHNICAL (Defaults:
GENERIC_KILL, OUT_OF_WORLD). A tag to collate the various technical damage types so that they can be checked easily for invulnerability/other purposes
### DamageType IForgeRegistry
Add an IForgeRegistry in ForgeRegistries for DamageTypes in ForgeRegistries, same as was done for BIOMES
That's it. I think
I've seen talk around in the Forge discord in the snapshots, but nothing since release, now that we have a finalised outline of what Mojang wanted to implement for this system.
I don't have the time myself to do a PR, but I figured I'd put all my thoughts here in case someone else wanted to, otherwise it'd just get lost in the vast messages of Discord.
The new DamageType system has both pros and cons. Being that it is a data-driven system, we can now tweak damage-related functionality from a datapack, which opens up a few options.
The way in which Mojang went about it however, leaves much to be desired.
So I'm just going to quick-fire off some suggested actions on Forge's behalf.
As for the actual implementation, that can come as a separate PR/issue/something I suppose?
Extensible Enums w/ OOP callback
DamageType has 4 functionality-defining properties. 3 of these are enums. This is problematic for modders for very obvious reasons.
It does however present us with some potential opportunities for modders.
DamageScaling
This is an enum that determines how the damage dealt might scale with the difficulty of the world.
Its options are:
NEVERWHEN_CAUSED_BY_LIVING_NON_PLAYERALWAYSMy suggestions:
shouldScale(DamageSource source), and patch/redirectDamageSource#scalesWithDifficultyto use this callback instead of a switch, with defaulted vanilla functionality for the existing optionsDamageEffects
This is an enum for the SoundEvent played when the player takes damage. Why it's an enum at all and not just a SoundEvent is baffling.
Its options are:
HURTTHORNSDROWNINGBURNINGPOKINGFREEZINGMy suggestions:
getHurtSound(DamageSource source), and patch/redirectPlayer#getHurtSoundto use this callback instead of a hardcoded return fromDamageEffects#sound, defaulting as a fallback to the original method for vanilla/ease of useDeathMessageType
This is an enum that determines whether the death message from the attack should be varied based on the context (I.E. if an attack was a mob pushing a player over a cliff, etc)
Its options are:
DEFAULTFALL_VARIANTSINTENTIONAL_GAME_DESIGNMy suggestions:
@Nullable getCustomDeathMessage(DamageSource source, LivingEntity victim), and patch/inject into the head ofDamageSource#getLocalizedDeathMessagecalling it, early-returning the method if the returned component is not null.Forge DamageType tags
Vanilla adds a number of tags for DamageType in
DamageTypeTags. They're definitely lacking some flexibility however.I propose forge adds its own tags, the same as it has for most other tag categories.
My suggestions (with default-included DamageTypes):
MAGIC,INDIRECT_MAGIC)IN_FIRE,ON_FIRE,LAVA,HOT_FLOOR,DROWN,STARVE,DRY_OUT,FREEZE) (Also maybe?LIGHTNING_BOLT,CACTUS,STALAGMITE)CACTUS,FALL,FLY_INTO_WALL,SWEET_BERRY_BUSH,STALAGMITE,FALLING_BLOCK,FALLING_ANVIL,FALLING_STALACTITE,STING,MOB_ATTACK,MOB_ATTACK_NO_AGGRO,PLAYER_ATTACK,ARROW, TRIDENT,MOB_PROJECTILE,FIREBALL,UNATTRIBUTED_FIREBALL,WITHER_SKULL,THROWN)GENERIC_KILL,OUT_OF_WORLD). A tag to collate the various technical damage types so that they can be checked easily for invulnerability/other purposes### DamageType IForgeRegistryAdd an IForgeRegistry in ForgeRegistries for DamageTypes in ForgeRegistries, same as was done forBIOMESThat's it. I think