Choonster

Minetweaker or one of its scripts is throwing an error while trying to undo adding a Thaumcraft research page.

Upload the full FML log (logs/fml-client-latest.log) to Gist and link it here.

There's something weird going on with your logs. The FML log just cuts out and seems to start several seconds after the MultiCraft log ends. It's not very clear what the error is, but it looks like you have some conflicting potion IDs and possibly some invalid potion IDs. The maximum potion ID is 31 for vanilla, but many mods (including Blood Magic) expand this to 255.

Thank you for the reply but I'm 17 Is that relevant? Do you understand what diesieben07 is telling you to do?

There's no error there, the log just ends with Inpure Core downloading a library.

Resource Loader is client-only.

If you have Gradle installed locally, use its installation directory as the Gradle Home. You can also just tell IDEA to use the default Gradle wrapper instead of installing Gradle locally.

Click the + button (Attach Gradle Project) in IDEA's Gradle window and browse to the other build.gradle file.

I usually just use one IDEA project per Gradle project (i.e. mod), but it seems you can attach another Gradle project as a module of the current IDEA project from IDEA's Gradle window. This is similar to using an Eclipse workspace with multiple projects (mods).

You shouldn't need to manually mark directories as Source/Resource Roots. The IDEA project should be created in the same directory as build.gradle, your code should go in src/main/java and src/main/resources, which will be automatically marked as roots. This tutorial explains how to correctly set up your project. If you're using Forge for 1.7.10 or earlier, add this to your build.gradle: // Fix resources not being loaded in IDEA // http://www.minecraftforge.net/forum/index.php/topic,32467.msg169687.html#msg169687 idea.module.inheritOutputDirs = true

Upload the full FML log to Gist and link it here.

This belongs in Modder Support, it should be moved there soon. Are you definitely adding the recipe in the init phase (i.e. is the method that adds the recipe definitely handling FMLInitializationEvent )? In your preInit method, you create an instance of ItemBerry without registering it or giving it a name. You then call ItemBerry.init and ItemBerry.register , which creates and registers an instance of Item with the name "berry" . You should register models from your client proxy instead of just checking the side in your @Mod class. Use ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition in preInit instead of the ItemModelMesher#register overloads in init. I would highly recommend creating a dedicated class to create, register and store your items (the same goes for blocks, entities, etc.) and a dedicated class to register your block/item models. You can see an example of what I mean here: I have registration classes in com.choonster.testmod3.init and my models are registered in com.choonster.testmod3.client.model.ModModelManager (called from the client proxy).

Override Item#getAttributeModifiers(ItemStack) instead of Item#getItemAttributeModifiers() .

Yes. Even in a LAN game, the players may be in separate dimensions to each other.

Does this method have the @SubscribeEvent annotation? Have you registered an instance of the class on the appropriate event bus? Are you sure you want to deny using the block regardless of what type of interaction event is was and what the player was holding and what they clicked on? If this is for an item, consider overriding Item#onItemRightClick . This is called when the item is used to right click air.

You can't assume that there's only one World loaded at any time and maintain a single list from WorldEvent.Load / Save . Each time a block is added or removed, you need to fetch the WorldSavedData for that World and add or remove the position from that instance's list. @ForgeSubscribe doesn't exist any more, use @SubscribeEvent . I suspect you misread the event handler tutorial you followed. You can use a for-each/enhanced for loop to iterate through a collection such as an array or list.

My fluid models are working without issue: You can see my fluid creation code here, my model registration code here and my blockstates file here.

Ah, that makes more sense.

Keep in mind that IDs for modded block/items are automatically assigned and will likely be different for every world, they're not a very reliable way to store persistent data. Registry names are a much more reliable identifier for blocks/items. RegistryNamespaced#getNameForObject can be called on Block.blockRegistry or Item.itemRegistry to get the registry name of a Block / Item respectively.

Yes, that looks correct. Is your field a List or a List<Position> ? Always use generic types when they're available.

You need to save the NBT list tag inside the provided NBT compound tag using NBTTagCompound#setTag in writeToNBT . If you're using generics properly, you shouldn't need to cast objects from your list to Position .

Use Block#getDefaultState to get the default state of a block, then chain IBlockState#withProperty calls to get an IBlockState with the specified property values.

World#getBlock and World#setBlock were replaced by World#getBlockState and World#setBlockState , respectively. These take a BlockPos instead of individual coordinates and take/return an IBlockState instead of a Block . Use IBlockState#getBlock to get the Block represented by a state. Use Block#getDefaultState to get the default state of a block, then chain IBlockState#withProperty calls to get an IBlockState with the specified property values.

Yes, as long as you haven't installed any JAR mods (i.e. mods that you need to put into the Minecraft JAR).

If the list is only maintained and checked on the server, won't it all be running in a single thread? Even if you needed to maintain the list on both sides, wouldn't each side have its own WorldSavedData instance(s) each only being accessed from a single thread?