Leaderboard

Do not create a new LazyOptional every time. This defeats the entire purpose of LazyOptional.

You know how when you buy a pair of headphones, they come in a box? You have a box labeled "headphones" right now and you're trying to plug it into your computer, but it doesn't have an audio jack.

So I just recently wiped my hard drive and I wanted to re-install forge to run wynntils on the wynncraft server but everytime I try to install it it always gives this error: https://imgur.com/CswUiZi I've already tried to restart my pc and disabling the firewall, though it seems other versions (1.16.4) work so I don't know what I'm doing wrong. I did play once on the 1.12.2 version and Java should be the latest version since I just downloaded it off of their site (windows offline 64bit one) so I don't know what I'm doing wrong. Here's the link to the log: https://pastebin.com/8cvJFVPN

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

Post your code and assets.

No. Stop. writeToNbt and readFromNbt are for saving to disk. Server-side. If you want to sync stuff to the client (assuming you want to use the vanilla mechanic, which uses NBT), you need to override a couple of methods (warning, this is a giant mess): getUpdateTag - Returns the data that should be sent to the client on initial chunk load (i.e. when it gets into render distance, etc.). Call super here and put whatever data you need to have available on the client in the NBTTagCompound returned from super. Then return it. handleUpdateTag - Called on the client with whatever tag was returned from getUpdateTag. By default this calls readFromNbt, which is a terrible default, but oh well. getUpdatePacket - Called to produce a subsequent update packet. You should return a SPacketUpdateTileEntity here if you need the data on the client to be updated from time to time. In theory you can return a partial update here, but usually it is best to just call getUpdateTag and pass that NBTTagCompound to the packet. The int parameter of the packet constructor can be set to whatever unsigned byte you like best. onDataPacket - Called on the client when the packet produced by getUpdatePacket is received. Usually you just need to call handleUpdateTag with the NBT data from the packet (SPacketUpdateTileEntity::getNbtCompound). getUpdateTag will always be called and it's data sent when the chunk is initially transferred to the client. You cannot stop this. If you need to update the client-side data later (i.e. you need the packet produced by getUpdatePacket to be sent), call World::notifyBlockUpdate on the server. You should care about when you call markDirty. You should not care when writeToNbt and readFromNbt are called. Remember, these are for saving the world to disk. Minecraft will do that when it sees fit. You need to call markDirty after doing the changes (so Minecraft knows to save to disk) and then call notifyBlockUpdate to notify the client of these changes (assuming you are using the syncing mechanism described above). Both happens server-side. That was in the context of "NBT is only used for saving to disk". ItemStacks have the terrible habit of using NBT for runtime storage, which is ugly, cumbersome and inefficient.

This will immediately crash the game, there are not just server side entities. The fact that it doesn't mean your event handler is not even running. It is not running, because @EventBusSubscriber only works with static event handler methods.

LootTableLoadEvent completely bypasses the data driven system. Modpack makers or just "regular users" can not change your logic by using a datapack if you use LootTableLoadEvent.

EnumFacing is Direction now. NBTBase would be INBT.

You could overwrite the vanilla fishing loot table, yes. However: Vanilla does not do any loot table merging. One datapack wins. So if you and another mod (or another data pack) both modify the fishing loot table, only one wins. That's why Forge has added global loot modifiers, which allow you to specify modifiers that act on the result of loot tables, without replacing them.

Use global loot modifiers to change loot tables.

That grabs the name from the NetworkPlayerInfo which is separate. You would need to set it from the ClientPlayerEntity in a sided-safe manner.

Use the already existing key binding for left mouse button.

Delete this file.

Forge installer will not open or close the launcher. Make sure you downloaded only the installer from https://files.minecraftforge.net/. The Minecraft launcher must be closed during Forge installation.

There's a list of tooltips provided, you can do whatever you want to it (remove them all, add your custom ones, or even flip them all around...).

Refer to the Optifine downloads page regarding compatibility with Forge.

What on earth are you doing with that key binding thing Just call isKEyDown on your TEST field... You tell EventBusSubscriber to use the mod bus, but ClientTickEvent fires on the Forge bus.

I just noticed that the titles are actually rendered in drawGuiContainerForegroundLayer() not render(). Also I believe you only need to set the value once in the constructor, or in init().

Then I don't know.

