Leaderboard

Minecraft 1.12: The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum. Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do. New Policy on Coremods: Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices. 1) Coremod must be the coremod only, and no extra library/features/apis/etc. There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run. 2) Coremod binaries must be signed. This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage. For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack. For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html 3) Coremods should be visible source. This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it. The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods. Major Policy change: I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc.. In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements. It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out! Response From Sponge:

You already get a random blockpos to generate the structure at. Just check the block below it with World::isAirBlock for example. You can get any blockstate at any position using World::getBlockState. You should also inspect the way vanilla does things like that before asking for help. Vanilla code usually contains samples for 90% of commonly used things.

You can't cast a Block to a IBlockState as Block is not an instance of IBlockState. Your IDE shoud've marked every line like that as an error and that code would not even compile. This is the entry method that gets called once each chunk. Yours is absolutely empty so your code will never run. This point of mine still stands. Your method is still empty, even after the changes. This is the method that gets called as a chunk generates, not any other method.

TE knows what the data is. --done TE changes and sends a packet with the changed data. --half done Client gets the packet and changes its local copy of the TE. --missing entirely Client re-renders. --done

Your render registration must be done in pre-init for entities. For items/blocks use ModelRegistryEvent. Registering items/blocks must be done in RegistryEvent.Register that is appropriate for the object(RegistryEvent.Register<Block> for blocks, RegistryEvent.Register<Item> for items/etc). Even if you are not yet using new versions of forge you should still use event registration system so you will not have to rewrite all your code when you do decide to update. At the very least you should register your models and renderers using pre-init, not init, if you refuse to use the ModelRegistryEvent for one reson or another. Why are you using RenderManager directly? You should use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory). Client-side only code can't be located in common classes or you will crash the server. It must either be located in your client proxy or in a class that you know for sure will not get loaded on server.

You have infinite recursion all over this method. The method calls itself on like every line but the first 4. That will not work well. Also this way of generating structures will make it nearly impossible for you to change the structure in the future. Consider using structure blocks/Template to generate your structure. This is the entry method that gets called once each chunk. Yours is absolutely empty so your code will never run. Casts like these are redundant as IBlockState::withProperty returns an instance of IBlockState. On a side note this constructor is as undescriptive as it gets. What are u/i/a supposed to be? Why is there a boxed Boolean? Why is it named f? Why do none of these parameters do anything but the b one? Do you yourself understand what this constructor is supposed to do? You probably should not just leave empty stubs like that in your code. If you are generating a method autoaticaly - fill it in then, there was a reason you generated it, was there? Is it not supposed to do anything? Why have you generated it then?

There is no user interface for Forge. If you successfully created a new profile and selected Forge then you are up and running. All you need to do now is copy the mods you want to run into your .minecraft/mods folder (for example C:\users\username\appdata\roaming\.minecraft\mods) the appdata folder is hidden by default so you'll need to set your folder view options to show hidden files and folders.

I am trying to add the old mod Greg tech to the new direwolf20 mod pack but I am unable to get my game to accept and use the greg tech mod. Is there any way I can do this or does "newer" versions of forge not support older mods?

What I did was to just put Entity#setSize([width of grown animal] * [a factor that goes from the smallest size* when it's a baby, up to 1 when it's an adult], [height of grown animal] * [the same factor]); in EntityLivingBase#onLivingUpdate. In order to calculate the factor I would need to see your code for handling aging, unless you could figure it out yourself? *By the smallest size I mean say if the smallest version of the animal was 20% the size of the adult one, the "smallest size" would be 0.2, if it was 10% it would be 0.1 etc.