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


  • Posts

  • Joined

  • Last visited

Everything posted by X-Lomir

  1. In the end I was, by mistake, calling a method twice. I had already checked for the logical side, but the fact that the method was being called 2 times made me wonder. Thanks to your comment I realized my mistake, thanks!
  2. I know AttackEntityEvent fires 2 times, 1 for each hand. Is there a way to understand which hand the event is currently being fired for?
  3. Okay, adding the string you wrote works for me too, although I'm getting an error that says it can't find a mixin, but I guess this is another problem ahah Thanks!
  4. Yeah, that api properties file is where I store the api key for publishing on CurseForge and GitHub. I forgot to mention that either you have it or all the inherent part must be commented out (or create a mock file).
  5. I swear that is the log I got, I don't know why the error only appears in console and is not present in the debug log. Anyway, I will put below also the stacktrace I copied from the console: Exception in thread "main" java.lang.StringIndexOutOfBoundsException: begin 0, end -4, length 0 at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source) at java.base/java.lang.String.substring(Unknown Source) at cpw.mods.securejarhandler@1.0.3/cpw.mods.jarhandling.JarMetadata.fromFileName(JarMetadata.java:79) at cpw.mods.securejarhandler@1.0.3/cpw.mods.jarhandling.JarMetadata.from(JarMetadata.java:44) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.moddiscovery.AbstractModLocator.lambda$createMod$0(AbstractModLocator.java:36) at cpw.mods.securejarhandler@1.0.3/cpw.mods.jarhandling.impl.Jar.<init>(Jar.java:134) at cpw.mods.securejarhandler@1.0.3/cpw.mods.jarhandling.SecureJar.from(SecureJar.java:58) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.moddiscovery.AbstractModLocator.createMod(AbstractModLocator.java:34) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator.lambda$scanMods$6(MinecraftLocator.java:39) at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(Unknown Source) at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source) at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toList(Unknown Source) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator.scanMods(MinecraftLocator.java:41) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer.discoverMods(ModDiscoverer.java:50) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.FMLLoader.beginModScan(FMLLoader.java:166) at MC-BOOTSTRAP/fmlloader@1.18.2-40.1.0/net.minecraftforge.fml.loading.FMLServiceProvider.beginScanning(FMLServiceProvider.java:86) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.TransformationServiceDecorator.runScan(TransformationServiceDecorator.java:112) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.TransformationServicesHandler.lambda$runScanningTransformationServices$8(TransformationServicesHandler.java:100) at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source) at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(Unknown Source) at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source) at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toArray(Unknown Source) at java.base/java.util.stream.ReferencePipeline.toList(Unknown Source) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.TransformationServicesHandler.runScanningTransformationServices(TransformationServicesHandler.java:102) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.TransformationServicesHandler.initializeTransformationServices(TransformationServicesHandler.java:55) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.Launcher.run(Launcher.java:87) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.Launcher.main(Launcher.java:77) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26) at MC-BOOTSTRAP/cpw.mods.modlauncher@9.1.3/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23) at cpw.mods.bootstraplauncher@1.0.0/cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:149)
  6. If I try to run Minecraft client from the dev environment, after generating the runs with gradlew genVSCodeRuns, I keep getting the following error: Exception in thread "main" java.lang.StringIndexOutOfBoundsException: begin 0, end -4, length 0 However the mod runs without problems if I put the jar in a modpack. My repo can be found here, I'm linking the whole repo because I don't know precisely what can be helpful to know for this error. I will also put below the debug log. [22ago2022 13:05:39.824] [main/INFO] [cpw.mods.modlauncher.Launcher/MODLAUNCHER]: ModLauncher running: args [--launchTarget, forgeclientuserdev, --version, MOD_DEV, --assetIndex, 1.18, --assetsDir, C:\Users\ricca\.gradle\caches\forge_gradle\assets, --gameDir, ., --fml.forgeVersion, 40.1.0, --fml.mcVersion, 1.18.2, --fml.forgeGroup, net.minecraftforge, --fml.mcpVersion, 20220404.173914, --mixin.config, soulfired.mixins.json] [22ago2022 13:05:39.829] [main/INFO] [cpw.mods.modlauncher.Launcher/MODLAUNCHER]: ModLauncher 9.1.3+9.1.3+main.9b69c82a starting: java version 17.0.3 by Eclipse Adoptium [22ago2022 13:05:39.850] [main/DEBUG] [cpw.mods.modlauncher.LaunchServiceHandler/MODLAUNCHER]: Found launch services [fmlclientdev,forgeclient,minecraft,forgegametestserverdev,fmlserveruserdev,fmlclient,fmldatauserdev,forgeserverdev,forgeserveruserdev,forgeclientdev,forgeclientuserdev,forgeserver,forgedatadev,fmlserver,fmlclientuserdev,fmlserverdev,forgedatauserdev,testharness,forgegametestserveruserdev] [22ago2022 13:05:39.867] [main/DEBUG] [cpw.mods.modlauncher.NameMappingServiceHandler/MODLAUNCHER]: Found naming services : [srgtomcp] [22ago2022 13:05:39.877] [main/DEBUG] [cpw.mods.modlauncher.LaunchPluginHandler/MODLAUNCHER]: Found launch plugins: [mixin,eventbus,slf4jfixer,object_holder_definalize,runtime_enum_extender,capability_token_subclass,accesstransformer,runtimedistcleaner] [22ago2022 13:05:39.886] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Discovering transformation services [22ago2022 13:05:39.893] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Found additional transformation services from discovery services: java.util.stream.ReferencePipeline$3@591e58fa [22ago2022 13:05:39.906] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Found transformer services : [mixin,fml] [22ago2022 13:05:39.906] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Transformation services loading [22ago2022 13:05:39.907] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Loading service mixin [22ago2022 13:05:39.908] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Loaded service mixin [22ago2022 13:05:39.909] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Loading service fml [22ago2022 13:05:39.912] [main/DEBUG] [net.minecraftforge.fml.loading.LauncherVersion/CORE]: Found FMLLauncher version 1.0 [22ago2022 13:05:39.912] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: FML 1.0 loading [22ago2022 13:05:39.913] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: FML found ModLauncher version : 9.1.3+9.1.3+main.9b69c82a [22ago2022 13:05:39.914] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: FML found AccessTransformer version : 8.0.4+66+master.c09db6d7 [22ago2022 13:05:39.915] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: FML found EventBus version : 5.0.7+5.0.7+master.6d3407cc [22ago2022 13:05:39.915] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: Found Runtime Dist Cleaner [22ago2022 13:05:39.917] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: FML found CoreMod version : 5.0.2+5.0.2+master.303343f8 [22ago2022 13:05:39.918] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: Found ForgeSPI package implementation version 4.0.15-4.x+4.0.15-4.x+4.x.038e91c0 [22ago2022 13:05:39.919] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: Found ForgeSPI package specification 4 [22ago2022 13:05:39.921] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Loaded service fml [22ago2022 13:05:39.923] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Configuring option handling for services [22ago2022 13:05:39.929] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Transformation services initializing [22ago2022 13:05:39.930] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Initializing transformation service mixin [22ago2022 13:05:39.953] [main/DEBUG] [mixin/]: MixinService [ModLauncher] was successfully booted in cpw.mods.cl.ModuleClassLoader@7e07db1f [22ago2022 13:05:39.970] [main/INFO] [mixin/]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=union:/C:/Users/ricca/.gradle/caches/modules-2/files-2.1/org.spongepowered/mixin/0.8.5/9d1c0c3a304ae6697ecd477218fa61b850bf57fc/mixin-0.8.5.jar%2322!/ Service=ModLauncher Env=CLIENT [22ago2022 13:05:39.975] [main/DEBUG] [mixin/]: Initialising Mixin Platform Manager [22ago2022 13:05:39.976] [main/DEBUG] [mixin/]: Adding mixin platform agents for container ModLauncher Root Container(ModLauncher:4f56a0a2) [22ago2022 13:05:39.977] [main/DEBUG] [mixin/]: Instancing new MixinPlatformAgentMinecraftForge for ModLauncher Root Container(ModLauncher:4f56a0a2) [22ago2022 13:05:39.978] [main/DEBUG] [mixin/]: MixinPlatformAgentMinecraftForge rejected container ModLauncher Root Container(ModLauncher:4f56a0a2) [22ago2022 13:05:39.979] [main/DEBUG] [mixin/]: Instancing new MixinPlatformAgentDefault for ModLauncher Root Container(ModLauncher:4f56a0a2) [22ago2022 13:05:39.979] [main/DEBUG] [mixin/]: MixinPlatformAgentDefault accepted container ModLauncher Root Container(ModLauncher:4f56a0a2) [22ago2022 13:05:39.981] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Initialized transformation service mixin [22ago2022 13:05:39.981] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Initializing transformation service fml [22ago2022 13:05:39.982] [main/DEBUG] [net.minecraftforge.fml.loading.FMLServiceProvider/CORE]: Setting up basic FML game directories [22ago2022 13:05:39.983] [main/DEBUG] [net.minecraftforge.fml.loading.FileUtils/CORE]: Found existing GAMEDIR directory : C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run [22ago2022 13:05:39.984] [main/DEBUG] [net.minecraftforge.fml.loading.FMLPaths/CORE]: Path GAMEDIR is C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run [22ago2022 13:05:39.984] [main/DEBUG] [net.minecraftforge.fml.loading.FileUtils/CORE]: Found existing MODSDIR directory : C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\mods [22ago2022 13:05:39.984] [main/DEBUG] [net.minecraftforge.fml.loading.FMLPaths/CORE]: Path MODSDIR is C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\mods [22ago2022 13:05:39.985] [main/DEBUG] [net.minecraftforge.fml.loading.FileUtils/CORE]: Found existing CONFIGDIR directory : C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\config [22ago2022 13:05:39.985] [main/DEBUG] [net.minecraftforge.fml.loading.FMLPaths/CORE]: Path CONFIGDIR is C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\config [22ago2022 13:05:39.985] [main/DEBUG] [net.minecraftforge.fml.loading.FMLPaths/CORE]: Path FMLCONFIG is C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\config\fml.toml [22ago2022 13:05:39.985] [main/DEBUG] [net.minecraftforge.fml.loading.FMLServiceProvider/CORE]: Loading configuration [22ago2022 13:05:40.027] [main/DEBUG] [net.minecraftforge.fml.loading.FileUtils/CORE]: Found existing default config directory directory : C:\Users\ricca\Desktop\mods\1.18\.2\soul-fire-d\forge\run\defaultconfigs [22ago2022 13:05:40.028] [main/DEBUG] [net.minecraftforge.fml.loading.FMLServiceProvider/CORE]: Preparing ModFile [22ago2022 13:05:40.031] [main/DEBUG] [net.minecraftforge.fml.loading.FMLServiceProvider/CORE]: Preparing launch handler [22ago2022 13:05:40.032] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: Using forgeclientuserdev as launch service [22ago2022 13:05:40.052] [main/DEBUG] [net.minecraftforge.fml.loading.FMLLoader/CORE]: Received command line version data : VersionInfo[forgeVersion=40.1.0, mcVersion=1.18.2, mcpVersion=20220404.173914, forgeGroup=net.minecraftforge] [22ago2022 13:05:40.054] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Initialized transformation service fml [22ago2022 13:05:40.055] [main/DEBUG] [cpw.mods.modlauncher.NameMappingServiceHandler/MODLAUNCHER]: Current naming domain is 'mcp' [22ago2022 13:05:40.057] [main/DEBUG] [cpw.mods.modlauncher.NameMappingServiceHandler/MODLAUNCHER]: Identified name mapping providers {srg=srgtomcp:1234} [22ago2022 13:05:40.057] [main/DEBUG] [cpw.mods.modlauncher.TransformationServicesHandler/MODLAUNCHER]: Transformation services begin scanning [22ago2022 13:05:40.059] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Beginning scan trigger - transformation service mixin [22ago2022 13:05:40.059] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: End scan trigger - transformation service mixin [22ago2022 13:05:40.060] [main/DEBUG] [cpw.mods.modlauncher.TransformationServiceDecorator/MODLAUNCHER]: Beginning scan trigger - transformation service fml [22ago2022 13:05:40.060] [main/DEBUG] [net.minecraftforge.fml.loading.FMLServiceProvider/CORE]: Initiating mod scan [22ago2022 13:05:40.068] [main/DEBUG] [net.minecraftforge.fml.loading.moddiscovery.ModListHandler/CORE]: Found mod coordinates from lists: [] [22ago2022 13:05:40.070] [main/DEBUG] [net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer/CORE]: Found Mod Locators : (mods folder:null),(maven libs:null),(exploded directory:null),(minecraft:null),(userdev classpath:null) [22ago2022 13:05:40.076] [main/DEBUG] [net.minecraftforge.fml.loading.targets.CommonLaunchHandler/CORE]: Got mod coordinates from env [22ago2022 13:05:40.078] [main/DEBUG] [net.minecraftforge.fml.loading.targets.CommonLaunchHandler/CORE]: Found supplied mod coordinates [{defaultmodid=[]}]
  7. 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?
  8. 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.
  9. 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 ๐Ÿ˜„
  10. 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 ๐Ÿ˜…
  11. @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.
  12. 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.
  13. 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.
  14. 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".
  15. 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.
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. 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?
  21. 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.
  22. The volatile immutable slab maps used to go from block to slab and vice versa, the ones instantiated in the ServerAboutToStart event.
  23. 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?
  24. 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.
  25. 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.
  • Create New...

Important Information

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