Choonster

It looks like the _JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variables is applied before the actual command-line arguments, so Java will use the maximum memory specified by them instead of the launcher's JVM arguments. Try deleting the environment variable(s) and making sure you only have the one [b]-Xmx[/b] argument specified in the launcher. Don't bump threads. Someone will post when they have something to say, bumping will just annoy people.

Are you sure you removed the first [b]-Xmx[/b] argument?

Same crash and same problem: You have two [b]-Xmx[/b] arguments.

Did you put the code in src/main/java and the assets in src/main/resources?

I think I was just looking at a different section of the log. The arguments are printed twice: once from Reika's DragonAPI (though it's not printed with a named logger, so it just shows as "FML") and once from the fake crash report generated by SplashProgress . These are in a different order to each other.

Your current arguments are [b]-Xmx512M[/b] -XX:+CMSIncrementalMode -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -XX:-UseAdaptiveSizePolicy -Djava.library.path=... -XX:+UseConcMarkSweepGC -Xmn128M [b]-Xmx5G[/b] (notice the two [b]-Xmx[/b] arguments). Delete the first [b]-Xmx[/b] argument.

Other way around, but yes. Are you sure? The default arguments for a profile are -Xmx1G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M , the latest log shows 512M at the start and 5G at the end.

This is the same crash as before. You added -Xmx to the end of the arguments, but the default arguments include it at the start. Remove the original -Xmx argument.

It looks like your TileEntityHeatPress#updateEntity method is calling TileEntityHeatPress#getRenderBoundingBox , which is then calling the super method. This throws a NoSuchMethodError because the super method doesn't exist on the server. You should avoid calling getRenderBoundingBox outside of client-only code and also mark it as client-only with @SideOnly(Side.CLIENT) so it's removed from the class on the dedicated server.

Forge doesn't provide the ability to change the location of the vanilla server config files (unless you specify a different location for the game directory, but that changes the location of everything else as well). The only command line arguments added by Forge are --mods (a comma-separated list of extra mod files to load) and --modsListFile (the path to a JSON file containing a list of extra mod files to load), Forge will pass all other options to the vanilla server. Vanilla supports the following arguments: --port <PORT> - The port to listen on. --singleplayer <OWNER> - Run the server in single-player mod with the specified owner. --universe <FILE> - The location of the Anvil file(?) This isn't actually used anywhere, it's probably a leftover from older versions. --world <DIRECTORY> - The location of the world directory. --demo - Run the server in demo mode. --bonusChest - Enable the bonus chest. --nogui or nogui - Run the server without the management GUI. The loop at the end of your script should work if you change it to run the Forge JAR and remove all of the Bukkit command line arguments.

The field isn't called field_146292_n in the development environment, it's called buttonList . You need to check both names. Look at (or use) FML's ReflectionHelper and ObfuscationReflectionHelper classes to see how they handle this. If I need to access a non-public field/method more than once, I'll usually use ReflectionHelper.findField / ReflectionHelper.findMethod and store the Field / Method object instead of looking it up each time.

Java ran out of memory. Increase the amount of memory Java is allowed to use by editing the value of the -Xmx argument (use 1G for 1 GB of memory). In the Mojang launcher, you can do this in the Profile Editor. Large modpacks usually require at least 2-4 GB of memory

So the server crashes? Upload the server's log/crash report to Gist and link them here. Uploading the class(es) involved in the crash to Gist would also help diagnose the issue.

ModModelManager#registerAllModels is called from CombinedClientProxy#preInit (this is only loaded on the client, the dedicated server loads DedicatedServerProxy instead), which is in turn called from TestMod3#preInit . registerFluidModel registers the model for a single IFluidBlock : The call to ModelBakery.addVariantName without any names prevents any model being loaded for the Item form of the IFluidBlock . If you don't call ModelBakery.addVariantName for an Item , the model with the same name as the one passed to GameRegistry.registerBlock / registerItem will be loaded. The ModelResourceLocation defines the location of the fluid's model ( testmod3:fluid with the Fluid 's name as the variant) The call to ModelLoader.setCustomMeshDefinition tells Minecraft to always use the model defined by the ModelResourceLocation for the Item . MeshDefinitionFix is an interface created by diesieben07 that allows a lambda to be used as an ItemMeshDefinition (this is needed because ForgeGradle doesn't know how to reobfuscate lambdas). If you're not compiling against Java 8, you'd use an anonymous class instead of a lambda. [*]The call to ModeLoader.setCustomStateMapper tells Minecraft to always use the blockstates file and variant defined by the ModelResourceLocation to get the model for the Block The fluid.json blockstates file tells Minecraft to use the forge:fluid model for each variant, passing the name of the fluid to render in the custom data. Forge's fluid model acts as both a Block and Item model, using a 3D model for the Block and a 2D model for the Item . Block#setCreativeTab works without issue on fluid blocks, but a Fluid isn't a Block and thus doesn't have a creative tab.

You've installed a coremod built for 1.7.10 in 1.8. Only install mods for the version of Minecraft/Forge you're running.

Does com.ec.lib.CustomGui.InvGui reference any client-only classes (i.e. classes annotated with @SideOnly(Side.CLIENT) )? If it does, you can't use it on the server side unless the fields/methods that reference the client-only classes are also annotated with @SideOnly(Side.CLIENT) .

You're calling ClientProxy.registerRenders (which presumably references client-only classes) on both sides, but this should only be called on the client side (from within the ClientProxy class). Either call it from ClientProxy#registerTileEntities or make a new instance method in ServerProxy , override it in ClientProxy to register your renderers and call the method on MainRegistry.proxy .

No, my code passes the Fluid to the BlockFluidClassic constructor. You're trying to pass the Block to its own constructor.

In getRemainingItems , you're overwriting the damaged tool with the default container item returned by ForgeHooks.getContainerItem . This will be null unless the item has a container item specified. You should only call ForgeHooks.getContainerItem when the item isn't a tool.

The actual exception that caused the crash is being hidden by an exception thrown from the crash report code. This is due to Minecraft being rebuilt without debug information by ForgeGradle and has been fixed in ForgeGradle 2.0.2. I'd suggest updating the plugin in your build.gradle, re-running setupDecompWorkspace , refreshing your IDE project and posting the new crash report. Edit: The itemstack argument of isTool will be null if there was no item in the slot. Check that it's not null before calling ItemStack#getItem on it.

Post the isTool method and the crash report. I'm guessing you're calling ItemStack#getItem on a null value.

That simply declares a field and assigns the default value ( null ) to it. At that point, you haven't created a Block instance or assigned it to the field. BlockFluidClassic doesn't have a (BlockFluidClassic, Material) constructor anyway, so why are you trying to pass the mercury block to its own constructor? Side note: Use the [nobbc][tt][/nobbc] tag (or the Tt button) for inline code.

Recent versions of ForgeGradle put the MCP mappings in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_type>/<mappings_version> (replace ~ with %USERPROFILE on Windows).

Looking at Thermal Dynamics in a decompiler, the fields in TDItems are never actually initialised. To get a duct ItemStack , get the appropriate Duct from the TDDucts class and then use the Duct#itemStack field.

EntityLivingBase#getHeldItem will return null if the entity (the player, in this case) isn't holding anything. You need to check that it's not null before calling ItemStack#getItem on it.