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.

Your block does not have a HALF property.

This is still being worked on, so even if you cobble something together, there's a good chance it would break in the coming days/weeks while a dimension registration setup is designed/implemented. At the moment, from what I understand, there is only 1 very busy person that has the ability to do mappings stuff, so best thing is to just be patient, and they'll get updated eventually. There is a new system in the works that should make it much easier to update mappings, but again, people working on this for free when they have time, so we have to be patient. As 1.16.1 is still being worked on quite a bit, bugs being found/fixed, etc., there's not a definitive list of changes yet, I'm sure once things settle down, there will be. If you want bleeding edge info and discussion on the new version, I would suggest visiting the forge discord and seeing what's being discussed there.

Query the Forge BLOCKS registry. It should have everything you need.

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

1.15.x is our new Long-Term Support candidate. I presume it'll remain the default until the grace period ends and we move to 1.15.x & 1.16.x, by which point the default branch *should* move to 1.16.x. Can't be certain though, because we're a long way away from a recommended build. Early beta, you see.

I did find the git branch, my eyes probably skipped over it. But I did check. Either way, the earliest change on the branch/build isn't even 24 hours old yet. It was committed at near-midnight last night.

displayGuiScreen takes a Screen, not a XPTransferScreen. So the JVM has to load both classes to see if they are compatible when loading your class (otherwise your class would be invalid).

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

Decompiling and changing a mod without the author's permission is against our "code of conduct", and is not encouraged. There is a public git repo of MorePlayerModels here, but it is for 1.10.2 and you're on your own to update it.

Looks to be SteveKunG's Lib causing the crash. It looks like it's only used by Indicatia and More Planets, which you have neither of. I can't see why you even have it installed, so better to remove it.

Check out some of the vanilla classes that extend that same class, it looks like LoadingMessageEntry has some of them labeled. Sorry not more help, I haven't done much in the way of rendering myself.

Howdy This is a vector math calculation. 1) use the two positions to define the vector offset from the player's eyes to the block (Vec_block minus Vec_Eyes) 2) use trigonometry to calculate the angles... The LookController class shows a vanilla implementation -TGG

Howdy Look in BlockModelRenderer renderModelFlat, renderQuadsFlat IForgeVertexBuilder::applyBakedLighting The rendering of quads is a bit unusual; there is logic that takes the maximum of the world lighting and the "baked quad" lighting. If you generate your own quads in a custom BakedModel (see the mbe examples) you should be able to bake maximum light into some quads and use the world lighting for other quads -TGG

Hi There are a few examples of different ways to generate block models in this tutorial project: https://github.com/TheGreyGhost/MinecraftByExample see mbe03, mbe04, mbe05. But it mostly comes down to what you mean by "glow". For example - the lamp block glows. Do you mean some sort of animated "halo"? Do you have a "concept" art that shows what effect you're trying to achieve, or something else in minecraft that is similar? -TGG

Your answer shows that you either did not read the provided documentation, did not understand it or didn't even bother to try and apply the acquired knowledge to your existing code.

AttachCapabilitiesEvent to attach the capability to the itemstacks

This class is never used before the registry events fire, therefor the entries in it are never registered. You should use DeferredRegister in one class only, like it is shown in the documentation.

Looks right.

Funny how 144mb for an ingot means that a nugget is 16mb, which is divisible by 4, and the 144 is also divisible by 9. But oh no, a bucket is only 1000mb, meaning an entire metal block block (9 ingots) does not perfectly fit in a bucket. So no, you don't want compatibility with base 4 and base 9, but also base 10. This is as mathematically possible as perfectly tuning a piano.

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

Check your debug.log, it will probably have an error in there somewhere about it, as it looks like the missing texture colors

any error msgs?

Please learn basic Java, all the problems listed here a basic Java syntax errors, you will not receive help here if you don't know Java.

No. Yes and yes. Check out TileEntity and ITickableTileEntity.

Ah ok, now I understand what you mean. That's nothing to do with the vertex normals information, it's because of back face culling. Each quad has a direction - a front face and a back face. Usually, the back face is not drawn. The direction that the face is pointing is determined by the order of the vertices. If you are looking at the front of the face, the four vertices should be in anti-clockwise order. So if the face is pointing the wrong way, you just need to reverse the order of your vertices. For example: your left-right draws in the order of maxY, minZ maxY, maxZ minY, maxZ minY, minZ which is clockwise https://3.bp.blogspot.com/-Lh9ked7q9Lg/UejFhn9OfbI/AAAAAAAAAAY/oYem6d_fSk8/s1600/MinecraftCoordinateSystem.png Instead, add the vertices in the opposite order, i.e. minY, minZ minY, maxZ maxY, maxZ maxY, minZ -TGG

Why are you using #getHitVec? Check if mop instanceof BlockRayTraceResult, and mop.getType() == Type.Block. Then, cast mop to BlockRayTraceResult, and call #getPos. if (mop instanceof BlockRayTraceResult && mop.getType() == Type.BLOCK) { BlockRayTraceResult bmop = (BlockRayTraceResult) bmop; BlockPos pos = bmop.getPos(); I'm fairly certain that if mop.getType() == Type.BLOCK, then mop is definitely BlockRayTraceResult, but better check instanceof to be sure that mop is not null. I'm not sure, but I believe #getHitVec returns the vector in which the ray from the player's mouseover intersects the block's collision box. However, due to the fact that we have a [-0, -0] XYZ coordinate which does not have a corresponding block coordinate, ([-0, -0] in XYZ = [-1, -1] in blocks), converting the hit vector to BlockPos will result in a loss of 1 unit coordinate in the north and west directions.

I'd recommend a modeling program like Blockbench, it's what I use for all the models in my mods. It has a built in brush tool for creating a texture, but I'll usually use Photoshop or something if I want the texture to look a bit better, if you're trying to make a default block model, I believe it's just a 16x16 cube, hope this helps!

Use the BlockBreakEvent Get the player's lookVec Do some vector math Break some more blocks (you may wish to do so by first firing off new BlockBreakEvents so that your pickaxe can't break blocks that are in protected areas (other mods cancelling the event, if so, don't break the block) and you will need to insure that when your own event handler is fired again for these positions that you don't do anything).

Howdy You have a couple of options; if you just want to generate a flat "pizza box" model with your texture, you can use any of the methods in these example classes https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe04_block_dynamic_block_models/AltimeterBakedModel.java https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe21_tileentityrenderer/RenderQuads.java or BlockModel::bakeVanilla If you want to generate an item model with 'holes' in it, similar to vanillla, then look at ItemModelGenerator to see how vanilla does it or ItemLayerModel forge extension for further clues. Haven't done that myself.... -TGG

When I get this type of error it's normally a sign that I've changed my code (eg added a new item) and re-used an old save. As a rule I always generate a new save after making significant code changes, I've been bitten a couple of times by weird behaviour that looks like a bug in my code but was actually just because I was re-using an old save. -TGG

[FIXED] Silly me... ... when testing the code I last posted, I was attempting to place a stack of honey bottles instead of a single honey bottle... Otherwise, it works fine. Thank you to all who replied.

class Ticker extends ITickable{ static int timer = 0; static boolean pressed = false; static boolean doublePressed = false; static void tick() { if (Minecraft.getInstance().gameSettings.keyBindLeft.isKeyDown()) { if (!pressed) { if (timer < 8) { doublePressed = true; } timer = 10; pressed = true; } if (doublePressed) { //do stuff } } else { pressed = false; if (doublePressed) { doublePressed = false; timer = 0; } } timer--; } } I honestly don't know if this will work, but this is how I think it should work. Obviously you can improve on this, but the idea is to make sure that the second press doesn't happen too soon.

Well, it seems as if the problem was that there was still a daemon running, after simply running gradlew --stop it worked fine.

Hmm, but I managed

Thanks, I got it! (For those who want to know, here is the code) @Override public IBlockState getStateForPlacement(World world, BlockPos pos, EnumFacing facing, float hitX, float hitY, float hitZ, int meta, EntityLivingBase placer, EnumHand hand) { return super.getStateForPlacement(world, pos, facing, hitX, hitY, hitZ, meta, placer, hand).withProperty(FACING, placer.getHorizontalFacing()); }