V0idWa1k3r

All sprites(blocks & items) are stored in one texture which is TextureMap.LOCATION_BLOCKS_TEXTURE. TextureAtlasSprite contains the UV coordinates for that sprite on this texture.

You could. Or you could use BufferBuilder directly. These are static: Gui#drawScaledCustomSizeModalRect Gui#drawModalRectWithCustomSizedTexture

The same way vanilla uses them in it's GUI

It's ITickable#update now. You will need to implement ITickable on your TileEntity.

You can override Block#getPlayerRelativeBlockHardness(IBlockState state, EntityPlayer player, World worldIn, BlockPos pos), check if the item in player's main hand is shears and return a lower value.

Use Block#createTileEntity(World world, IBlockState state). This method has a IBlockState as a parameter and you can return null if you do not want a TE to be created.

If you are using a TESR then TileEntity#getRenderBoundingBox allows you to specify a custom AxisAlignedBB to do frustrum checks and TileEntity#getMaxRenderDistanceSquared allows you to control the distance at which your tile will no longer be rendered.

Item#onItemUseFirst is called on both the client and the server. You lack a !world.isRemote check.

If you use Item#onItemUseFirst instead of Item#onItemUse returning EnumActionResult.SUCCESS will prevent Block#onBlockActivated from firing thus preventing any GUI/Container showing up. Alternatively you may set the result of PlayerInteractEvent.RightClickBlock to DENY

Icons have been replaced by the new model system. If you needed the icon for something else rather than defining the texture for the block(ex. rendering the icon in a TESR) you can use BlockModelShapes#getTexture Block#getBlockLayer Is still getRenderType. It now defines the way blocks are rendered(models/invisible/liquids) instead of being ids for block renderers since those are gone in favour of the model system.

You can't reference client-side only code like that from your common code, use proxies. Or delete that line entirely since you do nothing with the mc local anyway. What do you mean by "can't connect"? Is there an error in your log?

You can use the built-in gui sync methods in Container class: Container#addListener(IContainerListener listener) is for initial sync when the player opens the GUI, Container#detectAndSendChanges() is for periodic detection of changes and sending those changes to the client and Container#updateProgressBar(int id, int data) is for receiving updates on the client. You send updates with IContainerListener#sendWindowProperty. See ContainerFurnace or ContainerBrewingStand for examples. This obviously only works for the GUIs. If you want the data for a progress bar in the world or for something else you will have to use packets as Draco said.

Add a server-side check (!this.world.isRemote) to your te's update method. Recipe processing code like that should not run on the client anyway.

You would need to iterate through all inventory slots and check if each one of them is empty incrementing some counter if it is. To clarify - you would need to iterate the InventoryPlayer#mainInventory list.

There is Block#updateTick but if you want something like a spawner you most likely are looking for ITickable#update for which you would need a TileEntity. I would recommend looking into the way vanilla spawners work(BlockMobSpawner and TileEntityMobSpawner).

Override CreativeTabs#getIconItemStack and return an ItemStack chosen based on time from an array/list of ItemStacks.

If you do not want a TESR then don't register it. An empty TESR still has it's render method called even if it doesn't do anything. You can have a TE without a TESR. As for your issue - override Block#getRenderType and make it return EnumBlockRenderType.MODEL. BlockBed overrides that to return something else.

I do not think there is a method to render particles in the gui as vanilla never does that. The default spawnParticle method spawns them in the world only. You would need to create your own method to render the particle in the gui.

You can see how minecraft does that in net.minecraftforge.client.GuiIngameForge#renderHealth. Basically the withered/poisoned hearts are a part of the hud texture and MC just changes the uvs when it detects a certain potion effect active. If you want to replicate that effect you would need to use a RenderGameOverlayEvent to cancel the default hearts rendering when you need it and render your hearts with a different texture.

If I recall correctly a sound name should be prefixed by your modid. "name": "ctm:records/disk_1" If the file can't be found the startup log will contain a message that a file at a given resource location could not be found.

Entity::rayTrace only looks for blocks as it reroutes to World::rayTraceBlocks. You will need a custom ray-tracing method. You can see an example at EntityArrow::findEntityOnPath.

https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ People on this forum(including me) have no idea how you are currently doing your data saving/loading/interaction so we can't know why the problem occurs as you've not posted any code. Please provide relevant pieces of your code or a link to your mod's git repository.

No, there isn't. You do it whenever you want. Since other mods might query oredict to enable some kind of compatibility I would suggest duing it during init(as mod compatibility should happen in post-init according to docs anyway) or in registry event directly as you've suggested. If it implements IForgeRegistryEntry(or extends IForgeRegistryEntry.Impl) then it has a registry event(well actually rather if it has a registry then there is an event but in vanilla there is a registry for evey IForgeRegistryEntry implementation). Just lookup the usages in your IDE.

Yes, that would be the best way as you can't get null with that method. Depends on the entity in question. Default implementation provided by Entity returns the same in both of these methods and the default implementation is the only one used by vanilla as far as I am aware. Entity::getUniqueID is used everywhere by vanilla and Entity::getPersistentID is only used by forge. Both of those methods can be overriden, so I can't tell how different mods use/override them.

EntityPlayer.getUUID(GameProfile) returns the UUID of the profile if present, otherwise reroutes to EntityPlayer.getOfflineUUID(String). EntityPlayer.getOfflineUUID(String) returns a UUID generated from a username provided prefixed with OfflinePlayer. Entity::getPersistentID and Entity::getUniqueID both return the same in case of EntityPlayer - and that would be the result of EntityPlayer.getUUID(GameProfile). GameProfile::getId returns the UUID of the profile, or null if it is not present(could not connect to Mojang's servers). So there are really 2 cases: The player is logged in and in that case return the UUID from Mojang's servers The player is not logged in and in that case return a UUID generated based on their name.