LexManos

Just update Forge, and edit the config file.

We added a config value for this because of stupid mechanics like this. Honestly you should just toss down and chunk loader it'll make your server quite a bit more performant. https://github.com/MinecraftForge/MinecraftForge/commit/2df36137c2c995b5d12f1e8b7db101b47650b570

Yes, but Optifine is not a Forge mod. It is a major closed source coremod that screws with a lot of Minecraft's internals. We can't support that. It's on him to specify what Forge versions he is compatible with. This is simply how it works.

Logs

Optifine will need to update, nothing we can/will do on our end.

No

The bounding box for file entities only apply if the chunk the tile entity is in is getting rendered. You're looking up which is causing the chunk with the TE in it to be culled. You're better off splitting the OBJ into peices and rendering those. Also if it's a static object like this, rendering large amounts every frame is not good.

That may be a concern, there will always be copy pasta. But Honestly that is easy enough to do these days and SUPER easy to do wrong. So I think itd probably just increase the quality of the copy pasta. As for config stuff, that is to specific, we're not saying ANYTHING about functionality. Just guidelines on packaging.

Ah adfocus is having issues, this is why we provide direct links in the full list. Just use those links.

Our servers are fine, make sure ou only get the files from http://files.minecraftforge.net/

You should not need a COREMOD to modify your own code. There are plenty of ways to transform your own code without the use of a coremod. The intention of this is for people modifying OTHER's code.

Yes, Forge supports mutual dependencies. As long as you don't define both requiring to load AFTER each other. It should just detect that ModA wants ModB in the list, and ModB wants ModA in the list. The intention of #1 is to allow those who care about coremods to go in and figure out what is relevant to the coremod, the things that edit bytecode. It's to help prevent people from hiding things amongst 500 different classes that don't touch bytecode. On top of that it is also a technical thing. If the coremod code is separate from the mod code we can better manage the classpath and classloaders. We have had many issues over the years of people including APIs in coremod. Which screws over our ability to sort and verison APIs so that the one available is the one people want. I kinda expect that once people see start using the Jar-in-Jar stuff, {which I admit needs fleshing out and documentation} that people will stop fat-jaring APIs but instead include them as a internal jar. And let Forge pull out the ones that best suit the environment based on what mods say they need.

If you USE mixins, things should be baked down into metadata that Mixins{Mumfrey's library} loads. That data {Usually the compiled classes and whatever other metadata Mixins create} should be separate from your mod and signed. And the source code that generates that data should be visible in some way. If you require a coremod in your main mod, Just add 'required: mymod_coremod' to your @Mod. If you require a mod from your coremod {such as the handlers for the mixins you do} then you can add the mod as a dependency to the coremod.

I have made no secret, FastCraft is one of the thing we had in mind coming up with these policies. It's a obfuscated coremod that harms more computers than it helps. And the author is an ass when you try and understand it. Even going so far to threaten to sue you multiple times if you even THINK about looking inside it. FastCraft is cancer on the community, People need to stop using it.

Feel free to explode if a coremod is installed without its handler mod. We already have a mechanic for depending on other mods, so you can do normal dependency resolution. Tweakers are considered coremods for this policy, Its all the same thing. As for Mixins I've already spoken to Mumfey and he's on board with this. He just needs to sign the Mixin library and he'll be good. However, Mixins is a special case in regards to #1. Its entire point is to be a library for other coremods so there isn't anything to 'separate' out. The intention is to stop coremods being required by mods who dont NEED them because they use a central/popular library.

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:

Unless something majorly screws up our installer CANT download corrupt libraries as everything is checksumed. If things DO error then we need logs because it will scream the error in the logs. It sounds like you're going through a hosting provider that is doing something rather wrong. So go talk to them. Beyond that, go update to 1.11.2 at least if you want support on this forum. As for what is a error deserving of being on github, if you're not a modder. Then you shouldn't be making issues. Errors must also be verified to be EXCLUSIVELY Forge's issue. 10 seconds of searching would of found the same issue on this forum, and google, as its not a bug on our end. Anyways this doesn't need to go on anymore, point is use the forums for tech support and don't argue with me on github when I tell you nicely that that's not the place for stuff -.-

Give a full directory listing. MD5s of the files you're using Exact command and working directory that you're running. Give some actual details. You say you're a server admin. Yet you provide nothing for us to even try and help you. As Cloudy has said, this issue is caused by the server not being able to find the minecraft jar file. The minecraft jar file MUST be in the current working directory and have the EXACT name "minecraft_server.1.12.jar" All of this is setup properly for you by the installer. Hence not our bug. Bitching about my 'professionalism' will get you no sympathy. I told you to go to the forum because its a PEBKAC error NOT a bug and then you argued with me so I locked it.

We do not support crawling out site.

User was banned for using a cracked launcher

Tamas just updated Mercurious so this should be resolved. Im going to push a ASM library fix in a few mins. Edit: Oh wait its the updater, ya he hasn't done that yet. He'll do that in a few mins.

I'm the one who updates MCP, I updated it a few days ago. It'll be released whenever. But ya, experimental builds are up. THEY DO ERROR and there is missing APIs. So be warned. It'll take a couple more days of work, just be patient.

1.12 is in dev, dont use it.

make your workspace literally ANY other folder except the project folder A workspace can not be inside a project.

Dont have your workspace in your project.