vemerion

What exactly are you having trouble with? This line of code: event.getGenericTrades().add(new BasicTrade(5, new ItemStack(Items.ENCHANTED_GOLDEN_APPLE, 5), 2, 10)); would add a new trade that costs 5 emeralds and gives you 5 enchanted golden apples in return.

Do you mean that you want to know where the vanilla code is for creating the enchantment tooltips? If so, it is in the getTooltip() and the addEnchantmentTooltips() methods in the ItemStack class. If you want to add your own custom tooltip to an item, you can do so via the addInformation() method in the Item class if it is for your own custom item, or via the ItemTooltipEvent event if it is for a vanilla item.

Call the WandererTradesEvent event and add your own custom ITrades to the list in the event.

You can't really add new dataparamaters to vanilla entities. You should instead use capabilities.

It looks like you spelled 'stick' wrong in the recipes.

If you look at the call hierarchy of the placeEntity() method, you can see that the entity it returns is in fact the entity that is teleported. Therefore, to change the position of the entity you would only need to change the position of the entity you return before returning it.

I think the method makePortal() in the Teleporter class is where vanilla tries to find a nearby valid position to create the portal in. However, it is kind of a large and unreadable method, so I don't know if it is realistic to try and replicate it. Another possibility would be to do something similar to how the locate command works. I am not too familiar with world generation, but if your islands are generated similar to how vanilla structures are generated, then this could work.

I don't think there is a direct equivalent of CountRangeConfig, see this thread for more details.

Here is what I would do: override the canInteractWith() method in your custom container, and return false if the player is no longer holding your storage item.

The method has to be static.

You could perhaps store the buttons you want to change in an extra list, and then just iterate through that list and update the buttons when you want to perform the update.

You cannot have a global variable as a counter, since that will mess things up if several players use your item at the same time. I would recommend adding a capability, either to the player or to your custom item, which could hold your timer. You can read more about capabilities here.

A workaround to the fact that PlayerInteractEvent.LeftClickBlock is triggered multiple times could be to add a cooldown to the item, i.e. add this to your if statement: !playerEntity.getCooldownTracker().hasCooldown(heldItem) and then set the cooldown in the then statement, something like this: playerEntity.getCooldownTracker().setCooldown(heldItem, 5);

Well, if you want your shield to have the exact same model as the vanilla shield, you don't need to subclass it at all, just create a new instance of the ShieldModel in your item stack tile entity renderer. I think the easiest approach to this is to look how the vanilla ItemStackTileEntityRenderer renders the shield, and do something similar. On a slightly unrelated note, you should refrain from hardcoding your modid in strings as you have done in the ResourceLocation constructor, since that makes it less readable, and harder to change (which you probably should, since 'cave' is way too short).

Alright, cool! Be sure to give me a ping when you release the mod

Do you want the model to be like regular items, or similar to how the vanilla shield is? In the latter case you would need an item stack tile entity renderer (and maybe a model class too). Here is the slightly outdated official documentation on ItemStackTileEntityRenderer. I also recommend checking out the ItemStackTileEntityRenderer vanilla class to see how vanilla does it.

Teleporter is the vanilla Minecraft class, while ITeleporter is the forge alternative. There is no reason the extends Teleporter, since everything you get from it is a bunch of portal spawning logic. Your VoidTeleporter should work as desired if you implement ITeleporter, but keep the placeEntity override, since as the documentation in ITeleporter says, a portal will not spawn if you supply the Function with false.

Ah, I am glad you were able to solve it! I agree with you, world generation is such a hassle right now, I am hesitant to even go near those systems. But it will get better down the line I guess. Also, just because I am curious, are you working on a port of the fabric BetterEnd mod, or are you creating your mod from scratch? Either way, interesting mod idea!

Alright, let's try another way: If you extend the BiomeGenerationSettings.Builder class, and add your own method that takes a structure supplier, i.e. something like this: public static class Builder extends BiomeGenerationSettings.Builder { public BiomeGenerationSettings.Builder withStructureSupplier(Supplier<StructureFeature<?, ?>> structure) { this.structures.add(structure); return this; } } and then use this builder to create your biome instead. Does that work?

Yes, use the getStructures() method, and add your custom structure.

I am not super familiar with the world generation part of Minecraft, so forgive me if I am way off, but could you not just wait and add the structure to the biome until after your structure is registered (i.e. last in setupCommon)?

You could check if the item is an instance of IDyeableArmorItem, and if so, use IDyeableArmorItem.getColor().

By API, I presume you mean Forge? If so, the official documentation is a good place to get started with Forge. Cadiboo's tutorials are also a good introduction to Forge modding.

Well, every time you create a new custom packet type that will be sent from the client to the server, you have to ask yourself: Can a cheater utilize this? Think about this scenario: A player is being chased by zombies, and is close do dying. That player can then simply send a DataTransferInterfaceMessage to teleport to an arbitrary dimension and escape death. Also, it does not matter that the player can not place blocks in the custom dimensions, since a hacked client would not need the DataTransferBlock to send the messages.

You are registering your message class in init() in the PacketHandler class incorrectly. You should not create an instance of your message class and register the methods of that instance. Instead, change the init method to this: public static void init() { INSTANCE.registerMessage(nextId++, DataTransferInterfaceMessage.class, DataTransferInterfaceMessage::encode, DataTransferInterfaceMessage::decode, DataTransferInterfaceMessage::handle); } and change the encode, decode and handle methods to be static. This should fix your problem. EDIT: You should definitely add checks on the server side (in the handle method) to prevent a cheating player from freely teleporting between dimensions.