V0idWa1k3r

AnvilRepairEvent. You can get the "current anvil" from the opened container(event.getEntityPlayer().openContainer). It is likely an instance of ContainerRepair(although it might not be in case of modded anvils so you have to account for that). ContainerRepair has a selfPosition field you can use to get the position of the anvil. Although none of that is needed if you simply want to modify the break chance for the anvil. Just use AnvilRepairEvent#setBreakChance. There is no event for that. If you wish for one you can submit a PR. This is why you are using a EntityJoinWorldEvent in the first place - to replace the falling anvil entity provided by vanilla with your own wrapper/version that has the necessary hook.

Don't necropost. If you have an issue create a new thread instead of digging this 4 year old one. Things changed between versions and ItemStack.stackTagCompound can now be accessed via ItemStack#getTagCompound.

I've debugged your code. What's happening with the tile entity is by your logic first it consumes the items for the operation and sets the cookTime to 1. It also sets the smelting field to the output of the recipe. Everything seems correct so far. Apart from this condition: if(this.isBurning() && this.canSmelt() && cookTime > 0) This checks if the smelter is burning(true), if the cookTime is greater than 0(true) and if the recipe is correct(false)! It shouldn't check for the recipe since it already cached the output. Check whether the output is empty instead. As for the shift-clicking this is your issue: Slot slot1 = this.inventorySlots.get(index + 1); if(!AlloyerRecipes.getInstance().getAlloyerResult(stack1, slot1.getStack()).isEmpty()) You check if the item in the next slot + the item in the current slot make for a recipe. This Only works for one item, the one the player clicks and not the other since now the condition isn't true. Crashes the game if the player attemts to shift-click the item in their last slot You have to change your logic here and instead check if the clicked item can be used in a recipe, and if it can in which position, determine the slot according to that position and attempt to merge. Or just transfer the item in the slot regardless of whether it should be in that slot or not.

It would override any falling block. It doesn't matter whether the anvil is "new" or "old". It should also affect even the falling blocks currently in the process of falling.

I am not sure. With custom BakedModels, resourcepacks and RenderWorldLast event it is not something I can easily make a case for. If you can think of any other use case apart from yours then go for a PR.

If you think that these events will be usefull in any other scenario for modmakers then make a PR. New usefull events are always welcome.

EntityJoinWorldEvent happens every time any entity joins a world. As in every time World#spawnEntity is called. EntityFallingBlock is not an event. It's an entity.

It is simply a storage for items. It's the entire IInventory in one line of code. Elegant and simple. Instead of defining the ItemStack array/list you define the ItemStackHandler with your desired size. Then you can use it the same way you would use the IInventory - there are getters and setters for items in slots and insert/extract methods. The best thing is that you do not need to implement IInventory anymore and simply need to expose your ItemStackHandler instance as a capability. Then the tutorial is crap and you can tell the author of the tutorial just that. IInventory is what, 4-5 years outdated by this point and people might not even bother with checking for it anymore since they assume everyone moved to capabilities by now. We simply try to provide a solution which gives you the best results and compatibility. We are not taking it to an extreme, we simply tell you "Don't use IInventory, use capabilities". Ahem. Direct method signature: @Deprecated //TODO: Remove in 1.13, Use ResourceLocation version. public static void registerTileEntity(Class<? extends TileEntity> tileEntityClass, String key) BlockBase is an antipattern. What even is this? You do not need any of this. Just override TileEntity#shouldRefresh. You do not need this. You already return the state for placement at Block#getStateForPlacement. You do not need this since the super implementation of this method should already return MODEL. You are only (de)serializing your facing property but not the ACTIVE one. I assume you want that one to persist too. This is the IHasModel all over again just this time without an interface. You do not need this in your block class. This goes into your ModelRegistryEvent directly, even without the need for the proxy. All of the things you need are public. There is no need for this method to be anywhere else apart from your ModelRegistryEvent. Are you sure this is correct? What if I only put 1 piece of coal in your furnace? Then when this code is executed the stack in slot 2 will be empty and the currentBurnTime will be 0. Even though it should be the burn time of coal. This code makes no sense. "Serialize these as an integer using 4 bytes but truncate them to shorts first thus discarding the first 2 bytes". Why? Don't cast them to shorts at all just save them as ints in the first place. The fact that they are casted to shorts in TileEntityFurnace is a Mojang bug. Sigh. You do not need the get/setField nonesense if you are not using IInventory. And you are not. Just access the fields directly. You probably do not want to be setting the state to a new one every tick. Only do it when the "should be" and "current" states do not match. Any particular reasons for this array to exist? You are not iterating it. You are just using it to access elements at an index. You might as well use ItemStackHandler#getStackInSlot directly then. You already know that fuel isn't empty by now. If isBurning returns true then the burnTime for the fuel is not 0. Then the fuel isn't empty. Why use insertItem here? You might as well be using setStackInSlot. This return is pointless since it is the last statement that gets executed. I don't know about eclipse but Idea warns you about these kinds of things. This is not really an issue btw, just me nitpicking. ? Why? handler.getStackInSlot(0).shrink(); handler.getStackInSlot(1).shrink(); Does the same and is 50% less code. ItemStackHandler#getStackInSlot already returns an ItemStack there is no need to cast it to one. Again, a normal IDE would warn you about these kind of things. You do not need this method since it is directly copied from TileEntityFurnace. Why did you do it in the first place? The method is static and public, you do not need to copy it. As for the actual issue... It's a bit hard for me to tell just by looking at this code. I'll try to debug this locally and provide you with an answer in a bit. As for shift-clicking - something is wrong with your logic in Container#transferStackInSlot. Use the debugger to find out what exactly.

