eutro / multiblocktweaker Goto Github PK

Mod used:
GTCE1.15
JEI 4.1.20.586
Multiblock Tweaker 1.3.2

New world created: yes

Issue: As mentioned on discord GTCE 1.15 introduced #1580. If Multiblock Tweaker is used to make a recipe map (and/or) multiblock pattern with GTCE 1.15, no multiblock patterns show up in jei other than Multiblock Tweaker's. This also causes all machines to lose their jei recipe map pages. I have included an image of the JEI multiblock pattern screen and the script used

With some blocks, multiblocktweaker seems to fail to load textures, reporting
Error executing {[99:crafttweaker]: multiblocks/pizza_oven.zs}: Duplicate key TextureAtlasSprite{name='missingno', frameCount=1, rotated=false, x=2192, y=2112, height=16, width=16, u0=0.53515625, u1=0.5390625, v0=0.515625, v1=0.51953125}

The blocks I've had this problem with are twilight forest underbricks and chisel voidstone. For underbricks, the item is item:twilightforest:underbrick:0 and the is metastate:twilightforest:underbrick:0. However, when I let mbt infer the texture from the most common block in the design, it gives me the texture error. I'm 99.9% sure it also gives the same error if I use .withTexture on either the item or block form of underbricks.

I glanced over the code (the problem manifests SidedCubeRenderer.java:86) but I don't know the finer points of texture baking. I think it's caused by these blocks not being directly textured, instead they have blockstates which dictate other textures. The texture for underbrick with metadata 0 is really twilightforest:blocks/knightbrick. If I use .withTexture on that resource id the error goes away.

Here's the relevant part of the ct log and my script. About the .withTexture: lines: having no .withTexture line should reproduce the bug, and having the .withTexture(ICubeRenderer.nonSided("twilightforest:blocks/knightbrick")) line should have no error. Ignore the .withTexture(ICubeRenderer.fromBlock(<minecraft:brick_block>)) line.

crafttweaker.log.snip

pizza_oven.zs.snip

Also, the aisle orders are really confusing because the default for the pattern and design are different. In the design, aisles go left to right, arguments go bottom to top, and strings go front to back, but in the pattern, aisles go back to front, arguments go bottom to top, and strings go left to right. Patterns can have the order changed but designs can't.

Multiblock Tweaker: stable-backcompat-1.0.3
Ender IO: 5.1.55
Forge: 1.12.2-14.23.5.2847

The in world previews of multiblocks render above Ender IO fluid conduits when the fluid conduits are in separate Blockspaces. An image can be seen here:

In this image, the top right corner of the fluid conduit is seen to be behind the inworld preview. This happens for all blocks in the preview, not just the current erroring block. This also only happens with the fluid conduits, tested with Ender Fluid Conduits and Pressurized Fluid Conduits, and does not occur with item conduits or energy conduits. Not tested with redstone conduits as I forgot at the time I had my game open.

A method to copy recipes from one recipeMap to another without copying the actual recipeMap with count of inputs/outputs would be very useful for "Large" versions of machines or combining several machines into one.

It can work on multiblocktweaker-1.12.2-stable-gtceu-1.8.2,however,I update it to multiblocktweaker-1.12.2-stable-gtceu-1.9.0,it dont work anymore.

GregTechCE/GregTech@083673f#diff-4339447db7380de58d6ab3213277dc5c

The above change broke the jei eu/t formatting in CustomRecipeWrapper

It needs a new parameter for the energy tier

Mods
!mixinbooter-8.8
censoredasm5.18
CodeChickenLib-1.12.2-3.2.3.358-universal
CraftTweaker2-1.12-4.1.20.697
GregicalityMultiblocks-1.2.7
gregtech-1.12.2-2.8.5-beta
multiblocktweaker-1.12.2-stable-gtceu-1.9.0
OptiFine-OptiFine-1.12.2_HD_U_G5

latest.log

Just a reminder to use the offset timer instead.

As i sad mod is great but we need some help in some aspects. Mayby docs or discord.

Custom multiblocks do not function when mbt 1.8.2 for gregtech CEU is run with gtCEU version 2.5.2.
When upgrading gregtech version from 2.5.0 to 2.5.2, multiblock controllers cease to be craftable and disappear when placed in the world.
Errors are logged to chat like the file attached.
shortened_crafttweaker.log
A full crafttweaker log is also attached for further context.
crafttweaker (1).log

