V0idWa1k3r

World#getPersistentChunks returns all chunks that are kept loaded by forge's chunk loading system, not all currently loaded chunks. You could still keep a list of all loaded chunks by subscribing to the ChunkEvent.Load/Unload and keeping the chunk in question in a collection of some kind.

Define "localize". You can store it either in your capability or in a map, that doesn't matter. Since your capability is now stored per chunk you need to iterate over chunks in the world and get the capability instead of iterating over data in your world capability. Finish your code and provide any problems you might or might not have.

You are not resetting your FOUND_ITEMS map's state, thus the matches will never return true. IList#add inserts the entry into a given position in the list, shifting all entries with a higher or equal position to the right. This will crash the NonNullList created with the [int, T] constructor since the add operation in that case is not supported. You need to use set, not add.

Why? What stops you from having a ticksHappend variable per world, incrementing it and doing the same % operator on it as you would in a TE?

Don't you already have a set of all chunks currently in posession of your data? Your VoidEnergyHolder stores the data somehow, presumably in something like a Map<ChunkPos, IVoidStorage>? You can iterate all values of a map just fine. With my suggestion you don't even need to do that though. Why yes it would. Instead of manually listening to the save/load events you would have to do... absolutely nothing, as the capability, as long as it implements INBTSerializable/ICapabilitySerializable would do everything for you. All other code you have would remain unaffected(mostly, you would retreive the capability a bit differently but that's it).

Use the WorldTickEvent and do whatever it is you need to do there. If you are concerned about performance - don't be, there aren't that many chunks loaded in the world at any given time to be concerned. You can optimize this further by putting the data that needs updating in a Stack or something(when the value changes below default, since this is when you want to do the restoration), then iterate over that stack and process the value in the data and either add it back(after you are done iterating of course) if it still needs updating or doing nothing. Also I might be mistaken here but isn't a Chunk itself a ICapabilityProvider? As in couldn't you attach your capability directly to the chunk, rather than to the world?

You are reaching across logical sides here. More over this will only work on the physical client. You need to send the packet to the server when the button is pressed and cnahge the weather in a runnable that you will queue to be invoked in your packet handler.

Why do you need this "crafting fluid" in the first place? Why not just store the first/primary fluid and display it's texture? ...Change what the getter returns? All FluidStack calls route back to the Fluid that it is't, well, fluid. You have to do it regardless since IIcon no longer exists though.

Are you sure about that? I can't replicate the issue. In fact I have debugged the entities and can confirm that there only exists one entity instance per respective side after the swing.

Nope, didn't debug it to that extend but I suspect that is a client-side only glitch anyway.

You are not creating your throwable entitiy correctly. You need to tell it to be shot into a direction, and you are not telling it to do so. See how vanilla shoots it's projectiles at ItemSnowball for example. Literally every single one of your issues is fixed by adding the EntityProjectile#shoot call. Yes, I've debugged it If you want to play the "swing" animation return false in your override of Item#onEntitySwing. Edit: Oh, almost forgot. Instead of doing this Store the entity's starting position and check when the distance between the current position and the starting one is greater or equal to 100*100(don't do the check that calculates the sqrt for you that's not needed in this case). Of course you must make sure that your entity won't stop - so it needs to go through all blocks and have a constant velocity.

Iterate it. Or use streams.

ItemStack#shrink, ItemStack#setCount

Let me stop you right there. Don't create BasicX. There is already a BasicX, it's called X.(BasicBlock -> Block, etc.) This is an antipattern and should be avoided. Use an interface to define your contracts?

Also IModel is just a collection of info that is needed to build the IBakedModel. IModel and it's implementations contain no quads and thus can't be rendered. You need an IBakedModel instance.

What are you trying to accomplish exactly? Where do you want to render the fluid? In the item's model? In your GUI? In the world?

Don't ever implement IInventory. Use capabilities instead. Don't extend BlockContainer. It overrides a bunch of methods you do not need, like the rendering method. Just override Block#hasTileEntity and Block#createTileEntity. IIngredient by default doesn't care for the stack size since it is only used for vanilla crafting bench and that one only operates in stack sizes of one. You need to check the stack size yourself. Well, why wouldn't it? That's what you are telling it to do: private void finishRecipe() { ... resetInputStacks(); ... } private void resetInputStacks() { Arrays.fill(inputStacks, ItemStack.EMPTY); } You are telling your TE to fill all inputs with an empty stack when it is done. Unrelated Do you own mhfc.net? Because if you don't you can't name your package like that. And if you do - fix the security warning, I can't even access the site.

Define "machine stuff" ...Such as...? Not necessairly, programming is not all about learning, it's lso about inventing - taking the puzzle pieces that you have(aka your existing code knowledge) and putting them together to make something new.

I've tested it both on a SP world and on a dedicated server I've connected to.

Well, technically you didn't. You can't do something wrong if you don't do anything in the first place. https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/client/renderer/entity/RenderEntityTerraBladeProjectile.java#L36 Unless your repository is outdated your entity renderer does absolutely nothing apart from existing. You need to actually tell the game how to render your entity, it's not going to read your mind and magically work. You do have some code there, but it's commented out and thus isn't even compiled.

Yes. World.isRemote will be true for a client world and false for a server. You can read more about sides here.

If you don't want to do your checks for automated block placement players may or may not exploit en-masse you can check that the placer is not an instance of FakePlayer before running your code.

No. neighbourChanged happens when any additional block is changed regardless of whether it was changed by a player or something else, like a piston. You will pretty much have to use PlaceEvent as far as I am aware. What exactly is your code going to do? Checking a few blocks around the placed one and invoking a method within them if the condition is correct is a very fast operation. Performance should not be a concern here, and in any way write functional code first, optimize it later if needed.

Then this will never be false since ItemStacks in 1.12.2 can't be null. Use ItemStack#isEmpty The same way you check anything for the side it is performed on using World.isRemote

Don't just blindly cancel every sound, compare it first. You have the original sound at PlaySoundEvent#getSound, and it contains methods like ISound#getSoundLocation that you can easily use to check what the sound is.