What is this? If you want to know what the jump key is you must use KeyBindings. They are all public. Don't use keyboard.isKeyDown, use KeyBinding#isKeyDown. There are so many things wrong with this: You are leaking memory with this map since you never clean it up Player names can and will change Using strings as a key for a hashmap is a bad choice. Use a UUID You do not need this map at all. Use capabilities. This will persist between different saves since you never clean it. Don't use a HashMap. Use capabilities when you need to store something per player. Instead of all this tick/hashmap hackery use a KeyInputEvent to detect when the jump key is pressed and then perform the jump. Why? You can do this in a much simplier way: p.getPosition().down() And what if the block isn't an instance of BlockAir but is supposed to behave just like air, like RailCraft's residual heat? Use World#isAirBlock. This will fire when the jump event fires which is probably not what you want. You probably want to check that Entity.onGround is true in some kind of tick event. Also your double jump will only work if jumps[playername] == 1 yet you set it to 0 here thus making sure it won't work ever again. And you know why it won't work? Because when the tick event fires next and checks for the block below the player it is not going to be an air block. Thus it will set the jumps to 0 again even though you've jumped. Ad for your issue - use the debugger to find out what is wrong. However I suspect that if you fix everything I've mentioned the issue will fix itself.

Well as the name of the event suggests ClientTickEvent fires on the client. You always have an access to the client player. It's Minecraft.getMinecraft().player. However I feel that you want to accomplish something else here. Could you please clarify what exactly do you want to accomplish?

Unless you want your mod to be client-side only you can't do this in the FMLInitializationEvent. And you do not want your mod to be client-only since you are planning to have dynamic collision boxes for your non-cubes. And the server needs to know about those.

Wouldn't you be able to just periodically(LivingUpdateEvent, check if Entity.ticksExisted % X == 0 to make the check happen once every X ticks) check whether the entity has a "space suit" or similar equipped and if not deal drowning damage via Entty#attackEntityFrom? As far as I can see there is no reason to use ASM here.

Ahem. "Please bind my texture and then draw it at position [0,0] with a size of [0,0]" I don't think that this is the behaviour you wanted. Also you do not need to do this The game already does that for you.

This statement is ambiguous. Do you mean see as in see through the eyes of the entity(read: see the game from a different perspective) or see as in see a picture of the entity's vision on your HUD? If it's the former then you do not need the framebuffers, you simply need to change the renderViewEntity although I've heard that it is not quite that simple and causes frustrum culling issues.

A snippet of what? Setting the renderViewEntity? Creating a framebuffer? Rendering everything all over again? Setting the renderViewEntity: Minecraft.getMinecraft().setRenderViewEntity(yourEntity) Creating a framebuffer(somewhat of a pseudo-code as I don't know if Minecraft allows using framebuffers directly like that(it might bind it's own framebuffer somewhere else) but I think for your purpose something like this should suffice - so don't use this code directly, it is meant to be an example) int rbo = GL30.glGenRenderbuffers(); // Should be a field GL30.glBindRenderbuffer(GL30.GL_RENDERBUFFER, rbo); GL30.glRenderbufferStorage(GL30.GL_RENDERBUFFER, GL30.GL_DEPTH24_STENCIL8, texWidth, texHeight); int fbo = GL30.glGenFramebuffers(); // Should be a field GL30.glBindFramebuffer(GL30.GL_FRAMEBUFFER, fbo); GL30.glFramebufferTexture2D(GL30.GL_FRAMEBUFFER, GL30.GL_COLOR_ATTACHMENT0, GL11.GL_TEXTURE_2D, tex, 0); GL30.glFramebufferRenderbuffer(GL30.GL_FRAMEBUFFER, GL30.GL_DEPTH_STENCIL_ATTACHMENT, GL30.GL_DEPTH24_STENCIL8, rbo); But I think the minecraft-way of doing framebuffers is in the net.minecraft.client.shader.Framebuffer class. However I have never used it and as such you need to figure it out yourself but I would imagine it's not too hard. Seems like it largely does the same my example code does but instead uses OpenGlHelper which is the correct way of doing it I suppose since it accounts for extensions. Rendering everything: Minecraft mc = Minecraft.getMinecraft(); FMLCommonHandler.instance().onRenderTickStart(mc.getRenderPartialTicks()); mc.entityRenderer.updateCameraAndRender(mc.getRenderPartialTicks(), System.nanoTime()); FMLCommonHandler.instance().onRenderTickEnd(mc.getRenderPartialTicks()); Note that you will have to handle the case of the game being paused and supplying renderPartialTicksPaused from the game's timer to the updateCameraAndRender method and for that you will need refiection. But you still haven't told us whether you even need all this framebuffer stuff. Do you just want to render the game from a different perspective or do you actually want to render a quad on the screen that shows what another entity is seeing?

