Matryoshika

You need to extend FontRenderer and override FontRenderer::renderUnicodeChar. The actual font should be added to the game as a PNG file; The ResourceLocation of said file is used when instantiating your own FontRenderer. You should instantiate it as final inside your proxy, and call the FontRenderer from your proxy whenever you need to use it. To use this different font, you merely use the stored FontRenderer instead of calling Minecraft::fontRenderer like usual (or the FontRenderer given to you if that's the case), and draw the text with FontRenderer::drawString or any of the other drawing options. If you have any further questions, I would direct you to AbyssalCraft's GitHub, as they use the Aklo font to obfuscate some text.

EntityPlayer::func_192028_j aka EntityPlayer::playShoulderEntityAmbientSound is called every tick in the EntityPlayer's code. What this does is tell a shoulder-mounted parrot to play a sound. Not sure if Pixelmon even have parrots (or pixelmon that make use of the parrot's shoulder-sitting-ability)... The server-owner needs to either delete the player's data (easy solution), or edit said data with NBTExplorer etc; find the mounted parrot(s) under the shoulderEntityLeft & shoulderEntityRight tags respectively, and delete them.

cough Entity::isNonBoss cough Returns false if the entity is a boss.

Or you know, just call ItemStack::setStackDisplayName in Item::onCreated if it's your own item, or subscribe to the ItemCraftedEvent if you're dealing with other's items.

Blocks have always had ItemBlock variants, at the very least since 1.2... (~6 years & counting) However, previous to the 1.8 rendering update, the models for the ItemBlocks were made for you, from the blocks' models', if I remember correctly. And Blocks & Items are different. An ItemBlock is an Item that represents a block. They do not equal eachother in any way.

Galacticraft is trying to access code that only exists on the Client-Side, from the Server-Side. You should report this to the mod-author, so that he can fix his own code.

None of this is connected. During the FMLInitializationEvent, you call VolcanoStructure#load. FMLInitializationEvent has no connection to a world. It is part of the FML-life-cycle, before any world (there's by default 3, so you should make sure to check you're in the right one) has even started to be read into memory. VolcanoStructure#load does nothing, as well. It is an empty method. What did you expect to happen by calling it? There's nothing that calls VolcanoStructure::generateSurface, which actually creates the structure. Furthermore, this is not how one should create WorldGen structures. VolcanoStructure should implement IWorldGenerator, and then registered in FMLInitializationEvent with GameRegistry#registerWorldGenerator, which tells minecraft that when a chunk get's generated for the first time, it should run the code in every registered IWorldGenerator::generate methods. Oh, and don't use Block#getBlockById. Neither you nor anyone else knows what blocks those are without looking up the id's first. Just use Blocks#STONE or whatever.

There is no auto-magical way of getting a specific block in the world. Use BlockPos.getAllInBox using two opposite corners to get an Iterable<BlockPos> containing all BlockPos within that area. You then need to iterate through each element, and check if the block at that position is the block you want. Do keep in mind to limit the area you want to check, as scanning in 3-dimensional space gets exponentially larger the further out you scan.

You're not overriding Block::hasTileEntitywhich is required for Minecraft to run Block::createTileEntity. As stated in Problematic Code #4, you need to override both.

Please provide the crash-log. It has all the answers. Your eventhandler also looks awefully a lot like a TextComponentString class, not an actual class that deals with events... For now I'm going to guess that you're using the PlayerLoggedInEvent? You need to wait a tick before doing anything with the given player from that event; it isn't fully initialized, leading to several null-pointers.

Do any of your blocks contain TileEntities? Do any of your blocks do anything when placed? and as Jabelar stated, you should try to see where everything is bottle-necking by comparing the before & after time of your methods/loops' executions. Oh, and use bit-shifting instead of multiplying/dividing by 16. By habit you'll likely (in the future) divide by 16 to get chunk-coordinate from a block coordinate. This will be incorrect for negative values, due to how integers are rounded down (-15/16 = -0.9375). chunkX << 4 = blockX, blockX >> 4 = chunkX

You need to call ModelLoader#setCustomModelResourceLocation during the ModelRegistryEvent event, providing the ItemBlock, Meta (what Block::getMetaFromState would return for that state), ResourceLocation (Block::getRegistryName) & the variant; here being "inventory". This will tell Minecraft that a variant exists for this (item)block and that it is called "inventory", and should be gotten from the BlockState JSON's element of equal name.

Have a look at ItemMonsterPlacer::spawnCreature. That is the code that the spawn-eggs use to create & spawn an entity in the world.