The multiblock definitions of relevance here are defined in
multiblocks_normal.zs
and
multiblock_dml.zs

CraftTweaker 4.1.20.685
MultiblockTweaker 1.12.2-stable-1.7.1
Gregtech CE: Unofficial 2.5.3-beta

logs:
crash-2023-03-06_07.31.37-client.txt
latest.log

When deploying the Glider from OpenGliders, all of the projected blocks in the multiblock preview turn dark, as if they have a light level of 0. Image attached of what I mean by this.

Modpack is Omnifactory Dev version, MultiBlock Tweaker v. 1.12.2-stable-1.3.1

Screenshot_1210_194038

When trying to define front overlays and cube renderers for MBT multiblocks, only the server throws an error.
This doesn't happen on singleplayer worlds nor client-side.

crafttweaker (1).log
Versions: MBT 1.7.0, CEu 2.2.1

ALSON mentioned that you were able to pull something together that would allow recipes to bypass CE's recipe validation checks, allowing recipes to not require energy in any way.

Could get this ported to CEu?

Forge Version: 2854

crash-2020-06-12_09.40.40-server.txt

Eutro, mostly a reminder: I ran into a small issue where I was using an incorrect number of expected vs actual inputs, and the exception was thrown to the minecraft standard logs. It would be nice if these were caught and thrown to the CT logs.

Your work is pretty impressive and should be into GTCE and not out of the box. (with the new dev it should be doable)
I dont know if you will maintain your code properly but if you want and if GTCE doesnt wants your code (in case you dont want to code anymore) I can merge your code into mine :).

Hello i have some crash from making some recipce from Yours example zs script.
latest.log
Idn what's wrong. Maybe it's me being stupid

Craftweaker scripts are failling when updating to GTCEu 2.2.0, probably related to some API changes:

[INITIALIZATION][CLIENT][ERROR] [crafttweaker]: Error executing {[98:crafttweaker]: gregtech_greenhouse.zs}: gregtech.api.recipes.Recipe.<init>(Ljava/util/List;Ljava/util/List;Ljava/util/List;Ljava/util/List;Ljava/util/List;IIZ)V
java.lang.NoSuchMethodError: gregtech.api.recipes.Recipe.<init>(Ljava/util/List;Ljava/util/List;Ljava/util/List;Ljava/util/List;Ljava/util/List;IIZ)V
	at eutros.multiblocktweaker.gregtech.recipes.CustomRecipeBuilder.build(CustomRecipeBuilder.java:39)
	at gregtech.api.recipes.RecipeBuilder.buildAndRegister(RecipeBuilder.java:577)
	at gregtech.api.recipes.crafttweaker.CTRecipeBuilder.buildAndRegister(CTRecipeBuilder.java:178)
	at Gregtech_greenhouse.__script__(gregtech_greenhouse.zs:79)
	at __ZenMain__.run(Gregtech_greenhouse)
	at crafttweaker.runtime.CrTTweaker.loadScript(CrTTweaker.java:240)
	at crafttweaker.runtime.CrTTweaker.loadScript(CrTTweaker.java:105)
	at youyihj.zenutils.impl.delegate.ZenUtilsTweaker.loadScript(ZenUtilsTweaker.java:47)
	at crafttweaker.mc1120.events.CommonEventHandler.registerRecipes(CommonEventHandler.java:71)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_754_CommonEventHandler_registerRecipes_Register.invoke(.dynamic)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
	at net.minecraftforge.fml.common.eventhandler.EventBus$1.invoke(EventBus.java:144)
	at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
	at net.minecraftforge.registries.GameData.fireRegistryEvents(GameData.java:857)
	at net.minecraftforge.common.crafting.CraftingHelper.loadRecipes(CraftingHelper.java:636)
	at net.minecraftforge.fml.common.Loader.initializeMods(Loader.java:747)
	at net.minecraftforge.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:336)
	at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:535)
	at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:3931)
	at net.minecraft.client.main.Main.main(SourceFile:123)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
	at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

crafttweaker.log
(lines 49-106)
i have noticed that this happens because this line in ReflectionHelper does null-checking for other usecases, even though this line in CubeRendererBracketHandler does the necessary null-check for this as well.

script file i forgot to attach
where the ICubeRenderer is created