Jump to content

NarwhelZhu

Members
  • Posts

    12
  • Joined

  • Last visited

Everything posted by NarwhelZhu

  1. It works now, thanks. I think that will be all for this particular thread. It renders and fires from the dispenser now. Thanks for the help.
  2. Alright, I figured it out. Once again, an idiot mistake. I forgot to put throwerIn in the second entity constructor's super call. It appears now and I believe it's working fine. I'll update my code blocks to be correct for any future coders who have the same problem. Thank you for your help, even by just pointing out my own idiocy. One last problem though: it doesn't fire from a dispenser like a snowball does. It doesn't look like the snowball classes even have code for that though.
  3. Ah, thank you, I knew that it would be something really dumb like that. The entity does summon now, although it seems to be invisible. Is there some other obvious reason for that that I'm missing too?
  4. I'm trying to make a super basic throwable item that is essentially just a retextured snowball with virtually identical code just to understand the basics of thrown items, and almost everything works, except that the item won't appear when I right click it to throw it or be fired from a dispenser. The item and entity are registered, the rendering works just fine, I can summon the entity with /summon and it appears, and there are no errors in the console at any point. The problem seems to be that the onItemRightClick() method isn't even being called at all when I right click, as I put debug messages in the method that never get run. I'm guessing that there's just one little thing that I'm not adding that would solve the whole thing, but I have no idea what it might be. Most of the code for the item and entity is copied directly from the snowball class, so I'm not sure if it has anything to do with those classes. Edit: This problem has been solved. For any future readers who have the same problem, the code below is updated to be correct and can be used as a reference. Here's the code for the mod. Entity class: public class RiceBulletEntity extends ProjectileItemEntity { public RiceBulletEntity(EntityType<? extends RiceBulletEntity> p_i50159_1_, World p_i50159_2_) { super(p_i50159_1_, p_i50159_2_); } public RiceBulletEntity(World worldIn, LivingEntity throwerIn) { super(Registries.RICE_BULLET.get(), throwerIn, worldIn); } public RiceBulletEntity(World worldIn, double x, double y, double z) { super(Registries.RICE_BULLET.get(), x, y, z, worldIn); } @Override protected Item getDefaultItem() { return Registries.RICE_BULLET_ITEM.get(); } @Override public IPacket<?> createSpawnPacket() { return NetworkHooks.getEntitySpawningPacket(this); } @Override protected void onImpact(RayTraceResult result) { if (!this.world.isRemote) { this.world.setEntityState(this, (byte)3); this.remove(); } } } Item class: public class RiceBulletItem extends Item { public RiceBulletItem(Item.Properties builder) { super(builder); } @Override public ActionResult<ItemStack> onItemRightClick(World worldIn, PlayerEntity playerIn, Hand handIn) { ItemStack itemstack = playerIn.getHeldItem(handIn); if (!worldIn.isRemote) { RiceBulletEntity riceBullet = new RiceBulletEntity(worldIn, playerIn); riceBullet.setItem(itemstack); riceBullet.shoot(playerIn, playerIn.rotationPitch, playerIn.rotationYaw, 0.0F, 1.5F, 1.0F); worldIn.addEntity(riceBullet); } playerIn.addStat(Stats.ITEM_USED.get(this)); if (!playerIn.abilities.isCreativeMode) { itemstack.shrink(1); } return ActionResult.resultSuccess(itemstack); } } Item and entity registries: public class Registries { public static final DeferredRegister<Item> ITEMS = new DeferredRegister<>(ForgeRegistries.ITEMS, Minesokyo.MOD_ID); public static final DeferredRegister<EntityType<?>> ENTITIES = new DeferredRegister<>(ForgeRegistries.ENTITIES, Minesokyo.MOD_ID); public static void init() { ITEMS.register(FMLJavaModLoadingContext.get().getModEventBus()); ENTITIES.register(FMLJavaModLoadingContext.get().getModEventBus()); } public static final RegistryObject<Item> RICE_BULLET_ITEM = ITEMS.register("rice_bullet_item", () -> new RiceBulletItem(new Item.Properties().group(ItemGroup.COMBAT))); public static final RegistryObject<EntityType<RiceBulletEntity>> RICE_BULLET = ENTITIES.register("rice_bullet", () -> EntityType.Builder.<RiceBulletEntity>create(RiceBulletEntity::new, EntityClassification.MISC) .build("rice_bullet")); } Entity renderer: public class RiceBulletRenderer extends SpriteRenderer<RiceBulletEntity> { public RiceBulletRenderer(EntityRendererManager renderManagerIn, ItemRenderer itemRendererIn) { super(renderManagerIn, itemRendererIn); } protected static final ResourceLocation TEXTURE = new ResourceLocation(Minesokyo.MOD_ID, "textures/items/rice_bullet.png"); @Override public ResourceLocation getEntityTexture(RiceBulletEntity entity) { return TEXTURE; } public static class Factory implements IRenderFactory<RiceBulletEntity> { @Override public EntityRenderer<? super RiceBulletEntity> createRenderFor(EntityRendererManager manager) { return new RiceBulletRenderer(manager, Minecraft.getInstance().getItemRenderer()); } } } Renderer registries: @Mod.EventBusSubscriber(modid = Minesokyo.MOD_ID, bus = Mod.EventBusSubscriber.Bus.MOD, value = Dist.CLIENT) public class ClientEventBusSubscriber { @SubscribeEvent public static void onClientSetup(FMLClientSetupEvent event) { RenderingRegistry.registerEntityRenderingHandler(Registries.RICE_BULLET.get(), new RiceBulletRenderer.Factory()); } }
  5. Oof, sort of forgot about this problem for a while but now I'm trying it again, and it's still the same problem. Not sure if it's against the rules to revive threads as old as this, but I haven't actually solved it yet, so. The forge version is 14.23.5.2768 Minecraft 1.12.2 I have looked at the vanilla code, and low and behold, even the vanilla code uses the same method to override light level checks in its own mobs, specifically the blaze and silverfish. And obviously it works in vanilla.
  6. Can anyone help me with this? I've tried absolutely everything to make this work and it still hasn't. I'm thinking that it's either a forge bug, or overriding the isValidLightLevel method is just an outdated way of doing it and no longer works, since every post that mentions it was from several years ago. It certainly would make sense for it to work though.
  7. I'm trying to get a custom mob to spawn regardless of light level, and for some reason the code isn't working. I've overridden the isValidLightLevel() method to always return true, but they still seem to only spawn at night. There's nothing else wrong with it other than what time it spawns at, and as far as I'm aware it should be working exactly as intended. Here's my code. public class EntityCirno extends EntityMob { public EntityCirno(World worldIn) { super(worldIn); } @Override protected boolean isValidLightLevel() { return true; } } There is no AI implemented right now because the spawning should work fine without it, and it does, except that they still only spawn in the dark. I honestly, sincerely have no clue what I'm doing wrong. Other forum posts have said this is exactly what I need to do as well. I may just be missing something very obvious here.
  8. I'm trying to make a mob that will only naturally spawn once in a world at a time until it's either killed or it despawns, but for some reason my code isn't working and I'm not sure why. Here is my code, can someone tell me what I'm doing wrong? There are no errors when I load up the world, but it seems that the world.getLoadedEntityList().contains(this) is always returning false, even when one entity already exists, so more than one can spawn in the world. That tells me I'm using the method wrong, but I'm not sure what else to use or what I'm doing wrong with it. public class EntityRumia extends EntityMob { public EntityRumia(World worldIn) { super(worldIn); this.setSize(0.6F, 1.8F); } @Override public boolean getCanSpawnHere() { return !world.getLoadedEntityList().contains(this) && super.getCanSpawnHere(); } }
  9. I'm trying to make a mod with an entity that will have a semi-transparent black sphere around them whenever it turns day, but I'm having trouble learning how to actually do it. All the tutorials I've found so far say that I have to make the sphere using GL11 in the ClientProxy class and then render it by overriding the passSpecialRender() method, but as far as I can tell, there is no method by that name. Nor is there a class called Renderer, which I've also heard mentioned. Maybe those tutorials are just out of date or I'm just stupid. Can someone tell me what I'm missing here? Edit: Nevermind, I figured out how to do it. I had to use the doRender() method instead of passSpecialRender and it worked just fine.
  10. Thanks for the reply, I'll look into those resources, although the videos you linked are outdated by now I think. And what I mean by the ModelLoader method is this thing: "ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(item.getRegistryName(), id));". I only have a basic grasp on what it means, but in Loremaster's videos, he put that method in another method called registerItemRenderer inside the ClientProxy class, and then called that method in a RegistryHandler class using the subscribe events. And I don't understand why he did it that way, he kind of just expects you to either intuitively know why he did it somehow, or he expects you to just not care. Either way I didn't learn much from it. If you watch his video on custom items you'll see what I mean, I don't know how to describe it well. I'm not necessarily looking for a "tutorial" or a "guide," but I'm looking for ways to find information that I'll need to make mods on my own. For example, if certain methods can only run on client side or run differently on server side and client side, how will I know? In tutorials they say "you use the proxy classes for methods that can only run on either side," but how will I know when that's the case for any given method? Is there some metaphorical giant flashing sign for every method somewhere saying "yo, this method can only be run in the client proxy or else it will break everything, just a heads up"? Edit: Just realized ModelLoader is a class not a method, I'm an idiot sometimes lol
  11. I'm very new to Forge modding and have only been learning it for a few days, so I've been going through dozens of tutorials to try to understand how all the setup works. Right now I'm using Loremaster's 1.12.2 tutorials, but there are a lot of things I'm confused about that he doesn't explain, and I've seen a lot of people saying that the way he does it is highly inefficient, so I'm afraid he's teaching me bad coding practices, so I'm hoping someone can clear this up a bit more for me. Loremaster uses proxy classes in his tutorials, the ClientProxy and the CommonProxy, and from what I understand, the proxy classes are there to tell Forge what side to run that code in. But I've heard so many people say that using a "common proxy" is stupid because everything is common code except the actual designated client proxy and server proxy. If that's so universally true and known, why does every recent Youtube tutorial I find use the CommonProxy?? Are they all just stupid or something? And second, in his tutorials, he puts the ModelLoader method in the ClientProxy class, and I can only GUESS that the reason is because the ModelLoader method can only be run on the client side (because "models" are the 3D images the player interacts with, right? Maybe? I have no idea, I can't find a straight answer as to what a "model" actually is). That seems to make sense to me, but I tried using the ModelLoader method outside the ClientProxy class, and it seemed to work just fine. Nothing crashed, no exceptions, everything worked. If it worked, then why did it even need to go in the ClientProxy to begin with?? Is that an example of "reaching across sides" as the Forge docs put it? I can't seem to find a good tutorial that goes through this stuff so you actually know what things do and why so you know what you need to do and what's redundant. No tutorial I've seen ever really explains these things in depth, they just tell you to do what they do because, "well you wanted to make a mod right?? Of course I'm not actually going to go in depth on how to be efficient and only do things when you need to do them, just blindly follow what I do and you got yourself a probably badly-designed mod that will break with anything else except very basic stuff." It's kind of frustrating.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.