Origins (Fabric)

Origins (Fabric)

Mods
15M Downloads

"replace" in origin_layers JSON not working for base "origin" layer

HatTrkPatrk opened this issue ยท 3 comments

commented

Based on data/origins/origin_layers/origin.json placed into my mod resources with the following contents:

{
	"replace": true,
	"origins": [
		"mymod:origin1",
		"mymod:origin2",
		"mymod:origin3",
		"mymod:origin4"
	]
}

(of course with data/mymod/origins/origin[1-4].json also setup)

The expected behaviour is that the base set of origins ( https://github.com/apace100/origins-fabric/wiki/List-of-origins ) would be removed, and the specified set of origins (mymod:origin1, mymod:origin2, mymod:origin3, mymod:origin4) would be used in the layer instead.

Unfortunately this is not the case. The default origins persist, and the newly-specified ones are just merged in.

[11:18:19] [Render thread/INFO] (Origins) Trying to read layer file: origins:origin
[11:18:19] [Render thread/INFO] (Origins) Trying to read layer file: origins:origin
[11:18:19] [Render thread/INFO] (Origins) Merging origin layer origins:origin
commented

Could this be a result of the files being processed in the wrong order?

Scenario 1: Let's say the data/origins/origin_layers/origin.json for a mod or datapack is processed first

  1. Method apply in io.github.apace100.origins.origin.OriginLayers loads the JSON data from the mod
  2. replace is true and therefore existing data is replaced by its declarations (and since the mod is loaded first there is no existing data)
  3. Next the JSON data from origins itself is loaded
  4. replace is false and therefore its data ( https://github.com/apace100/origins-fabric/wiki/List-of-origins ) is merged in

Scenario 2: Let's say the data/origins/origin_layers/origin.json for Origins is processed first

  1. Method apply in io.github.apace100.origins.origin.OriginLayers loads the JSON data from Origins itself ( https://github.com/apace100/origins-fabric/wiki/List-of-origins )
  2. replace is false and therefore its data is merged into existing data (and since it's loaded first there is no existing data)
  3. Next the JSON data from the mod or datapack is loaded
  4. replace is true and therefore existing data is replaced by its declarations

Scenario 1 is the behavior I'm observing.
Scenario 2 is the expected behavior.

commented

Follow-up on this. The behavior seems maddeningly inconsistent, but I can confirm it depends entirely on what order the files are processed in.

I forked the repo and added in some extra verbose logging to see what order the files were being loaded in.
https://gist.github.com/hattrickpatrick/ee16957d6e825c808a2338deb3bb7461

Then I ran tests with the fabric API and my mod's JAR alongside it, and no other mods. The behavior was inconsistent - sometimes it would load my mod's JSON first, others it would load Origins' built-in JSON first.

[13:59:56] [Render thread/INFO]: Trying to read layer file: origins:origin
[13:59:56] [Render thread/INFO]: --------------------------------
[13:59:56] [Render thread/INFO]: {"replace":true,"origins":["mymod:origin1","mymod:origin2","mymod:origin3","mymod:origin4"]}
[13:59:56] [Render thread/INFO]: --------------------------------
[13:59:56] [Render thread/INFO]: replace = true
[13:59:56] [Render thread/INFO]: Trying to read layer file: origins:origin
[13:59:56] [Render thread/INFO]: --------------------------------
[13:59:56] [Render thread/INFO]: {"replace":false,"order":0,"enabled":true,"origins":["origins:arachnid","origins:avian","origins:blazeborn","origins:elytrian","origins:enderian","origins:feline","origins:human","origins:merling","origins:phantom","origins:shulk"],"allow_random":true,"exclude_random":["origins:human"],"allow_random_unchoosable":false}
[13:59:56] [Render thread/INFO]: --------------------------------
[13:59:56] [Render thread/INFO]: replace = false

[14:27:33] [Render thread/INFO]: --------------------------------
[14:27:33] [Render thread/INFO]: {"replace":false,"order":0,"enabled":true,"origins":["origins:arachnid","origins:avian","origins:blazeborn","origins:elytrian","origins:enderian","origins:feline","origins:human","origins:merling","origins:phantom","origins:shulk"],"allow_random":true,"exclude_random":["origins:human"],"allow_random_unchoosable":false}
[14:27:33] [Render thread/INFO]: --------------------------------
[14:27:33] [Render thread/INFO]: replace = false
[14:27:33] [Render thread/INFO]: Trying to read layer file: origins:origin
[14:27:33] [Render thread/INFO]: --------------------------------
[14:27:33] [Render thread/INFO]: {"replace":true,"origins":["mymod:origin1","mymod:origin2","mymod:origin3","mymod:origin4"]}
[14:27:33] [Render thread/INFO]: --------------------------------

[16:07:47] [Render thread/INFO]: --------------------------------
[16:07:47] [Render thread/INFO]: {"replace":false,"order":0,"enabled":true,"origins":["origins:arachnid","origins:avian","origins:blazeborn","origins:elytrian","origins:enderian","origins:feline","origins:human","origins:merling","origins:phantom","origins:shulk"],"allow_random":true,"exclude_random":["origins:human"],"allow_random_unchoosable":false}
[16:07:47] [Render thread/INFO]: --------------------------------
[16:07:47] [Render thread/INFO]: replace = false
[16:07:47] [Render thread/INFO]: Trying to read layer file: origins:origin
[16:07:47] [Render thread/INFO]: --------------------------------
[16:07:47] [Render thread/INFO]: {"replace":true,"origins":["mymod:origin1","mymod:origin2","mymod:origin3","mymod:origin4"]}
[16:07:47] [Render thread/INFO]: --------------------------------
[16:07:47] [Render thread/INFO]: replace = true
commented

Should be fixed with the newest version (1.1.0, released yesterday).
Origin layers now support a loading_priority integer field similar to origin files. If a layer is set to replace, all origins from the same and lower loading priority will become unavailable, but layer files with a higher loading priority with replace set to false will still add to that layer.