warjort

As the javadoc says, this event is only ever fired on the (logical) server. So the isClientSide() check is redundant, it's always false.

https://github.com/sp614x/optifine/issues/6974

The log messages show the objects were registered when you used the RegisterEvent. I think you need to post your debug.log and show what is actually referencing the feature. I think there is something else going on here.

That code is already in a supplier that doesn't get called until the ConfiguredFeatures are registered. Its not during classloading. I already talked above about how to do the block properly for modded blocks.

Change your Max Frame Rate to be something that is more than zero in the minecraft video settings.

BlockBehaviour.BlockStateBase.canBeReplaced()

Entity.pick() for the relevant player. See: https://github.com/MinecraftForge/MinecraftForge/blob/bb4818630c0c6cdd7c4178b4d77dc406153c2bcb/src/main/java/net/minecraftforge/client/gui/overlay/ForgeGui.java#L680

Good mod authors include the minimum required forge version information in their mod metadata. Then forge will give you an error if you try to use an earlier version.

Having something like this as an item, sounds like a security nightmare. The item can be easily transferred to other users.

You mean you want to bypass the player's permission level check of the command? Commands are always run server side unless you register them especially as client commands. You can find something similar to your requirements in BaseCommandBlock.performCommand() which runs commands with permission level 2 - see CommandBlockEntity's inner class createCommandStack()

Never knew that. The static final not working is probably more due to compiler "inlining" the value?

You said that before, but you didn't know of an example mod to point to that does it that way. There are many mods using the event, which does work. Anyway, here's an example that works using DeferredRegisters. public class ModFeatures { private static final DeferredRegister<ConfiguredFeature<?, ?>> CONFIGURED_FEATURES = DeferredRegister.create(Registry.CONFIGURED_FEATURE_REGISTRY, ExampleMod.MODID); private static final DeferredRegister<PlacedFeature> PLACED_FEATURES = DeferredRegister.create(Registry.PLACED_FEATURE_REGISTRY, ExampleMod.MODID); public static final RegistryObject<ConfiguredFeature<?, ?>> DIAMOND_BLOCKS_CONFIGURED = CONFIGURED_FEATURES.register("diamond_blocks", () -> { var block = ForgeRegistries.BLOCKS.getValue(new ResourceLocation("minecraft:diamond_block")); var target = List.of(OreConfiguration.target(OreFeatures.NATURAL_STONE, block.defaultBlockState())); return new ConfiguredFeature<>(Feature.ORE, new OreConfiguration(target, 64)); }); public static final RegistryObject<PlacedFeature> DIAMOND_BLOCKS_PLACED = PLACED_FEATURES.register("diamond_blocks", () -> new PlacedFeature(DIAMOND_BLOCKS_CONFIGURED.getHolder().get(), commonOrePlacement(10, HeightRangePlacement.triangle(VerticalAnchor.absolute(-24), VerticalAnchor.absolute(56))))); public static void register(IEventBus bus) { CONFIGURED_FEATURES.register(bus); PLACED_FEATURES.register(bus); } } The static register(IEventBus) method needs to be called with the MOD event bus. From what I can tell, the only difference from the event method is the objects are not registered with the BuiltinRegistries with the above? They are held elsewhere.

These are not errors. They are warnings that are kind of left there by programmers to remind them they need to tidy things up, but its low priority. Think of them as sticky notes on the refrigerator. 🙂 The first few are forge's internal mods. The latter ones are due to Mojang, you will find them in the vanilla game as well. Forge 40.1.0 is considered the stable version of forge for 1.18.2 by the developers. But you will find some mods that require later versions because they use new features not in the stable version, or they need later bug fixes to run properly.

adoptium is the java done by openjdk/eclipse openjdk are the people that actually write the base version java. Others like Microsoft, Oracle, IBM or Apple take the OpenJDK version and modify it for their operating systems. That site claims to contain an Oracle version from about 7 years ago. Even if its not infected with viruses, they are not supposed to redistribute that file without a license from Oracle to do so.

The download page says which version of forge they support. https://optifine.net/downloads If you don't like it, talk to them. 🙂

Now you are back to asking java questions. You need to research how Iterable and Stream are used for iteration in java. They are ubiquitous concepts. Or you can just use your ide to find the many uses in the vanilla code.

The method is the BlockPos.betweenClosed() I mentioned earlier. You give it the opposite corners. There are few variants for Iteratables and Streams and different ways of passing the parameters.

Those are forge's internal mods, you can ignore it. I don't know why it even prints those messages. 🙂

The -Xmx goes in the users_jvm_args.txt The nogui goes in the run.bat See the comments in those files. Which you use depends upon whether you want to configure java (the jvm) or minecraft.

You will probably need to delete the build/classes folder to force gradle to do recompile everything.

Something like the following in your build.gradle I haven't tested the above, so if it doesn't work, check the gradle and javac docs for the exact magic incantation. 🙂

Do you still have the old code? Maybe that is interfering with it somehow? I don't actually know what using DeferredRegister on those registry keys does.

-Xmx is a JVM argument, you are trying to pass it to minecraft which doesn't understand it

RenderSystem.enableBlend()?

Rubidium is a broken client side only mod You can remove it from the server, you don't need it there.