BuildCraft
BuildCraft for 1.20.1 Forge
Here is BC for 1.20.1 Forge.
Compared to BC Forge 1.18.2:
- Fixed TESR and GUI of ZonePlanner
- Fixed GUI blueprint tooltip rendering
- Added PowerConvertor block to convert MJ and FE to each other (maybe removed or replaced by another block, I'm not sure)
- Enabled renderLaserStatic and SpriteFluidFrozen
(build.gradle is still hard for me, so... I've not found how to make some code in build.gradle from BC Forge 1.12.2 work in 1.20.1) (Just like 1.18.2, we should add trove4j-3.0.3.jar to classpath to make it loaded although it is a dependency in build.gradle. I'v not found a better way...)
I've created a proper branch for this, but I'm not going to look at this until after Christmas now.
Initial thoughts:
- Trove would best be handled by migrating to
it.unimi.dsi.fastutil, as it has very similar collection classes (but is provided by minecraft). This does require a lot of find-replacing stuff though :/ - I don't really like power convertors, but I'm unsure if I can reasonably stop you from implementing this. I'd much prefer it if you made proper engines for each way?
Fixed a bug from 1.12.2 which shuffles the elements in Direction.VALUES(EnumFacing.VALUES)Where? I'd quite like to fix this, since that sounds pretty bad.
I've created a proper branch for this, but I'm not going to look at this until after Christmas now.
Initial thoughts:
- Trove would best be handled by migrating to
it.unimi.dsi.fastutil, as it has very similar collection classes (but is provided by minecraft). This does require a lot of find-replacing stuff though :/- I don't really like power convertors, but I'm unsure if I can reasonably stop you from implementing this. I'd much prefer it if you made proper engines for each way?
Fixed a bug from 1.12.2 which shuffles the elements in Direction.VALUES(EnumFacing.VALUES)Where? I'd quite like to fix this, since that sounds pretty bad.
That sounds fine~
Thanks for the suggestion. I just tried replacing trove, and seems everything works well.
Emmm... maybe using an FE engine to make MJ is better? Someone told me the iron engine decreases the FPS a lot, and advised me to add a block tp convert FE to MJ. Maybe it will be replaced or removed soon, but I don't have a clear idea yet.
I looked up the code and I'm sorry that seems I made a mistake that EnumFacing.VALUES is not be effected in 1.12.2. QwQ
Someone told me the version of 1.20.1 conflicts with the mod Redirector (A mod modifies all values() methods in Enum classes with ASM. It removed the bytecode in the method values() except returning the field $VALUES directly, without cloning the array, to invoke the method faster). With Redirector, all the engines have wrong directions when a quarry is placed. I found the bug was caused by https://github.com/BuildCraft/BuildCraft/blob/1027c9c85cb1066ddb86307ea6893ceec7240647/common/buildcraft/builders/tile/TileQuarry.java#L192 With Redirector, the quarry shuffles Direction$.VALUES.
In 1.12.2, EnumFacing.VALUES is public, but in 1.16+ Direction.VALUES is private. I changed all EnumFacing.VALUES to Direction.values() in BC's code when migrating BC to 1.18.2. When trying fixing the bug conflicts to Redirector, after reading the introduction of Redirector, I changed the access permission of Direction.VALUES to public with accesstransformer, and replaced all Direction.values() back to Direction.VALUES in BC's code to look for the reason to the bug, as well as to increase the efficiency of invoking, and did not find the code in TileQuarry of 1.12.2 is EnumFacing.values() rather than EnumFacing.VALUES. I tested today and found that, in 1.12.2, although with Redirector, EnumFacing.$VALUES will not be shuffled (We can see EnumFacing.values() will not be modified by Redirector through the log, but EnumFacing$Axis.values(), EnumFacing$Plane.values(), EnumFacing$AxisDirection.values() will be modified. I didn't find why EnumFacing is excluded... maybe loaded earlier than Redirector?)
Redirector breaks assumptions of otherwise working Java code; I would not worry about trying to support it.
I was testing this a bit and I think sodium stuffs up the entity and pipe rendering. Thought I'd might at well let u guys know
I was testing this a bit and I think sodium stuffs up the entity and pipe rendering. Thought I'd might at well let u guys know
It was ModernFix's Dynamic Resources.
Link: https://github.com/embeddedt/ModernFix/issues/516
A lot of memory seems to be used by facades, especially in larger packs, since one is made for every block state. Since most blockstates will be visually similar if not identical, it might be better to add a config where users can list blocks that need facades generated for all states, and otherwise only create a facade for the default block state of each block.
seems to crash when on server, not sure if this is my modpack or not
