Leaderboard

Forge for 1.16.1 The first Forge build for 1.16.1 is now live thanks to the hard work of: covers, illy, jd, garrett, giga, and the rest of the forge crew. With their help we were also able to release the updates to MCPConfig for 1.16 and 1.16.1 the same day that vanilla did. The Nether Update has brought a lot of changes to many systems, and as with any update there are likely to be bugs. We are still evaluating and working on some of the systems like dimensions and trees to come up with the best system to allow for modders to integrate with vanilla’s new dimension system. We are also expecting Mojang to release a 1.16.2 fairly shortly and are prepared to work on updating to it as soon as they do. As with every update, there are bugs and other minor things to be expected. Please report them responsibly and have fun with the new version! Changes to the LTS There are a couple changes happening to the Long Term Support system originally introduced here. We are moving the LTS from 1.14.4 to 1.15.2 to reflect the community being more active and also changing how we chose what version the LTS will be to be more maintainable. We are now going to be supporting the latest (n) and second latest (n - 1) versions, with the reservation of potentially having the LTS being n - 2 if something is Mojang ends up really making a mess of a particular version. That being said we still will be providing critical fixes for all possible versions. Do not worry about 1.14 being instantly dropped while we are still working on updating 1.16, as we have a customary grace period for while everything is still in flux before we start strictly enforcing the LTS rules. New Team Members We are happy to announce we've added a few new members to the Forge team officially. These people have been a part of the community for a while and have been helping out a lot. The first two are new members of the 'Toolchain' team. Which is responsible for some of the backend tools, like the decompiler, update scripts, gradle and other internals. The others are joining our ever growing list of Triage team members. Who are responsible for managing the issues and pull requests on our github. They are the front line of bug reports and feature requests, treat them with respect and listen to what they tell you! Toolchain covers1624 JDLogic Triage AshersLab Curle OrionOnline pupnewfster

and because you use MCreator you got this far and are now bitching because you can't get something to work and you feel we should just do the work for you when you haven't even put in the effort to learn Java. There is a reason we dislike MCreator and you are only reinforcing that opinion. Learn Java.

Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.

If it is your item, override getContainerItem(ItemStack) in your item class and return whatever you want returned to the player. If it's not, you need a custom IRecipe class (you need to register an IRecipeSerializer for it) and override getRemainingItems.

Here is a forum. It operates under "forum" rules: threads stay "open" by default. The only reason to close threads (as in, a moderator locks it) is if it has been necro'd or is off topic (asking for help with unsupported versions falls into "off topic"). I don't know why so many people think that this place operates likes Stack Overflow.

Hi, used Minecraft 1.16.1 and forge-1.16.1-32.0.7-installer.jar on Ubuntu 20.04. Tried different openjdk versions from 8-14, none worked. Minecraft was running once, stopped via console, this was a fresh install. My install command : java -jar forge-1.16.1-32.0.7-installer.jar --installServer the part where it fails : Data io/netty/internal/ Processor failed, invalid outputs: /home/regnator/mc/./libraries/net/minecraft/server/1.16.1/server-1.16.1-slim.jar Expected: 6cbe49c4d26497791d1d511c2d3b7d1fa46fa2e9 Actual: 3f1b64c684df16a25e6c44079b06ac12131db572 /home/regnator/mc/./libraries/net/minecraft/server/1.16.1/server-1.16.1-extra.jar Expected: 79ed2a48582a58ce917a04344c35c9c9abb557e2 Actual: 501b61ed1857f6452fe36a5faaf1265d38999c6f full logs : https://privatebin.net/?29f4d24ddf99dcf7#4ykHNhbSaNdwNfu2HEzyrUgUp9dw4527zrCXdqx43d1r EDIT: Still fails with forge-1.16.1-32.0.14-installer

Thanks for the amazing work, it was such a fast release!

Forge 1.16.1 32.0.7 just dropped and that *does* use vertical biome detection (visible in the nether from the vanilla F3 screen). Doubt many people know much about this right now... Time to investigate...

