TheMasterGabriel

If you are making a client-side only mod, register your commands with ClientCommandHandler instead of the typical way. All those commands are client-side and are sent from EntityPlayerSP.

From a brief glance, I don't see an alternative to GameData. However, it's discouraged to use internal methods as, well, they're supposed to be internal. As for Q2, it depends on what you want to do with it.

If you mean "executed by the player", you can just check if the ICommandSender is an instanceof EntityPlayerMP using CommandEvent#getSender. If you actually mean client-side, check if it was sent by EntityPlayerSP. However, basically every single vanilla command is sent from the server (hence the EntityPlayerMP). The only exception is when chat messages are sent from a GUI.

You can listen for CommandEvent, which gets called whenever a command is about to be executed. There is no event atm that gets called after a command is executed, at least I don't think. If there is, I couldn't find it.

To my knowledge, you will have to do it yourself. BlockPos has a method (BlockPos#getAllInBox) to retrieve all the BlockPos within a rectangular prism, but not a sphere. In general, I would pull all the blocks with a cube with the player at the center and using your radius as half the side length. You can then filter out the unwanted blocks with a simple distance check (BlockPos#distanceSq). If you want to only get blocks with a certain properties, it might be a good call to use Google's Iterators#filter with the iterator returned from BlockPos and a custom predicate, which would filter for the distance as well as the block properties you want.

1.7.10 isn't supported by Forge anymore, not to mention this is the wrong section.

1.7.10 isn't supported by Forge anymore.

I'm not sure what you mean. If the new block at that position is fire, and the old block was your custom log, then by vanilla logic your log was burned by fire. Of course, this doesn't account for if modded items replace things with fire (like an axe that replaces a block with fire instead of air). It also doesn't take into account if your log is just destroyed completely, which happens from time to time. (Fires don't necessary have to set other blocks to fire, they can just destroy them.) But as I said, it's not foolproof. A better alternative might be to use Forge's substitution system to replace the vanilla fire block with a custom one. It should be the same in every respect other than the BlockFire#tryCatchFire, which you would need to add your custom block case to.

A crash log would be helpful.

Couldn't you just register a custom IWorldEventListener in the World.Load event and do your logic in IWorldEventListener#notifyBlockUpdate? The method itself passes 2 block state parameters: the current block state and what the previous block state was. You can check if the old block was your custom block and the new block is fire, which would emulate your block "being consumed by fire". The only instance where this fails is if the block is set to fire by a command, but you could probably get around that by tracking the console/chat log (although that's a bit hacky, not 100% fool proof and not really clean). It's not perfect but probably as close as you can get without an official hook. Edit: Also probably a good idea to only register the listener on the server world.

Although thinking about it some more, I don't really need to project 4D to 3D. I just need a 4D vector that hashes to a long value between the min/max values of BlockPos#toLong. Any idea what those min/max values are? I assume they would just be (new BlockPos(-2999984, 0, -2999984)).toLong() and (new BlockPos(2999984, 255, 2999984)).toLong() . I'm not sure though. The bit math is beyond me.

Hmm, that's a really interesting idea. And it would certainly reduce the possibility of a collision. Although I might run into the problem with the hash extending beyond the MC world size. I'll give it a go, and see if I can come up with something along the way.

Oh fake worlds! What fun! Alright, I'm going to have to completely redo my system. All for the best though.