What is an empty gui? If it does not store any information (e.g. inventories, sharing data) a simple screen will work using Minecraft#displayGuiScreen (this is client only). Otherwise you will need a registered container and screen, and open it with NetworkHooks#openGui (this should be done on server, in this case you send a packet when the key is pressed). There's a key input event that you can use, or use client tick event to proceed with keybindings (check Minecraft.java).

Any version from 8-14 will work, Java 8 and 11 currently still receive LTS support. We usually recommend using https://adoptopenjdk.net/. I don't own or use a Mac so I can't help you with the installation.

PlayerList#getPlayers. Note that names are not suitable for anything but displaying them to the user - they can change. Internally you should work with UUIDs always. ServerLifecycleHooks.getCurrentServer

I think this is caused by the fact that you did not create the cows attributes. In your main class cunstructor do: // Register the setup method for modloading bus.addListener(this::setup); and add the method: private void setup (final FMLCommonSetupEvent event) { event.enqueueWork(() -> { GlobalEntityTypeAttributes.put(ModEntityTypes.GS_COW.get(), MobEntity.setCustomAttributes().create() } }

This is not applicable for 1.16.2+ as the system was changed. First, you will need to register your Configured Feature within the associated WorldGenRegistries. I would suggest looking at how the Features class does the registering and borrow the method. Note that this should be deferred until FMLCommonSetupEvent. For reference, the register event is not thread-safe, so it should be wrapped using the synchronous work queue provided in the event (e.g. enqueueWork). From there, you can attach the feature to the biome(s) of your choice using BiomeLoadingEvent. You can grab the generation settings builder there and add a feature during a specific point in the generation process, in your case most likely UNDERGROUND_ORES.

No, I simply gave you all the options before - not my opinion on which is the best

Not at all. In fact Minecraft has something specifically for this, the entity ID. It exists precisely and only for this purpose - identifying entities across the client/server boundary.

Something is broken about your workspace. I would recommend to re-clone your repository (you are using Git or something similar, right?) and just try again with a new workspace.

You already found it, you override each recipe JSON file using the data pack mechanism. Although I would advise not doing it manually, use data generation instead.

As, I've already explained, you need to download some JDK 8. Then, attach it to your IDE of choice and use that to compile the jar.

Looks like ChickenChunks is causing a deadlock: It is trying to access its own chunk while that chunk is being loaded. But the chunk loading cannot complete, because the chunkloader is still loading, but that cannot complete because its waiting for the chunk to load, which is waiting for the chunk loader to complete... you see where this is going. Report this to ChickenChunks.

Some mod that is modifying loot is breaking things. There are a lot of errors related to data loading in your log. allthemodium and shows invalid recipes. It seems to include recipes for 1.16 as well as recipes that reference items that do not exist. "slurpiesdongles" has invalid recipes that reference items that do not exist. "carpetstairsmod" has invalid recipes that reference items that do not exist. "productivebees" has invalid recipes that reference a recipe type that does not exist. "silentgems" has invalid recipes that reference tags that do not exist. "mekanism" has invalid recipes that reference a recipe type that does not exist. "quark" has invalid recipes that are straight up invalid JSON. "endores" has invalid loot tables that reference items that do not exist (this seems to be the most likely root cause, but it is hard to tell). Make sure these mods are up to date and report these issues to the mod authors, include the log. Then "explorercraft" causes an exception while trying to modify loot tables using an outdated, deprecated method. Report this to the mod author and tell them to use global loot modifiers. The error might not be their fault though, other mods down the line cause similar exceptions using the same, outdated and deprecated method. This does not mean they should not be using global loot modifiers instead. The total list of listeners to the deprecated event for modifying loot is:

Tried it, this is in the client log: Please read your logs.

You should really do this. Not sure what your issue is now though, would have to check with the debugger. Either do that yourself or post a Git repo of your mod.

You need to use runtimeOnly, like Mekanism tells you.

someone who wants to be part of my team. must have at least one of these requirements that I am looking for: !) mod programmer (above all: mob, biomes, objects, weapons and blocks). 2) good at giving realistic animations to the mobs that I will show you. 3) good at textures (they must be "Mowzie's Mobs" style) """write to me with your Discord name""" CERBERUS Guerriero della morte Demone Piccolo drago Piccolo fungo Molti piccoli funghi Fungo medio Fungo gigante rovinare Non morto più solido Troll con tamburo Valhalla Knight

