Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Posts posted by Choonster

  1. 10 minutes ago, Draco18s said:

    Also at 645 lines, that sounds like more work than just writing the json by hand.

     

    For simple blocks, it can be a single method call that generates both the blockstates file and the block model. If you have a lot of similar blocks, you can use loops or helper methods to save having to write out the JSON by hand (or having to write your own JSON generation code).

     

    The fluent-style builder classes make it very simple to use. The IDE can auto-complete all the methods and fields for you, so you don't have to manually type out block, property and value names.

    • Like 1
  2. 1 minute ago, Animefan8888 said:

    Wow. When did that become a thing? Also why did it become a thing? It seems a bit weird to have that in your mod during and post compilation. Is that something you would remove/exclude before compiling your mod since assets are packed into the jar file anyways?

     

    Mojang added data generators (or stopped stripping them from the built JAR) in 1.14. Model generation was added in October last year by this PR.

     

    The code is still in the mod JAR after it's built, but it doesn't run at all during normal gameplay; there's a separate main class (net.minecraft.data.Main) that runs data generators.

    • Like 2
  3. 1 hour ago, Maciej916 said:

    Thank you it worked :)

     

    
            CookingRecipeBuilder.smeltingRecipe(Ingredient.fromItems(ModBlocks.COPPER_ORE.get()), ModItems.COPPER_INGOT.get(), 0.6f, 200)
                    .addCriterion("item", InventoryChangeTrigger.Instance.forItems(ModBlocks.COPPER_ORE.get()))
                    .build(consumer, new ResourceLocation("copper_ingot_smelting"));

     

     

    That code creates the recipe in the minecraft namespace, you should use your mod ID as the namespace of the ResourceLocation (i.e. call the two-argument overload of the ResourceLocation constructor).

  4. 3 hours ago, wasEnabled said:

    So, to clarify, for anyone else who finds this post.  What I was doing incorrectly was that was using Tasks > build > build but I was taking the .jar file from my /build/libs folder, which is named after my modid (so in my case it's named justfileapi-1.0.jar), but this is a pre-re-obfuscated version of the jar.  In the /builds/reobfJar/ folder however there is an "output.jar" file which is my re-obfuscated .jar file -- this is the final version which I manually renamed and deployed.

     

    The JAR in the build/libs directory is the correct one, you just need to run build instead of jar. You don't need to use anything from any of the other directories in build, they only contain temporary/intermediate files.

  5. 2 hours ago, FireController1847 said:

    It worked! Awesome, thank you!

     

    I don't suppose you'd be willing to help me understand what this piece of code does? I kind of get that it's making a packet for the attribute, but what is this "sendToTrackingAndSelf" method?

     

    It sends the packet to all players whose clients are tracking the entity (i.e. all players within X blocks of it) as well as the entity itself (if it's a player).

  6. 2 hours ago, TheOnlyTrueEnte said:

    Just out of curiosity though and since I might add more Dispense behaviors in the future, is there a way to actually add Dispense functionality to an already registered block?

     

    It should be possible to overwrite the existing behaviour simply by calling DispenserBlock.registerDispenseBehavior with your IDispenseItemBehavior. If you want to delegate to the existing behaviour, you'll need to use reflection to access DispenserBlock.DISPENSE_BEHAVIOR_REGISTRY and fetch the existing behaviour before overwriting it.

    • Thanks 1
  7. 21 minutes ago, TheOnlyTrueEnte said:

    No. If my TNT extends TNTBlock, dispensing Flint and Steel onto it will just spawn a vanilla TNTEntity. Here's an excerpt from IDispenseItemBehavior#init, of the OptionalDispenseBehavior for FLINT_AND_STEEL:

    
    if (blockstate.getBlock() instanceof TNTBlock) {
    	TNTBlock.explode(world, blockpos);
        world.removeBlock(blockpos, false);
    }

    TNTBlock#explode is obviously a static method here so I can't do anything to sort of override it.

     

    This should have been fixed by this PR (merged in Forge 1.14.4-28.1.92). The dispense behaviour now checks for any flammable block and calls Block#catchFire instead of calling the static method.

    • Thanks 1
  8. 11 minutes ago, imacatlolol said:

    Woah... The DeferredRegister system is really cool! That's even better than anything I was expecting, thanks for bringing it to my attention!

    I'm assuming it won't interfere with ObjectHolder, right? From the looks of it, I simply need to initialize ObjectHolder objects with DeferredRegister#register instead of null and ObjectHolder will still take over any replacements by other mods.

     

    If you're using DeferredRegister, you don't need to use @ObjectHolder at all; the returned RegistryObject is internally registered as an ObjectHolder and as such is automatically updated with overrides.

  9. 2 hours ago, oitsjustjose said:

    That makes sense. I had a hunch that it had something to do with priority / race condition, it I wasn’t sure and wondered if it was something else. Ok. 
     

    Is there a way to programmatically remove recipes? I’m aware of RecipeManager but I’m not sure in which context I can obtain an instance (or should I declare my own?), and either way I’ve had issues with not being able to remove from the list (I imagine by the time it becomes accessible it is immutable but I didn’t look too far into it as it felt like a hack).

     

    You can see how I remove recipes according to various conditions here. The recipe maps are immutable, but the fields storing them aren't final.

    • Thanks 1
  10. 8 minutes ago, Simon_kungen said:

    So, it seems like this thread died right when it was born. So let me reformulate: Read custom Json files in the data/ directory and do stuff with that. Does Minecraft have a static function to read the Json files and get the values inside that?

     

    It looks like Vanilla extends JsonReloadListener for recipes (RecipeManager), advancements (AdvancementManager) and loot tables (LootTableManager).

×
×
  • Create New...

Important Information

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