kiou.23

you should call .get() on the registry objects. any time you're dealing with registry objects, and you need the actual thing "inside" the registry object, you use .get() (that's because a registry object is just a fancy supplier) the problem is that when registering to a deferred register, you need to pass a supplier which returns the actual object. but in the code you're just passing the object (in your "sign" tile entity registration) also, the DeferredRegister::register(string, supplier) returns a RegistryObject, not a TileEntityType also, don't name your tile entity type deferred register a "entity type deferred register", entity types are another thing entirely (for entities, and not tile entities) also also, please properly type your Registry Objects, if it's a SignItem, don't type it to RegistryObject<Item>, but use the more specific RegistryObject<SignItem>, same goes for your blocks

like, your Main class, the class that has the "@Mod(MOD_ID)" written on top of it

maybe take a look at how beacons work?

did you also replace it in the build.gradle, and is it the same id that you're passing to your @Mod annotated class?

a lot has changed since 1.8.9, like, a lot, almost everything. there isn't a 1 to 1 mapping from 1.8 to 1.16, you're better of just learning the new systems and rewriting the mod entirely. as for the list of classes, methods and fields, you can get them directly from your ide. the forge docs, and the community docs, has a lot of resources. and if there is something that isn't on the docs, and that you can't figure out by yourself, you can ask for help for that specific problem here in the forum

you need to set your blocks render layer to be cutout during the client setup. things haven't been renamed. Forge previously used mcp mappings, but recently Mojang relesead the official mappings, and so the newer versions of forge ship with those by default. you can cahnge the mappings channel and version in your build.gradle to switch back to mcp they should work, just have different names. you can use of your IDE's auto complete to see what method shares the signature (parameters and return type), that you were using

since that's just using an ItemStackHandler, I used the ITEM_HANDLER capability that already exists in CapabilityItemHandler Bur for registration you just create a field, in a class like ModCapabilities, of type Capability<Your Capability class>, and use @CapabilityInject() and I didn't have to use an attach event because I'm using the capability in a custom Item. but for attaching it's the same thing, just listen to the proper event, and call event.addCapabicall, then give it the cap ID and an instance of the cap provider

in the provider's serializeNBT you call the IStorage's writeNBT, but in the IStorage's writeNBT you call the provider's serializeNBT. You never actually serialize your data. 1. You don't need an IStorage, just do the serialization in the provider itself. 2. your lazy altar isn't actually lazy. google the concept up. don't initialize the the field on instantiation, instead wait until the capability is requested to initialize it, then cache it. 3. no need to implement ICapabilityProvider, only ICapabilitySerializable, also, you should define the generic parameter of the interface. 4. don't put your capability instance on the capability provider class. that's separation of concerns 101 5. on your getCapability, make sure that the capability being requested is the one you're providing! Hold on, I have a mod with a private repo that uses capabilities. I'll make it public to share it here so you can see some examples EDIT: here's some examples https://github.com/jvcmarcenes/skbackpacks EDIT2: I had forgot, for serializing ItemStackHandlers you can use of CapabilityItemHandler.ITEM_HANDLER_CAPABILITY write/read method

are you making a mod, or just having issues to use mods?

that doesn't mean you need a tile entity, the data is being stored in the player's capability, not the block There's no need to extends the ItemStackHandler, just instantiate it You don't need to use IStorage, plus they're being removed in the next versions. just do the serialization in the provider and when your CapabilityInstance.register called? What are these for? why are you converting the ItemStackHandler to an Inventory, to use the ItemStackHandler And you didn't show the CapabilityProvider. You're over complicating this, I've already explained what it is that you need: your Capability Provider will provide an ItemStackHandler, in this case, handle serialization in the Provider's serialize and deserialize methods and you don't need a TE, at least not for this. the TE is meant to store additional data for blocks, since the data you're storing isn't kept in a block, but in the player, you don't need a Tile entity. to open the container you just need an INamedContainerProvider, which passes any data that the Container needs, to the container. and you'll get this data from the Capability

ohh, my bad then, I'm sorry I edited the source in. the problem the OP had was possibly a different one, I can't really tell tho