Either the Javadoc tells you, or you just have to use your IDE to search for where it is fired.

Check the world save for serverconfig, clear that folder too

No, that wouldn't be feasible as this data driven system gets more developed over time. It would be just as easy to store a simple key interface that executes when a player is within a biome as needed without having to AT to extend the biome class.

Thanks for the report. This was actually me messing up a fix for vanilla clients showing errors due to Forge's custom attributes. I've fixed up the fix: https://github.com/MinecraftForge/MinecraftForge/pull/7560

Please learn basic Java. The == operator is the wrong tool here.

This is now wildly off topic, so I will close this thread.

A jar file in your gradle cache is corrupted. The easiest, but brute-force, method is to just delete .gradle in your user home folder. But that will mean you need to re-import any Gradle project.

minecraft 'net.minecraftforge:forge:...' under dependencies in build.gradle and if you are using intellij, there should be a gradle panel. Select it and there should be a refresh button, or when you made changes to the build.gradle file a small window will pop up and asks you if you want to reimport the gradle project.

Yes! This worked! Thank you so much. I can't express how grateful I am, I've spent nearly three days trying to figure out this issue and it finally works. Thank you.

For anyone else looking for this in the future, create mixins for net.minecraft.network.NetworkManager like so: @Inject(method = "sendPacket(Lnet/minecraft/network/Packet;)V", at = @At("HEAD"), cancellable = true) private void onSendPacket(Packet<?> packet, CallbackInfo callbackInfo) { //System.out.println("Packet Sent: " + packet.toString()); PacketSent event = new PacketSent(packet); MinecraftForge.EVENT_BUS.post(event); if (event.isCanceled() && callbackInfo.isCancellable()) { callbackInfo.cancel(); } packet = event.packet; } @Inject(method = "channelRead0", at = @At("HEAD"), cancellable = true) private void onChannelRead(ChannelHandlerContext context, Packet<?> packet, CallbackInfo callbackInfo) { //System.out.println("Packet Recieved: " + packet.toString()); PacketRecieved event = new PacketRecieved(packet); MinecraftForge.EVENT_BUS.post(event); if (event.isCanceled() && callbackInfo.isCancellable()) { callbackInfo.cancel(); } packet = event.packet; } PacketSent and PacketRecieved are custom events that you can make yourself by making a class that extends Event.

ModList.get().isLoaded

Some things to clear up: Saving to disk for tile entities (and normal entities) happens automatically, you get no control over when it happens. The only thing you must do is call TileEntity::markDirty when data that needs saving has changed. This tells Minecraft "Hey, I need saving before you unload me". When that happens does not matter and you should not care about it. markDirty also tells nearby blocks "hey, my tile entity data has changed" (by calling Block::onNeighborChange if Block::getWeakChanges returns true for the neighboring block). This is used to update comparators when a nearby inventory changes. Making these two things one method is ugly, but that's how it is. Loading from disk for tile entities happens automatically. You can (usually) assume that your tile entity will not be in a state of "I am freshly created but do not have the data yet". Only exception is a constructor in your TileEntity class (seriously, you almost never should write one) and obviously the Block::createTileEntity method, where you just created the fresh instance. Stop thinking in terms of "store stuff in NBT". NBT is a serialization format (like JSON). You store things in your tile entity, which happens to use NBT to persist data into the world. But nobody but the methods writeToNbt and readFromNbt need to care about this and nobody else but them should touch NBT. getUpdateTag (which you have pointlessly overridden) is vanilla's crude tile entity synchronization mechanism. For vanilla this mechanism is "take the complete tile entity state, serialize it like we would if saving to disk and then shove it down the network". Adopting this mechanism in modded code is terrible, since modded tile entities often have incredibly complex functionality and produce lots of data when saving to disk. There is no need to shove all this crap down the network. Only send over what you need to and if you are feeling especially nice, stop using the terrible NBT-based syncing that vanilla uses. Now, on to the issues with your code: Do not implement that client-only ITickable interface on your tile entity. You will crash a dedicated server. Never, ever use getTileData. Seriously. For your own tile entities, store data in normal fields (see above). Do not use NBT here, NBT is for saving to disk, only (ignore ItemStacks, they are terrible).