Bear in mind that more players use metric systems than imperial (according to minecraft server statistics, and the fact that there are few countries which still use the imperial system). It is far easier for users to understand that half a bucket is 500mb, than it is for them to see 648 "atoms" (If that is the approach, I would prefer to use something like "voxellites" which has no real-world bearing than "atoms" which could cause huge confusion for users of chemical mods). And to the next argument that you would just display it as "3 1/2 buckets" or 3 1/1296 buckets", that is hugely unnatural for me (and presumably many others). I'm not sure what the issue with 144mb/ingot is. Why does a melted compound have to fit in the same space as a solid one? It doesn't in real life. And as far as cauldrons, I think it's fair enough to just lose 1mb in a cauldron. Who cares about 1/1000 of a bucket of an infinite resource? And for those mods which have finite supplies of water, they usually add their own mechanisms for collecting/storing it, so the cauldron issue is moot.

You use @CapabilityInject to inject the other mod's capability. You can put this annotation on a method too (see the javadocs) and that method will then only be called if the other mod is present. In that method you can then enable your mod's compatibility features. If you put this method in a separate class that class will never load unless the other mod is present.

With the migration the WYSIWYG editor no longer has a button for in-line code (teletype). Several other buttons may have also been lost, but TT was the only one I used regularly. Example (link preview doesn't display it, but LootModifierManager is formatted as inline code):

You're not a modder, you're someone who used a cookie-cutter mod builder who now has an ego as a result. Learn Java.

Use Entity#getEntityId and World#getEntityByID instead of UUIDs for syncing.

Howdy I think capability is great for items, entities, etc where 1) you're attaching the same general capability to a variety of different object types or a variety of different capabilities that you're adding to multiple objects ("composition" instead of inheritance/interfaces); or 2) you want vanilla or other mods to be able to interact with your objects in a general way; or 3) you want to attach information to vanilla objects For example - the capability to store items CapabilityItemHandler.ITEM_HANDLER_CAPABILITY is very useful because other mods and vanilla objects can automatically interact with your object to add or remove items. You don't need to tell them anything except that your object provides the capability interface. Or if you wanted to model a radioactive wasteland you could attach a RadiationSickness capability to each entity, including vanilla, to store the amount of radiation damage that has been suffered by each entity. In contrast, if you're just storing information (in your item) that's of no particular interest to other items, blocks, or entities, then you're probably better off with just "private" NBT information. -TGG If you're interested in general information on the pros and cons of this coding technique, these links might be interesting https://www.baeldung.com/java-decorator-pattern https://www.geeksforgeeks.org/decorator-pattern/?ref=lbp

The method is called Minecraft#getInstance.

I got into minecraft modding recently and was surprised by how hard it is to find useful up-to-date information. Because of that, I decided to document my learning journey and write a book about Minecraft modding for beginners. It applies to Minecraft 1.16.1 and the latest version of forge. Keep in mind it is still a work in progress. More chapters will be added in the coming days. Suggestions and questions also are welcomed. Link: https://thebookofmodding.ml/

You cannot do this, KeyBinding is a client-only class. You cannot do this, RenderTypeLookup is a client-only class. Please don't spam the log with things like this. Nobody cares. You are subscribing to a lot of client-only events in this class. Client-only events must be in a separate event handler and you must explicitly tell @EventBusSubscriber that it is a client-only event handler (by passing Dist.CLIENT). You cannot create registry entries in static initializers (here, here). Use the appropriate registry events or DeferredRegister. You never register the sound events you create here. Do not use a "base class" for blocks and items (BlockBase, ItemBase, BlockItemBase in your case). Using inheritance for code-reuse is an antipattern. You are now extending BowItem, because I told you to use the "item use" mechanic as seen in the bow. I did not tell you to extend BowItem. You also completely bypass the most important method of BowItem, because you override it without calling super: onItemRightClick. You need to call setActiveHand so that the game knows the Item is being used. onItemRightClick will not trigger again then until right click is released (or the max use duration is reached). Again: Look at BowItem. Don't extend it.

How do i give something back to the player when he crafts something like the bottles or buckets?

Use JSON. https://github.com/MinecraftForge/MinecraftForge/blob/1.15.x/src/generated/resources/data/forge/tags/items/arrows.json

This is a known issue, we're looking into it. Add -Dfml.earlylaunchwindow=false to your JVM args as a workaround for now.

i don't think there is any better way, then copy & replace.

Instead of asking, try it. We'll be here if it doesn't work

