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

[sovdeeth]

I'm still not a huge fan of having some sources be editable and some not
I'd like some others' opinions on the topic, whether it should be allowed as is or if sources should be only editable upon creation (say, within the exprsec). It would mean the wrapper class wouldn't be needed.

[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?

[APickledWalrus]

I think this is looking really good so far. Here's what I found

[APickledWalrus]

This is looking really good - almost ready for primetime! My comments are mainly formatting suggestions for your convenience 🙂

[APickledWalrus]

Looks great - excellent work! I might like for some of the examples (ex: conditions) to be more detailed (maybe have them send a fun message or something - ideally, they're runnable)