You don't need to tag the method with @SubscribeEvent because you're manually adding the event listener method in your Main constructor, here: FORGE_EVENT_BUS.addListener(EventPriority.HIGH, OreGeneration::generateOres); (also, there's no point in setting EventPriority to high) the docs goes into the different ways of attaching your event listeners: https://mcforge.readthedocs.io/en/latest/events/intro/ This line if (!(event.getCategory().equals(Biome.Category.NETHER) || event.getCategory().equals(Biome.Category.THEEND))) { isn't doing s**t, it's flawed logic, you want this to only be true when the biome category is the overwold, right? so walk through it, imagine the biome is in the nether, the left part of the || will be evaluated to false, correctly, but then, the biome is in the nether, but not in the end, the right part will evaluate to true, and false || true == true And about the registering, IIRC you don't "need" to register the feature, but you should, I don't quite remember why, so don't quote me on this. I'll look for where I read this, if I find it I'll add it here as an edit EDIT: found it:

It's easier to use InventoryHelper#spawnItemStack also note that BlockPos stand for the bottom corner of the block, you need to properly offset the spawning position

yeah, that's not what tile entities are for. Tile entities are for blocks. what you need to open the container, is an INamedContainerProvider then you're not properly serializing your data, make sure you properly overrode the serializeNBT and deserializeNBT methods in your Capability Provider. and post your new code if you're still with some issues

I wasn't thinking of it! cool idea, it could be like lucky blocks

Why do you have a tile entity? isn't the capability for the player entity? What's the purpose of IStorageInstance? and what's the difference between AltarCapability and DefaultAltarCapability? I think you're under some fundamental misconception over the capability system. Here's what you need: 1. A capability, and a capability is just a class which holds any arbitrary data you need. Since what you want is an "inventory", forge provides an implementation for that, the ItemStackHandler. If you don't require any custom logic on top of just a holder of ItemStacks, you don't even need to extend it, just use the ItemStackHandler capability. 2. A capability provider, which will manage the capabilities for your player. in it you'll handle serialization, and on the getCapability method, you'll check if the requested capability matches your capability, and if it does, return the lazy capability 3. you'll register the capabilities, and attach them on the proper event handler 4. if you want the inventory to be displayed, and interacted with by the player, you'll need the container and a container screen (not a tile entity, those are for blocks).

That did it, thanks!

I have added some entities, and am trying to detect right/hit clicks, and left clicks. however none of them seem to trigger when I click the entity. I can confirm that I was clicking inside the entity hitbox Interact Listener: @SubscribeEvent public static void onEntityInteraction(PlayerInteractEvent.EntityInteract e) { if (e.getWorld().isRemote()) return; if (!(e.getTarget() instanceof DiceEntity)) return; DiceEntity dice = (DiceEntity)e.getTarget(); ItemStack diceItem = dice.getItem().copy(); dice.remove(); e.getPlayer().addItemStackToInventory(diceItem); } Hit Override: @Override public boolean hitByEntity(Entity entity) { Main.LOGGER.info(this.getName().getString() + " was hit by " + entity.getName().getString()); return super.hitByEntity(entity); } repo: github.com/jvcmarcenes/dicehoard

That should only be the path if you own the domain <MOD_AUTHOR>.com, which commonly isn't the case if you don't own a website/domain, the recommended package name is io.github.<MOD_AUTHOR>, or some repository hosting service you use. The name of the package, however, does not affect the issue

Doesn't the thread run asynchronously? If not, my bad then, I apologize for the bad advice

You haven't, latest commit is from 3 days ago forgot to push?

any reason why using Java threads wouldn't work? you could do: new Thread(() -> { Thread.sleep(/* how long to wait in miliseconds */) /* do your logic here */ }).start();

Would be easier if you posted the actual error too

World#notifyBlockUpdate (mcp maps) what for?

https://www.youtube.com/playlist?list=PLGProEDTdBjghW5IZsiWno6e9QAkHChyQ this are the videos that got me started with modding. and he goes over the naming changes from mcp to mojmaps