Cadiboo

Some thing is likely trying to access LWJGL (Light Weight Java Gaming Library) (The library that renders everything) before it has been set up/from another thread HOWEVER, I'm not sure this is the problem because 1.7.10/1.8.9 is so old that no-one knows how to support it anymore. Update to receive support

Directly modifying the minecraft jar has not been required or supported since beta 1.4 IIRC. Do not do it, it breaks all other mods and mod loaders, may not work at all, can cause weird issues, is a security issue and corrupts installs. Do not do it! Especially if you don’t know java, shown by

You’re directly modifying minecraft classes using MCP?

What modpack, what mod, and what happens when you use the official launcher?

Why do you need this info, what are you trying to do?

Context is everything, post your code

At least Java lets you know about it if you write your code properly, many other languages (like JavaScript) don’t.

The stuff I’ve posted is just from a list in my notes, you should read the EAQ and the Code Style post by diesieben, they have lots of good stuff

Please post your logs

Are you running minecraft 1.7.10? Post your logs

You could always just go into new chunk

Doesn’t exist Sorry, there were weird characters that I couldn't see on mobile https://pastebin.com/hhuStZgi

One of your coremods was made for <=1.7.10, and is trying to load a class that no longer exists.

Not in vanilla JSON, but the code to do it would be pretty simple, and you could also add an API allowing other people to use JSON

Also, try and post a fix for the issue

if (isTouchingLava(block)) { world.setBlockState(stateOfAnotherBlock); }

No, I also never said anything about a default constructor. You have complete control over creating your items, you just have to do it at the right time. What: Not using an object base class Why: Using an object base class (commonly called BlockBase or ItemBase) is unnecessary and is an anti-pattern. There is already a BlockBase class, it’s the minecraft Block class. Making a class just to have its children inherit default implementations of methods goes against the OOP principle of Composition over Inheritance Consequences: Using a class like this stops you from extending other classes and because lots of minecraft code uses instanceof checks to specially handle logic, you are likely to encounter weird and hard-to-fix bugs. How: Instead of putting all your common logic in 1 class and extending it, extract the logic to utility methods. For example: Instead of calling setRegistryName, setTranslationKey, etc. inside your object base’s constructor, extract it to a helper method and call it on every object when you create it. In this example "setup" calls the above methods. registry.register(setup(new CustomItem(), "custom_item")); You still have access to the registry name, just use the name you pass into the constructor

What: Using @ObjectHolder Why: Using @ObjectHolder allows you to have static field references to your objects, allows other mods to override your objects without problems related to outdated field references. It manages your static references for you, without you having to manually manage and assign all your fields yourself Consequences: Not using @ObjectHolder can result in problems with mods overriding your objects, which can lead to undefined behaviour and/or crashes. How: Put @ObjectHolder at the top of your object holding class (for example ModBlocks or ModItems). Have your modid as the parameter of the annotation. Have your field be public static final and null, and name them the same as the registry name of your object in capitals. After you register your objects (in the appropriate registry event) your fields will be automatically filled with the correct values. For example: @ObjectHolder(yourModId) class ModBlocks { public static final Block YOUR_BLOCKS_REGISTRY_NAME_IN_CAPITALS = null; } What: Using registry events Why: Using registry events paves the way for Forge to dynamically load and unload mods without restarting minecraft. Registry events are dedicated events with support for mod-sorted execution and overriding objects in the registry and/or querying the registry. Consequences: Using static initialisers can result in weird & unreproducible crashes and creating & registering your objects in preInit is no longer supported. How: In your event subscriber class subscribe to the appropriate registry event (Registry.Register<typeOfObject>) I definitely did not say this

The Thaumcraft API only contains the human readable source code, it doesn’t contain any of the executable class files. You need the obf or deobf thaumcraft jars. You can then add them to your gradle attach the “api” to them as a source in your IDE

You need ForgeGradle 3 I think

What exactly have you tried? What was the log gradle outputted? Did you refresh the gradle project after running the tasks?

Or you could use IntelliJ

Recommend Forge convention What: Not using static initialisers Why: Using static initialisers does not allow you to control when your objects are created or the order in which your objects are created Consequences: Using static initialisers prevents other mods from overriding your objects, prevents forge from being able to dynamically load/unload mods and can cause weird, unreproducible crashes. How: Use the @ObjectHolder annotation if you need static references to your objects and create & register your objects in the appropriate registry event. (Note: before registry events Modders created and registered their items in preInit. This practice became out of date in 1.7 with the introduction of registry events, and is no longer encouraged or supported) (Excuse the copy paste, it’s easier for me to do it, and it also ensures that I don’t forget to include some information)

You mean createTileEntity

Why are you initialising your blocks in a static initialiser?