Matryoshika

You'll have to use a TileEntity for this. TileEntities exists inside of blocks and allow the block to do stuff. (Furnace, chest, Sign etc are TileEntities) (Blocks(and items) are Singletons, meaning there is only 1 of each, with each placed block/itemstack holding a representation of them. If you store any data, or change anything in one, the same thing will happen to every other block/item) Store the id/channel in each TileEntity. Preferably with a 0 or -1 id when placed initially, and this id won't allow the teleportation/switch. Don't allow a new id to be assigned if there already exists 2 or more TileEntities with that id. (You don't want 3 or 745 of these to switch with eachother) The radius has to be the same as well, otherwise you'll get a small sphere floating in a crater on one side, and the opposite on the other, which will overwrite blocks, destroying them. Scan the surrounding areas twice; Once to store the blockstates, and a second time to store any other TileEntities in the area. Do this for both TileEntities. Once everything is done, have the tiles send the arrays/lists of blockstates & tileentities, have your tiles set the blockstates & tiles that they got, in the same way you scanned them (so a furnace placed to the north of your first tile gets placed to the north of your second tile) One more thing: Please find a different tutorial. Mr.Crayfish's tutorials are quite outdated when it comes to registration & rendering of blocks/items. A large majority of the "why isn't [Thing] rendering!?" threads here stem from people using his tutorials. (Don't call Minecraft::register, use ModelLoader. Register models and content in ModelRegistryEvent and RegistryEvent respectively etc)

You got an issue of brief Client-Server mis-match Server: Didn't allow the thing. -Your code did this Client: Allowed the thing. -Running as usual Server: No you didn't. -Client updates with data from Server Solution: Remove the World#isRemote check

Create a custom WorldProvider. Override createChunkGenerator to return a custom ChunkProvider that does not spawn any blocks. In init, un-register and re-register the overworld (dim 0) , using DimensionManager. I do this in Underworld, but it's an optional config that was requested. Search for "forceUnderworld". I also recommend that you either extend or copy ChunkProviderOverworld, as that way you will still get proper biomes from scratch.

If you've already opened BlockRegistry, please refresh it. Fixed ItemBlock registration (which you can ignore when registering Items)

You are still referencing a Client-Only class (ItemRender(as it does things Client-side, it can never be called in "common" code, which can be called on both server & client)) and will thus face more issues. Here, here's my take on a proper tutorial on how to register & render blocks (You can mirror everything, and switch out Block for Item). Sit down, take your time, read it through, and try to understand the steps. It makes use of 2 things not discussed here, mainly the RegistryEvent & ModelRegistryEvent. I believe it would be better for you to use these, and let Forge handle calling your Render-class Client-Side only, for you. If something renders black & purple, either link us the fml-client-latest.log inside the projectname/run/logs folder, or pastebin the error reported in the console. "Exception loading model for variant...."

You can freely edit scale, rotation, and translate the X, Y & Z coordinates of Items & Blocks in the model JSON's I have an example here, with an item extending that JSON here.

I believe the method is called once per side, per hand. Server, right-hand.... Client, left-hand. Add a check with the EnumHand parameter you get.

Method declared in a class annotated with a SideOnly.CLIENT cannot be referenced in an annotated method OOoooooh You have SideOnly on the CLASS already, and are trying to put it on a method in the class as well.

public boolean shouldSideBeRendered(IBlockState state, IBlockAccess blockAccess, BlockPos pos, EnumFacing side) { if (blockAccess.getBlockState(pos).getBlock() == this) return false; return super.shouldSideBeRendered(state, blockAccess, pos, side); } ... If this == this, don't render?

The tutorial is faulty to begin with. Even if you put @SideOnly on the method, importing anything from minecraft's client package (in "common" code) will crash a dedicated server. You would be better off splitting the registering of content & rendering them. In a "registry" class, put all your Items in an ArrayList<Item> (and mirror that for blocks), then for-each-loop through the list, registering each one. In a separate class altogether, "render", you register the renders (with ModelLoader) for each entry in the same list that you get from the registry class

Not to mention, Items are Singletons. There exists only 1 of each item. Any data stored in the Item class, will be global for each ItemStack containing said Item. The way you intend to work using this SelfStack will thus not work. You are given the correct ItemStack in almost all possible method parameters (here, it's par1ItemStack¹), either directly, or if need ever be, through the EntityPlayer. ¹Please edit your parameter names as well. par1, par2...par27 looks horrible and are easily mistaken for each other by the human eye.

You need to create a custom WorldProvider, and override calculateCelestialAngle. Then you need to register said WorldProvider to the wanted dimension(s), by calling DimensionManager#unregisterDimension(id) and then re-registering it with DimensionManager#registerDimension(id, DimensionType#register(...)) Though I would iterate over the worlds, and check their WorldProvider's first, and only change if the WorldProvider is an instanceof the overworld's WorldProvider, as some dimensions have "frozen" time, etc.

To make it a bit more clear: The method debugScanWithSheet gets a Sheet object from dataGatherer::getSheet. It then creates an ArrayList<String> using the keys from the mentioned sheet. It then iterates through each element in the arraylist with a ForEach loop, where each new value is called "index". If the scanDebug begins with "detect_", it assigns a new variable val to sheet.get(index). If val is not 0 nor Integer.MAX_VALUE, and index is not 0, it draws the string. As such, you need to investigate how the Sheet object looks like. What is the key->value structure? (string->what?) What does the String represent? The entity-id? It would seem the most likely. For future reference, please post your code to pastebin.com or similar webpages. GitHub would be the most optimal.

His tutorials are quite outdated by now. A large part of the item/block registrations & rendering issues on this forum stem from outdated practices shown in his tutorials. (For example, nowadays, use the RegistryEvents instead of preInit for item/block registration, register models in preInit, not init, don't useMinecraft::register for models, use ModelLoader etc)

Technically, Minecraft does not stand for that. It simply renders what it was given. The PNG format makes use of something called "Transparent colour". Most image-editing software that exports into PNG will have a "Transparent Colour" option when exporting. Would you mind if I asked what software you used? I haven't seen a non-white default TC outside Krita, so far.

Thank you. How I missed that simple way of doing it is beyond me =_= Well, that's what you get for coding at 6 in the morning.

So, I had an idea that I wanted to try out. I want one of my blocks, to "crack" when an anvil lands on it. When an anvil lands, (onEndFalling) it calls world#playEvent with a null EntityPlayer, event-type 1031 & the blockPos. As such, I made an IWorldEventListener, but here comes the issue. I know that the event is only fired for that world, but without a World variable to use, I cannot see a way to actually use this data to affect the world around it. How would I go about this? Is there a better way around this?

Can you manually render the outline? I usually use GL11.GL_LINE_STRIP for rending things like this.

You need to manually attach the Capability to the intended object, as well as register the Capability. To attach a Capability to an Entity (like a player) you need to use an @Mod.EventBusSubscriber annotated eventhandler for the AttachCapabilitiesEvent<Entity> event. To register the Capability, call CapabilityManager::register with the Interface class, an IStorage object for the Capability, and lastly a Factory for said Capability (Most just call a new instance of the Capability with lambda). It would be easiest for everyone if you posted your code, and state what you have tried already.

It does exist Client side, but it is never saved there. If the player logs out, or the server restarts, the client's data will reset. If you want to reliably do things Client-Side, you will need to send packets from Server->Client with the data.

You are spawning the entity only on the client.

You say you want to change all the stone below a certain Y-level to your own block. If we are speaking more than 3-5 layers thick, the you will notice lag-spikes wherever you go, as using world#getBlockState and/or world#setBlockState is not optimized for large-scale operations. If you look at the ChunkProvider/IChunkGenerators, they deal with worldgen in a more optimized way, though in a completely different context. Depending on the amount of blocks you want to change, you might want to rethink how you are going to do it. you may want to place down a new block that on random ticks, replaces all stone (and itself) within the chunk below your wanted level to this dense stone. As such, you would only need to have your worldgen place 1 block in each chunk, and due to the random ticking, there will rarely be 2 chunks or more having their blocks changed at the same time.

The relevant events here, are client-side, and hopefully called/registered in the ClientProxy. As such, Minecraft::thePlayer & event#player would reference the exact same object.

Capabilities only store the data Server side. You need to sync the data to the Client with packets.

A WeakReference points to an object that can be collected by the GC. Storing the player object directly, even after the player logs out, keeps it in memory, when it is no longer required. As such, overuse of this practice can and will lead to "memory leaks".