Choonster

Arrows deal damage to the entity they hit in EntityArrow#onUpdate (lines 292 to 316 in Forge 1.8.9-11.15.1.1763). This is determined by multiplying the arrow's base damage with its motion (the magnitude of the vector composed of the motionX / Y / Z values) and then adding a random bonus if it's a critical hit. The base damage of the arrow is set when it's fired from the bow, this is 2.0 by default. If the bow has the Power enchantment, it adds 0.5 damage plus a further 0.5 damage for each level. Edit: The base damage is 2.0, not 20.

So pass it an IRenderFactory instead of a Render .

That doesn't tell me much. Which method are you talking about? What's the exact error message shown by your IDE?

In preInit, register an IRenderFactory for your entity using an anonymous class or method reference. In this class's createRenderFor method, create and return a new instance of the appropriate Render class using the RenderManager argument.

Because you're still creating the Render instance before the RenderManager instance has been created. IRenderFactory#createRenderFor must create a new instance of your Render class using the supplied RenderManager argument.

To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page. Don't implement IRenderFactory in your Render class. The whole point of IRenderFactory is to delay the creation of the Render instance until the RenderManager instance is created (between the preInit and init phases). Use an anonymous class or method reference to implement IRenderFactory , like I described in my first post.

I suspect the Render#renderManager field is null . Upload your the latest versions of your Registers , ClientProxy and RenderTerrakon classes to Gist/Pastebin with syntax highlighting and link them here.

You're using the index in the AllPlayers list as the index for the worldServers array. worldServers contains the WorldServer instance for each dimension. Vanilla only has three dimensions, so once you try to create more than three CustomPlayer s you're using an invalid index. I'd suggest using for-each/enhanced for loops instead of for / while loops here.

IRenderFactory is just an interface with a single method: createRenderFor . This method is called to create the Render instance for the entity class. If you're building against Java 6/7, just use an anonymous class to implement it. If you're building against Java 8, either use an anonymous class or create a constructor in your Render class with the same signature as IRenderFactory#createRenderFor and use a method reference to that constructor. Constructors implicitly return a new instance of their class, so you just need to match the arguments of IRenderFactory#createRenderFor : a single RenderManager argument.

Player data is stored in the playerdata directory of the save, with each file name being the UUID of that file's player. If both computers are on the same network, you can probably use symbolic links to link either the playerdata directories or the individual player files. Otherwise you may be able to use a service like DropBox, but that will probably require using a third party application or moving the playerdata directory or the individual player files into the DropBox directory and creating symbolic links in the original location.

You can probably use ForgeGradle 2.0.2 with Forge 1.8-11.14.3.1520, just change the version number in your build.gradle. You'll probably have to update to a newer version of Forge eventually, so I'd recommend trying the latest 1.8.9 version and seeing if you can narrow down the performance issues.

That isnt the problem, the call for that IS coming from the client proxy and not my common proxy. The code you posted shows registerTexture being called in the same method as GameRegistry.registerItem . Do you have a separate registration method for the dedicated server? I realise it's not causing the issue that this thread is about, but it will cause issues if you don't separate client-only code properly.

The substitution alias system ( GameRegistry.addSubstitutionAlias ) is supposed to allow this, but I haven't had much luck with it myself.

ModelLoader and ModelResourceLocation are client-only classes. If you register models from common code instead of from your client proxy, you'll crash the dedicated server.

You're using 2.0.2 stable, which includes the fix. Once you've set up the ForgeGradle workspace and imported the project into your Eclipse workspace, the crash in the OP should no longer happen.

"ForgeGradle 2.0-SNAPSHOT" without a number after it means you're either running an old snapshot or one of the stable versions. In your build.gradle script, have you got a buildscript block followed by apply plugin: 'net.minecraftforge.gradle.forge' (the snapshot) or have you got a plugins block (the stable version)? Most recent versions of the MDK have both of these, with one commented out. If you're not sure, upload your build.gradle script to Gist and link it here. Make sure you keep the .gradle extension so it has syntax highlighting. The eclipse folder isn't generated by Gradle, it's only included in the MDK download. I don't use Eclipse myself, but from what I understand you can create a workspace yourself and import the project generated by the eclipse Gradle task. The eclipse folder shouldn't be required.

This exception is caused by ForgeGradle not rebuilding Minecraft with debug information (see this issue). There is another exception being thrown that's the initial cause of the crash, but the missing debug information causes the crash report system to crash the game (hiding the initial cause). Make sure you're running either ForgeGradle 2.0.2 or the latest 2.0 snapshot (2532819 at the time of this post), delete the ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version> directory (replace ~ with %USERPROFILE on Windows) and then re-run gradlew setupDecompWorkspace . This should rebuild Minecraft with debug information, revealing the initial cause of the crash.

Your implementation of IGuiHandler#getServerGuiElement must return a Container , not a GuiScreen .

If the World#perWorldStorage field is public in 1.6.4, your new code is correct. The field is protected in 1.8.9, but that may be a recent change.

Any IMessage sent through SimpleNetworkWrapper can be either client-to-server or server-to-client. You just need to register the message using the receiving Side rather than the sending Side . The main purpose of a Container is to sync inventory contents between the server and client, but you can also use ICrafting#sendProgressBarUpdate to send two int s to the client-side Container (this calls Container#updateProgressBar on the client side). Container doesn't provide any way of sending other types of data or client-to-server data, you need to use your own packets ( IMessage s) for that. This tutorial explains SimpleNetworkWrapper in more detail.

The Side passed to SimpleNetworkWrapper#registerMessage is the side that receives and handles the packet, not the side that sends it. A client-to-server message should be registered with Side.SERVER . S35PacketUpdateTileEntity is usually returned from TileEntity#getDescriptionPacket to sync data from the server to the clients in the area surrounding the TileEntity . The client-side handler for this packet calls TileEntity#onDataPacket . This can't be used to send values from the client to the server.

An instance of World is one dimension, yes. There's no point in creating an ArrayList if you're immediately assigning another value to the variable. Declare the mbBlockList variable in the same statement as you're calling mbdata.getList() in. Your get method does receive a World argument, but it uses World#loadItemData to load the data from that World . At least in 1.8.9, this uses the global MapStorage ( World#mapStorage ) instead of that dimension's MapStorage ( World#perWorldStorage ).

Have you looked at the source of the World#loadItemData method? In 1.8.9, it uses World#mapStorage (global) rather than World#perWorldStorage (per-dimension).

Ah, I'm glad you fixed it. Gradle files aren't Java code, so you should have kept the .gradle extension on the Gist file. I probably should have made this clearer in my previous post, I copy/pasted it from a more general response I use to tell people how to post code properly.

I doubt this will be easy. You'll probably need to read up on how OpenGL and Minecraft's lighting system work and then modify/re-implement the lighting system using ASM. Doing this likely break compatibility with a lot of mods.