Heyo o/ This can be marked as solved, For future people with similar problems, the issue comes from us using model inheritance and having the overrides on the ancestor model. Essentially our GenericSpellBook class gets instantiated for every spell there is in our mod, this means we have to have many different item JSONs, and we wanted to spice them up with textures. In trying to find a good way to do that we tried property overrides. We gave up on this after this post and switched to making our datagens do alot of the grunt work, but I re-visited it and put overrides on the individual JSONs and it worked. Tl;DR Don't do: Item_Model.json { "parent": "mod:item/parent_item" } Parent_Model.json { "parent": "item/generated", "textures": { "layer0": "gramarye:item/book/loot_spellbook" }, "overrides": [ { "predicate": { "gramarye:element": 0, "gramarye:level": 0 }, "model": "gramarye:item/book/spellbook_fire_novice" } ] } Spellbook_fire_novice.json { "parent": "gramarye:item/book/spellbook_base", "textures": { "layer0": "gramarye:item/book/loot_spellbook", "layer1": "gramarye:item/book/fire", "layer2": "gramarye/item/book/novice" } } Do this: Item_Model.json { "parent": "item/book/looted_fire_novice", "overrides": [ { "predicate": { "gramarye:booktype": 1.0 }, "model": "gramarye:item/book/crafted_fire_novice" } ] } crafted_fire_novice.json { "parent": "item/generated", "textures": { "layer0": "gramarye:item/book/crafted_spellbook", "layer1": "gramarye:item/book/fire", "layer2": "gramarye:item/book/novice" } } looted_fire_novice.json "parent": "item/generated", "textures": { "layer0": "gramarye:item/book/loot_spellbook", "layer1": "gramarye:item/book/fire", "layer2": "gramarye:item/book/novice" }

At the moment this is only possible with right clicking. Left clicking does not transmit the ray-trace information to the server. You'd have to catch LeftClickBlock event clientside, get the ray trace and send it over in a custom packet.

