Jump to content

BrewingCoder

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by BrewingCoder

  1. Thank you!! Crap I originally just C/P'd that exact code block from another source and never revisited it; just the actual generators. And regarding the tokens; yes, but you know my mod is like small potatoes, and fixing up the ci/cd stuff in the build was like waaay down on my to-do list I will definitely get that figured out.
  2. Sure thing, here's a gist of the error log when running outside of dev: https://gist.github.com/BrewingCoder/0b4d9bca2b6b6586cd1578e99072b972 The repo is here: https://github.com/BrewingCoder/BrewTools This issue only started occurring recently. The last few commits and builds I've done have been around implementing data generation to replace static files. Though I do need to do a few more tests reverting back to a lower forge build though -- I just realized that a bump to 40.1.0 was also a recent change. -BC
  3. I appear to be running into a timing issue; something that I do not experience in a development environment when running Minecraft from IntelliJ but do experience when running outside of development. I get the following error when running outside dev: [23:53:27] [Worker-Main-20/ERROR]: Exception caught during firing event: Registry Object not present: brewtools:abyssal Index: 1 Listeners: 0: NORMAL 1: ASM: class com.brewingcoder.brewtools.world.OreGeneration createConfiguredOreFeature(Lnet/minecraftforge/fml/event/lifecycle/FMLCommonSetupEvent;)V java.lang.NullPointerException: Registry Object not present: brewtools:abyssal at java.base/java.util.Objects.requireNonNull(Objects.java:334) Which basically means that the OreGeneration appears to be attempting to register before the blocks? All of my registrations happen inside the constructor of my Mod Class like so: public BrewTools() { IEventBus bus = FMLJavaModLoadingContext.get().getModEventBus(); Configs.register(); ModBlocks.register(bus); ModItems.register(bus); ModSounds.register(bus); bus.addListener(this::setup); bus.addListener(this::enqueueIMC); bus.addGenericListener(BlockEntityType.class,this::registerTileEntities); MinecraftForge.EVENT_BUS.register(this); MinecraftForge.EVENT_BUS.addListener(EventPriority.LOW, OreGeneration::onBiomeLoadingEvent); } as you can see, the Blocks are registering before the Ore Generation features. The blocks are registered using the typical deferred registry method like so: public static final DeferredRegister<Block> BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS, BrewTools.MODID); public static final RegistryObject<Block> ABYSSAL = registerBlock("abyssal",()-> new Block(defaultProps)); .... public static void register(IEventBus bus){ BLOCKS.register(bus); } Any idea why this is happening? Especially why it would work in development but not in a non-development environment? -BC
  4. it's probably having trouble resolving the dependency maven location; an error from Gradle would be really swell. That's sure to tell you exactly what the issue is.
  5. I'm trying to overcome a little issue. I'm trying to save data to an item's tag. This works perfectly fine in survival but does not work in creative mode. @Override public ActionResultType interactLivingEntity(ItemStack stack, PlayerEntity player, LivingEntity livingEntity, Hand hand) { if (hasAnimal(stack) || !livingEntity.isAlive() || livingEntity instanceof PlayerEntity) return ActionResultType.PASS; if (!player.level.isClientSide && livingEntity.isAlive() && livingEntity instanceof MonsterEntity) { CompoundNBT entityNBT = livingEntity.serializeNBT(); stack.getOrCreateTag().put(NBT_ANIMAL,entityNBT); livingEntity.remove(); return ActionResultType.SUCCESS; } return ActionResultType.PASS; } I totally get if I was trying to do something like ItemStack.HurtAndBreak() which would damage it, but the tags don't even populate with data once outside of this event (They are retrievable while still locally in the event and have access to the instance passed into the event). The item in question is a single-stack item. Switching to Survival rectifies this situation. Is this expected? Normal? If not am I doing something wrong? ~BrewingCoder
×
×
  • Create New...

Important Information

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