sciwhiz12

The second error is, if I am correct, from running the Forge dev client/server on Java 9+. It can be safely ignored.

It seems that you moved the files, but you haven't refreshed your launch files for your IDE. Remove the old launch files, then run: For Eclipse: gradlew genEclipseRuns For IDEA: gradlew genIntellijRuns For VS Code: gradlew genVSCodeRuns

What version of Forge and what IDE are you using?

What do you need maps in config files for?

Why are you using #getHitVec? Check if mop instanceof BlockRayTraceResult, and mop.getType() == Type.Block. Then, cast mop to BlockRayTraceResult, and call #getPos. if (mop instanceof BlockRayTraceResult && mop.getType() == Type.BLOCK) { BlockRayTraceResult bmop = (BlockRayTraceResult) bmop; BlockPos pos = bmop.getPos(); I'm fairly certain that if mop.getType() == Type.BLOCK, then mop is definitely BlockRayTraceResult, but better check instanceof to be sure that mop is not null. I'm not sure, but I believe #getHitVec returns the vector in which the ray from the player's mouseover intersects the block's collision box. However, due to the fact that we have a [-0, -0] XYZ coordinate which does not have a corresponding block coordinate, ([-0, -0] in XYZ = [-1, -1] in blocks), converting the hit vector to BlockPos will result in a loss of 1 unit coordinate in the north and west directions.

Before asking questions, please do some searching of your own: most things can be found in the sources or in guides/tutorials. See World#getChunkAt(BlockPos) to get the chunk for a specific position. World#getChunk(int, int) takes the two int values as coordinates for a chunk, not x and y positions for a block ([0,0] is the chunk encompassing [0,y,0] to [15,y,15]).

Disclaimer: I haven't used any energy system in my mods yet. private int ratePerTick = 20; // adjust if needed private int powerRemaining = 2500; // will be changed by other code public void tick() { if (powerRemaining > ratePerTick) { addPower(ratePerTick); powerRemaining -= ratePerTick; } else { if (powerRemaining > 0) { addPower(powerRemaining); } powerRemaining = 0; } }

Looking at the code for World#playBroadcastSound leads to WorldRenderer#broadcastSound, which calculates coordinates based on the given position and the player's PoV pos (I think?), which eventually just calls ClientWorld#playSound. Based on this, I recommend that in your packet, change from ISound to SoundEvent (+ pitch & volume), and copy the coordinates code from WorldRenderer#broadcastSound, and calling ClientWorld#playSound(double, double, double, SoundEvent, SoundCategory, float, float, boolean).

You are referencing the ISound class in your packet, which is only accessible from the physical client side. Looking and guessing from your posted code (please post your complete mod code to GitHub when requesting help), I assume you reference the class from SPlaySoundPacket. Don't use client- or sever-only classes in common code (such as networking). Consider using SoundEvent. Why do you need a packet for playing sounds? Can't you use World#playSound(PlayerEntity, BlockPos, SoundEvent, SoundCategory, float, float)? If you really need to reference client- or server-only classes for any reason, reference them only in FMLClientSetupEvent or FMLDedicatedServerSetupEvent, and in a seperate class.

Currently, there's no big complete authoritative source of documentation on many aspects of Forge modding; most modders go by reading tutorials and guides for simple to mid-level concepts, and either reading source code or asking for help on chats or forums like these for more difficult or niche concepts (minutiae of rendering, MC internals, custom dimensions/worlds). Most big guides and tutorials are outdated; major updates to Minecraft means changes to its internals. For example, 1.8 started the process of moving from metadata to BlockStates, 1.13 had the Flattening and added datapacks, and 1.15 changed the rendering system. Some guides and tutorials which I found and read are: the official Minecraft Forge documentation McJty's youtube tutorials (McJty is the modder for RFTools) TheGreyGhost's MinecraftByExample github TheGreyGhost's blog with explanations to key concepts these Minecraft Forge forums (search Modder Support or User Submitted Tutorials using Google) Choonster's TestMod3 (check the 1.14.4 branch) Now, to answer your titular question: Blockstate JSONs using the multiparts tag allow a quick and easy way to implement pipe- or fence-like models. Non-animated models can use JSONs, or OBJ files. For anying more complex or animated, use TileEntityRenderers (but if possible, always use normal models).The 1.15 update changing the rendering system simplifies it from learning OpenGL from scratch to mostly never needing it. See Block#getShape and related methods for how collision boxes work (look at vanilla code or above tutorials). If you can't understand it yet, try looking at code from other mods and seeing how they do block rendering. Fork/clone a copy, and start reading and messing around with the code using the debug tool in your IDE. If you have any questions, please either reply or make a new thread detailing your issues or your questions.

