Jump to content
  • Home
  • Files
  • Docs
  • Merch
Status Updates
  • All Content

  • Advanced Search
  • Existing user? Sign In  

    Sign In



    • Not recommended on shared computers


    • Forgot your password?

  • Sign Up
  • All Activity
  • Home
  • Choonster

Choonster

Forge Modder
 View Profile  See their activity
  • Content Count

    5047
  • Joined

    July 19, 2015
  • Last visited

    7 hours ago
  • Days Won

    72

 Content Type 

  • All Activity

Profiles

  • Status Updates
  • Status Replies

Forums

  • Topics
  • Posts

Calendar

  • Events
  • Event Comments

Everything posted by Choonster

  • Prev
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • Next
  • Page 1 of 200  
  1. Choonster

    [Solved for igniting custom TNT] [1.14.4] add Dispense Behavior to vanilla item

    Choonster replied to TheOnlyTrueEnte's topic in Modder Support

    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.
    • November 29
    • 5 replies
      • 1
      • Thanks
  2. Choonster

    [Solved for igniting custom TNT] [1.14.4] add Dispense Behavior to vanilla item

    Choonster replied to TheOnlyTrueEnte's topic in Modder Support

    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.
    • November 29
    • 5 replies
      • 1
      • Thanks
  3. Choonster

    [SOLVED][1.14.4] ObjectHolder "Always Null" Warning Workaround?

    Choonster replied to imacatlolol's topic in Modder Support

    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.
    • November 9
    • 5 replies
  4. Choonster

    [SOLVED][1.14.4] ObjectHolder "Always Null" Warning Workaround?

    Choonster replied to imacatlolol's topic in Modder Support

    One way is to use a method that always returns null but suppresses IDEA's warnings, like this: method, usage The newer way is to use the DeferredRegister system that was introduced relatively recently. I've started updating to this, but it doesn't look like I've pushed any of my changes to GitHub.
    • November 9
    • 5 replies
      • 3
      • Like
  5. Choonster

    [1.14.4] [SOLVED] Custom ShapelessRecipe class inconsistent with Crafting

    Choonster replied to oitsjustjose's topic in Modder Support

    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.
    • October 26
    • 5 replies
      • 1
      • Thanks
  6. Choonster

    [1.14.4] Anvil Crushing mechanic + Custom Data JSON structure

    Choonster replied to Simon_kungen's topic in Modder Support

    It looks like Vanilla extends JsonReloadListener for recipes (RecipeManager), advancements (AdvancementManager) and loot tables (LootTableManager).
    • October 19
    • 3 replies
  7. Choonster

    [1.14.4][Solved] OnPlayerJoinEvent not firing?

    Choonster replied to Elrol_Arrowsend's topic in Modder Support

    @Mod.EventBusSubscriber only registers static @SubscribeEvent methods, your onPlayerJoin method isn't static. See the documentation for more details.
    • October 19
    • 2 replies
  8. Choonster

    [1.14.4][Solved] Complex Commands

    Choonster replied to Elrol_Arrowsend's topic in Modder Support

    You need to create a literal argument (Commands.literal) for "string" and call requires/then/execute on that as necessary and do the same for "player". In your main command registration (where you call CommandDispatcher#register), create a literal argument for "testcommand" and call then on it with the result of each literal method chain. If string and player are more like separate commands than modes of the same command, you can move each sub-command into its own class with a static method that returns an ArgumentBuilder<CommandSource, ?> (the result of the literal method chain) and call these methods in the then calls of the main command registration. See ForgeCommand or my TestMod3Command for examples of this.
    • October 19
    • 2 replies
  9. Choonster

    How to disable forge's "freezing registries" log?

    Choonster replied to TheShinyBunny's topic in Modder Support

    Remove the REGISTRYDUMP log marker from your run configurations in the minecraft > runs section of build.gradle and then re-run the genIntellijRuns or genEclipseRuns task to re-generate the IDE run configurations. For a less-permanent option, you can edit your IDE's run configurations directly instead.
    • September 13
    • 1 reply
      • 1
      • Like
  10. Choonster

    Where is the "days without sleeping" counter implemented?

    Choonster replied to OsHeaven's topic in Modder Support

    If you look at the references of PhantomEntity and EntityType.PHANTOM, you'll see that Phantoms are spawned by the PhantomSpawner class. This checks Stats.TIME_SINCE_REST for each player, which is incremented every tick while the player isn't sleeping in PlayerEntity#tick.
    • September 9
    • 2 replies
  11. Choonster

    [1.14.4][SOLVED] set block facing direction based on player

    Choonster replied to andGarrett's topic in Modder Support

    All you need to do is override Block#getStateForPlacement to return the state with the FACING property set based on the BlockItemUseContext. You don't need to override Block#onBlockPlacedBy or set the state in the World.
    • August 25
    • 6 replies
      • 1
      • Thanks
  12. Choonster

    [1.14.3] Working ORE GENERATION class

    Choonster replied to ianm1647's topic in Modder Support

    Currently, you need to create your own Feature implementation that does the same thing as OreFeature but can be configured to replace your desired block. If/when this pull request is merged, all you'll need to do is create a new FillerBlockType that matches the block you want to replace.
    • August 24
    • 4 replies
  13. Choonster

    [1.14.4][SOLVED] set block facing direction based on player

    Choonster replied to andGarrett's topic in Modder Support

    getFacingFromEntity doesn't appear to exist in Vanilla/Forge. Is it your own method? You should be using Block#getStateForPlacement to determine the placed BlockState, this provides you with an instance of BlockItemUseContext which has the BlockItemUseContext#getNearestLookingDirection method to get the facing from the entity placing the block.
    • August 24
    • 6 replies
  14. Choonster

    [Solved] [1.14.4] Determine whether a chunk is fully loaded during chunk loading

    Choonster replied to Choonster's topic in Modder Support

    Thanks, that worked perfectly.
    • August 24
    • 2 replies
  15. Choonster

    [Solved] [1.14.4] Determine whether a chunk is fully loaded during chunk loading

    Choonster posted a topic in Modder Support

    I have a chunk capability that stores an energy value for each chunk. The Capability.IStorage implementation calls ChunkEnergy#setEnergy when reading from NBT, this in turn calls ChunkEnergy#onEnergyChanged which sends a packet to update all clients tracking the chunk with the new energy value. In 1.12.2, I used World#isBlockLoaded before getting the Chunk from the World to prevent an infinite recursion scenario where loading the chunk attempts to load the chunk. In 1.14.4, I'm using IWorld#chunkExists instead; but this returns true even when the chunk is being loaded. If I then call World#getChunk while the chunk is being loaded, this seems to result in a deadlock where the chunk loading never completes and the world never loads. The code on GitHub currently uses world.getChunk(x, z), but I've tried calling world.getChunk(x, z, ChunkStatus.EMPTY, false) just to see if it will return null or an empty chunk and this results in the same deadlock. It seems like I could use ChunkHolder#func_219299_i and ChunkHolder#func_219278_b to get the ChunkStatus of a chunk, but there don't seem to be any public methods to get a ChunkHolder and I'm reluctant to use internal APIs if there are public APIs available. Does anyone know if there's a way to determine whether a chunk is fully loaded without causing a deadlock if called during chunk loading?
    • August 24
    • 2 replies
  16. Choonster

    [1.14] Forge Fluid Model?

    Choonster replied to Draco18s's topic in Modder Support

    The closest equivalents I can see are World#func_225319_b or WorldRenderer#markBlockRangeForRenderUpdate, though a lot of places that used to call World#markBlockRangeForRenderUpdate don't seem to call anything in its place now.
    • August 22
    • 7 replies
  17. Choonster

    [1.14] Forge Fluid Model?

    Choonster replied to Draco18s's topic in Modder Support

    Forge's fluid system (including the forge:fluid model) was removed in 1.13 due to large changes in the Vanilla fluid system. Forge's new fluid system is still being worked on, you can see some of the progress in this PR and KingLemming's fork. Until then, you could look at Vanilla's waterloggable blocks (IWaterLoggable) where the block can exist in the same space as a fluid (usually water). Extended states were replaced by the model data system in this PR.
    • August 21
    • 7 replies
  18. Choonster

    [1.14.4] Determining if an ItemStack can be smelted (blasted or smoked)?

    Choonster replied to Draco18s's topic in Modder Support

    AbstractFurnaceTileEntity stores its IRecipeType (BLASTING, SMELTING or SMOKING) in the protected AbstractFurnaceTileEntity#recipeType field, so you could use reflection to access this instead of using those instanceof checks. This would also handle any modded furnace that extends AbstractFurnaceTileEntity.
    • August 17
    • 3 replies
      • 1
      • Like
  19. Choonster

    [1.13.2] Fluid Logging

    Choonster replied to ChampionAsh5357's topic in Modder Support

    You'll probably have to wait until Forge's fluid system rewrite is completed, I'm pretty sure the Vanilla system only really supports water.
    • August 16
    • 4 replies
  20. Choonster

    HarvestDropsEvent not working as expected.

    Choonster replied to Andrew Murdza's topic in Modder Support

    Bus.FORGE is the default, so it doesn't need to be specified manually.
    • August 16
    • 4 replies
  21. Choonster

    [1.12 to 1.14] Make custom mobs spawn only at night (custom biome)

    Choonster replied to Alex Sim's topic in Modder Support

    It was made public again in this PR (1.14.4-28.0.37). Update Forge.
    • August 12
    • 4 replies
      • 1
      • Thanks
  22. Choonster

    [1.12 to 1.14] Make custom mobs spawn only at night (custom biome)

    Choonster replied to Alex Sim's topic in Modder Support

    It looks like spawning conditions are handled by EntitySpawnPlacementRegistry in 1.14. You need to call EntitySpawnPlacementRegistry.register with your EntityType and a predicate that determines the conditions under which it can spawn. Zombies and other hostile mobs use MonsterEntity::func_223325_c for the predicate, this checks the difficulty and the light level.
    • August 12
    • 4 replies
      • 1
      • Thanks
  23. Choonster

    [1.12.2] Only first fluid registered renders properly

    Choonster replied to Lyinginbedmon's topic in Modder Support

    I don't know exactly what your issue is, but I can point you to my 1.12.2 fluid code where I have several fluids with their own textures: initialisation and registration, model registration, blockstates file.
    • August 3
    • 2 replies
  24. Choonster

    [1.14.4] IForgeItem#initCapabilities called before Capabilities are registered

    Choonster replied to Choonster's topic in Modder Support

    It turns out that the constructor of the @Mod class is too early to call CapabilityManager#registerCapability as it uses the CapabilityManager#callbacks map, but this is only initialised between RegistryEvent.NewRegistry and RegistryEvent.Register being fired. Due to this, I kept the capability registration in FMLCommonSetupEvent and just added null protection to the IForgeItem#initCapabilities implementations. This fixed the crash. You can see the changes I made in this commit.
    • August 3
    • 4 replies
  25. Choonster

    [1.14.4] IForgeItem#initCapabilities called before Capabilities are registered

    Choonster replied to Choonster's topic in Modder Support

    Lex responded to the issue on GitHub and basically said to register the capabilities earlier and add null protection to the IForgeItem#createProvider implementation:
    • August 3
    • 4 replies
  • Prev
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • Next
  • Page 1 of 200  
  • All Activity
  • Home
  • Choonster
  • Theme
  • Contact Us
  • Discord

Copyright © 2019 ForgeDevelopment LLC · Ads by Curse Powered by Invision Community