polarbear316

When using a parent block model like "parent": "minecraft:block/torch", block/torch in this instance will be the torch block model of any resource pack currently being used. Is there an API call to make it so the native block model is used? Or is the only way is to make a copy of the native block model and use it myself?

The only argument I can think of is that since onItemUseFirst is called before the block's onRightClick, or whatever the actual event name is, I can return EnumActionResult.SUCCESS and the block's event will not be triggered. Not sure if the new mechanics you mention can do this, if so could you point me in the direction of them? The only reason for wanting to prevent the block's event is in the case of mods like StorageDrawers. The item will get stored on normal right click, and I was wanting to prevent storing of the item all together in those types of mod.

Using the latest forge: 12.16.0.1802. While onItemUse is called on both sides, I need onItemUseFirst as it is called before the block being right clicked is activated, allowing me to prevent any action it might initiate.

Is this part still being developed? As I see the comment //TODO: Hook interact event here... in NetHandlerPlayServer#processPlayerBlockPlacement. Was needing it, onItemUseFirst, for a mod I wanted to modify to be able to work with 1.9 when I came across the comment. So wasn't sure if there was a change of events or if it just hadn't been implemented yet.

Ah, didn't see that post.

This is a known issue: Issue #2570 And also mentioned here

As mentioned that is intentional. The bug being mentioned is this one, which states that chests opening with slabs, stairs, etc over them is a bug. And while Mojang says its not a bug, Lex, not wanting to do more coding work than needed, is deciding to treat it as a bug. So this means Forge will continue to make it so chests cannot be opened when slabs, stairs, etc are over them.

Actually you can, all major modern browsers (Chrome,Firefox,IE 8+, etc) support a HTTP header named X-Frame-Options. If a server sends that header with whatever page it is serving, the browser will not allow it to be rendered in a <frame>, <iframe>, or <object> tag. Since you seem to be using Apache, simply adding the following to your Apache config will make the server send it for everything that it serves. Header always append X-Frame-Options DENY Or switch out DENY with SAMEORIGIN if needing to allow framing on your own pages. For instance, Stackoverflow uses it to prevent sites from framing there content There are of course techniques to get around it, like scraping the target site and directly rendering the html, but I don't think many of these types of sites do anything more than just include an iframe. RFC 7034 paper MDN reference page

Ok fixed with build 1780

With the latest 1.9 forge builds, latest tested being 12.16.0.1776, when using the Enchanting table enchantments are listed and addable to items they are not meant to be enchanted onto. For instance, with a sword in the item slot, enchantments like Protection III and Aqua Affinity are listed and can be added to the sword. Another example, with Boots in the item slot, enchantments like Power IV and Silk Touch are listed and can be added to item. No mods are in use, mods directory is empty. Seems to be only with the 1.9 builds as I tested the Forge build 11.15.1.1765 with MC version 1.8.9 and enchantments worked properly. Also tested with vanilla 1.9 Minecraft to rule out a vanilla bug and enchantments worked properly. Logs: fml-client-latest.log: http://pastebin.com/gqBvBMWy latest.log: http://pastebin.com/ULp2JVQ5