Choonster

That lets it continue to other tasks after javadoc, but the Javadoc generation still fails.

My mod depends on HWYLA, which has an API JAR containing both compiled classes and their source code. Unfortunately there seem to be some Javadoc errors in this code, which is preventing the generation of Javadoc for my own code. The Gradle output looks like this (from this CI run): > Task :processResources > Task :classes > Task :makeLibraryMetas UP-TO-DATE > Task :jar > Task :downloadMcpConfig > Task :extractSrg > Task :createMcpToSrg > Task :reobfJar /home/runner/.gradle/caches/forge_gradle/deobf_dependencies/mcp/mobius/waila/Hwyla/1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2/Hwyla-1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2-api.jar(mcp/mobius/waila/api/IComponentProvider.java):56: error: invalid end tag: </br> * Callback used to add lines to one of the three sections of the tooltip (Head, Body, Tail).</br> ^ /home/runner/.gradle/caches/forge_gradle/deobf_dependencies/mcp/mobius/waila/Hwyla/1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2/Hwyla-1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2-api.jar(mcp/mobius/waila/api/IComponentProvider.java):57: error: invalid end tag: </br> * Will only be called if the implementing class is registered via {@link IRegistrar#registerComponentProvider(IComponentProvider, TooltipPosition, Class)}.</br> > Task :javadoc ^ /home/runner/.gradle/caches/forge_gradle/deobf_dependencies/mcp/mobius/waila/Hwyla/1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2/Hwyla-1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2-api.jar(mcp/mobius/waila/api/IComponentProvider.java):58: error: invalid end tag: </br> * You are supposed to always return the modified input tooltip.</br> ^ /home/runner/.gradle/caches/forge_gradle/deobf_dependencies/mcp/mobius/waila/Hwyla/1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2/Hwyla-1.10.11-B78_1.16.2_mapped_snapshot_20200916-1.16.2-api.jar(mcp/mobius/waila/api/RenderableTextComponent.java):5: error: package mcp.mobius.waila.api.impl does not exist import mcp.mobius.waila.api.impl.WailaRegistrar; ^ 4 errors > Task :javadoc FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':javadoc'. > Javadoc generation failed. Generated Javadoc options file (useful for troubleshooting): '/home/runner/work/TestMod3/TestMod3/build/tmp/javadoc/javadoc.options' How can I tell Gradle/Javadoc to ignore these errors and just generate the documentation for my own code? I could probably turn off doclint, but I'd rather avoid doing that. I've tried inspecting the tasks.javadoc.source property and adding an exclude filter to the task; but these only contain the paths of my own code, not the HWYLA JAR or source files.

Instead of using multiple DeferredReigsters and iterating through your Blocks to register your BlockItems, it's probably simpler to just register the BlockItem at the same time as the Block (with DeferredRegister, so the actual registration still happens at the right time). This can be done helper methods like these; you could create a single method that takes the ItemGroup as a parameter, or separate methods for each ItemGroup.

You can register BlockItems with DeferredRegister in the same way as normal Items. Since Blocks are registered before Items, just call RegistryObject#get on your RegistryObject<Block> in the Supplier. I use these two utility methods to automatically register a BlockItem with the Block using DeferredRegister. RegistryUtil.getRequiredRegistryEntry just returns the registry entry from a RegistryObject or throws an exception if it's not present; but this isn't required in 1.15+ because RegistryObject#get already does this (it didn't in 1.14).

You could probably pass a Supplier/RegistryObject of the TileEntityType to the Block's constructor, then use that to create the TileEntity.

williewillus has an explanation of the changes in 1.13/1.14 here and 1.15 here.

Use SlotItemHandler.

cpw created an issue for that a while ago, but hasn't gotten around to fixing it yet.

For mods with Maven repositories, you can use fb.deobf dependencies like this. This deobfuscates the mod for you.

Use Data Generators to generate the JSON files, there's no need to copy any files. There's a discussion of the system and some links to examples here:

Which Minecraft version are you using? In 1.14.4/1.15.2, the Forge blockstates format has been deprecated/removed; and the model system has been reworked such that multi-layer models are defined in the model file itself rather than the blockstates file.

Store a reference to the player in the StandCapability class, then send to that player (on the server).

The server should be handling all of the game logic, including when to send packets to the clients. The client shouldn't be requesting a sync, it should mostly just be responsible for notifying the server of player input and displaying/rendering the data that the server tells it to. The capability handler class (IStandCapability) should send the sync packet to the client whenever its data changes, and probably when the player logs in as well. This is assuming that the player that the capability is attached to is the only one who needs this data on the client. Don't just write your capability to NBT and send that in the packet, only send the data that the client needs for display purposes. I don't know exactly why your current implementation doesn't work, but if you do things properly it should be easier to figure out what (if anything) still isn't working. On a related note, IStandCapability isn't a good class name; the I prefix is usually reserved for interfaces. If you have an interface IFoo with a single default implementation, it's common to name that class Foo.

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.