See how vanilla does music disks at ItemRecord and do the same.

Well here you register the value for the TYPE as an EnumChesterType. But later you use this data manager key as if it was associated with a byte. Stay consistent. If only java had a way to automatically check these kind of errors for you... You know, if only you could put a constraint on the TYPE parameter instead of it being a generic Object accepting anything. Something like DataParameter<Byte> TYPE = ...

(De)serialize the enum as the ordinal. Use the ordinal in your DataManager. Pseudo-code: Deserialization: setType(EnumChesterType.values()[tag.readByte("type")]) Serialization: tag.writeByte("type", this.getType().ordinal()) getType: EnumChesterType.values()[dataManager.get(TYPE)] setType: dataManager.set(TYPE, type.ordinal())

You do not need all this "metadata" nonsense, get the enum by it's ordinal(Enum.values()[ordinal], Enum#ordinal). As for your capability question create a field of ChesterInventory in your entity class, (de)serialize it when needed(readFrom/writeToNBT), override Entity#hasCapability and Entity#getCapability. In those methods check if the capability is yours exactly the same way you are checking it in your provider. If it is return your ChesterInventory, otherwise return a super implementation(return cap == YOUR_CAP ? yourField : super.getCapability(cap, facing) and return cap == YOUR_CAP || super.hasCapability(cap, facing))

Consider changing your field from a string to an enum and serialize/deserialize it by an ordinal. It will save on both the NBT data size and the network packet size(more on that later). If you want some data of the entity to affect something on the client you need to create a new DataParameter, store your data in the entity's DataManager with that DataParameter as the key and retrieve the data by using that DataParameter as the key. See pretty much any minecraft entity for an example, an EntitySheep for example. Additionally since it is your own entity you do not need a capability provider, the entity itself is one. Directly have the inventory stored in your entity as a field, override Entity#hasCapability and Entity#getCapability to check if the capability parameter is your capability and return your inventory if it is, otherwise default to a super implementation. By the way if you are wondering the reason the static field worked was only because you were reaching across logical sides. It would not work if you would have launched a dedicated server and connected to it.

I actually don't think it's too challenging. As long as you change the renderViewEntity you can just do the same the game does when it renders everything. And it doesn't do much - it just calls a couple of public methods here and there. I also don't think CMEs are going to be a thing. CME happens when a collection is modified while it is iterated. That shouldn't happen when the game simply renders the scene twice.

As far as I know OBJLoader is a custom model loader provided by forge designed to create block/item models from a wavefront file. If you are using OBJLoader then you must render your thing as an item. You could in theory bake the IModel you get from the loader yourself and later render it similar to how RenerItem#renderItemModelIntoGUI does it. That would be your example. But you would need to use ModelBakeEvent to bake your model first. And then you would need to fully mimic the code of RenerItem#renderItemModelIntoGUI(which expects an ItemStack btw so you would need to fix that too). It might be easier to use either a custom dummy item(don't show it in the creative menu and it will be completely hidden in the game) or a custom model loader, wavefront isn't too complicated - for example here is mine simple .obj loader and vertex uploader.

You would need to create a framebuffer, set it up correctly, bind a render texture to it, bind it as the active framebuffer and pretty much mimic the entire rendering of the game but with the Minecraft.renderViewEntity being the entity of your choice. Then you would retrieve your texture, bind it and render a quad with it. This is theoretical, I have never done anything like that and don't even know if this is possible. Look at minecraft's shaders, they might offer an insight at the issue. Edit: If you simply want to change what the player sees on the screen(read: not add another texture on to of player's view) then you simply need to change Minecraft.renderViewEntity to the entity you wish to view the world from. However this was raised in an another topic and I believe the author of that topic had some frustrum culling issues with this approach.

Depends on how you got it to load. If it is a block/item model then you can use RenderItem#renderItemAndEffectIntoGUI. If it is a custom model with a custom loader it is up to you to upload each and every vertex to the BufferBuilder. It also depends on where you want to do that from. If it is your own GUI then there are no problems. However if you just want it rendered somewhere on the screen at all time you will need to use an event. RenderGameOverlayEvent will do fine.

Overriding the player rendering is the only logical way of achieving what you want. Call GlStateManager.rotate and pass 180 degrees to it to rotate the model vertically. You can also just call ModelBiped#render instead of manucally rendering each part. I believe the event gives you all the parameters you need. Instead of passing a different scale parameter to the model scale the entire thing with GlStateManager.scale. However there is an issue with this approach - the model will dissappear if you look up above the player's bounding box even though it should be visible. The reason for that is that the player's bounding box is no longer in the camera's frustrum. I believe morph mod fixed that by manually changing the bounding box of the player. I don't know how exactly it did that but I suspect calling Entity#setSize might be enough.