Change it to: this.setDefaultState(this.getDefaultState().with(BORDER, false).with(SHADING, false)); (edit the default values as needed)

Woops. Forgot about @ObjectHolder. Won't happen again. To @CaptainDoge, Your class is registering to the wrong bus; use Bus.MOD. RegistryEvents are fired on the mod-specific event bus. Change your event handling method to static. Move the code constructing the Block into the event registerAll, and make a public static final field annotated with @ObjectHolder. Never put your block constructor in an instance field on your event handling class with @EventBusSubscriber. Since you're using @EventBusSubscriber, you'll never get the instance containing your registered block, and any further created instances will make additional, unregistered, and useless instances of your block. Corrected code:

Your mods.toml file has an invalid updateJSONURL (line 29) and displayURL (line 32). Do not put "-" as the value if you intend not to have those URLs, just remove the line altogether.

Put your registerConfig call in your mod constructor. Mod event order: Mod construction (move yourregisterConfig here) RegistryEvent.Register<T> Config loading Common setup (your registerConfig was in here) Sided setup ... See ModLoader.loadMods, line 152 for source.

event.getRegistry().registerAll( new LeafReplacementBlock(Block.Properties.create(Material.LEAVES)).setRegistryName("minecraft:oak_leaves") ); You need to call setRegistryName with the registry name of the block you want to replace. I suggest assigning the new LeafReplacementBlock(...) to a public static field in your class, and then caliing registerAll.

Because you haveRegistryObject there, then you're using DeferredRegister. Please check if the second parameter to the DeferredRegister constructor is correct. If you intend to replace "minecraft:oak_leaves", the modid to be passed to that constructor should be "minecraft". If you're replacing vanilla blocks and registering your own custom blocks, I suggest either: making two DeferredRegister objects and naming them seperately (preferrably in seperate classes); or registering your vanilla replacements in RegistryEvent.Register (see the docs or a tutorial), and your own blocks in DeferredRegister.

Forge 1.12 is no longer supported on this forum. Please update to a modern, supported version (1.14.x).

You're very welcome!

You're welcome! And another thing which I noticed; You are registering your listener for PlayerInteractEvent.LeftClickEmpty in your BaseItem class. This is a problem: if you create multiple instances of BaseItem, you are registering your listener multiple times, which means that your code will send multiple packets for the same event. To fix this, I recommend moving that code out of your BaseItem class, and into another class -- either a dedicated EventListener class, or even just inside your Arknights mod class: This fixes the problem, and gives a cleaner way to add more event listeners in the future.

From what I understand, classes in Java are only loaded by the JVM on the first called reference to that class. Referencing FMLClientSetupEvent is safe, because that class exists in the net.minecraftforge.fml.event.lifecycle package, which is common to both client and server distributions. Futhermore, calling event.getMinecraftSupplier() is safe, even though it calls net.minecraft.client.Minecraft (of which the whole package only exists in the physical client), because if that line is called and run by the JVM, it is because FMLClientSetupEvent was called, which is only called on the physical client. And referencing Minecraft is safe, because the Minecraft class will only be loaded if and only when something about that Minecraft class is queried (such as Minecraft.getInstance()). And, as said above, the only time the Minecraft class is called in the mod class is when FMLClientSetupEvent is called, which is only done on the physical client. Same principles apply to DedicatedServer: as long as your physical client code never reaches any statement referring to anything in net.minecraft.server.dedicated, your code should be safe. FYI: Checking FMLEnvironment.dist or using DistExecutor are two other ways to check what physical side you are running and to run code on a specific physical side, respectively. Source: https://stackoverflow.com/questions/16330355/when-are-imported-classes-loaded-in-java https://stackoverflow.com/questions/7560721/when-does-the-jvm-load-classes

A comment, if I may: The problem in your code is that you construct your SimpleChannel at the wrong time. NetworkRegistry::newSimpleChannel should be called from your FMLCommonSetupEvent function, but instead you call it when the class Arknights is constructed -- a long time before FMLCommonSetupEvent will be called. To fix this, here are the adjustments: And the explanations: