Leaderboard

Why the fauk does your renderer change what blocks are in the world? That's not the job of a renderer.

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.

They both point to the same error: Your invalid mod ID.

https://github.com/MinecraftForge/MinecraftForge/pull/6982

What you did in the first place is correct, as you looked at the vanilla code that obtains this effect for player hearts as an inspiration...of course that code is not very explanatory as you already pointed out so, you could take some time reading it very carefully in order to assess what every line of code exactly does, or you could copy that portion of code in your code and try to play a bit with it to see how things change, and so you can adjust it to your needs

My only comment would be on OpenClientScreenMessage as the Minecraft instance can just be obtained inside the method itself. This is still 'safe' I believe, but we should avoid calling anything that might only be available on the client that is not isolated in a different class. This is my opinion as it still won't be loaded unless on the physical client.

You cannot. Your mod needs to run on the client, subscribe to the event and cancel it there. What event is this?

Your serializeNBT method is completely broken, it keeps overwriting the same data every loop iteration.

Update Forge if you want Java 15 support.

To reiterate... if you think it's such a good idea, do it yourself and actually provide numbers. Thread locked.

Gasp, you're not on the server.

I seem to recall getting this error myself... I think it had something to do with caps, also I do what GitHub suggests and put those in a gradle.properties in my user folder so they're global and there's no risk of accidentally committing them

Yup, thats world gen - i.e. no world access. WorldSavedData cannot be accessed during world gen. You can use IChunk#getBiomes to get biome information.

GatherDataEvent only fires during data runs, not during client or server runs

Note: I am using registry events instead of deferred registry so if someone chimes in on a difference that works better than listen to them. this method still works so i am yet to be motivated to change. I am able to replace blocks using the RegistryEvent.Register<Block>. I get the old resource location ForgeRegistries.BLOCKS.getKey(oldBlock); and set the custom block with that blocks registry location newBlock.setRegistryName(resourceLocation); ForgeRegistries.BLOCKS.register(newBlock); I also replace the Item (again i dont know if this is still needed as doing so still works so i have yet to change it)

Do not use OnlyIn. Minecraft#player is always the client player. By accessing it on a packet thats sent to the server, you are reaching across logical sides, which will just crash on dedicated servers and cause strange behavior in single player.

There is no way to do this. The smithing container is hardcoded to just decrease its inputs and not use the container item (see SmithingTableContainer#func_230301_a_).

There are several problems which all contribute to the things you are seeing (or rather not seeing): Your event handler for ModelRegistryEvent is not called, because you registered it to the wrong event bus. ModelRegistryEvent is fired on FMLJavaModLoadingContext.get().getModEventBus(), but you used MinecraftForge.EVENT_BUS. You create the RenderMaterial wrongly. Minecraft will use Atlases.getSignMaterial to create the material - which does not match up with what you are doing here. You need to also use that method. This means that the "minecraft" namespace will be used, there is no way around that. Because of this you should prefix the name of your WoodType with your ModID, so "effetewood_effete", to avoid collisions not only with the texture but also the WoodType registry. Then your texture also needs to be in minecraft/textures/entity/signs/effetewood_effete.png naturally. In ModelRegistryEvent you also need to add the RenderMaterial to the set of built-in textures (ModelBakery.LOCATIONS_BUILTIN_TEXTURES) so that Minecraft will actually load the texture and stitch it onto the atlas. Because the field is protected, you can use a little hack to avoid having to use reflection: static class FakeBakery extends ModelBakery { private FakeBakery(IResourceManager resourceManagerIn, BlockColors blockColorsIn, IProfiler profilerIn, int maxMipmapLevel) { super(resourceManagerIn, blockColorsIn, profilerIn, maxMipmapLevel); } static Set<RenderMaterial> getBuiltinTextures() { return ModelBakery.LOCATIONS_BUILTIN_TEXTURES; } } Now you can just call FakeBakery.getBuiltinTextures to get the field and add your RenderMaterial to it. Because you now have your own tile entity type, you need to tell Minecraft to use the SignTileEntityRenderer for it. Use ClientRegistry.bindTileEntityRenderer in FMLClientSetupEvent for that. Registering the wood type in ModelRegistryEvent means it won't be registered on the server. However FMLCommonSetupEvent is too late, so you have to do it in the mod constructor. Unfortunately in this case, mod construction (like many startup events, e.g. FMLCommonSetupEvent) runs in parallel on a threadpool, which means you cannot just register your WoodType there (the underlying data structure ObjectArraySet is not threadsafe). With normal event handlers (like FMLCommonSetupEvent) you can just use enqueueWork on the event to run something synchronously on the main thread. However in this case we are in the mod constructor, which doesn't receive an event instance. There is still a DeferredWorkQueue for us to use though (i.e. call enqueueWork to run something on the main thread): DeferredWorkQueue.lookup(Optional.of(FMLConstructModEvent.class)).get().enqueueWork with a Runnable lambda will do the trick. In there you can then safely register your WoodType. With these fixes the custom sign now works:

Nope, you're just registering the item twice. Your block calls this method which creates an item to which you then create another item under the same name.

No.

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.

You are reaching across logical sides. You need to send a custom packet.

"If I never tell the structure about this property, will it know about it?" Think about that for a minute.

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.

Loop over every stack in the player's inventory until you find a match.

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...).

What did you not understand of those classes you looked at?

A capability attached to the player will do what you need then.

It is only returning the attributes. To set your own attributes change the "MobEntity.setCustomAttributes().create()" to YourEntityClass.func_234188_eI_().create(). I would recommend to rename "func_234188_eI_" to "setCustomAttributes" or something similar though

I believe the ModId in mods.toml and in your main mod class arent matching. Are you sure that your @Mod(...) tag in your main mod class contains the correct ModId?

The client spec should be the only config to be applied on the physical client side. Common specs take precedent on whichever physical side holds the logical server. As such, they can consider to be accurate when being applied to the logical server. A common spec should be used when applying to a logical server if it should modify all instances of the underlying world being played. If its a per world configuration, then a server config should take priority. This is not true. This means that you are trying to execute logical server code on the logical client, which leads to desynchronization. If you really do need to sync the common configuration, you can send a packet. Here is also an unofficial version of the packet docs as well for more reference.

I don't know if this is intentional but in your SkillStorage, method writeNBT you kept rewrite/override the value of "xp", "static", and "dynamic". I guess what you are trying to do here is something like: for(int i = 0; i < 26; i++) { data.putInt("xp" + i, (int) instance.getXp(i) * 10); data.putInt("static" + i, instance.getStaticLevel(i)); data.putInt("dynamic" + i, instance.getLevel(i)); } so does writeNBT(), you assign the same value to every slot or whatever it is.

The method is canInteractWith. Actually for anvil (RepairContainer) it seems to be checking if the block belongs to the ANVIL block tag

Try refreshing the gradle project and rerunning genIntellijRuns.

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.

If I understand it correctly getUpdateTag provides the information that needs to be synced (check its doc), and getUpdatePacket provides the packet that going to be send to the client, I think it's fine to put any number for the tileEntityTypeIn (the second parameter of SUpdateTileEntityPacket), since it's hardcoded to check if the tileentity and the number matches. And then onDataPacket is called when the client has received the packet, it provides the data send from the server which you gather the information you need for client from it.

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.

You don't want processRightClick, it is for right clicking while not aiming at a block. You want func_219441_a.

It won't run the mods even if you add license info. If the mods do not have license info, that means they are 1.15 mods, they will not run on 1.16.

You never attach your capability to anything, because your AttachCapabilitiesEvent handler is not registered. @EventBusSubscriber registers the class to the event bus, meaning only static methods will be registered.

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.

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).

On the server this will re-send the block and it's TileEntity packet to the client. That will then cause the block (or rather it's render chunk) to be re-rendered. notifyBlockUpdate is also called when one block changes into another. Currently these parameters are only used by the entity pathfinder to detect if a path needs to be recalculated based on a block change. markDirty does two things: It tells Minecraft that the data in your TileEntity has changed and so it must be written to disk on the next write cycle (note that it doesn't change anything about when data is written). If you change data in your TileEntity and not call markDirty that data might be lost when the chunk is unloaded. It calls onNeighborChange on neighboring Blocks (this method is different from neighborChanged, which is called when the actual block state changes). This used by e.g. comparators to update their state, because they depend on the inventory data.