Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/29/17 in all areas

  1. Minecraft is a tag on Stack Overflow (so is Minecraft Forge) and when Documentation happened I was all "yes, this would be a nice thing to have" so that there was a community managed*, central repository of Minecraft modding examples. Documentation (as a feature) has (largely) failed, but those articles I wrote are still there. *Pull Requests to Read the Docs don't count: if the owner(s) of the git repo disappears for any reason, they can't accept the PRs. Not to mention the fact that the Read the Docs doesn't even mention json models and a whole slew of other topics. Like a page on how to get started, which has an existing PR that has had no action in six months.
    2 points
  2. get forge version 2362, it works with optifine.
    2 points
  3. Actually it is fine to have it where it is, as the @SideOnly annotation will cause it to be stripped on the server side, so it won't exist to be called.
    1 point
  4. You should register models in the ModelRegistryEvent.
    1 point
  5. Forge explicitly excludes vanilla Items from having their burn time determined by IFuelHandlers, so it's not currently possible to modify the burn time of a vanilla Item. If this PR is merged, you'll be able to modify vanilla burn times using an event.
    1 point
  6. You could use this if you need an instance of ItemBlock, sure. Or you could completely dismiss this line and just use Item::getItemFromBlock whenever you need an instance of ItemBlock. This should be in a client-only side class. In your client proxy or some place else. Yes, it will. First the registry event is fired for blocks, then all ObjectHolders for blocks get populated, then the registry event is fired for Items, then all ObjectHolders for items get populated, then all other registry events get fired in alphabetical order and all other ObjectHolders are populated last. Apart from all that - yes, looks like you are using the new registry system correctly.
    1 point
  7. It's new with that PR which was merged 5-6 days ago.
    1 point
  8. You'll need to create a class that extends StateMapperBase and implements StateMapperBase#getModelResourceLocation to do something similar to StateMap#getModelResourceLocation. Instead of using the Block's registry name as the domain/path of the ModelResourceLocation directly, it should prefix the path with the name of the subdirectory. Register an instance of this for your Block(s) with ModelLoader.setCustomStateMapper in ModelRegistryEvent.
    1 point
  9. Yes, but using the ModelMesher is still the worst option.
    1 point
  10. I have implemented an invisible light block in my mod, you can see it here. Overriding rayTrace to return null means the block has no collision box or wireframe highlight, and overriding getRenderType to return INVISIBLE means the block has no model. Get/set the light value in the same way as any other block (in mine I have the light value as a changeable property of the block which is stored in the state, but for a constant light level that's not necessary). Place the block in the world in the same way as any other, using World#setBlockState.
    1 point
  11. Well, Lex says differently. As far as I am aware the registry events have been moved to directly after pre-init but before init. Maybe the docs are not updated yet? I am subscribing my handlers for registries during pre-init and it works fine.
    1 point
  12. PLEASE!! :'(Restart file scala-library.jar in http://files.minecraftforge.net/fmllibs/ for MC 1.5.2 . I will be grateful so much. Sorry for my english;)
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.