You can either copy the functionality of a command's execute method, which would be the best, or you can manually call the commands execute method, providing the MinecraftServer, ICommandSender (All entities implement this) and the string-array for the command arguments. The latter option would require redundant object->string handling (for example teleporting requires x, y & z coordinates) and can only be done on the server. Use your ServerProxy (commonly misnomered as CommonProxy) to properly facilitate this.

You are constantly creating a new EntityItem every frame. These will stack up, and just cause excessive cleanup for the GarbageCollector (which cleans up used memory). Declare a final EntityItem outside the method and just reference whenever you want to render. You are completely missing a pushMatrix call. You need to revert the rotation & the translation after you have rendered the EntityItem An example of reverting the rotation would be as I did in my code I linked earlier GlStateManager.rotate(angle, 1, 1, 1); //Rotating everything renderBody(te, x, y, z, partialTicks, destroyStage); //render the thing GlStateManager.rotate(-angle, 1, 1, 1); //reverting the rotation with an equal but negative angle If you want to use the same logic as I do for calculating the angle, then instead of multiplying by 100 (what you changed) you should divide by a larger number than 40 (what I used).

well, can you post your current code/update your github? Can't help if I don't know what you have & what you have done.

You are rendering your item outside the pushed matrix. Move it to be rendered inside of it. TESR's are also singletons. There is only one TESR that does the work for rendering every single tile-entity that it is bound to. If there are several loaded at the same time, then you need to compensate the rotation, either by using a variable from the TE itself, or any other "outside" data, otherwise it'll speed up by +1x times for each tile. I would also recommend that you start to undo whatever you rendered after you are done. "Artifacts" are a type of behaviour when rendering isn't stopped once you think it has, and starts interfering with other's rendering. OpenGL artifacts are annoying and hard to track down. GLStateManager helps out a bit, but in the end artifacts shouldn't exist. An example of "undoing" would be to translate your TESR to where you want it, render the item, then translate again with negative values, to reset it. This goes for every action you do with OpenGL. I have a TESR that spins in all axii, as well as bobbing up and down here. You can take a look and see where your code differentiates. Do note, I'm calling other methods as well so a pure copy/paste will lead to unintended behaviour.

You cannot make any new objects on one side and expect the other to know what the hell is going on. Rendering is done on the client. Here, there's no renderer for, nor any idea what the hell an NEntityBat is. Further more, this will break Entities for other mods. Server & Client each have their own registry with entities. What you're doing, is de-syncing the entity registries between server & client. The entity-type at position X in the registry on the server should always equal the same entity-type at position X on the client. This will lead to issues for other mods registering their entities after you. TL;DR What you're doing is not possible, not without breaking Minecraft

Do not use ForgeRegistries for registration. It is only for iterating over. Forge freezes the BLOCK & ITEM registries during the life-cycle, meaning you cannot edit them after the life-cycle reaches that point. Use the Register<IForgeRegistryEntry> Events instead. It was made specifically to register these objects. Never use the unlocalized name for anything other than localizing it. It has nothing to do with what the item is. Use IForgeRegistryEntry::getRegistryName. It has already been formatted to modid:name for you, no need for manually concatenating the modid, nor using the whole substring mess.

I had a similar issue in one of my mods, trying to streamline snow/grass/sand/clay generation, with their location being determined by a noise-generator (hence I would have no control over chunk boundaries) What I ended up doing, is creating a placeholder block, that when randomly ticked (which should provide ample time for the chunks around it to get generated) would first check the environment, and then act accordingly, and here, the first one to tick would replace itself and several others within range to the mentioned blocks. What I'm trying to say here is, a single block placed during worldgen, and then "activated" afterwards, would perhaps be the best option to the "bigger than one chunk" issue. Once it is activated, it checks if it can actually do everything. If it cannot, well, then it can just replace itself with air. If it can do something, which here would be to build something, well, then time to pack up, cause it's settling in. (eg, start building) Perhaps have the block contain a TileEntity that can perform higher logic, like "place x blocks per tick" to make the strain even less.

They are not deprecated per sé, rather Mojang's devs stating "don't manually call these". They are just fine to override. This only applies to the @Deprecated methods in the Block class, AFAIK.

ItemStack::getCount

You will need to use Reflection to switch the final booleanChunkGeneratorSettings::useMineShafts found in ChunkGeneratorOverworld::settings, which also happens to be private, so you'll need to use Reflection again to gain access to that as well. You should do all of this during the ChunkGeneratorEvent. It is the only way to gain access to the IChunkGenerator in use by the world at the time. You need to be sure to only change the useMineShafts value once (per runtime at least) and not every time a chunk gets generated. (Foo::Bar means that Bar is a non-static field or method in Foo)