Choonster

The genVSCodeRuns Gradle task generates run configurations for VS Code.

Capabilities aren't synced automatically, you need to sync them yourself. It doesn't look like you're doing this. You probably don't want to use LazyOptional#orElse like that, if the capability isn't present you should either do nothing (if it's expected to not be present sometimes); or throw an error (if it should always be present). You generally don't want to carry on performing the action on a new instance that's not stored anywhere or used by anything. Use LazyOptional#ifPresent to run code only when the capability is present, or LazyOptional#orElseThrow to throw an error when it's not present.

I actually managed to get DeferredRegister working with a custom registry (created in RegistryEvent.NewRegistry) by using a lazy-loading IForgeRegistry wrapper class. You can see my implementation here. This is for 1.14.4, but I imagine it will work in 1.15.2 as well.

By default, Forge generates three run configurations for your IDE: runClient, runServer and runData. You need to use runData to run the data generators.

You can use the Data Generator system to avoid writing blockstates/model files by hand. There's a discussion of the system and some links to examples here:

I don't think this is the case, at least not any more. I'm using IntelliJ IDEA Community Edition and I seem to have full access to JSON syntax highlighting/validation and schema validation. The editions comparison page also lists JSON under Community Edition.

Use SlotItemHandler instead of Slot.

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.

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.

BlockStateProvider is the correct way to generate blockstate and model files. There's an example in Forge's GitHub repository here, and in my mod here.

This looks like an issue with Forge's dev-time login implementation, I've reported it on GitHub.

The mappings are provided by MCP and many are contributed by the community. You can contribute using MCPBot and its issue tracker. Mojang did start providing mappings, but there are potential legal issues preventing Forge from using them. I believe CPW tweeted about this a while back and the Forge twitter account retweeted it.

I haven't tested it, but I assume you can just remove REGISTRYDUMP from the forge.logging.markers property of the run configuration in build.gradle and regenerate your IDE run configurations.

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.