Damage Source

[Absolutionism]

Problem

No current support for Damage Sources, including reading and checking data of damage sources, no previous event values for damage sources, and unable to create custom damage sources

Solution

New module for damage sources. Adds expressions and conditions to get/set/check the data of damage sources Updates EffHealth to allow use of custom damage sources DamageSourceWrapper for a continuous data setting of a custom damage source.

Testing Completed

The newly created test file

Supporting Information

Had to add an ignore list in ClassLoaderTest because when loading the DamageSourceWrapper on 1.19.4, was throwing an exception.

---

Completes: none Related: none

[Fusezion]

I'm in agreeance with sovde here, a damage source should only be modifiable via the exprsec as a means to limit ambiguity, unsure how it would allow removal of the wrapper, it's still needed I would assume unless we store custom information onto the event.

[sovdeeth]

I'm in agreeance with sovde here, a damage source should only be modifiable via the exprsec as a means to limit ambiguity, unsure how it would allow removal of the wrapper, it's still needed I would assume unless we store custom information onto the event.

You can just store a builder on the exprsection, yes

[Absolutionism]

You can just store a builder on the exprsection, yes

We would still need the wrapper for a couple of reasons. To even initiate the builder, would need a DamageType, granted that could be mitigated by simply requiring it in the pattern of the ExprSec The Builder doesnt extend DamageSource so it wouldn't be viable for an event-value and the default expression. Another is that with the Builder, there are no getters. So if something is set then there's no way to ensure the finalization is valid. Which the only check needed to be done is to ensure that if causing entity is set, then the direct entity needs to be set, or else get an IllegalArgumentException

I feel the wrapper should be kept, since DamageSource is still experimental, if the API was updated to allow control over more aspects, then the wrapper would be nice to have.

[sovdeeth]

You can just store a builder on the exprsection, yes

We would still need the wrapper for a couple of reasons. To even initiate the builder, would need a DamageType, granted that could be mitigated by simply requiring it in the pattern of the ExprSec The Builder doesnt extend DamageSource so it wouldn't be viable for an event-value and the default expression. Another is that with the Builder, there are no getters. So if something is set then there's no way to ensure the finalization is valid. Which the only check needed to be done is to ensure that if causing entity is set, then the direct entity needs to be set, or else get an IllegalArgumentException

I feel the wrapper should be kept, since DamageSource is still experimental, if the API was updated to allow control over more aspects, then the wrapper would be nice to have.

The event-value thing could be easily done via just building the builder when necessary, but I see your point about future proofing given this api still seems very unfinished.

[Absolutionism]

btw, can you remove the up for debate now?