Draco18s

There are some helper methods in the Level class that already do this for you. I don't know what the mojang names are, but canLightningStrikeHere and getGroundHeight are the mcp names

You mean like the autosmelting functionality? https://github.com/MinecraftForge/MinecraftForge/blob/1.18.x/src/test/java/net/minecraftforge/debug/gameplay/loot/GlobalLootModifiersTest.java#L145

Override getVoxelShape, or whatever the Mojang name is. Take a look at literally any vanilla block that has bounds less than a full cube.

Do this (top down): G┬┐ └┴M where G is the generator and the M is the machine and the four others are cables. Will your code crash, infinite loop, or transmit power?

That's no different than the CPU it takes to update a non-entity block. My point is that tickable entities (even ones that do nothing in their tick method) take up CPU cycles every game tick, while non-ticking ones do not.

I bolded a section in the quote of your previous post. Your CopperCableBlockEntity doesn't have a constructor that matches the parameters being passed. Compare: https://github.com/hawon10617/SpaceSim/blob/master/src/main/java/net/hawon/spacesim/common/block/entity/ExampleChestBlockEntity.java#L15 https://github.com/hawon10617/SpaceSim/blob/master/src/main/java/net/hawon/spacesim/common/block/entity/GeneratorBlockEntity.java#L46 With: https://github.com/hawon10617/SpaceSim/blob/master/src/main/java/net/hawon/spacesim/common/block/entity/CopperCableBlockEntity.java#L12 I'm a bit less familiar with 1.17 and newer and how the various lambda stuff is defined, but I can compare the other block entities you have that do work with the one that doesn't: Your other two subclass and only have 2 parameters in their constructor, and generate the third for super.

How do you plan on determining whether or not the bolded statement is true? (by the way, the way IC2 works is that generators "push" power into cables and cables push that power into all connected adjacent blocks that accept power).

If your TE isn't Tickable, then it's not going to take any CPU.

99.99% chance that this is being used incorrectly. Show the whole class where this line is.

You need to set the block's render type in your client setup.

Ok, so, this is really quite simple. The client is a lying, cheating, bastard. Do nothing on the client that the server needs to know about. Only send user input actions (not results) to the server. The server controls all. Block states are automatically communicated to the client when they change (unless the update flag says not to). As for why there are two entities: The same reason you have two java processes. One on the server (the server controls all) and one on the client (for how else would it be rendered?).

You can't do this. You want the blockstate of a block in the world, use the world given to you in the event. You want the player? Use the player given to you in the event. This code will crash dedicated servers. Yeah, because the server says "the fuck you doing client, that position is a pumpkin."

Show your code.

I meant that you don't want your code leap frogging from "tree" to "tree" when they're close enough together. Brich forest is probably fine, but the dark oak forest might be worth a test to make sure it doesn't take out the whole forest (ignoring item durability if you abort when it breaks).

There isn't one, just create a tick event handler and count ticks yourself.

He says before finding a birch forest. https://gist.github.com/prydin/cc48a3ddd645bcd6f73d63bac6aa75b7#file-featuredetector-java-L94-L97 You should be able to do an instance-of check against the LeafBlock class. Also note that other mods may not use "xxx_leaves" for their leaves, but might do "yyyleaves" or "zzzleafblock" As for the property: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/EventHandlers.java#L39

The best description of a "tree" is "a wood block above a dirt block with more wood blocks on top with leaves nearby." With the leaves being in at least one of the 17 other positions around the top-most log in the stack (also those positions might have more logs, and if you find one, keep checking in the adjacent new 25 for more logs in order to detect big trees). Knowing "these leaves are part of a tree" doesn't help identify if the player "chopped down the whole tree."

But that doesn't solve the issue of where the "tree" is.

Nope, its just a bunch of log and leaf blocks. This is the best I was ever able to do (warning, very very old code): https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/util/TreeCountGenerator.java#L55

You should absolutely call ForgeHooks.canHarvestBlock(state, entityPlayer, world, pos) before attempting to do anything to a block. If the return is false, skip that block. As for the proper way to dig it out, dig around in the vanilla blocks class and look for where ForgeHooks.modifyLoot is called. Once you find that spot you might have to go up the call stack a little bit before you find the exact thing to call, and if might be several things. Been a while since I looked at it.

Do you know what OneDrive is? It's a cloud storage service. Do not put your Minecraft server there, as the files will be changing frequently and if conflicts occur, the minecraft server executable will probably just corrupt everything.

What is MegaMinerEvents? What is MegaMiner for that matter?

"Required" in the sense that it's the correct way to do things to maintain mod compatibility. But loot tables are still loot tables and can still be overridden with data packs. Forge won't stop you from doing it.

What. Yes you can. GLM run after all vanilla logic. ...no, the two things are unrelated. ILootConditions are things that need to be true for loot things to happen. They're conditions, not loot tables or modifiers. And no, you must use a loot modifier to modify loot. In theory you could create a fortune-like enchantment and its own ILootCondition and then overwrite every single loot table from every single mod to add your special condition block, but that seems like a lot more work to me. And a lot less compatible. It doesn't. Also, what if someone else does the same thing you're doing, but different? Use GLM.

Because it's stable. 1.17 was a very short lived version, 1.16 was around longer and is a middle point between the previous LTS (1.14) and the current.