Open Parties and Claims

Open Parties and Claims

25M Downloads

Anything wildcard gets broken after installing Eldritch End mod (Fabric 1.20.1)

gamerpotion opened this issue · 7 comments

commented

Hi, we are adding Eldritch End to 8.5.0 release of our pack and noticed the wildcard in config gets broken for OPAC

example:
itemUseProtectionExceptionList = ["minecraft:diamond", "minecraft:experience_bottle", "origins:orb_of_origin", "minecraft:firework_rocket", "waystones:*", "fwaystones:*", "pack_it_up:*", "*guide*", "things:things_almanac", "*book*", "a*tome", "arcanus:*", "immersive_aircraft:*", "usefulbackpacks:*"]

fwaystones:* means any waystone can be used in claims, however with Eldritch End added it stops the wildcard function of OPAC.

We have narrowed it down to Eldritch by disabling bunch of mods and found eldritch was the culprit.

to best replicate this issue, create a fresh Fabric 1.20.1 profile
add:-

  • Eldritch End
  • OPAC
  • Xaeros minimap/worldmap
  • Wraith waystones
    (all latest versions of the mods on 1.20.1 Fabric)

open openpartiesandclaims-server.toml (you may need to create new world)

then change
forcedBlockProtectionExceptionList = ["minecraft:crafting_table"]
into
forcedBlockProtectionExceptionList = ["minecraft:crafting_table", "fwaystones:*"]

then go into singleplayer world.

use the following commands
/openpac-claims admin-mode
/openpac-claims server-claim-mode

then in world map create a claim (it should be red and display as server claim)

then place down a waystone but do not use it yet

use the following commands again to disable the modes
/openpac-claims admin-mode
/openpac-claims server-claim-mode

now try to use a waystone and it will give a message that not usable etc
You can test this with all types of waystones

exit game, disable EE mod, start game again then try to use waystone and it will work as normal. So something is stopping the wildcard function of OPAC

issue was also raised here nvb-uy/Eldritch_End#50
EE dev recommended raising with youselves first since they cant see why this is happening.

commented

I can confirm this. Currently investigating the cause.

commented

Alright, it seems that EE makes ResourceLocation.isValidResourceLocation just always return true, even if there are invalid characters present, so my mod uses a wildcard as a normal resource location, which is completely reasonable.
This is happening because of this dependency mod of EE, which completely breaks the RL path validity check as some sort of compatibility "fix". I assume they want to allow all languages in resource locations but they simply allowed every character:
https://github.com/ChloePrime/AAAParticles/blob/master/common/src/main/java/mod/chloeprime/aaaparticles/mixin/MixinResourceLocation.java

I'll add additional checks for characters used in wildcards to fix this.