Leaderboard

Mmmm it seems you did not folllow the advice of Draco18s, which i'll quote here: Your block extends the vanilla CraftingTableBlock class, but its not the vanilla crafting table itself (Blocks.CRAFTING_TABLE)...the vanilla crafting table container checks for the player proximity only with the Block.CRAFTING_TABLE, so of course your block doesn't satisfy the condition for the container to open. I think you would need to create a custom container which extends WorkbenchContainer and override the canInteractWith method to check for proximity with your own crafting table block. Then you have to tell your CraftingTable block to open your custom container instead of the vanilla one. You can see how vanilla opens the WorkbenchContainer by looking inside the CraftingTableBlock class. I don't know if this is the best way to achieve this though, there may be a better way

What I was trying to say is, apparently the ifPresent() check failed, therefore you are printing a default value (got from orElse()). Here you should use orElseThrow so there will be an exception when the entity does not have the capability (to notify you that somethings wrong with your capability). No, the capability is added during the attaching event. And if I understand it correctly, LazyOptional.of(MOD_CAP::getDefaultInstance); this will provide an instance from the factory that you have passed in the third parameter when you register the capability, and you are currently splitting up your capability into ModCap and ModCapMethods, which for me it seems a bit redundant (a class can have multiple interface implementations), and might be the cause of the problem.

.orElse(new ModCapMethods() This won't assign the living entity a new instance of your capability. This means System.out.println(target.getCapability(ModCap.MOD_CAP).orElse(new ModCapMethods()).get()); If the capability does not exist on the entity, it prints the default value (of the new instance). By using orElseThrow you can get notified whenever you are accessing an entity that does not have the capability (which should not happen). At the moment it seems like the entities does not have your capability, is the capability correctly registered, and capability correctly attached?

I'm trying to register a custom Villager Profession but I'm not sure if what I'm doing is correct. The following runs without a hitch however the villagers never run the the block like they do other Job blocks and even if they are getting the job when I'm not looking, I'm unsure how to set a custom texture so they appear uniquely. // ModProfessions.java public class ModProfessions { public static final DeferredRegister<VillagerProfession> PROFESSIONS = DeferredRegister .create(ForgeRegistries.PROFESSIONS, HuntingUpdate.MOD_ID); private static final ImmutableSet<Item> HUNTER_ITEMS = ImmutableSet.of(Items.BEEF, Items.PORKCHOP, Items.CHICKEN, Items.RABBIT, Items.RABBIT_HIDE, Items.MUTTON, Items.LEATHER, Items.COOKED_BEEF, Items.COOKED_PORKCHOP, Items.COOKED_CHICKEN, Items.COOKED_RABBIT, Items.COOKED_MUTTON); public static final RegistryObject<VillagerProfession> HUNTER = PROFESSIONS.register("hunter", () -> new VillagerProfession("hunter", new PointOfInterestType("hunting_table", ImmutableSet.of(ModBlocks.HUNTING_TABLE.get().getDefaultState()), 5, 40), HUNTER_ITEMS, ImmutableSet.of(ModBlocks.HUNTING_TABLE.get()), SoundEvents.ENTITY_VILLAGER_WORK_BUTCHER)); } // HuntingUpdate.java (Main Class) public HuntingUpdate() { // Register the setup method for modloading FMLJavaModLoadingContext.get().getModEventBus().addListener(this::setup); // Register the doClientStuff method for modloading FMLJavaModLoadingContext.get().getModEventBus().addListener(this::doClientStuff); ModBlocks.BLOCKS.register(FMLJavaModLoadingContext.get().getModEventBus()); ModItems.ITEMS.register(FMLJavaModLoadingContext.get().getModEventBus()); ModEntities.ENTITY_TYPES.register(FMLJavaModLoadingContext.get().getModEventBus()); ModProfessions.PROFESSIONS.register(FMLJavaModLoadingContext.get().getModEventBus()); // Register ourselves for server and other game events we are interested in MinecraftForge.EVENT_BUS.register(this); } Any help would be super appreciated thanks!

I would take a look at how the Never Needed or Wanted (NNOW) mod handles new villagers, PoI blocks, and trades. The unique villager textures are based on the names when you register the profession (here), which points to the corresponding file in your textures/entity. The mod creator also made some nifty reference classes, VillagerUtil and RandomTradeBuilder, that reduces some repetitive code when making multiple villager types.

Forgive me, Idk much about changing physics, but given you've been waiting 3 hours, you deserve a reply. Hopefully someone more experienced will give advice. Your formatting is fine, no worries. If you're willing to post your code, we can help you debug it. When you say it's only working graphically, do you mean the entity/block rendering obeys your new physics, but not their bounding boxes/hit boxes? Also is this affecting vanilla blocks/entities, or only ones created in your mod?

Use updatePostPlacement and check if the bottom block is air, if so return air's default state (check bush block).

Ah, shame. Glad it brought you a laugh though! Also, back to OP's post, not sure how relevant it is, but any LivingEntity has two methods: isPartying and setPartying. It's what parrots use for jukebox detection. Hope it helps!

This is an excellent post detailing the steps. It says to install DCEVM and the Hot Swap plugin, but another user claims only the first one is necessary. I followed the same steps, but wasn't able to see any edits in-game. Perhaps it'll work for you though (if it does, lmk)

I don't mean to sound rude, but I disagree with that. Many times when learning something new, I'd find some example code, or code that achieves a similar effect to what i need, I'd read through it, attempt to understand and learn from it, then maybe tweak it if needed. I'm sure I'm not the only one! I understand that not everybody does that, but if they are serious about learning whatever it is, then they would. That's just my opinion though.