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

X-Lomir

Members
  • Posts

    86
  • Joined

  • Last visited

Everything posted by X-Lomir

  1. Is there any way to change how runs are generated? My use case is the following: I have setup a task in my build.gradle to change some otherwise invalid values in my mods.toml. However, since the bin folder is constructed without running the build.gradle file, the mods.toml used to run and test the mod has all the invalid values instead of the correct ones. I would like to change how runs are generated, at least for VSCode, so that each run configuration has this extra property: "preLaunchTask": "prelaunch", And also a tasks.json gets generated with the following content: { "version": "2.0.0", "tasks": [{ "label": "prelaunch", "command": "./gradlew processResources", "type": "shell" }] } Is there any way to accomplish this? Is it possible to make it work also on other editors (IntelliJ and Eclipse) other than VSCode?
  2. Okay, I actually finally managed to solve it and, as usual, it was a very trivial mistake: I had useShapeForLightOcclusion returning true regardless of whether the vertical slab was supposed to emit light. Adding a check for the light emission level solved my issue.
  3. Update: I discovered that it's not just a bug of double vertical slabs, it affects also normal vertical slabs. The actual bug is the following: "external" faces (faces that align with the edge of the block) do not emit light, only "internal" (faces within the block) do. Here a couple of images to better understand the situation: https://imgur.com/a/ryaevWb (I used the hardcoding trick explained before here, that's why a oak slab is emitting light). So at first I noticed the bug only with double vertical slabs as they are naturally without "internal" faces that can emit light, but upon further inspection this is what the bug actually was. Honestly I still have no idea on how to fix this, but maybe this new info can help in getting some help 😄
  4. If it's needed to test it out, you can just hardcode the LEVEL values in both methods to 15, removing the 0 in the constructor and removing the calls to getReferredProperty. Btw getReferredProperty I'm sure works fine because it works with normal vertical slabs and it keeps the correct light level for double vertical slabs, and anyway the bug is still there even when hardcoding 15. I really have no clue on why this happens, it's the last bug I have to fix before I can release a new stable version and I've been trying to solve this for days and I made no progress 😅
  5. @diesieben07I have a new bug that I can't understand why it's happening. For a bit of context, I added the feature of double vertical slabs, similar to double slabs. However the bug happens when a vertical slab that emits lights becomes double: at that point it stops emitting light. Normal vertical slab just placed: https://imgur.com/a/QCXa16B Double vertical slab just placed: https://imgur.com/i43sHvt And as you can see in both cases the level property stays to 15, however when it's double light is not emitted, not even after updating the chunk. The relevant code is the following: public BlockState getStateForPlacement(BlockPlaceContext placeContext) { BlockPos pos = placeContext.getClickedPos(); Level level = placeContext.getLevel(); BlockState referredSlabState = VerticalSlabUtils.getReferredSlabState(placeContext.getItemInHand()); // if item in hand and block clicked on have the same referredSlabStates, then they are both the same kind of vertical slabs if (referredSlabState == VerticalSlabUtils.getReferredSlabState(level, pos)) { BlockState blockstate = this.defaultBlockState().setValue(WATERLOGGED, false).setValue(DOUBLE, true); if (referredSlabState != null) { BlockState referredBlockState = VerticalSlabUtils.getReferredBlockState(referredSlabState); BlockState referredState = referredBlockState != null ? referredBlockState : referredSlabState; blockstate = blockstate .setValue(LEVEL, getReferredProperty(referredState::getLightEmission, referredState::getLightEmission, level, pos)) // Set the level property exactly as below .setValue(OCCLUSION, referredState.useShapeForLightOcclusion()); } return blockstate; } else { BlockState blockstate = this.defaultBlockState().setValue(FACING, placeContext.getHorizontalDirection()).setValue(WATERLOGGED, level.getFluidState(pos).getType() == Fluids.WATER); if (referredSlabState != null) { BlockState referredBlockState = VerticalSlabUtils.getReferredBlockState(referredSlabState); blockstate = blockstate .setValue(LEVEL, getReferredProperty(referredSlabState::getLightEmission, referredSlabState::getLightEmission, level, pos)) // Setting the level property like this works for normal vertical slabs .setValue(OCCLUSION, (referredBlockState != null ? referredBlockState : referredSlabState).useShapeForLightOcclusion()); } return blockstate.setValue(SHAPE, getStairsShape(blockstate, level, pos)).setValue(DOUBLE, false); } } public VerticalSlabBlock(Material material) { super( BlockBehaviour.Properties.of(material) .isValidSpawn((state, getter, pos, entityType) -> false) .isRedstoneConductor((state, getter, pos) -> false) .isSuffocating((state, getter, pos) -> false) .lightLevel(LightBlock.LIGHT_EMISSION) .dynamicShape() ); this.registerDefaultState( this.defaultBlockState() .setValue(FACING, Direction.NORTH) .setValue(SHAPE, StairsShape.STRAIGHT) .setValue(WATERLOGGED, false) .setValue(LEVEL, 0) .setValue(OCCLUSION, false) .setValue(DOUBLE, false) ); } If there's any other part of the code that's needed let me know, anyway as always here you can find the whole repo.
  6. 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.
  7. 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.
  8. 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".
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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?
  15. 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.
  16. The volatile immutable slab maps used to go from block to slab and vice versa, the ones instantiated in the ServerAboutToStart event.
  17. 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?
  18. 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.
  19. 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.
  20. 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?
  21. I'm wondering... Couldn't I put a property into my BlockState that will hold the referredBlockState? Basically in VerticalSlabBlock#getStateForPlacement I could read the NBT tag from the itemstack and save it in my BlockState, the same way I do for light. This way I could get rid of BEs altogether and make better use of BlockState chaching system. Also it would allow my blocks to be pushed by pistons and to mimic properties I currently cannot mimic because their getter only takes a BlockState as input. The only problem I can see would be how to handle VerticalSlabBakedModel#getQuads because of that thing with the breaking progress animation.
  22. I managed to solve the issue. The fix was actually quite simple, and I'm also not exactly sure why it works, but it does and I'm satisfied with it 🤣 I think it works because the BLOCK VertexFormat has, in order, a position element, a color element and the 2 UVs elements. A position elements uses 3 vertex elements (x, y and z), a color element takes 1 vertex element, U and V elements take 1 vertex element each. So the index for U is 3 + 1 + vertexIndex, where vertexIndex is the index of the current vertex, which increases every iteration by the size each vertex takes in the vertices array. Similarly, the index for V is 3 + 1 + vertexIndex + 1, accounting for the previous U vertex element. However I'm not sure this is the correct explanation, but I'll leave here my intuition and the fixed method to update vertices: private int[] updateVertices(int[] vertices, int[] referredVertices, TextureAtlasSprite oldSprite, TextureAtlasSprite newSprite, boolean faceUp) { int[] updatedVertices = vertices.clone(); for (int vertexIndex = 0; vertexIndex < DefaultVertexFormat.BLOCK.getVertexSize(); vertexIndex += DefaultVertexFormat.BLOCK.getIntegerSize()) { float y = Float.intBitsToFloat(referredVertices[vertexIndex + 1]); // Lower only top face since RenderType CutoutMipped will remove extra transparent texture bits that go out of the shape. if (faceUp && y > 0 && y < 0.5) { updatedVertices[vertexIndex + 1] = Float.floatToRawIntBits(y + 0.5F); } updatedVertices[vertexIndex + 4] = changeUVertexSprite(oldSprite, newSprite, updatedVertices[vertexIndex + 4]); updatedVertices[vertexIndex + 5] = changeVVertexSprite(oldSprite, newSprite, updatedVertices[vertexIndex + 5]); } return updatedVertices; }
  23. It was pointed out to me a bug my mod has when using shaders other than Minecraft defaults, for example with Optifine internal shaders and BSL Shaders. The bug consists in all textures, apart from the oak planks, for my vertical slabs to be completely messed up. I guess this has to do with how I'm forcefully writing in the vertexes of my model. Is there a way to test and debug my mod with Optifine and, optionally, an external shader pack? Do you have any suggestions or insights about what may be causing the problem and how to fix it? I'm also trying to ask for some help on Minecraft Shaders Discord, I'll update here if I find a solution.
  24. I added a class for transparent vertical slabs. Everything works fine so far except one thing that is transparent vertical slabs still cull their faces and the faces of their neighboring blocks. Is there some method or property I can override in my new class or do I necessarily have to duplicate my JSON models and remove the cullfaces? EDIT: I found getOcclusionShape and it looks like it's working.
×
×
  • Create New...

Important Information

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