urbanxx001

I have the following event class, which should change the rendering type of a vanilla mob when it's capability is updated. The capability itself works, however the events don't seem to be firing. Edit1: Actually it doesn't seem like the events are necessary. So the issue is updating the capability, which probably requires sending a packet when the item that sets the capability is used. Edit2: Since it's being sent and received client side, I probably need a C2S packet and then S2C one. Edit3: Got it working! It was updating on server and not client [Classes removed as the mod isn't released yet]

Woo got it to sync by setting the pos in the read/write methods, which are called by getUpdateTag().

I'll definitely consider IItemHandler down the line, thanks. With openGui() I was passing the block pos: NetworkHooks.openGui((ServerPlayerEntity) player, ((INamedContainerProvider) tileentity), t -> t.writeBlockPos(pos)); So the problem is this isn't synced with the client. I'll try getUpdatePacket() and onDataPacket() in the te then.

Alright I've redone a bit and it's working as long as the block position is given manually in the packet handler. I've been trying to pass it from the tile entity => container => screen instead, however something strange occurs in the container. It receives the correct te and block position, but then a second te with null position is detected. Classes below. ModBlock ModTileEntity ModContainer

That looks right. You can test it and see if everything is functioning correctly. There might also be a way to read/write the ingredients as a single array, but it would be the same amount of code.

Reading those variables entirely depends on how you created the write() method. For reference, the vanilla classes such as CookingRecipeSerializer are a good template. The only difference is they return the recipe from factory: return this.factory.create(recipeId, etc.) If you have variables such as cooking time and experience returned, they should also be written and read.

Right it's being sent in two places, idk why I sent a second one in PacketUpdateContainer. I'll fix the argument mismatch as well. Thanks for catching those.

Ah that makes sense. I replaced it with that, but receive the same error. Hopefully it's not an issue on the receiving end (container).

It's called in: private static void commonSetup(FMLCommonSetupEvent event) { DeferredWorkQueue.runLater(() -> { CapCompScreen.register(); PacketHandler.register(); }); } which in turn is called in the Common Proxy class as: final IEventBus modEventBus = FMLJavaModLoadingContext.get().getModEventBus(); modEventBus.addListener(CommonProxy::commonSetup);

I have a button in my screen class to send a packet to the container in order to update the inventory (client to server), according to this. Opening the gui and clicking the button in-game, I receive an invalid message error that originates from: PacketHandler.CHANNEL.send(PacketDistributor.ALL.noArg(), new CapCompContainer(ModContainerTypes.MULTI_9X3.get(), containerID, containerInd, senderInv, 3)); According to this the issue could stem from registration, but I ensured that the packet is registered in FMLCommonSetup and specified the network direction PLAY_TO_SERVER. Classes: PacketHandler PacketUpdateContainer CapCompContainer CapCompScreen

That did the trick! Thank you so much

Of course: IModTag ModTagItem ModTagProvider ModTagStorage ModEvents CommonProxy Main

Alright I tried: @Mod.EventBusSubscriber(modid = Main.MOD_ID) And added a log inside the event: Main.LOGGER.info("Logged capability event"); But the info wasn't generated in latest.log or debug.log.

Ok. Sorry for how tedious this has been. I removed the @Mod.EventBusSubscriber line and tried MinecraftForge.EVENT_BUS.register(ModSubscribeEvents.class); and FMLJavaModLoadingContext.get().getModEventBus().register(ModSubscribeEvents.class); But throws the same error in-game.

After checking the capability register is in FMLCommonSetupEvent: CapabilityManager.INSTANCE.register(IModCap.class, new ModCapStorage(), ModCapMethods::new); And the event in: @Mod.EventBusSubscriber(modid = Main.MOD_ID, bus = Mod.EventBusSubscriber.Bus.MOD) public class ModSubscribeEvents { @SubscribeEvent public void attachCapabilitiesEntity(final AttachCapabilitiesEvent<Entity> event) { if ((event.getObject() instanceof LivingEntity) && !(event.getObject() instanceof PlayerEntity)) event.addCapability(new ResourceLocation(Main.MOD_ID, "mod_cap"), new ModCap()); } } orElseThrow() still throws an error. I'm in the same boat as this guy, I don't think he resolved it. Out of curiosity, does anything need to be created in the data folder?

Apologies I understand what you mean now, orElse was giving a false positive with a temporary object that it was registered, which means I should inspect the register again. Will use .orElseThrow(() -> new IllegalArgumentException("Illegal argument")) instead. Thank you for your help.

The orElse line isn't the one I'm using to set the capability, it's the .ifPresent(IModCap::set) Ah ok. I checked and fixed the register method and the AttachCapabilityEvent, but still receive the default value. Should all entities automatically receive the capability through that event? If not, does it need to initially be attached to them with something like EntityJoinWorldEvent?

Ahh it's a Shader. I'm familiar with the terrain-warping ones, made one a long time ago for bedrock. The closest thing I can think of that physically alters blocks is the No Cubes mod, but that's a static change to the terrain, not a constantly-updating one that occurs with shaders when it's a certain radius from the player. Perhaps you can adapt that type of code to work in an event that constantly detects the radius, to mirror the hitboxes with your rendering. Although that would most likely be very laggy. Again hopefully someone else can give input, but asm might be your best bet.

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?

Below are my capability classes for attaching to vanilla living entities (besides player). I'd like to change the entity's capability (to a value of 1.0F) when right clicking with a mod item. I thought this would be accomplished with: target.getCapability(ModCap.MOD_CAP).ifPresent(IModCap::set); But checking the values before and after with: System.out.println(target.getCapability(ModCap.MOD_CAP).orElse(new ModCapMethods()).get()); Still yields 0.0F (the default value). Since it returns the default, the capability should be registered (so ifPresent should pass?), but I could be wrong. ModCap Class ModCapStorage Class ModCapMethods Class IModCap Class ModItem Class

Ah so its in that class, I'll look more closely then. Thanks!

For a custom recipe, I recommend taking a look at the RepairItemRecipe class in the source. However if your item is a weapon, tool, or armor that extends an existing archetype like a sword, helmet, etc, then it should automatically implement that recipe (combining durability in crafting table). If you want to add the anvil version of this, you can override the getIsRepairable() method in your item class. If you want more info on registering a custom recipe, lmk.

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)

Which class(es) handle(s) the Ender Dragon's purple light upon death? this is outdated but it mentions a layer class, I've looked through the current ones but none referring to the ender dragon.