shieldbug1

I don't know what line 44 is, but I'm guessing it's MinecraftForgeClient.registerItemRenderer(TF2Mod.RocketLauncher, new RenderRocketLauncher()); Try putting that code in your client proxy.

Also, you're using !world.isRemote == false. If you want it to happen on the client, use world.isRemote, if you want it to happen on a server use !world.isRemote. There's no reason to invert it, an then check for false (that's inverting it twice, and is simply redundant).

PlayerEvent.PlayerLoggedInEvent, PlayerEvent.PlayerLoggedOutEvent, FMLNetworkEvent.ClientConnectedToServerEvent, FMLNetworkEvent.ServerConnectionFromClientEvent, FMLNetworkEvent.ServerDisconnectionFromClientEvent, FMLNetworkEvent.ClientDisconnectionFromServerEvent, EntityJoinWorldEvent. Those are just some, use whichever you need. There's a nice list of events here.

Okay, I'll try explain block metadata as best as I can. Block metadata is exactly 4 bits. That is, from 0000 to 1111. Once you have four logs registered, since they all have 3 rotation values, then you'd have something like this: Two of the bits would be used to determine the log type (00, 01, 10, 11), and the other two for rotation (00, 01, 10). This leaves you with exactly one more possible combination (1111), and that can't store enough information about a log. Leaves use metadata for their type (again assuming 4, that's 2 bits). I believe they also use a bit for whether they were naturally placed or not, to know whether or not they SHOULD decay, and maybe another bit to flag that decay needs to happen. If someone registered more than 4 logs to a single block, then they are either using a tileentity, or ignoring rotation.

Yup, the way hugo_the_dwarf suggested is the 'right' way to do it if you're using your own custom item. If you needed to do this with a vanilla item, however, then you'd be using either the LivingUpdateEvent or the TickEvent.PlayerTick.

Could you show us some code?

Read the JavaDoc comments. You're probably gonna use 3 (flag 2 + flag 1). Also remember to use world.getBlockMetadata(x, y, z) in place of metadata, you can't use an instance variable as there is only 1 instance of a block ever.

I have not had much luck yet. I'm sure there's an easy solution but I can't find it, and I'm too tired to keep checking. I suggest you set up some break-points in places you think might have to do with how certain of the GUIs get the name and trace it to a point you can easily change.

I tested it, it seems that's true. I'm doing some testing now to try and find a way to do this, I'll tell you if I find anything. So far I've tried reflection on the Minecraft.getMinecraft player, and reflection on the GameProfile too. No results yet.

PlayerEvent.NameFormat seems like exactly what you're looking for but you seem against that in the previous thread from what I've read. I don't actually think reflection would help you at all here (not with displayname) because NameFormat gets fired every time getDisplayName or refreshDisplayName is called, I believe, which is exactly the same as changing displayname through reflection. This should affect scoreboards etc (though only on your client, other people on the server will see the normal username) If it doesn't, what you can try to do is to intercept every time a GUI that contains the name is opened (Player list when you press TAB, chat, scoreboard, etc.) and then replace it with your own GUIScreen that extends the type you're trying to intercept, with your own code in the places you need it, though this seems like a whole lot of extra work and could potentially break compatibility with any other mods trying to do the same thing.

Could you show us the code that isn't working?

The reason of why you can't have 5 logs is because block metadata is 0-15 (4 bits). Two bits are used for rotation, which leaves two bits for other metadata. 2 bits = 4 combinations.

Do you need to change metadata more than once after every click? While(true) is a terrible idea, as the game will freeze since it will stop 'ticking'. If you want to toggle it every time it's clicked then you can do something like world.setBlockMetadataWithNotify(x, y, z, metadata == 0 ? 1 : 0, FLAG) If you want to change independently every tick from the moment it was clicked, however, I suggest a TileEntity. If you want it to change independently every so often from the moment it was clicked you could probably get away with setTickRandomly and using the method that gets called then (onUpdate or onUpdateTick or something)

My bad, I skimmed over the crash log. When do you initialise and register oreGemEnd to the GameRegistry?

Ore dictionary has to go in your init method, not your pre-init. This is not a forge bug. I believe it's because registering blocks actually registers an ItemStack, which uses Item.getItemFromBlock which returns null during the Pre-Initialisation stage of Minecraft.

I think there's a getLocalizedName method for every block. But if there isn't I'm pretty sure you can use StatCollector#translateToLocal or something

That's because the sub-blocks aren't actually blocks, they're ItemStacks with metadata values. If you want an array of blocks that have sub blocks, that's fine. But if you want to actually store all the actual sub blocks themselves, you're going to need an ItemStack array/list.

Okay first of all What is that for loop? Just use a while statement. Anyway, what are you trying to ACTUALLY do? What do you need this array for? And what do you mean by it not working? If it crashed, what was the crash report?

What have you tried? Show us some code, please.

IExtendedEntityProperties to save the stat and LivingDeathEvent to change it should work.

I believe it's a bug with the current version. Rerunning gradlew setupDecompWorkspace seems to fix it.

Get an iterator, and just iterate through the registry. Basic Java Iterator. Nothing special. On a side note: What do you need the list for?

GameData#getBlockRegistry and GameData#getItemRegistry look promising.

You're welcome C:

You're welcome