Choonster

src/generated/resources and any generated models, loot tables, recipes, etc. (see GatherDataEvent, DataGenerator and the implementations of IDataProvider) inside of that directory should be included in your repository, but the .cache directory should be ignored. If you look at Forge's repository, you'll see that it ignores the .cache directory while including everything else in src/generated/resources.

I can't see anything obviously wrong with your data generators, have you tried stepping through the code in the debugger? I have some working data generators here.

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).

Use the build overload that takes a ResourceLocation argument to change the name of the generated recipe.

tterrag did create a PR for that here, but it went stale.

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.

You need to run the build task, this reobfuscates the built JAR so it can be loaded outside of the development environment.

It's still isRemote (and probably always will be), see this issue on the MCPBot issue tracker.

Minecraft assumes that every block is an opaque cube by default, so it doesn't render the adjacent block faces. Override Block#isOpaqueCube to return false to fix this.

Yes. The client loses the attribute (which may be a Vanilla bug, I'm not sure), but the server retains the correct value and re-syncs it to the client.

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).

I'm pretty sure this method worked in 1.12.2, the linked code is for 1.14.4 but I haven't tested it yet.

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.

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.

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.

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.

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.

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

@Mod.EventBusSubscriber only registers static @SubscribeEvent methods, your onPlayerJoin method isn't static. See the documentation for more details.

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.

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.

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.

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.

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.

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.