Add an event to modify dimension environment attributes

[Hugman76]

This pull request introduces a new API to facilitate the modification of dimension environment attributes, which are natively immutable.

Rationale

Since the introduction of environment attributes, several use cases have emerged requiring modifications at the dimension level. Currently, applying an attribute across an entire dimension requires iterating through and modifying every individual biome within that dimension using the Biomes Modification API.

This event provides a direct interface for interacting with dimensions attributes. Furthermore, it allows datapack and modpack creators to maintain granular control, as dimension-level modifications are designed with lower priority than biome-specific definitions during attribute evaluation in vanilla.

Usage Example

DimensionEvents.MODIFY_ATTRIBUTES.register((dimension, attributes, registries) -> {
  if (dimension.is(BuiltinDimensionTypes.OVERWORLD)) {
    attributes.set(EnvironmentAttributes.CLOUD_COLOR, PURPLE);
  }
});

[maityyy]

It's a useful API that we should definitely have, but I'm sure all we need is something like EnchantmentEvents or LootTableEvents, copying the Biome Modification API design is completely unnecessary, confuses users and inflates the code base too much

[Hugman76]

Thanks a lot for the feedback @maityyy, I fully agreed with your points and have almost nothing to add really. I've gone back and remade the whole thing from the ground up using events.

I have to note that modifying attributes using ServerLifecycleEvents.SERVER_STARTED seems to only modify dimensions after they've been baked into the levels. I suppose this means at some point the level and dimension are unsynced. This results in this very same event not being able to fetch the modified attributes (as tested in FabricDimensionTest.)

Therefore, I used ServerLifecycleEvents.SERVER_STARTING to fire the attribute modifications.

I've updated the PR's title and description accordingly.

[modmuss50]

Is the stopwatch needed?

[maityyy]

I think not, it's a leftover from the PR author's initial attempt to copy the Biome Modification API design. BMAPI uses Stopwatch probably because of the logic of sorting modifications

[modmuss50]

Yeah, I imagined so. I dont think its really that useful in biome modficiation either tbh.

[modmuss50]

Question: Is this the only use for the dimensionsModified boolean?

[Hugman76]

Yep! This is meant to prevent any accidental double-modification, but that should never occur

[modmuss50]

Question: Is this needed to get the color? If so a game test would likely be better.

[Hugman76]

Yep that's needed. I don't understand how the MODIFY_ATTRIBUTES can be fired in the game test environment though.

[modmuss50]

Stupid such as? Doing this sorting will likely hide mistakes.

[Hugman76]

Leftover from previous iteration. I figured I'd leave this comment from BMAPI since it makes debugging easier if someone messes up badly.

[maityyy]

Logging is not necessary, please remove