hiotewdew

The "Biomes" class. In Eclipse, vanilla source is in Referenced Libraries -> forgeSrc-xx-xxx_mapped_snapshot_xxx.jar Not sure about IntelliJ

It's also possible the examplemod is somehow included in the classpath. Check "Project and External Dependencies", your "run/mods" folder, and the build path (rclick project and external dependencies -> Build Path -> Configure Build Path... look for examplemod

Try running "gradlew clean eclipse genEclipseRuns" and then refresh your gradle project (F5 when selecting project in package viewer)

Look at how vanilla biomes do it.

Global Loot Modifiers are likely the best method, but to show another method, you can actually use data combined with a bit of code to add loot tables fairly easily. Here's how I do it. Then you can just define a loot table connected to that RL with the same pool name and it's done.

Is your pack.mcmeta present and on the correct pack version? These are the actual error lines: [14Aug2020 01:36:11.471] [Render thread/WARN] [net.minecraft.resources.ResourcePackInfo/]: Couldn't get pack info for: java.nio.file.NoSuchFileException: D:\Mod Writing\forge-1.15.2-31.2.0-mdk\submechanica\build\resources\main\pack.mcmeta\pack.mcmeta [14Aug2020 01:36:11.548] [Render thread/WARN] [net.minecraft.resources.ResourcePackInfo/]: Couldn't get pack info for: java.nio.file.NoSuchFileException: D:\Mod Writing\forge-1.15.2-31.2.0-mdk\submechanica\build\resources\main\pack.mcmeta\pack.mcmeta

You'd want a tile entity with a UUID field that saves to NBT. Then, override onBlockPlacedBy in your Block class, get the tile entity, cast it to your TE type after an instanceof check, and set the uuid field to the provided player's UUID.

Show the contents of the "bin" folder? It might be that eclipse is duplicating the examplemod from a sourceset somewhere.

No it doesn't. The second you run that on a DEDICATED SERVER it will crash. As I just explained, you need to use DistExecutor or packets.

Do not use Gradle 5.0, use 4.9

Your code is going to crash if you run it on a multiplayer server because it loads client classes regardless of if it runs or not. You need to use packets or DistExecutor

gradlew eclipse, F5 to refresh project

no no, instead of creating a custom particle type and particle data that you never use, instead just use BasicParticleType. This is as simple as deleting your particle type and data and replacing ObisidianParticleType::new with () -> new BasicParticleType(false)

Ah unfortunately all my Particle code is textured particles using the Sprite particle renderer. One thing I am a bit confused on is why you are registering particle data and have a custom Particle type class when you can simply use the default BasicParticleType

Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.

DistExecutor is used for physical side, whether you are using a minecraft client or dedicated server (in this case, this is the relevant information as only physical clients do rendering) isRemote references the logical side, where true is the logical client. Logical client just means if it's not running the gameserver instance on that thread, so isRemote could return false on clients on the server thread. Also, isRemote checks do not properly avoid classloading, unlike DistExecutor which avoids them by utilizing the double supplier trick.

Not fully used Particle rendering on 1.15, only 1.14, but perhaps the issue is that your line has zero-depth? I believe you may need a small amount of depth for the line to actually render. Although, it looks like you may have that. Try ending the buffer? Also take a look at some vanilla particle renderers to see how those are done.

Dunno if you ever found a *real* fix - but my fix was disabling it in creative (the item has no use in creative, it's a bag that returns even after you die)

Yep.

Doesn't really matter - same bug happens with or without it. Had it originally, removed it, re-added, nothing.

I need to "register" my capability? How? Isn't already registered as an itemhandler capability, like builtin?

So I was doing some reading trying to figure out why my item with an itemhandler capability was losing all of its items when it changed slots in creative on the server- and someone on the MMD discord mentioned that the client handles inventory in creative. I found this: http://www.minecraftforge.net/forum/topic/27248-player-inventory-synchronization/ So apparently I'm doing something wrong with my cap provider/deserialization or something that is causing the client to not get the right items in the right spot. What I mean by "changing slots" is I will take the bag, move it from slot 1 on my hotbar to slot 2 and all the items will have disappeared. (It's a GUI, and definitely not desync, relogging fixes nothing). Otherwise works fine in survival on server and on the client (although I have noticed it a few times in creative on the client - possibly the effective server thread is responsible) Capability Provider: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/SatchelCapabilityProvider.java Item: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/ItemDeadMansSatchel.java Container: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/ContainerSatchel.java Not sure if I should be using the NBT argument from initCapabilities somehow. Is there a way to force handling on the server for my container - even in creative?

How do I register using NBT values?

Yes, and a good example of how my blockstate should look. I can try it when I'm at my computer but my mesher registration might not be right. Does new ModelResourceLocation("registryname", "type=1"); work as a valid location to get a variant with the type attribute with the value 1?

I've gotten some help in the MMD Discord, but I'm still not fully understanding what my JSON files should look like after using the mesher to register item variants. This is my registration code: // Model registration for(BlockGenericSkull skull : genericskulls.keySet()) { HeadItemMeshDefinition meshDefinition = new HeadItemMeshDefinition(skull); ItemBlockSkull item = (ItemBlockSkull) skull.getItemBlock(); ModelBakery.registerItemVariants(item, meshDefinition.defaultModelResourceLocation); for (int i = 0; i < skull.texCount; i++) { ItemStack stack = new ItemStack(item); stack.setTagCompound(new NBTTagCompound()); stack.getTagCompound().setInteger("TYPENUM", i); ModelBakery.registerItemVariants(item, meshDefinition.getModelLocation(stack)); } ModelLoader.setCustomMeshDefinition(item, meshDefinition); } And this is my ItemMeshDefinition: package its_meow.betteranimalsplus.client; import its_meow.betteranimalsplus.common.block.BlockGenericSkull; import its_meow.betteranimalsplus.common.item.ItemBlockSkull; import net.minecraft.client.renderer.ItemMeshDefinition; import net.minecraft.client.renderer.block.model.ModelResourceLocation; import net.minecraft.item.ItemStack; public class HeadItemMeshDefinition implements ItemMeshDefinition { public final ModelResourceLocation defaultModelResourceLocation; public HeadItemMeshDefinition(BlockGenericSkull head) { this.defaultModelResourceLocation = new ModelResourceLocation(head.getRegistryName(), "inventory"); } @Override public ModelResourceLocation getModelLocation(ItemStack stack) { if(stack != null && stack.getItem() instanceof ItemBlockSkull && stack.hasTagCompound()) { return new ModelResourceLocation(this.defaultModelResourceLocation.getResourcePath(), "type=" + stack.getTagCompound().getInteger("TYPENUM")); } return this.defaultModelResourceLocation; } How should my JSON models look? I only want to change my texture, not transforms/models using the NBT data. Do I need an "item blockstate"? How should it look? I don't really have a base of the JSONs to work off of, otherwise I would link them too. Also not looking for recommendations on how to do it another way, currently sticking to NBT as it works best for my project and won't be removed in 1.13 (metadata).