Choonster

You can also host your mod on CurseForge. You slowly earn points based on the number of people who download the mod, these points can be spent on Amazon/Steam gift cards or money via PayPal. A couple of years of WoW AddOns hosted on Curse earned me enough points for US$100, so it's not a huge amount of money; but it's better than nothing. You can also upload to CurseForge through their Gradle plugin, though I haven't done this myself.

It's entirely possible to declare a variable in any part of a method, including loops. I think you should review the basics of Java.

It shouldn't be necessary to check if it's in lava, the method should only be called if it's already known that it is in lava.

I don't think this should be in your event handler, since the item usually won't be in lava at the moment it's dropped. Entity#setOnFireFromLava will be called when the item is in lava, you should be able to override this to check for the portal activation criteria.

You should compare Item instances directly (e.g. someItemStack.getItem() == Items.nether_star ), don't compare their unlocalised names.

Call WorldProvider#setSkyRenderer with an implementation of IRenderHandler that renders the sky (including celestial bodies) for your dimension. Look at RenderGlobal#renderSky to see how vanilla renders each dimension's sky.

Break the class down into its primitive components (strings, booleans and numbers) and write those to the buffer.

Implement it in your Entity class and do what the doc comment for each method says: write your data to the buffer on the server and then read it back on the client. FML will call the methods for you, you just need to implement them.

If you need any information on the client side, you'll need to send it from the server in some way. Depending on the nature of the information, you may want to use the DataWatcher or implement IEntityAdditionalSpawnData .

Your entity class must have a constructor that takes a single World argument.

There's no such event. LivingDeathEvent is only for living entities (i.e. entities that extend EntityLivingBase ).

I think this is caused by your strange implementation of the state <-> meta conversion methods. You're treating the LIT_UP and FACING properties as mutually exclusive instead of combining them. You should store the facing index in the lowest three bits of the metadata (i.e. use the return of EnumFacing#getIndex directly) and the lit state in the highest bit (i.e. convert the boolean to 1 or 0 [true or false] and then shift it left 3 bits using the << operator). Combine the two values with bitwise OR ( | ). To extract the facing index from the metadata, AND ( & ) the metadata with 7 (0111 in binary) and convert it back to an EnumFacing with EnumFacing.getFront (the name is misleading, it just gets the facing with the specified index). To extract the lit state, AND the metadata with 8 (1000 in binary); if the result is non-zero, LIT_UP is true. I've written an example of this here. The models aren't working properly yet, but the state changes correctly when right clicked. Edit: I fixed the models.

It's controlled by the log4j2.xml file inside the Forge JAR. You can probably change it by removing level="INFO" from line 54.

This is correct. I've just been updating to the latest Forge version occasionally, since it's just a test mod I don't worry about compatibility with older versions of Java or Forge.

I'm not too sure, sorry. I just found a lot of people with the same exception message having that solution recommended to them.

This definitely sounds like a use case for a TileEntity . You should look for tutorials or look at examples in vanilla code. Players can change their name now, so you should store their UUID instead ( Entity#getUniqueID ). You can use UsernameCache#getLastKnownUsername to get the last known username of a player's UUID for display purposes.

A block in the world doesn't store any information beyond 4 bits of metadata unless it has a TileEntity . What are you trying to achieve?

Are you creating your own dimension or modifying the Overworld? If it's your own dimension, just don't generate the structures in the first place. coolAlias has a tutorial on event handling here. Jabelar has a tutorial here.

HarvestCheck is only fired if the Block 's Material requires a tool. This is not the case for Material.wood .

nolpfij_wildycraft is causing the crash, but dragonSword is also using invalid names for its items. Report these errors to the mod authors.

I'm guessing you have Forge Multipart in both your mods and mods/1.6.4 folders, which means it's trying to load the mod twice. It should only be in one of the two folders.

I'm not entirely sure, but this could be caused by Java using IPv6 instead of IPv4. Try adding -Djava.net.preferIPv4Stack=true to the Java command line arguments (Settings -> Java/Minecraft -> Java Parameters in the ATLauncher). Also make sure Minecraft isn't being blocked by your firewall.

You can download the latest version of Java from the Java website. You've cut off the parts of the log with the Java version and the OutOfMemoryError 's message. Upload logs/fml-client-latest.log to Gist and link it here.

To completely disable a specific type of structure generation: Create a class that extends the appropriate MapGen class (e.g. MapGenStrongholds ) and overrides canSpawnStructureAtCoords to return false . Subscribe to InitMapGenEvent , check for the appropriate EventType and assign a new instance of your class to the newGen field. This replaces the default generator with one that does nothing.

You cut off the start of the crash report. Post the full crash report from C:\Program Files (x86)\Minecraft\ATLauncher\Instances\CrundeeCraft\crash-reports\crash-2015-09-07_09.16.24-client.txt.