Weird error with origins attribute

[PickyPixelStudio]

Hey,

I don't know if i need to report this problem to Origins too, because the script work when i use minecraft's attribute.
But when i try to use PlayerEx attribute, it doesn't.

Got this in log :

[12:31:14] [main/ERROR]: There was a problem reading sub-power "role:berserker/nordicborn_freezedmgresist" in power file "role:berserker/nordicborn": Error reading data field at modifier.attribute: Identifier "playerex:freeze_resistance" was not registered in registry "minecraft:attribute". [12:31:14] [main/ERROR]: There was a problem reading power file role:big_boy (skipping): Error reading data field at modifier.attribute: Identifier "playerex:constitution" was not registered in registry "minecraft:attribute".

I made the exact same script as him

{ "type": "origins:attribute", "modifier": { "attribute": "playerex:constitution", "operation": "addition", "value": 12.0 }, }

Minecraft : 1.19
Fabric : 0.14.8
PlayerEx : 3.3.2
Origins : 1.6.2

PS : I just see a new version of PlayerEx, and th problem is still here.

[CleverNucleus]

Hi there,
I understand what is happening, and why it worked previously. Rest assured you have not done anything incorrectly.

The reason (I suspect) it is not working for PlayerEx attributes is because they are registered when the PlayerEx datapack loads (on world join or on /refresh) and this must be happening after the Origins datapack loads, not before.

I'm hesitant to label this a bug as it's really not - everything from both mods are working as they should, it's just an incompatibility.

I'll look into this further to see if I can fix it from my end first, if not then I will attempt to fix it on Origin's side and make a pull request.
Hope that is helpful,
Thanks for bringing this to my attention.

Edit: I'm going to transfer this issue to Data Attributes, as it is technically the incompatible mod, not PlayerEx.

[CleverNucleus]

Hi there,
Just to provide an update on this issue, for my own sake and others:

1. Issue

When using datapack-loaded attributes provided by Data Attributes (such as from the PlayerEx mod) in Origins' attribute power datapack (i.e. giving an origin bonus attributes - for example playerex:strength), the player cannot join a world and is disconnected as the attributes that Origins is looking for are not yet registered to the game.

Specifically, when Origins searches for, say, playerex:strength in Registry.ATTRIBUTE, it is not present because it has not been loaded by Data Attributes yet.

2. Initial Solution Theory

At first I thought the solution would be to forcefully hardcode Data Attribute's datapack to always be the first one loaded after vanilla packs. The idea was that Data Attribute's would do its thing and register the json attributes to the game, and then Origins would do its thing and by the time it searched for the attributes in the registry, they would be there.

This did not work, and I still do not understand why.

3. Further Solution and Notes

It is important to state that this is not a bug - not with Data Attributes, nor with Origins; both mods are functioning as intended. This is a situational incompatibility between two features of two mods.

Because the solution discussed in (1.) was not fruitful, this leads me to believe that this incompatibility cannot be solved on the end of Data Attributes. Therefore, I endeavoured to fix this issue on the side of Origins and make a merge request once complete. It should be noted at this point that the actual incompatibility seems to be not with Origins itself but with one of its libraries: Apoli.

When I cloned Apoli, I noticed that the repository contains errors in the code. Now, I could just be missing something, perhaps something simple even, but as far as I can tell there are errors in the code, namely here. The static method getFactory of type <T, U> ActionFactory<T> has three parameters:

Type	Label
SerializableDataType<ActionFactory<T>.Instance>	actionDataType
SerializableDataType<ConditionFactory<U>.Instance>	conditionDataType
Function<T, U>	actionToConditionTypeFunction

We see that for the last parameter, the argument passed is t -> t, which does not satisfy the parameter type of Function<T, U>, as no where in the class are <T> and <U> related, extended or similar. Attempting to cast as an Object was unsuccessful, and at this point I gave up.

I know that despite not satisfying simple Java it still works, because decompiling Origins and viewing the Apoli library shows the same code, meaning that it does work in a compiled state, but I am unable to compile it myself nor do I have the time to spend troubleshooting and figuring out what I am missing.

Conclusions

Despite the prospect of a fix looking fairly dire at this point, there is still a relatively simple way to solve this incompatibility that I'm almost certain would be successful - and this was the solution I was aiming to implement myself and then request a merge.

1. All references of the attribute power in Apoli should replace the use of EntityAttribute with either a Supplier (Supplier<EntityAttribute>) or the attribute's identifier, Identifier.
2. The actual use of the EntityAttribute and subsequent application of the attribute modifier should occur after datapack loading is complete, or more specifically, when the user selects their origin and the C2S packet is sent (i.e. when the player is already in the world).

Alternatively, Origins (Apoli) could interop with Data Attributes as a dependency and use its attribute system, but this is unlikely in my experience as a developer. No one wants to use someone else's library/API, especially when it exceeds 100kB and the only purpose to doing so would be to fix an incompatibility that only occurs occasionally.

Therefore, I will leave this issue open as a reminder to myself as well as a place to reference for if and when others encounter the incompatibility - but I myself will put this on hold and I will likely not be providing a fix anytime soon. Origins still works with Data Attributes, it just can't use any of the json attributes (namely from PlayerEx) in its power system.