warjort

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.

I don't spot what you are doing wrong from the code you posted. Are you certain it is using the new code? Try adding something like the following your common setup: private void commonSetup(final FMLCommonSetupEvent event) { ResourceLocation id = new ResourceLocation(MODID, "creeper_ore"); LOGGER.info("CF:" + BuiltinRegistries.CONFIGURED_FEATURE.get(id)); LOGGER.info("PF:" + BuiltinRegistries.PLACED_FEATURE.get(id)); } This will confirm they are registered in the builtin registries. I did a bit more testing on my example code to see if I had made a stupid error, but it seems to be correct. I added a biome modifier to actually use it and I get diamond blocks in my overworld: { "type": "forge:add_features", "biomes": "#minecraft:is_overworld", "features": "examplemod:diamond_blocks", "step": "underground_ores" }

Not related to your problem (and not really wrong) but you should be using your BlockInit.CREEPER_ORE.get() to get your block. I only used the ForgeRegistries because I used a vanilla block that I didn't register.

You are missing the calio and apoli mods. The fact that forge is also in the list probably means at least one of your mods needs a later version of forge than 40.1.0, or it could mean you are trying to use a mod that is not for 1.18

Make sure you have the latest versions of those mods. If you do, you need to talk to authors of those mods.

Sorry, I shouldn't answer questions first thing in the morning. :-) I just answered it as a generic DeferredRegistry question, but this is a ConfiguredFeature. Registration for this works in a different way. They don't have normal registries instead you have to use some utility methods to put them in the "BuiltinRegistries". I've been pointing people at some Botania code for 1.18 as an example, but the RegistryEvent has been changed to be RegisterEvent in 1.19 and it works in a slightly different way. Here's some code I knocked up to show the equivalent to what Botania does but in 1.19 This following code is not really tested so double check the details. I just checked the objects are available in the MinecraftServer.registryAccess() registries - which is what your problem is. @Mod.EventBusSubscriber(modid = ExampleMod.MODID, bus = Mod.EventBusSubscriber.Bus.MOD) public class ModRegistration { @SubscribeEvent public static void register(RegisterEvent event) { event.register(Registry.FEATURE_REGISTRY, helper -> { // normally this would be one of your blocks var block = ForgeRegistries.BLOCKS.getValue(new ResourceLocation("minecraft:diamond_block")); // registration code starts here var target = List.of(OreConfiguration.target(OreFeatures.NATURAL_STONE, block.defaultBlockState())); var configuredFeature = FeatureUtils.register(ExampleMod.MODID + ":diamond_blocks", Feature.ORE, new OreConfiguration(target, 64)); PlacementUtils.register(ExampleMod.MODID + ":diamond_blocks", configuredFeature, commonOrePlacement(10, HeightRangePlacement.triangle(VerticalAnchor.absolute(-24), VerticalAnchor.absolute(56)))); }); } } This puts the registration in the same place Features would be registered. The example above does not actually register a Feature, it uses the vanilla OreConfiguration feature. The above code registers a ConfiguredFeature and PlacementFeature in the BuiltinRegistries which will be copied into the world gen registries (overridable and usable by datapacks). NOTE: The "commonOrePlacement" method is from PlacementUtils and needs an Access Transformer to use it, or you could make your own utility method.

The only thing I can find for this broken mixin are these: https://github.com/search?q=MixinAbstractBlockStateBookShelf&type=code One is called "test-byg-repo" the other "plume". The plume mod looks like a 1.16 mod from the names of the classes? You should contact the authors.

I don't know how he can be more specific without writing your mod for you. 🙂 Anyway, you can't use reflection because the field is final. Instead you would need to use an access transformer to make the isRandomlyTicking field in the BlockBehaviour class non-final and public: https://forge.gemwire.uk/wiki/Access_Transformers Mod lifecycle events like FMLCommonSetupEvent are explained in the docs here: https://docs.minecraftforge.net/en/latest/concepts/lifecycle/ or you can see an example in the mdk. Something like (untested code): event.enqueueWork(() -> { Block vineBlock = ForgeRegistries.BLOCKS.getValue(new ResourceLocation("minecraft:vine")); vineBlock.isRandomlyTicking = false; });

Look at what the vanilla SayCommand class does, or whatever command you want to emulate.