Open lzlrd opened 2 years ago
This occurs both with the C2ME defaults and my current settings:
# Configuration for async io system
[asyncIO]
# (Default: true) Whether to enable this feature
enabled = true
# (Default: 2) IO worker executor parallelism
serializerParallelism = 2
# Configuration for threaded world generation
[threadedWorldGen]
# (Default: true) Whether to enable this feature
enabled = true
# (Default: 5) World generation worker executor parallelism
parallelism = 4
# (Default: true) Whether to allow feature generation (world decorations like trees, ores and etc.) run in parallel
# (may cause incompatibility with other mods)
allowThreadedFeatures = false
# (Default: false) Whether to allow reducing lock radius
# (may cause incompatibility with other mods)
reduceLockRadius = false
# (Default: false) Whether to enable global BiomeCache to accelerate worldgen
# This increases memory allocation
useGlobalBiomeCache = false
# Configuration for vanilla worldgen optimizations
[vanillaWorldGenOptimizations]
# (Default: true) Whether to enable this feature
# (may cause incompatibility with other mods)
enabled = false
# (Default: true) Whether to enable End BiomeCache to accelerate The End worldgen
# This is included in lithium-fabric
# (may cause incompatibility with other mods)
# INCOMPATIBILITY: Set to false forcefully by: lithium
useEndBiomeCache = false
# Configuration for general optimizations
[generalOptimizations]
# (Default: true) Whether to let async chunk request no longer block server thread
# (may cause incompatibility with other mods)
optimizeAsyncChunkRequest = true
# (Default: -1) Defines which chunk compression should be used
# -1 for Vanilla default (also prevents mixin modifying vanilla default
# from being applied)
# 1 for GZip (RFC1952) (Vanilla compatible)
# 2 for Zlib (RFC1950) (Vanilla default) (Vanilla compatible)
# 3 for Uncompressed (Fastest, but higher disk usage) (Vanilla compatible)
#
# Original chunk data will still readable after modifying this option
# as this option only affects newly stored chunks
# Other values can result in crashes when starting minecraft
# to prevent further damage
#
chunkStreamVersion = 3
# Configuration for no-tick view distance
[noTickViewDistance]
# (Default: false) Weather to enable no-tick view distance
enabled = false
# (Default: 12) Minimum no-tick view distance value
viewDistance = 12
# (Default: 6) No-tick view distance updates per tick
# Lower this for a better latency and higher this for a faster loading
updatesPerTick = 6
# (Default: false) Whether to use compatibility mode to send chunks
# This may fix some mod compatibility issues
# INCOMPATIBILITY: Set to true forcefully by: antixray
compatibilityMode = true
# Configuration for clientside functions
[clientSide]
# Configuration for modifying clientside max view distance
[clientSide.modifyMaxVDConfig]
# (Default: true) Weather to enable c2me clientside features
enabled = false
# (Default: 64) Max render distance allowed in game options
maxViewDistance = 64
I'm pretty sure at least one of your mods are loading minecraft too early. Please try to get a minimum set of mods that can reproduce this error.
Also, I suggest removing cardboard and its dependencies (such as icommon
) before trying to reproduce this issue.
This happens on 1.18 with fabric-loader 0.12.8 and FabricProxy. I built a version of FabricProxy which strips out the only explicit use of an Identifier, but the crash still occurs. C2ME with MixinIdentifier removed from c2me.mixins.json doesn't trigger the crash.
Probably an issue with FabricProxy, but looking through the source code I can't see an obvious culprit.
I'm pretty sure at least one of your mods are loading minecraft too early. Please try to get a minimum set of mods that can reproduce this error. Also, I suggest removing cardboard and its dependencies (such as
icommon
) before trying to reproduce this issue.
It seemed to be an issue with Cardboard, though I can't say for certain as I moved back to Purpur (or well, Pufferfish Purpur). I'll leave this issue open as @sachk seems to also experience this bug, though.
I'm experiencing a server crash with
mc1.17.1-0.2.0+alpha.5.0
that I didn't previously experience onmc1.17.1-0.2.0+alpha.4.0
during Mixin preparation. The "short log", containing just the error is:The complete log, with Mixintrace, is shown below: