• Recently Browsing

    No registered users viewing this page.

  • Posts

    • Post the debug.log and a screenshot.
    • So... How to fix? Install Java 14?
    • The initial part of your answer is what I was looking for, thank you so much for clearing it up for me.  
    • No you don't need a utility class, it's a matter of preference only.  You can create an object and register it on the event bus, or you can register a utility class instead (for its static methods), Forge supports both methods, eg both of these work: ServerLifeCycleEvents serverLifeCycleEvents = new ServerLifeCycleEvents(); MOD_EVENT_BUS.register(serverLifeCycleEvents); public class ServerLifecycleEvents { @SubscribeEvent public void onServerStartingEvent(FMLServerStartingEvent event) { } } ///------- or ------------ MOD_EVENT_BUS.register(ServerLifeCycleEvents.class); public class ServerLifecycleEvents {   @SubscribeEvent   public static void onServerStartingEvent(FMLServerStartingEvent event) { } //static here }   I personally prefer the utility class for setup code because I only ever need a singleton and they are so simple I never need to write a test harness for it, so creating an object just adds a bit of extra overhead.  I also like the imperative style of explicitly adding to registries.    Or do you mean- can you just add registration methods to the objects themselves?  (eg create a new Block and have it register itself?, or perhaps using a static initialiser inside the Block class)  In that case - the answer is "no" because the objects must be registered with vanilla at the correct time, which is not guaranteed unless you use the forge initialisation events.   Many folks like to eliminate utility classes as much as possible by using static initialiser assignment of a DeferredRegister, eg   * private static final DeferredRegister<Block> BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS, MODID); * * public static final RegistryObject<Block> ROCK_BLOCK = BLOCKS.register("rock", () -> new Block(Block.Properties.create(Material.ROCK))); * * public ExampleMod() { * BLOCKS.register(FMLJavaModLoadingContext.get().getModEventBus()); * } Again I think that's a matter of personal preference although some people do hold strong opinions about the right way to do it (TM).
    • You might find this tutorial project useful: https://github.com/TheGreyGhost/MinecraftByExample   In order to find the code for Nether portals, you need to know a bit about the objects and datastructures used by Minecraft; that's where the various tutorials around the web can be a big help. The source code itself is generally poorly documented (very few comments in vanilla code, and somewhat patchy comments for the Forge code) and often the names of methods can be misleading or even wrong, because the code has been decompiled and then manually deobfuscated by crowdsourcing.   So for example for NetherPortals, the relevant code is in NetherPortalBlock and PortalSize, but it will be difficult to understand what's going on.  You might be better off with BedBlock or DoorBlock but even those are likely to be hard work until you have a number of the key concepts around blocks and blockstates under your belt.   -TGG  
  • Topics

  • Who's Online (See full list)