Animefan8888

My new recommendation doesn't update them every tick. My recommendation involves this. Capability to store creation time. When the Capability is Attached in AttachCapabilityEvent<ItemStack> also make sure to add it to a WeakHashMap which will map the Expiration Time to all of the ItemStacks that expire at that time, or ItemStacks to their Expiration Time which ever you want. Then when the expiration time happens expire all the ItemStacks. Which would likely include removing them from the WeakHashMap. This way there is no way to get around Items expiring because you are always dealing with the ItemStack. Mind you it is kinda hacky. But this way you can update every ItemStack as you wish and only when they need to. Think of it as a scheduling system.

I assume it would only be ItemStacks that contain Items that are food. And I agree but it is the brute force approach. Also I said you probably shouldn't do it every tick for large numbers of items. Maybe instead store ItemStacks in a WeakHashMap that maps them to their expiration time. Then only update the ItemStack when their expiration has happened.

The easiest solution is to not use Twitch. I don't know if it supports 1.14+ yet anyways. And looking at the error it seems it is missing a library IE it wasn't downloaded for some reason which means the Forge installation wasn't done correctly.

How did you install forge? Does this crash happen when you have no mods installed? If not check to see which mod is doing it by removing mods.

I think it can it would be best to test this yourself however.

Not sure how much you know about Events but here is the documentation. You need to subscribe to the PlayerEvent.HarvestCheck event. And call HarvestCheck::setCanHarvest(true). Use the methods within the event to determine if the player is holding your Hammer and if they are say they can harvest the block.

Step through your render code in the debugger does your getEntityTexture method ever get called and does that texture ever get bound?

You either need to used the PlayerEvent.HarvestCheck event to say the player can harvest those blocks with your Hammer Item(s) or make your Hammer a Pickaxe by adding a ToolType via the Item.Properties::addToolType method. I believe the first option is the most suitable.

What does this look like? Do you add cobblestone to it? That would be my only idea as well, but I can't see what's wrong with it. Try setting a breakpoint in the area before global loot modifiers are called to see why your loot modifier condition is not true.

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. For more information read the LTS at the top of the page.

Even this can be exploited. I know there is a mod that adds a Lunch Box item from which you can eat from. I like the idea of Attaching a Capability to each ItemStack and using that as a registry, using some sort of "WeakList" implementation to avoid Memory Leaks. Then just iterating over them every world tick. Or some other not performance crippling way. IE every 20 ticks or split up between the ticks.

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. For more information read the LTS at the top of the page.

You are not supposed to do that from what I can tell I haven't messed around with Global Loot Modifiers yet, but seeing as how LootModifier::doApply returns a List<ItemStack> I assume that are the drops. ItemStacks can never be null. Use itemStack::isEmpty I'm also unsure about this. I don't know if a BlockState will ever be null. I'd assume the default null-like value is the BlockState for AIR. Have you stepped through your LootModifier::doApply code is it called twice? Is it called at all aside from your Block.spawnDrops call?

This is not adequate. What if another mod edits the stripping Map the same way you do. You want them to be compatible therefore you need to get the current value using Reflection and take all of the data in it and transfer it into your map. Then replace the map. Also This will not work in the actual game IE running it from the Minecraft launcher you must use the obfuscated name of the field which you can get the mappings here. You should also use ObfuscationReflectionHelper instead of raw Reflection.

1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. For more information read the LTS at the top of the page.

Only this event and when it changes. A player in a completely different area of the world doesn't know about an Entity near another player far away and therefore does not need to know about any Capability changes. There are two ways to do this. Have your Capability on each entity keep track of each player that is tracking it on the server. Get the tracking Player in the PlayerEvent.StartTracking when you initially send the data. And don't forget to remove the player from the Capability tracking list in PlayerEvent.StopTracking.

You need to override Entity::createSpawnPacket and return NetworkHooks.getEntitySpawningPacket

Use the CommandEvent event to do that.

No they should instead use the global loot modifiers. Check out here and here.

The folder tree is models/item and models/block now not models/items and models/blocks.

You do know you are setting it to 1,000 right?

The difference is when the events are fired. You should actually use LivingHurtEvent I just didn't notice it because LivingDamageEvent shows up first. LivingHurtEvent is fired before the damage reduction calculations are fired whereas LivingDamageEvent is fired afterwards. You should just override the registry. Which is the first option. This way your enchantment will be treated exactly like the bane of arthropods enchantment.

The problem with that then goes for users too. If they update their mod version and it adds new content the ItemGroup will not be sorted in the correct way. It's better to sort the ItemGroup.

I believe they are, but registries are persistent so if you add a block create a world then add another block which is registered before that block it will still appear second. I'm not a hundred percent sure on if this is the optimal way to do it, but in your own ItemGroup you can override ItemGroup::fill and after getting all of the items in the tab you can sort them.

You're setting the registry name twice. Here and here Only do the first one, but change the string.