There is no direct way to check for "uncooked" vs "cooked". However you use a check for food (ItemStack#isFood) in combination with a check for smelting recipes (if a food item is smeltable it's probably uncooked and if a food item is a result of a smelting it's probably cooked).

BooleanProperty

Use capabilities.

Ok, but you didn't add your block/item to an existing ore tag (eg iron, gold) you created a new ore type (which is fine) but then didn't tell forge that your new ore type was an ore by adding it to the ores.json list (which is what your code is grabbing): https://github.com/MinecraftForge/MinecraftForge/blob/1.15.x/src/generated/resources/data/forge/tags/items/ores.json

404 Repository Not Found But here, have an example: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/data/forge/tags/items/ores/iron.json

any error msgs?

The button constructor now takes a lambda reference for what happens. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/client/gui/FilterGuiContainer.java#L91 I just mapped it back to actionPerformed, but because its a lambda, you can make each button take in a method that only matters for that button.

Yes. No. You don't need to change the hitbox. Just subscribe to an attack event and change the way hitbox are calculated in an attack.

Howdy The problem is here; you mixed up short (2 bytes long) and float(4 bytes long) so your UV was overwriting dud values into the baked skylight+blocklight. private void putVertex(BakedQuadBuilder builder, Vec3d normal, double x, double y, double z, float u, float v, TextureAtlasSprite sprite, float r, float g, float b) { //ImmutableList<VertexFormatElement> elements = builder.getVertexFormat().getElements().asList(); ImmutableList<VertexFormatElement> elements = SLAB_BLOCK.getElements().asList(); for (int j = 0 ; j < elements.size() ; j++) { VertexFormatElement e = elements.get(j); switch (e.getUsage()) { case POSITION: builder.put(j, (float) x, (float) y, (float) z, 1.0f); break; case COLOR: builder.put(j, r, g, b, 1.0f); break; case UV: switch (e.getIndex()) { case 0: float iu = sprite.getInterpolatedU(u); float iv = sprite.getInterpolatedV(v); builder.put(j, iu, iv); break; case 2: builder.put(j, (short)0, (short)0); // error is here break; default: builder.put(j); break; } break; case NORMAL: builder.put(j, (float) normal.x, (float) normal.y, (float) normal.z); break; default: builder.put(j); break; } } builder.setApplyDiffuseLighting(true); } Due to non-defensive coding assumptions in IForgeVertexBuilder, it was taking your incorrect slBaked value (2047 instead of 0), overwriting the skylight (15), leaving a packed texture coordinate with zeros in the least significant bits, i.e. effectively 0 skylight = dark. default int applyBakedLighting(int lightmapCoord, ByteBuffer data) { int bl = LightTexture.getLightBlock(lightmapCoord); int sl = LightTexture.getLightSky(lightmapCoord); int offset = LightUtil.getLightOffset(0) * 4; // int offset for vertex 0 * 4 bytes per int int blBaked = Short.toUnsignedInt(data.getShort(offset)) >> 4; int slBaked = Short.toUnsignedInt(data.getShort(offset + 2)) >> 4; bl = Math.max(bl, blBaked); sl = Math.max(sl, slBaked); return LightTexture.packLight(bl, sl); } It works fine now... -TGG

Howdy You might find this working example of nbt storage in items useful https://github.com/TheGreyGhost/MinecraftByExample see mbe12 You could use capabilities, but that is probably unnecessarily complicated for what you want to do, by the sound of it -TGG

Note that the method only has to be static if you are registering the event subscriber class with @EventBusSubscriber. It should be non-static if an instance of the event subscriber class is constructed and registered via the event bus' register method.

That would send a packet for every entity in the world, which is rather inefficient considering that when the time stops, all the values in the velocity would be 0. I would suggest making a separate packet for time stopping and time continuing. Moreover, I would suggest to send a list of all affect entities in one packet. However, if you really want to update the velocity individually, change the velocity of the entity directly and call Entity#markVelocityChanged. This will make the game sync the entity's velocity on the next tick (therefore custom packets are not necessary) (this would send a packet for each marked entity, which would be inefficient on a large scale). I'll check the arrow problem out, but I think it might be caused by the arrow's still picking up downward velocity from gravity every tick. In one of my mod I implemented a similar time stopping concept, and circumvented similar problems by keep setting the velocity of affected entities to 0. The client logic is similar to: listEntity <- a list of entities affected by the time stop; onStopPacketReceive: add specified entities to the list; onContinuePacketReceive: remove entities from the list; onTickEvent: set the velocity of all entities in the list to 0;

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

http://tutorials.jenkov.com/java-reflection/private-fields-and-methods.html

I don't know about that public class FireworkRocketEntity extends Entity implements IRendersAsItem, IProjectile The class CLEARLY implements IProjectile.

This is a problem. You can't share data across sides like this. You have to pass any data that your container factory needs through the network. On the server side, when opening the GUI use the openGui variant that lets you write data to the PacketBuffer. Then on the client side read the same data back. For an entity write it's ID (Entity#getEntityId) and then get the entity back (World#getEntityByID). You cannot access client-only code here, this is common code. Use the data that is passed to you. You get the inventory (and by that the player and world). Use it.

And this is why my first reply was an attempt to get you to think about your problem.

@MistaOmega Thanks.

Why don't you use Entity#isAirborne? Also, you should use this to get if a keybind is pressed, Minecraft#gameSetiings#"insert keybind here"#isPressed.

But I'm not sure if you can use that information during mod loading.

Yes, OP's question was how to avoid this. @TDplay You need to use PlayerEvent.BreakSpeed.

You need to create your own class (preferably enum, it’ll be easier) and let it implement IItemTier as an interface. You’ll need to override all the methods of IItemTier in your new class - look at what the vanilla one does, and just replicate its functionality. Then you can just use your MyModItemTier.SOME_MATERIAL in the constructor of your new tool Items.

private static BlockState updateDistance(BlockState blockState, IWorld world, BlockPos blockPos) { int i = distance; try (BlockPos.PooledMutableBlockPos pos = PooledMutableBlockPos.retain().setPos(blockPos)) { loop: for (int k = -1; k < 2; k++) { for (int l = -1; l < 2; l++) { for (int m = -1; m < 2; m++) { if (k == 0 && l == 0 && m == 0) continue; pos.setPos(blockPos.getX() + k, blockPos.getY() + l, blockPos.getZ() + m); i = Math.min(i, getDistance(world.getBlockState(pos)) + 1); if (i <= 1) break loop; } } } } return blockState.with(DISTANCE, Integer.valueOf(i)); } distance is 7, I just did this so I can easily control it.

Check the DistExecutor class.

Alright, I've found out the existence of the Feature class but i dont know how to use it. Please help

Update: ITS WORKING Screenshot: Next on the list: Smooth Lighting