Draco18s

The main server thread? Hell no. You sleep the main server thread, then water stops flowing, redstone stops updating, mobs stop moving, and players get disconnected due to a timeout. Thread.Sleep() is almost never the solution to "I need to wait for something." Never never never never.

"Freeze entire game while we wait for this block to update." Yes, that's exactly what we want.

Two of those files are 0 bytes, nice. Anyway: Your BlockList file is only 25 lines long.

$100 says you didn't bother telling the server that you wanted to change the item's name when you did things on the client side gui.

It already is one.

...as such, don't store the BlockState for stripping, store the stripped property and do state.with(stripped).

I swear I've done ref things in my modding work before. Eh. Oh well.

Touche. You can simulate it with the ref keyword, or by returning a Tuple.

Learn about the out keyword. Yes. I still don't think you really need this method/interface, but not a huge deal. foreach(Block block : MyBlocks) { BlockItem bi = new BlockItem(block) event.register(bi); } If you want a custom block item, you'll have to treat it special anyway.

Just FYI: This: https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L46 This: https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L65 And this: https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L82 All do the same thing: register this class's annotated or otherwise indicated methods with a given event bus (of which there are two: line 46 and 65 are registering things with the mod bus, 82 is registering with the Forge bus; on top of that line 71 stores one of those busses (the mod bus) to a local variable despite having already said "fuck local variables" earlier on line 65 and again on 72). Not to mention that half of the registered event methods do fucking nothing, like these: https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L106-L111 https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L125-L143 Additionally, client code will crash the dedicated server: https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/ExampleMod.java#L113-L123

Once per world when the world is loaded. The block can't store data about the decay process, because blocks are singletons. Your options are either (a) a tile entity or (b) world capability data (that knows about the positions and times). Use world.getCapability to get your capability and store/retrieve/update the data as needed. Your capability will still be a map of postions -> times. The World class is already a capability provider, you don't need to create your own unless you want to have a capability attached to an option that is not already a capability provider. Worlds, chunks, entities (including tile entities and players), and itemstacks are all capability providers. Pretty much. I don't think you need your DecayHandler class, as your capability class is your DecayHandler. It just needs to store a map of postion->time. Depending on how you want to track that time (every tick? only when the block gets an update tick?) might alter the implementation details a little, but in general it's just a list of positions and the decay value. Or possibly just a list of block positions if no actual time data is relevant (the block would just query the capability to see if it should decay or not, and if so, remove its position from the capability). I mean the scheduled tick system. world.scheduleBlockUpdate or something like that. You give it a position and a number of ticks to wait, and your block will have its updateTick method called at that time.

What DemonUmbra said, but thought I'd point out this: "Yes, create a stack that knows about metadata, then discard the metadata, I'm sure it'll be fine!" ItemStack#areStacksEqual

https://github.com/TheGreyGhost/MinecraftByExample/tree/1-16-3-final 1.16.3 isn't going to vary that widly from 1.16.5 beyond the deobf process (1.16.3 iirc still uses MCP names while 1.16.5 uses the official Mojang names). https://github.com/Cadiboo/Example-Mod 1.15 is also pretty similar.

Don't do that either, return super.getCapability() the real problem here is not that it can or can't be null, but that get().orElse(null) is just bad. If it really should never be null, then get().orElseThrow(new Exception("capability was unexpectedly missing!")) If it may be null, use get().ifPresent(cap -> { do stuff });

False: https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/altar/PAAltarBlock.java#L216 https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/altar/PAAltarBlock.java#L218 https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/altar/PAAltarBlock.java#L160 Unrelated, this is just bad code design. https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/PACraftContainerBlock.java#L52-L57 https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/PABlock.java 1) that default getRenderLayer is terrible because it's objectively wrong. That should never return null. 2) you shouldn't be using the Registry events any more and this loop through thing is dumb. instead of calling myBlock.register(event) you could just do event.register(myBlock) and not need these methods at all. Ditto your items. 3) block items should be aware of their blocks. Blocks should not be aware of their block items. Items are registered after blocks for a reason. The fuck is this used for and why. https://github.com/IceMetalPunk/psychic-altars/blob/949a1d0757e9e0cb306da9079c6bcd24816c2bf4/src/main/java/com/icemetalpunk/psychicaltars/blocks/OmenBlock.java#L12

How are you registering your EventHandler class with the event bus?

You're trying to load a client side only mod on the server. Also, contact the mod's author, not us.

This is still a registry event. You should also make your items use a deferred register. By the way, what is this, why is it here, and why does it have a .json? https://github.com/MacDax/McraftForge/blob/master/src/main/java/com/mcexamples/examplemod/BlockSimple.java#L22

It's called once per game-logic-tick, which under ideal and normal circumstances, is 20 times a second. If game logic is for some reason running slow (eg. lag), then it will be slower (but so will everything else). If it's faster for some reason (undefined example) then it'll be faster, but so will everything else. And of course, these values (e.g. "20 times a second" or "every 50 ms") are all approximate averages. It'll never be precisely the declared rate, but as far as you and your code should be concerned, it is.

Do not create a custom main menu.

Yeah, it's a super last resort sort of deal. I've done it once and I hated that I had to, but my use-case was so niche that doing something like making a PR to Forge was just going to get rejected (as an example, I wanted to change how long a moon phase was) and there was no other way to affect it, as it was a hardcoded value.

Thank you for that code, so that I could understand why you were returning values the way you were. The correct way to do this would be to return a boolean. for(DecayHandler decayHandler: decayHandlers){ if(decayHandler.OnTick()){ decayHandlersToBeRemoved.add(decayHandler); } } But as I said, this whole custom data structure is unnecessary. ...The heck? You don't need this entire block. Much less two loops and a temporary variable! decayHandlers.removeAll(decayHandlersToBeRemoved); Yes, but also no. Yes, in the sense that you do need to have a way to serialize your data, but in 99% of cases you should simply be providing a method to serialize and let the game decide when to call it, via the Capabilities system. The structure you have here is a world capability, assuming the existing systems didn't do what you needed them to sufficiently. Speaking of: You know there's more than one world, right? Even in single player you have the ClientWorld, the Overworld, the Nether, and the End. Hashtag I wonder how redstone repeaters work.

And how do you call this class and its method? Your thread title says iteration, but I do not see a loop. Why aren't you using the scheduled block tick system? What happens if the random isn't 0 and your tick function returns? No shit sherlock. The game doesn't magically know how to save your miscellaneous runtime class to the save file.

Translation matrix stuff is annoyingly complex to figure out what's not working correctly. All I know is that the symptom you mention is a result of always rendering at 0,0,0 relative to the camera, as opposed to relative to a block in the world, the way the DrawHighlightEvent.HighlightBlock event works.

TLDR your block highlight outline does not have to match your model exactly. Also, if I'm not mistaken, that voxelshape extends outside the 1x1x1 block volume.