Leviathan143

What I'd recommend doing then, is looking at the WorldProviders for the dimensions. Look for things that are in both the Nether & End providers , but aren't in the Overworld provider. It may help narrow down the cause.

All ItemStack s returned by Block#getSubBlocks are added to the creative tab(s) of the block. The sole purpose of Block#getSubBlocks is to allow variants of a block to be added to the creative inventory.

No, see his reply to Draco. Lamba wants part of/the whole model to be fullbright. Fullbright means that lighting will always be maximum. Not that when I say "lighting", I am NOT referring to MC's light level mechanic, but rather to the client-side lighting of models.

Are the assets located at E:\MC modding\Geothermal Energy\src\main\resources\assets\azatedGeothermalMod ?

We're making armor specifically for each block, like dirt armor or obsidian armor. Unless you are making a metric ton of armours, it's better to do the textures manually. I think I know where to start if you need to create textures dynamically, however it is rather complicated. Additionally dynamically created textures won't necessarily look good, as not all textures tile well.

We're creating armor that uses the textures of blocks, so I don't think there's any other way to do it without mapping blocks to their textures at runtime. Are you making dirt armour, obsidian armour, etc? Or are you making armour that's a bit like TiCon tools?

What specifically do you need them for? We can give much better help if we know what you're trying to do.

Either watch the github repo, or hang around in #minecraftforge on EsperNet. The recent issues and pull requests on the repo give you an idea of what's being fixed, what's being changed, and what's being added. I assume the IRC channel is where the development of Forge is discussed.

What are you actually trying to do? If you are trying to make your entity pass through other entities, that is NOT the correct way to do it. doBlockCollisions() calls Block#onEntityCollidedWithBlock() on any block the entity is colliding with, it has nothing to do with entity-entity collisions.

All right, and if im not mistaken i do all these render methods in the TileEntity correct? The GL which you will need to render anything is done in a TESR(TileEntitySpecialRenderer), not the TE itself.

On the AITasks note, targetTasks would be a good one to check. The AI Tasks in there deal with finding attack targets. If an entity has something in there its definitely hostile.

That's not quite correct, or at least not clear enough. Since EntityPlayer extends EntityLivingBase, any instance of EntityPlayer is an instance of EntityLivingBase. The reverse is not true, not all instances of EntityLivingBase are an instance of EntityPlayer. This is why you cannot cast an EntityLivingBase to EntityPlayer, unless you first check that the EntityLivingBase is an instance of EntityPlayer.

Do you plan for all variants of this block to have the same texture on all sides? You should also note that Blocks can only store 16 states in metadata(4 bits). That's 4 boolean properties max.

You still haven't fixed any of the issues we mentioned(e.g the issues Matryoshika mentioned).

Pretty sure he's referring to this. You know the bug that occurs when a block exists on the server but not on the client? If you walk into the block you get stuck. He believes that is a block in its own right, rather than a bug.

That is not instantiation, that is field creation. Instantiation looks like this: new ResourceLocation("minecraft:steak") Oracle has a very good set of tutorials on the java basics. I've linked them below: https://docs.oracle.com/javase/tutorial/java/concepts/ https://docs.oracle.com/javase/tutorial/java/nutsandbolts/ https://docs.oracle.com/javase/tutorial/java/javaOO/

As Animefan said, that is achieved by using the OreDictionary. Documentation on the OreDictionary can be found here.

Reflectively get the value of LootTableManager#GSON_INSTANCE and call Gson#toJson() with it, passing in the LootTable that you want serialised.

I think the best option is to actually place the Blocks and their TEs in a World. This way the TEs should have everything they could expect to have. The easiest way to do this is to create an inaccessible void world dimension that all filtering hoppers place their phantom blocks in. For performance and resource reasons, each filtering hopper should load and unload the chunk it uses in the dimension as it is loaded and unloaded. You could probably get away with a World that only has a single Chunk if you wanted to, a single Chunk could serve 10,000+ filtering hoppers in the manner I have described.

I have an idea, but first I'd like to check that I understand what you're trying to do. You have a block with an inventory. If blocks that have TEs are inserted into that inventory, their TEs are instantiated. If any other item/block is inserted, the inventories of the contained TEs are tested to see if they will accept the item/block, and it is inserted into one of the inventories that will take it. In 1.9+ there are problems with this approach. Some TEs behave differently depending on the attached blockstate. To get their blockstate they need the World it is in. Since your block never actually places them they have a null World, causing a crash when the TEs try to check their blockstates, as most authors don't expect a null World. Is the above correct?

In 1.10.2 TE's also need to override TileEntity#getUpdateTag() . There is also a corresponding TileEntity#handleUpdateTag() method, which you will need to override if you want to do anything other than calling TileEntity#readFromNBT (This is what the default implementation does). I don't know for sure that this is your problem, but trying doesn't hurt. These methods are certainly involved in client-server communications though.

As you've been told 3 times, MC uses RGB as its color system. The color values range from 0.0 to 1.0, yellow would be 1.0, 1.0, 0. There is no fourth colour parameter. Your "yellow" is invisible because you are spawning it somewhere on the plane z=0, out of render distance.

Make it 0.001 units smaller than a full block, it only needs to be smaller than a full block for entities to collide with it.

I do do that, but I mean lets say I have recipes that use Items.leather, Items.iron_ingot, etc. and have almost all the items in the game somewhere in my code. I refactor each one (Items.leather to Items.LEATHER) and so forth but it is still quite a bit of work -- select it, call up refactor window, type in the new one, ignore the warning about refactoring when there are errors (when updating you have a lot of errors that can impact easy refactoring), then repeat another 50 times. It literally can take hours. Or do you mean there is some easy way to change all the Items fields to refactor at once? I fixed that issue using Notepad++'s Find in All files feature & regex. Open Notepad++ and press Ctrl+Shift+F to open the Find in All Files dialog. Set it to regular expression mode and set the directory to your mod's src folder. Use the regexes in this gist and click Replace in Files. I recommend making a backup of your source before you run the regex in case it hits an edge case and does something odd. The worst thing it can do is capitalise a single word that comes after a target.

.nbt structure files are made ingame with the structure block.