-
Posts
5117 -
Joined
-
Last visited
-
Days Won
75
Posts posted by Choonster
-
-
2 hours ago, Draco18s said:
"The guy who wrote this had to test it somehow! I wonder if he wrote any test code and where I might find it...maybe the Forge Github? Nah, couldn't be there, that would be dumb."
The OP is asking about Vanilla loot conditions and functions, not global loot modifiers.
11 hours ago, The_Wabbit said:For 1.16.x custom loot conditions and loot functions require registration of matching LootConditionType and LootFunctionType. There are no hooks via Forge registry events and using the builtin registry directly (sample how below) doesn't work (tried doing before registry events and after...nada).
Registry.register(Registry.LOOT_CONDITION_TYPE, <my_name>, new LootConditionType(<my_serializer>))
This is probably staring me right in the eyeball, but I can't see it. Any directions/samples would be appreciated.
I'm not 100% sure if it's the correct time to register them, but I do it on the main thread after FMLCommonSetupEvent (i.e. inside a lambda passed to event.enqueueWork). I use the Vanilla registries, just like in your example.
I'm not sure if it's necessary to register non-Forge registry entries at any specific time like it is with Forge registry entries.
This is my FMLCommonSetup handler, this is my LootConditionType registration and this is my LootFunctionType registration.
- 1
-
3 hours ago, ChampionAsh5357 said:
If I'm not mistaken, there should be a builder that allows a supplier of a configured feature to be taken in. However, if this does not work, then you would need to handle the features within the biome itself in the highest priority. You can also create a json version of the biome and use the entry as a dummy. This way the feature can be loaded into the world from the json itself without the need to navigate around registries.
Thanks, I saw the Supplier overloads but didn't think to use them for lazy/deferred references.
I realised after posting that my issue was actually with a SurfaceBuilder rather than a Feature (I could have moved the Feature registration since it wasn't being used in the Biome), but the same solution applies: use the Supplier overload instead of trying to pass the ConfiguredSurfaceBuilder directly.
For future reference, I fixed the original issue and a few related worldgen registration issues with this commit.
I decided not to go with the JSON route since my biome makes use of a lot of Vanilla features/structures (the same ones as the Vanilla Desert biome) and I didn't want to write all of that out by hand. I would have liked a data generator approach like blockstates, models, loot tables, etc.; but the Vanilla BiomeProvider is only designed to generate "report" files from already-registered Biomes. I did end up adding my own version of BiomeProvider that only generates files for my own mod's biomes in this commit, the generated JSON file is 1,968 lines.
-
I'm trying to register a Biome with a Feature from my mod, but I'm having difficulty because Biome registration happens before Feature registration.
This is the relevant registration code:
- Feature (DeferredRegister)
- Biome (DeferredRegister)
- ConfiguredFeature (Vanilla registry, called from here in RegistryEvent.Register<Biome> with HIGH priority to run before Biome DeferredRegister).
The game crashes on startup because the ConfiguredFeature registration runs before the Feature has been registered:
java.lang.NullPointerException: Registry Object not present: testmod3:banner at java.util.Objects.requireNonNull(Objects.java:290) at net.minecraftforge.fml.RegistryObject.get(RegistryObject.java:120) at choonster.testmod3.init.ModConfiguredFeatures.register(ModConfiguredFeatures.java:25) at choonster.testmod3.TestMod3.registerBiomes(TestMod3.java:57)
What's the best way to work around this? Should I create the Features in RegistryEvent.Register<Biome> and then register them in RegistryEvent.Register<Feature>?
-
I've reported this to Hwyla here.
-
I've cross-posted this to StackOverflow here, hopefully someone over there will have an answer.
-
1 hour ago, Serilum said:
Does using the '--continue' flag in the gradlew command work?
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.
- 1
-
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).
- 1
-
You could probably pass a Supplier/RegistryObject of the TileEntityType to the Block's constructor, then use that to create the TileEntity.
-
-
Use SlotItemHandler.
-
On 5/24/2020 at 7:21 PM, loordgek said:
should addListener throw a exception if you try to add a GenericListener ??
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.
-
1 hour ago, Novârch said:
I've run into a problem here , as you can see above I'm sending the update packet using this method: INSTANCE.send(PacketDistributor.PLAYER.with(() -> (ServerPlayerEntity) player), new SyncStandCapability(props)) , but I run into some trouble using that in the class you're referring to as I can't get the player, using Minecraft#player would give me the client player, which I can't use, what PacketTarget would be most suitable for use in this class?
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.
- 1
-
Capabilities aren't synced automatically, you need to sync them yourself. It doesn't look like you're doing this.
3 hours ago, Novârch said:LazyOptional<IStand> power = Minecraft.getInstance().player.getCapability(JojoProvider.STAND, null); IStand props = power.orElse(new IStandCapability());
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.
- 1
-
5 hours ago, Rikka0_0 said:
How to invoke the DataGenerator? I launched the game, the GatherDataEvent is not fired by MinecraftForge.
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:
-
16 hours ago, diesieben07 said:
IntelliJ JSON support requires IntelliJ Ultimate.
As such no third party JSON plugins are allowed, as far as I know.
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.
[1.16] syncronising itemstack capabilities for any item
in Modder Support
Posted
With my system, each capability type that needs to be synced to the client has several sync-related classes:
A factory function for the container listener is registered with CapabilityContainerListenerManager.registerListenerFactory at startup so that when a player opens a Container, a new listener can be created and added to it.
The network messages have the concept of a "data" class, which is a simple POJO (or even a primitive type like int or long) containing only the data that needs to be synced from the server to the client. The base classes for the messages handle the functionality that's common to all capability types, the message classes for each capability just need to provide functions to do the following:
These functions could be defined anywhere (they could even be lambdas passed directly to the base class methods), but I keep them as static methods in a "functions" class so they can be shared between the single and bulk messages.
The system might be a bit over-engineered, but it means that I can easily add syncing for a new item capability without having to rewrite all the common syncing logic.
There are several implementations of this in TestMod3 that you could use as examples: