crashes with pretty much any of the mods

[youmukonpaku1337]

i removed the threading mods from the list, but it kept crashing until i removed every mod except fabric api and cloth config

[youmukonpaku1337]

no logs because they are pretty much just it crashing with each mod

[KenRouKoro]

If you want to use MCMTCE with Lithium, you need to disable the following in the Lithium configuration file.

mixin.alloc=false
mixin.entity=false
mixin.collections=false
mixin.chunk=false
mixin.ai.pathing=false
mixin.ai.poi.fast_init=false

[KenRouKoro]

For MCMTCE, any logs are helpful, including JVM crash reports.

[KenRouKoro]

Of course some error reports require you to have a basic knowledge of Chinese (

[KenRouKoro]

and does not work with C2ME, please read the README compatibility table carefully.

[youmukonpaku1337]

yes, i have removed lithium, dimthread, c2me, and servercore, still crashes

[youmukonpaku1337]

it says its incompatible with chunky, paradise lost, collective, and cammie's combat tweaks

[KenRouKoro]

Please provide an error log.

[youmukonpaku1337]

okay

[youmukonpaku1337]

give me a second

[youmukonpaku1337]

https://www.toptal.com/developers/hastebin/xahemaziti.sql here is the log

[KenRouKoro]

The logs show that Servercore has a Mixin conflict with MCMTCE in TickEntity. I checked the curseforge page for Servercore, which is an optimization module, and like Lithium, its Mixin is fatal for MCMTCE systems. (Servercore also intercepts Entity tick processing) Please try removing Servercore and retrying.

[youmukonpaku1337]

tried that

[youmukonpaku1337]

it just errors out about another mod

[youmukonpaku1337]

like collective-fabric

[youmukonpaku1337]

then cammie's combat tweaks

[youmukonpaku1337]

then paradise lost (which i really dont want to remove)

[KenRouKoro]

This is why MCMTCE exists. Most modules are not designed to operate in a concurrent environment, and it is normal for errors to occur. To give two examples, AE2 and TECH. the code in AE2 itself is well suited to running concurrently, but the code it uses to determine whether it is in a server environment is implemented by determining whether the current thread is a server thread, but it will only recognise one thread rather than many. MCMTCE determines the thread pool size (i.e. the number of threads) based on the number of CPU cores, and AE2 itself does not recognise this. What I did to fix AE2's compatibility with MCMTCE was to rewrite AE2's server judgement code using Mixin (yes, Mixin can be used for modules and not just Minecraft). Unlike TECH, TECH's cable system does not work in a concurrent environment at all. For its fix, I used Mixin to completely rewrite TECH's cable runtime logic so that its cable system runs in an additional thread, which I call the "Tech cable system daemon thread", using a blocking queue to implement single-threaded logic emulation. In theory, this new system is much better than the original Tech cable system and I am considering submitting it to the Tech project team. The modules that have been fixed are currently on the compatibility list, I can't really guarantee any compatibility with the modules outside the list. Fixing compatibility is actually complicated, as I need to read the source code of the module and determine the fix, while for closed source modules (such as IC2) it is difficult for me to fix compatibility. This would be a very time consuming task. The modules you have mentioned have been documented and will be fixed in the future.

[youmukonpaku1337]

thats great

[StockiesLad]

This is why MCMTCE exists. Most modules are not designed to operate in a concurrent environment, and it is normal for errors to occur. To give two examples, AE2 and TECH. the code in AE2 itself is well suited to running concurrently, but the code it uses to determine whether it is in a server environment is implemented by determining whether the current thread is a server thread, but it will only recognise one thread rather than many. MCMTCE determines the thread pool size (i.e. the number of threads) based on the number of CPU cores, and AE2 itself does not recognise this. What I did to fix AE2's compatibility with MCMTCE was to rewrite AE2's server judgement code using Mixin (yes, Mixin can be used for modules and not just Minecraft). Unlike TECH, TECH's cable system does not work in a concurrent environment at all. For its fix, I used Mixin to completely rewrite TECH's cable runtime logic so that its cable system runs in an additional thread, which I call the "Tech cable system daemon thread", using a blocking queue to implement single-threaded logic emulation. In theory, this new system is much better than the original Tech cable system and I am considering submitting it to the Tech project team. The modules that have been fixed are currently on the compatibility list, I can't really guarantee any compatibility with the modules outside the list. Fixing compatibility is actually complicated, as I need to read the source code of the module and determine the fix, while for closed source modules (such as IC2) it is difficult for me to fix compatibility. This would be a very time consuming task. The modules you have mentioned have been documented and will be fixed in the future.

You could use fernflower/quiltflower decompiler to get access to its source code. Also, brilliant work with the recode of certain modules from other mods.