warjort

All those shapes are mostly used for things like lighting, block/entity collision and hitboxes. For the rendering you need to change the RenderType, the default is RenderType.SOLID if you don't change it. The old way was to use ItemBlockRenderTypes.setRenderLayer() but that has been deprecated as of 1.19 The recommended way is to put this configuration in your block model json. /** @deprecated Set your render type in your block model's JSON (eg. {@code "render_type": "cutout"}) or override {@link net.minecraft.client.resources.model.BakedModel#getRenderTypes(BlockState, net.minecraft.util.RandomSource, net.minecraftforge.client.model.data.ModelData)} */ @Deprecated(forRemoval = true, since = "1.19") public static void setRenderLayer(Block block, RenderType type) {

Item.useOn() is first called on the client, if you return SUCCESS, then the same method will be called on the server. See for example MapItem.useOn() or one of other vanilla Items similar to your usecase.

Issue with neko's enchancted books trying to load client classes on the server. Check you have the latest version then report it to the mod author.

Mojang won't fix things in 1.18.2 unless it is a security issue. Their supported version is 1.19.1

If Minecraft 1.18.2 doesn't support your OS I don't know? One option would be to spin up a virtual machine and use an OS that is supported. Or maybe MacOS has some emulation mode that lets you run it on a supported architecture? e.g. pretend its x86 if you have arm

Changing the gradle config will have no effect. Forge doesn't use gradle for this, it emulates the minecraft launcher. It uses those package files I linked to earlier and downloads the stuff it is told to use from Mojang's website.

Do you understand how Suppliers work in terms of deferring code execution? Are those RegistryObject.get() invocations run during classloading or during the Supplier.get() for the List at registration time? It should be more like this. public static final Supplier<List<OreConfiguration.TargetBlockState>> OVERWORLD_LEGENDARY_ORE = // Pass the suppliers, the blocks have not been created yet we are in the classloading regOverWoldOres(BlockInit.LEGENDARY_ORE, BlockInit.DEEPSLATE_LEGENDARY_ORE); public static Supplier<List<OreConfiguration.TargetBlockState>> regOverWoldOres(RegistryObject<Block> normalOre, RegistryObject<Block> deepslateOre) { return Suppliers.memoize(() -> List.of( OreConfiguration.target(OreFeatures.STONE_ORE_REPLACEABLES, // Use the supplier at registration time when the blocks now exist normalOre.get().defaultBlockState()), OreConfiguration.target(OreFeatures.DEEPSLATE_ORE_REPLACEABLES, deepslateOre.get().defaultBlockState()))); }

I believe Forge has to use whatever Minecraft uses. Which for 1.18.2 is 3.2.1 See: https://launchermeta.mojang.com/v1/packages/f1cf44b0fb6fe11910bac139617b72bf3ef330b9/1.18.2.json 1.19 uses 3.3.1: https://piston-meta.mojang.com/v1/packages/92e6f1eba1748a43b8e215d0859a42bce4f999d2/1.19.json

None of the code above shows a RegistryObject.get(). Please don't just post any error you get in this forum without thinking about it. We are not here to write/debug your code for you. You need to take the time to work things out for yourself. You spent less than 6 minutes on this problem.

If there is nothing in ForgeRegistries, use the vanilla Registry class. Double check it is not @Deprecated which means it is in ForgeRegistries and you missed it. 🙂

The error says it can't load this native library. I don't know enough - anything 🙂 - about native code on the different MacOS architectures to be to tell you might be wrong, sorry.

That is not the debug.log and it doesn't contain the error. You are registering different items to the same name (both are "nature_wood"). https://github.com/JPermSolves/ElementalSwords/blob/340e43851f6c86709501ad042069a89adbf93ce8/src/main/java/net/juder/elementalswords/block/ModBlocks.java#L30 https://github.com/JPermSolves/ElementalSwords/blob/340e43851f6c86709501ad042069a89adbf93ce8/src/main/java/net/juder/elementalswords/item/ModItems.java#L31

No, you need to add a breakpoint in that exception handler for Main.main() and see what the value of "throwable1" is. If that doesn't tell you anything useful, you will have to trace through the initialisation code inside the try block to see where/why it is failing.

Did you try using the debugger like I suggested on the linked thread. This should tell you the real error message? And did you try resetting/clearing the gradle cache? See the other thread again.

https://github.com/SizableShrimp/EntityModelJson

Neither of those logs contains the "DecoderExceptions (incorrect header check, invalid distance too far back, etc.)" error message? The server does have a message saying you disconnected as you say. And the client has a message saying JEI is responding to a disconnect event, but no error message. The "DecoderException" error message says there is a problem with the decompression of the network packet. One thing I notice is you have the following on the client: but on the server it is So it looks like the server is trying to use ipv6. If you look at the changelog for forge 1.18.2 https://maven.minecraftforge.net/net/minecraftforge/forge/1.18.2-40.1.69/forge-1.18.2-40.1.69-changelog.txt It says So one option would be try the latest release of forge, 40.1.69 which has this change. Another would be to configure the server to use ipv4 like the client? -Djava.net.preferIPv4Stack=true NOTE: I don't know if this really the cause of the DecoderException, it could be caused by one of the mods and the ip version is just a red herring. 🙂

NOTE: That will return minecraft:air if for some reason the item is not registered.

You don't have any data in your packet? You should read the "Handling Information" section here: https://forge.gemwire.uk/wiki/Main_Page/1.18 The actual handling on the client will involve getting the player from Minecraft.getInstance() then updating the capability with the data from the packet. I assume you only want the player to know about its own money. Players knowing about every other player's money on the client needs handling in a different way using broadcasting and entity ids.

You need some network message(s) to synchronize the capability state with the client. Then you can just access it. You don't explain what kind of capability it is, accessing the capability means getting a reference to the object the capability is attached to, e.g. the player is on the minecraft instance.

Passing 0 here means no updates are performed. Using the value 2 will send updates to the client. See ServerLevel.markAndNotify() used by setBlock() or you could just use setBlockAndUpdate() which passes the value 3 (so it also notifies neighbouring blocks of the change). There is supposed to be a vanilla class somewhere that holds the values of these bits, but I don't know the name of it. 🙂

The issue has been fixed in 1.19: https://github.com/MinecraftForge/MinecraftForge/issues/8853 You should report it as bug if it also occurs in 1.18 A simple workaround is to type the command while in the nether to make sure 0,0 is always loaded.

Update your java to something that is not prehistoric. 🙂

java.lang.NoSuchFieldError: inventory at snownee.jade.addon.create.ContraptionProvider.appendServerData(ContraptionProvider.java:36) ~[JadeAddons-1.18.2-2.0.0.jar%2389!/:2.0.0] {re:classloading} at snownee.jade.addon.create.ContraptionProvider.appendServerData(ContraptionProvider.java:20) ~[JadeAddons-1.18.2-2.0.0.jar%2389!/:2.0.0] {re:classloading} at mcp.mobius.waila.network.RequestEntityPacket$Handler.lambda$onMessage$0(RequestEntityPacket.java:57) ~[%5B玉%20🔍%5D%20Jade-1.18.2-forge-5.2.1.jar%2372!/:5.2.1] Issue with jade addons, make sure you have the latest version then contact the mod author.

Looks like an issue with effective_fg. Make sure you have the latest version the contact the mod author.