Waystones

Waystones

123M Downloads

Unable to make teleports free (config reading still not working?)

BlueRaja opened this issue ยท 5 comments

commented

(moving issue from here since this problem still exists)

Minecraft Version

1.17.1

Mod Loader

Forge

Mod Loader Version

37.0.126

Mod Version

Waystones 8.2.0, Balm 1.8.1

Do you use any performance-enhancing mods (e.g. OptiFine)?

no


Repro steps:

  1. Delete config/waystones-common.toml on both the client and server
  2. Run the server
  3. Change maximumBaseXpCost = 0.0
  4. Restart the server
  5. As client, attempt to teleport

Expected results

Able to teleport even with 0 XP because teleports are free

Actual results

Not able to teleport because buttons are disabled.

2021-11-30_13 22 19

Interestingly, if I make the same change to the client's config/waystones-common.toml, it appears like you can actually teleport:

2021-11-30_13 25 44

However, if you actually click on a teleport, the menu disappears but the player does not teleport. On the server, the console shows

[Server thread/INFO]: Rejected teleport due to missing xp
commented

Fixed in Balm 2.2.0 (Minecraft 1.18) and 1.8.2 (backported to Minecraft 1.17)

commented

I tried forking the repo to fix the issue and send a PR, but apparently @blay09's Github Maven repo can't be accessed by anyone else, making it impossible for Gradle to download the Balm dependency. I tried to get it working using a local file for a few hours, but it seems Maven just doesn't work well for that use-case.

The hilariously hacky workaround to this bug that I've come up with in the meanwhile is:

  1. Use Recaf to edit the .jar file and make maximumBaseXpCost default to 0 (in waystone/config/WaystoneConfigData$XpData)
  2. Have every client set maximumBaseXpCost = 0 in their local config/waystones-common.toml file
commented

I'll have to look into an alternative again.

Er, I may have been too hasty in saying that. I was setting gpr.key to my Github password in gradle.properties, but I just realized it needs to be a Personal Access Token. Setting it to that makes it build correctly.

It's still not running, but this is my first time working on a Minecraft mod and I'm pretty sure the issue is with my local environment.

commented

but apparently @blay09's Github Maven repo can't be accessed by anyone else

Unfortunately this is a GitHub-wide issue that I've only found out about yesterday, I'll have to look into an alternative again.

commented

After some debugging, it appears the issue is that the latest bugfix didn't work.

WaystonesConfig.initialize() calls Balm.getConfig().registerConfig(WaystonesConfigData.class, ...) which sets both the activeConfig (with default values) and syncMessageFactory. Then later when the ModConfigEvent.Loading or ModConfigEvent.Reloading events are called in ForgeBalmConfig.initializeBackingConfig(), both the checks in the above link fail because the syncMessageFactory is set, and the currentServer is not set until after the configs are initially read. Thus we end up with an activeConfig that has default values, even though both configs and configData have the correct config data.

Removing that conditional completely (so that setActiveConfig() is always called) seems to fix the issue with the config files not being read on the server, but the changes are still not propagated to the clients (meaning players still need to edit their configs to match the server's). I haven't figured out why that's happening.