Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error with IC2 Classic in development environment #7670

Closed
bdew opened this issue Nov 22, 2022 · 1 comment
Closed

Error with IC2 Classic in development environment #7670

bdew opened this issue Nov 22, 2022 · 1 comment

Comments

@bdew
Copy link

bdew commented Nov 22, 2022

Issue description

Looks like IC2C is initializing some cache when client has finished loading and that calls fillItemCategory on Mekanism item that tries to read the max charge from server config which isn't loaded at that point.

As the error says it currently only errors in dev but will be happening in prod in the future.

Also it makes it a pain for me to work on Advanced Generators which has integration with both mods.

	Exception message: java.lang.IllegalStateException: Cannot get config value before config is loaded.
This error is currently only thrown in the development environment, to avoid breaking published mods.
In a future version, this will also throw in the production environment.

Stacktrace:
	at com.google.common.base.Preconditions.checkState(Preconditions.java:502) ~[guava-31.0.1-jre.jar%2398!/:?] {}
	at net.minecraftforge.common.ForgeConfigSpec$ConfigValue.get(ForgeConfigSpec.java:844) ~[forge-1.19.2-43.1.52_mapped_official_1.19.2-recomp.jar%23182%23194!/:?] {re:classloading}
	at mekanism.common.config.value.CachedResolvableConfigValue.get(CachedResolvableConfigValue.java:39) ~[Mekanism-1.19.2-10.3.5.474_mapped_official_1.19.2.jar%23196!/:10.3.5] {re:classloading}
	at mekanism.common.config.value.CachedFloatingLongValue.get(CachedFloatingLongValue.java:17) ~[Mekanism-1.19.2-10.3.5.474_mapped_official_1.19.2.jar%23196!/:10.3.5] {re:classloading}
	at mekanism.common.item.ItemEnergized.fillItemCategory(ItemEnergized.java:66) ~[Mekanism-1.19.2-10.3.5.474_mapped_official_1.19.2.jar%23196!/:10.3.5] {re:classloading}
	at ic2.core.platform.recipes.helpers.ItemStackCache.init(ItemStackCache.java:42) ~[ic2_classic-242942-4060461_mapped_official_1.19.2.jar%23198!/:1.19.2-2.0.1] {re:classloading}
	at ic2.core.IC2.complete(IC2.java:358) ~[ic2_classic-242942-4060461_mapped_official_1.19.2.jar%23198!/:1.19.2-2.0.1] {re:mixin,re:classloading}
	at net.minecraftforge.eventbus.EventBus.doCastFilter(EventBus.java:260) ~[eventbus-6.0.3.jar%23107!/:?] {}
	at net.minecraftforge.eventbus.EventBus.lambda$addListener$11(EventBus.java:252) ~[eventbus-6.0.3.jar%23107!/:?] {}
	at net.minecraftforge.eventbus.EventBus.post(EventBus.java:315) ~[eventbus-6.0.3.jar%23107!/:?] {}
	at net.minecraftforge.eventbus.EventBus.post(EventBus.java:296) ~[eventbus-6.0.3.jar%23107!/:?] {}
	at net.minecraftforge.fml.javafmlmod.FMLModContainer.acceptEvent(FMLModContainer.java:107) ~[javafmllanguage-1.19.2-43.1.52.jar%23184!/:?] {}
	at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$10(ModContainer.java:122) ~[fmlcore-1.19.2-43.1.52.jar%23187!/:?] {}
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?] {}
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?] {}
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?] {}
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?] {}
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?] {}
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] {}
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?] {}

Steps to reproduce

No response

Minecraft version

1.19.2 (Latest)

Forge version

43.1.52

Mekanism version

10.3.5 (Latest)

Other relevant versions

No response

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

https://gist.github.com/bdew/8c7c5a6addce8ea20eeaacae2466842c

@pupnewfster
Copy link
Member

Honestly sort of sounds like IC2C is caching things at a point earlier than it is reasonable to do so. Given for our case it has to do with energy storage values, but I am sure plenty of other mods are also using configs. Though I will look at changing it for the next build when I get around to working on it, as one thing that does somewhat confuse me is I vaguely recall vanilla calling fillItemCategory earlier for clients (which I would presume this would crash on but doesn't), though maybe vanilla stopped doing that sometime recently

pupnewfster added a commit that referenced this issue Dec 23, 2022
…joining world) and use defaults for fillItemCategory config queries before the world is loaded #7670. Also switch creative energy cube default side config to setting nbt in the creative tab instead of changing on place, and improve how the logistical sorter calculates its initial facing to happen before actual placing instead of after
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants