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:

Try setting the "ambientocclusion" tag to false in your model file.

Hi Kander16, I can try to help clarify some things with the new 1.12 recipe formatting: As far as I know of with the shaped crafting recipes go, you are only allowed to 1 shape per .json file, thus requiring 2 files assuming you still want those same configurations. Also for the shapeless recipes and the id's of the materials used. I experienced this as well but I had to change it to if I had more than one of the same thing I had to repeat the entry instead of using the ["count: X]; however, because Forge 1.12 is still in the early works, it's possible this could or couldn't change. And as for the last one, I can't help you there as I've never messed with the OreDictionary.WILDCARD_VALUE too much. But I hope the rest helped you somewhat!

And wrap that log in a spoiler tag.

It might be an issue with MCP mappings where mods use latest mappings but your deobfuscated MC is not. I remember thePlayer being renamed to player and theFontRenderer to fontRenderer at some point. I suggest checking the actual names of fields in Minecraft class.

Okay, so then you fix that error. If you get a new problem when you make a step forwards, you shouldn't step backwards - you should fix the new problem. Where in the code do you open the container?

Yes it will. And the next thing it will do is load your TE from NBT data, which contains your storage data aswell. In the end you will end up with the new storage object being identical to the one you had when leaving the world.

From what I can see here you are only sending a packet to the player if this condition is correct: the getter is fine, but the energyLevel is not. You set it 2 lines above as and then you reduce the energy level by loss of energy. If something modifies the energy level of your tile you will not have that change handled here. This way of handling energy changes only handles energy loss, not gain and that is what you are observing. You need to figure out a different way of handling energy changes, maybe have something like energyLevelLastTick as a field in your TE, have that set at the end of your update and compare against it at the beginning. As long as you read and write your energy storage to TE's NBT data it won't reset. What makes you think that it resets?

Simply : @Override public void init(FMLInitializationEvent event) { super.init(event); ItemModelMesher mesher = Minecraft.getMinecraft().getRenderItem().getItemModelMesher(); YourClass.initClient(mesher); }

You're right, and thanks for the politeness. I'm super interested in modding tho. Congrats on the fix!

Your assets folder is misspelled. assests

If villagers aren't returning an IItemHandler but are returning an IInventory, then.... SHOCK, MAGIC Don't use the IItemHandler slots and use regular slots like you're already doing with the player's inventory.

If you are making a mod then you should have access to the Entity class. If your not making a mod then i do not believe this is a section for you although i do appreciate you trying to help.

I don't think so. Modifying code via bytecode manipulation requires extensive knowledge of the JVM stack and instruction set. You can't really "copy-paste" an injection and expect it to work on a new class. It might work, it might not. To Lex: I support these changes. I will continue to advocate that things should be done through forge and will likely not help people learn how to use ASM, at least not in a public setting, but I would instruct (to the best of my ability) how to coremod safely. I did a lot of it in 1.7.10 (and I'm not necessarily proud of it) and for the folks that merit knowing should be informed. Maintaining compatibility is important. The one thing we will want is an easily accessible guide on signing jars and how to share the singing details correctly. It definitely isn't something i know how to do off the top of my head and I'm not confident that I'd be able to search out a solution either. (Can I search, sure, but I read between the lines that there might be a step that has to be done a certain way and don't know if I would be able to find details). I'm also glad to see the appointment of someone to handle lingering PR requests and filtering, I know I had some that took a while to be approved. Even if in some cases it was my own fault for not following the guidelines, but again, best practices aren't something most people can pick up in an afternoon. Its easy to make mistakes (like knowing that X mistake was made in several places) and I know you don't have much time to impart that knowledge yourself. Don't hesitate to find a few helpers for Mezz, as well. Don't want to see him getting bogged down either.