Allow registration of custom attributes onto existing entities.
i509VCB opened this issue ยท 3 comments
This was an API gap I discovered while experimenting with custom entity attributes.
So lets assume we create a new attribute, piercing for example.
So we register it with below code, not much of a challenge to create an entity attribute.
public static final EntityAttribute PIERCING = register("generic.piercing", 5.0D);
private static EntityAttribute register(String path, double maxValue) {
...
So per 1.16 snapshots, entities must now have the attribute registered through the DefaultAttributeRegistry.Builder
. One issue is lets assume I wanted to register the piercing attribute to all entities. So there are two solutions:
A. Use Mixin to add the attribute to all entities. This requires in some cases with modpacks hundreds of exhaustive mixins.
B. Replace every entity's default attribute container with a new one that contains our own attribute as well. This is also exhaustive and not very compatible with other mods who may also want to add their own attributes to entities.
So the solution I see is to allow adding custom entity attributes to the builder. The specifics of this can be a challenge, such as whether we should allow this to be done by entity type, or entity class. Below is two ideas I did think of, but more ideas are welcome
// EntityType based
CreateDefaultAttributesCallback.event(EntityType.CAT).register(builder -> {
builder.add(CustomAttributes.PIERCING, 3.0D);
});
// Entity class based
CreateDefaultAttributesCallback.event(HostileEntity.class).register(builder -> {
builder.add(CustomAttributes.BLUDGEONING).add(CustomAttributes.PIERCING);
});
For classes, for now you can probably mixin to like the static CatEntity.createCatAttributes
etc and call add
on the return value of the method, etc.
Should you do it by entity type, it should be fine too, but it is a bit hard to convert existing default attribute container to a builder.
Yeah that is a bit of a challenge. The big thing is that the entity attributes are initialized during bootstrap, which is before the server entrypoint but after the client entrypoint. And a single mod directly accessing the DefaultAttributeRegistry would load everything before other mods had the chance