Yea I thought that using a capability would solve this problem, but then I ran into the server-sided null world object problem, not to mention the fact that I didn't think the order in which code would run (my block requiring its TE to load and set my block's copied property, which it would use to know what TE? What ever could be the problem with that.) So this goes back to @Draco18s idea of a dummy dimension. So all my overridden methods that delegate to my copied block need to use that dummy dimension's world instance instead of the current one. Also, my ExtendedBlockState would not read from my own TE. Rather, it would check what block is at its current position in the dummy dimension and return that IBlockState? That seems to make sense to me. Side note, is it safe to use DimensionManager.getWorld(id) on both logical sides? I'm asking because some of my delegated methods are server-specific while others are client-specific (like Block#randomDisplayTick). Completely unrelated: Why is the quoting system so unbelievably annoying. What is with the random numbers appearing, not to mention the huge blank spaces like above.

Hmm. I did not know this. So, for example, I cannot cast the IBlockState parameter in Block#isOpaqueCube to an IExtendedBlockState? Again, my block needs to be able to replicate any block that it wants to, including blocks with their own TEs. If my copied block clones a furnace, for instance, it needs to provide TileEntityFurnace. Likewise for more complicated TEs, like chests. Without doing so, tons of things would fail. For instance, if my block were mimicking a chest, it would delegate the onBlockActivated method to BlockChest. However, Chests require that the TileEntity at their current position be an instanceof TileEntityChest for them to do anything. Using my own TE would cause this to fail (Unless there is some hacky way to trick Java's instanceof check by allowing my TE to dynamically extend any TE instance, which doesn't make sense let alone exist).

Oh, I see the problem with what I'm doing. I cannot use Block#getExtendedState to set my block's unlisted property because it gets called after Block#createTileEntity, which uses my block's unlisted property to decide what TileEntity should be created.

Yes I figured that, which is why I am using an unlisted property. The trouble is getting the unlisted property to persist across loads. I can serialize it in my TE's NBT tag, but I cannot set it back again when my TE deserializes. When a TE is loaded server-side, its internal world instance has not been set yet, thus I can't use World#setBlockState. TE's positions are set, their world objects are not. The exception is when a TE is loaded client-side, because for some reason their world objects are set before their NBT loads (even though the code executed is exactly the same?). Under normal circumstances, this wouldn't pose a problem, as I could just set the world in TileEntity#setWorldCreate, which is called before the NBT stuff (this is what signs do). However, as I want my copying block to act just like their counterparts, I do not have that liberty. My block, when it is mimicking a block with a TE, returns that associated TE in Block#createTileEntity (which is necessary, as other TEs depend on instanceof among other things). To get around this, I thought of using a capability, which I would attach to TE on creation. Using a capability allows me to save the copied block data in any TE instance, rather than just my own. But again, I run into the null world problem during deserialization. The only solution I can think of at the moment would be to use that weird client-side thing to my advantage. Since TEs on the client do have world access during NBT load, I could set the blockstate on the client and then send the update to the server via a packet. However, I prefer not to do that as the server generally should handle all that stuff. (and it seems a bit hacky)

1.7.10 is no longer supported by Forge.

Well for starters they provide a way to serialize IBlockState's to NBT data. Minecart's use it to save their displayed blocks. It's also used quite a bit in ParticleManager, as the state ids are used in figuring out the sound to play and the texture to show when spawning the "break block" particles, among other things. There are other ways too, which you can use your IDE to check out.

I suppose. I guess testing will be the judge. Do you have any pointers on how to achieve this? I'm not aware of any baked model that has access to a World and BlockPos instance in getQuads so I can fetch the information from my TE. My original idea was to store the copied block state in an unlisted property, which I would set when my TE deserialized from NBT, and then read that property from within my model to use in getQuads. However, it appears that TEs' World objects get set after they read from NBT, so I cannot set said property. (Although for whatever reason, TEs on the client side have access to their World objects during NBT reading).

If you mean "Can I edit code while running the game", it depends on your IDE (but most of them have this feature). Eclipse has a little green beetle button next to the play button that runs the game in debug mode. While in debug mode, any non-breaking edits will be instantly noticeable in-game. If you make a breaking edit, Eclipse will tell you that you need to relaunch the game before the edit has an effect. I'm not sure about Intellij though.

No. 1.7.10 is no longer supported.

Yes, but because I'm trying to make a block that is an identical copy of what its mimicking (in terms of looks, functionality, and interaction), all those methods are important. Block#tickRate was just an example, there are other methods like Block#isCollidable and Block#getTickRandomly which are called by external things (or could be called by other mods). Because it needs act just like its copied counterpart, I need to take into account everything, even things not currently used in vanilla (as other mods may use them).

Unfortunately, I found another problem. Some block methods, like Block#tickRate, don't provide any useful arguments whatsoever (World and BlockPos, or IBlockState). That means I cannot get the copied block state from my block's iunlistedproperty in order to call Block#tickRate on it. The only way to do this would be to have direct access to the IBlockState via a local field, as BlockStairs does. I may end up having to go with the "new block instance for every single valid iblockstate" method after all.

I suppose that's true. Alright, I'll give it a go. It may not be a pretty solution, but it's a solution nonetheless.