Choonster

Interestingly, the furnace uses TileEntityFurnace#func_174904_a to determine the cook time of the item being smelted, but this always returns 200. It doesn't look like Forge provides any hooks for changing this value, but you may be able to file a suggestion in the Suggestions forum or a pull request on GitHub to implement a hook for it. Forge does provide the IFuelHandler interface for determining fuel values (burn times), but this isn't used for vanilla fuels and the highest value returned by any fuel handler is always used.

You can subscribe to FillBucketEvent to allow the vanilla bucket to pick up your fluids. You may want to make sure the Fluid being drained is one you've actually specified a bucket model for, otherwise you'll end up giving the player an item with no model. There's no equivalent of this event for the glass bottle; but you could subscribe to PlayerInteractEvent (with the RIGHT_CLICK_AIR action), check that the player is holding a glass bottle and looking at one of your fluids, give them the appropriate filled bottle and then set useItem to Result.DENY . How you implement the bucket item itself is up to you, you can either use metadata or NBT to store the contained Fluid . If you're using metadata, you can register it with FluidContainerRegistry . If you're using NBT, you can implement IFluidContainerItem (or extend ItemFluidContainer , the default implementation); FluidContainerRegistry doesn't support NBT-based containers. You can see my FillBucketEvent handler here and my bucket item here. A lot of this logic is adapted from the vanilla bucket.

Keybindings are client-only, but the server is in control of the game. Changing things on the client will just get them overwritten by the server's values. You need to handle your keybindings client-side and then send a packet to the server telling it that the key was pressed so it can take the appropriate action. diesieben07 has a tutorial on the Simple Network Wrapper here, there are probably several keybinding tutorials out there.

Are you talking about the type of the field that holds the instance or the type of the instance itself? The type of the field doesn't matter (as long as it's compatible with the instance's type), the type of the instance determines the behaviour of the block/item. ItemGlassBottle overrides Item#onItemRightClick to decrement the stack size and add a water bottle to the player's inventory when they right click while looking at water. This is hardcoded to detect water and add a water bottle, so if you wanted to do the same thing for your own liquid you'd need to override the method yourself. Since ItemGlassBottle doesn't add any other behaviour, there's not much difference between extending Item and ItemGlassBottle . BlockAir overrides several methods to make it completely invisible and untouchable, so it's probably easier to extend it or instantiate it directly when making a similar block than extending Block and overriding the same methods to do the same thing.

There's a space between java and -Djava.net... .

You tried to access a GuiScreen field on TConstruct's TabRegistry class, which doesn't extend GuiScreen . Edit: Disregard this post, I misinterpreted the error.

Only ever download mods from their official site or a trusted modpack launcher like FTB, Curse, ATLauncher, etc. Don't use sites like Skydaz.

It looks like it was still loading when the log stopped. The only real errors I can see are related to Reika's mods (DragonAPI, RotaryCraft, ElectriCraft) missing signatures and DragonAPI having a blank access transformer class specified, but these happen quite early on and don't seem to have stopped the game. Try re-downloading the latest versions of these mods.

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 .