Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

X-Lomir

Members
  • Posts

    81
  • Joined

  • Last visited

1 Follower

Converted

  • Gender
    Male
  • Location
    Italy

Recent Profile Visitors

9789 profile views

X-Lomir's Achievements

Stone Miner

Stone Miner (3/8)

0

Reputation

  1. I suggest you create a new ConnectableWallBlock that extends LeavesBlock, setting the PERSISTENT state property to true (because I imagine your walls don't need to decay). This way most of the leaf property you would expect from a block made of leaves should be already included and you also take advantage of Minecraft automatically setting the render layer to cutoutMipped or solid depending on the user graphic settings. Maybe won't solve your problem but it's sure a step forward.
  2. Yep. Instead of telling Forge a specific method needs to be called upon a certain event (which is what you were doing in the constructor) you're telling Forge to register that class (not instance, so only the static fields) to the event bus. Then, by adding @SubscribeEvent and the type of the event as parameter to the methods Forge will know that it has to call them upon the specified event. By the way if you think about it you're never calling any method you register to the event listeners (this::methodName passed the method as parameter, doesn't call it), you're instead passing them as parameter so that Forge knows what to call and when. The key difference is that in the constructor you're registering the methods to the event bus by calling IEventBus#addListener, instead with the separate class you're using annotations to do it. I am glad I was of help and I hope this explanation was helpful too.
  3. I told you, the methods need to be static. This is because with the annotation you're subscribing the class, not an instance of it. Quote from @diesieben07: "@EventBusSubscriber registers the class to the event bus, as such your event handler methods must be static." Quotes from me: "be careful to make your methods static if you do the same", "The important parts here are the Annotation for the class and the fact that its methods are static", "move those two methods into a separate class and make them static".
  4. As I said in my first reply, what I did was to directly subscribe a class that would handle the color events: @EventBusSubscriber(value = Dist.CLIENT, bus = Bus.MOD) public class ColorHandlerEventHandler { @SubscribeEvent public static void onColorHandlerEventBlock(ColorHandlerEvent.Block event) { // do stuff } @SubscribeEvent public static void onColorHandlerEventItem(ColorHandlerEvent.Item event) { // do stuff } } The important parts here are the Annotation for the class and the fact that its methods are static. If you do this you should also remove the lines in your constructor where you add those methods as listeners on the bus. So, to sum it up, remove the lines that register registerBlockColors and registerItemColors, move those two methods into a separate class and make them static, annotate the class with @EventBusSubscriber(value = Dist.CLIENT, bus = Bus.MOD) and you're good to go.
  5. Yeah I know, this is because Minecraft Vanilla doesn't have slabs of such materials, so in Vanilla no vertical slabs will have a need for coloring. However if you try my mod in combination with another mod that adds horizontal slabs of grass or foliage or whatever other block that needs coloring you will see that the vertical slabs will appear and will be tinted correctly I'm glad you could figure out the other problem anyway
  6. That register method takes as first parameter a instance of BlockColor, you are passing it an int (FoliageColor#getDefaultColor returns an int). A BlockColor instance is quite easy as BlockColor is just an interface with a single method: public interface BlockColor { int getColor(BlockState p_92567_, @Nullable BlockAndTintGetter p_92568_, @Nullable BlockPos p_92569_, int p_92570_); } Since you basically want to copy the coloring foliage gets, you can do something similar to me: @SubscribeEvent public static void onColorHandlerEventBlock(ColorHandlerEvent.Block event) { event.getBlockColors().register( new BlockColor() { public int getColor(BlockState state, @Nullable BlockAndTintGetter getter, @Nullable BlockPos pos, int tintIndex) { return getter != null && pos != null ? event.getBlockColors().getColor(Blocks.OAK_LEAVES.defaultBlockState(), getter, pos, tintIndex) : -1; } }, ModBuildingBlocks.CONNECTABLE_OAK_LEAF_WALL ); } Where you basically create a new BlockColor instance that returns the same coloring for oak leaves. Alternatively you can also create a separate class implementing BlockColor: public class ConnectableOakLeafWallBlockColor implements BlockColor { public int getColor(BlockState state, @Nullable BlockAndTintGetter getter, @Nullable BlockPos pos, int tintIndex) { return getter != null && pos != null ? Minecraft.getInstance().getBlockColors().getColor(Blocks.OAK_LEAVES.defaultBlockState(), getter, pos, tintIndex) : -1; } } And just pass it to register: @SubscribeEvent public static void onColorHandlerEventBlock(ColorHandlerEvent.Block event) { event.getBlockColors().register(new ConnectableOakLeafWallBlockColor(), ModBuildingBlocks.CONNECTABLE_OAK_LEAF_WALL); } The choice is yours. Also be careful because you need to avoid having this part of the code when your mod runs only server-side or it will just crash being unable to find BlockColor (which indeed exists only client-side). I fixed this problem by having a separate class handling my color registering annotated like so (be careful to make your methods static if you do the same): @EventBusSubscriber(value = Dist.CLIENT, bus = Bus.MOD) public class ColorHandlerEventHandler { @SubscribeEvent public static void onColorHandlerEventBlock(ColorHandlerEvent.Block event) { // do stuff } @SubscribeEvent public static void onColorHandlerEventItem(ColorHandlerEvent.Item event) { // do stuff } } I speak from experience 🤣 I hope I was of help, if you need to look more at my code the most updated branch is this one.
  7. However if I compute my maps during that event I won't have access to the recipe manager anymore, am I right? Also, other than the recipe manager, I need my maps to be computed before I do MutableSearchTree<ItemStack> creativeSearchTree = Minecraft.getInstance().getSearchTree(SearchRegistry.CREATIVE_NAMES); for(BlockState referredSlabState : VerticalSlabUtils.slabStateMap.values()) { creativeSearchTree.add(VerticalSlabUtils.getVerticalSlabItem(referredSlabState, VerticalSlabUtils.isTranslucent(referredSlabState))); } creativeSearchTree.refresh(); during the RecipesUpdateEvent.
  8. Okay, now it works without crashing and without major inconveniences. However I found two issues: Vertical slabs don't show up in the creative inventory, neither the dedicated tab nor the search tab. In the stonecutter menu the recipes are there but they are not visible, resulting in a shift of the visual recipes compared to the actual output recipe. They most probably originate from the same problem, that is when I compute the maps I use ForgeRegistries.ITEMS.tags().getTag(ItemTags.SLABS), but this returns null. This is because in ForgeRegistryTagManager I can see the field tags being a map with size 0, client side. I'm guessing it's because Minecraft registries, and the same Forge registries, are only server side. However I'm not sure what to do to get the Item list of slabs client side.
  9. So the server will have them after ServerAboutToStart event fired, after on the client the RecipesUpdated event will fire and there I can send a request to the server to get the values for my maps. Correct?
  10. Because I actually use them also to render. I had changed my code to make so that my vertical slabs refer the slab and not the block to fix some issues, however this caused some problems in rendering. So I needed the maps during rendering to go from slab to block whenever possible, and also I have a map holding all the translucent slabs.
  11. The volatile immutable slab maps used to go from block to slab and vice versa, the ones instantiated in the ServerAboutToStart event.
  12. Thanks, it works now! I found another problem unfortunately: when the version of the mod that's on the client tries to access the volatile immutable maps the game crashes. The issue is that those maps are never instantiated on the client. How do I fix this? Do I have to register a packet and every time I want to access those maps I must send and receive a packet? Or is there a smarter way? Also I'm wondering why on the Forge docs it's written to use a separate class when creating a simple channel object. Wouldn't it be okay if I did it in my JustVerticalSlabsLoader?
  13. Here the code of the handler class. It is not updated with the annotation, however all I did in local was to add the annotation as shown before and remove the line to register that class in my mod loader class. Before this change it would crash when server side only, but would color correctly in single player. After this change it's not coloring correctly in single player. I didn't check if it fixed the crash server side.
  14. I did this: @EventBusSubscriber(value = Dist.CLIENT, bus = Bus.MOD) public class ColorHandlerEventHandler And removed the manual subscribing in my mod loader class. However now in single player my grass vertical slabs are back to being greyscale.
  15. I'm trying to put my mod on a server and I get this error: -- Head -- Thread: main Stacktrace: at cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:138) ~[securejarhandler-1.0.3.jar:?] {} -- MOD justverticalslabs -- Details: Caused by 0: java.lang.reflect.InvocationTargetException at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?] {} at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?] {} at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?] {} at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?] {} at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?] {} at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:67) ~[javafmllanguage-1.18.2-40.1.20.jar%23126!/:?] {} at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:106) ~[fmlcore-1.18.2-40.1.20.jar%23125!/:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?] {} at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?] {} at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?] {} at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?] {} Caused by 1: java.lang.NoClassDefFoundError: net/minecraft/client/color/item/ItemColor at crystalspider.justverticalslabs.JustVerticalSlabsLoader.<init>(JustVerticalSlabsLoader.java:159) ~[justverticalslabs-1.18.2-3.0.0.0.jar%2390!/:1.18.2-3.0.0.0] {re:classloading} at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?] {} at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?] {} at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?] {} at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?] {} at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?] {} at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:67) ~[javafmllanguage-1.18.2-40.1.20.jar%23126!/:?] {} at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:106) ~[fmlcore-1.18.2-40.1.20.jar%23125!/:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?] {} at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?] {} at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?] {} at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?] {} Mod File: justverticalslabs-1.18.2-3.0.0.0.jar Failure message: Just Vertical Slabs (justverticalslabs) has failed to load correctly java.lang.reflect.InvocationTargetException: null Mod Version: 1.18.2-3.0.0.0 Mod Issue URL: https://github.com/Nyphet/just-vertical-slabs/issues Exception message: java.lang.ClassNotFoundException: net.minecraft.client.color.item.ItemColor Stacktrace: at cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:138) ~[securejarhandler-1.0.3.jar:?] {} at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?] {} at crystalspider.justverticalslabs.JustVerticalSlabsLoader.<init>(JustVerticalSlabsLoader.java:159) ~[justverticalslabs-1.18.2-3.0.0.0.jar%2390!/:1.18.2-3.0.0.0] {re:classloading} at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?] {} at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?] {} at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?] {} at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?] {} at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?] {} at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:67) ~[javafmllanguage-1.18.2-40.1.20.jar%23126!/:?] {} at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:106) ~[fmlcore-1.18.2-40.1.20.jar%23125!/:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?] {} at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?] {} at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?] {} at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?] {} at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] {re:computing_frames} at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?] {} How do I fix this? Should I put a @OnlyIn(Dist.CLIENT) in my color event handler class? Or add a check for the side in the methods that register BlockColors and ItemColors? Or something else entirely?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.