Abastro

If what you need is the location to provide the api, why just gets around with ClassLoader#getResource? It seems that getPath only gives input string for ClassLoader#getResource again. Try this: String urlDic = "/assets/hpspells/speech/spells.txt" Also are there no other types of the input?

Because it is wildcard value, it will always accept all the itemstacks with the item. Just replace the recipe with your own one.

You should not be using forgedebugmodelloaderregistry as your domain. map_Kd forgedebugmodelloaderregistry:tardis Do not just copy-pasting from the test mod. The map location should be (your resource domain):(resource name), like ResourceLocation. Also note that the texture gets into "assets/(resourceDomain)/textures/blocks". And the log you given is unrelated with this issue, it is normal behavior of Forge Obj model loader.

You should add every items that can be displayed on the creative tab.

Found out that I omitted the assets on the resource folder. "/assets/hpspells/speech/spells.txt" will work.

It seems that assets folder is ignored on the real mc enviroment, compared to dev environment where resources are just read. You can simply omit the 'assets' part, so it becomes "/hpspells/speech/spells.txt". This worked well for me.

You should take it into account that linear interpolation with partialTicks is needed on the rendering, including the rotations of the player.

Try providing the location of hopper model through ModelLoader.setCustomModelResourceLocation(...), and bind hopper state mapper using ModelLoader.setCustomStateMapper((Your Block), (new StateMap.Builder()).ignore(new IProperty[] {BlockHopper.ENABLED}).build()); (Gotten from BlockModelShapes#registerAllBlocks) This will ensure that the model will be identical to the vanilla hopper model in any case. If you want to make your model modifiable in resourcepacks, you should copy the model, textures, and blockstates file for the hopper. EDIT: first parameter of setCustomStateMapper should be your block, sorry for the previous mistake.

1. You can use Block#getActualState(IBlockState state, IBlockAccess worldIn, BlockPos pos) or Block#getExtendedState(IBlockState state, IBlockAccess worldIn, BlockPos pos). I can't see any better way in performance, since the block state is not saved into the world itself. 2. I think the code could be easily cleaned further by using for loops and maps. EDIT: Gotten from BlockStairs code, the stairs also use this way. public void addCollisionBoxToList(IBlockState state, World worldIn, BlockPos pos, AxisAlignedBB entityBox, List<AxisAlignedBB> collidingBoxes, @Nullable Entity entityIn) { state = this.getActualState(state, worldIn, pos); for (AxisAlignedBB axisalignedbb : getCollisionBoxList(state)) { addCollisionBoxToList(pos, entityBox, collidingBoxes, axisalignedbb); } }

(Sorry for my blindness not catching the last line)

I think it is not a bug but a feature in forge configuration system. Since it should load properties before any property is initialized, the value loaded from the file couldn't be checked. Also it is not checked in getInt(or getValue), since it might be odd to check and give value in bound while the actual value does not change. (Changing the value will result in messy code, in my opinion.) The minValue / maxValue are only for Gui Configs, currently.

Note that PlayerLoggedInEvent has the joined player as public field. 1. MC username: player.getDisplayName() 2. Time they joined: I'd assume that you know how to get system time. To get minecraft time, use World#getWorldTime(). (Player has public field named worldObj) Get the Overworld using MinecraftServer#getEntityWorld() to get universal server time. 3. How many players have joined: - length of World#playerEntities for players in the world. - MinecraftServer#getCurrentPlayerCount() for all players in the server. And what do you mean (EDIT) by saving the list?

You didn't put the written NBT into the itemstack tag when it was previously absent.

It seems that it uses own packet system to give the client world information, and the client stores the world to the ProxyWorldManager. Also if one uses proper rendering pipeline, there won't be compatibility issue. ..Though it also looks like that it might have severe performance issue.

Why don't you check World#isRemote? If adding it changes something, than the problem is in your block/tileentity.

No, it was about the Vanilla recipes. For ore recipes, you can still do it using ShadedOreRecipe/ShapelessOreRecipe. It also accepts the ore id instead of the ItemStack itself.

Ah, sorry for not catching the mistake: You registered something wrong. ModelLoader.setCustomStateMapper(BlockInit.RAINBOW_SAPLING_BLOCK, rainbowLeafStateMap.build()); ModelLoader.setCustomStateMapper(BlockInit.RAINBOW_SAPLING_BLOCK, rainbowSaplingStateMap.build()); I see something duplicated.

If the upgrades belong to the gun, then you should store the capabilities to the itemstack for guns. In this case, 1. Upgrades for the gun: Capabilities for the gun. - The implementation may vary up to your purpose and design decision. 2. Applying the effect: Use events, and check for the capabilities(upgrades).

So, it seems that it does not update because you used 0, which won't do anything. From the World#setBlockState, it's same for markAndNotifyBlock. /** * Sets the block state at a given location. Flag 1 will cause a block update. Flag 2 will send the change to * clients (you almost always want this). Flag 4 prevents the block from being re-rendered, if this is a client * world. Flags can be added together. */

What did you used for flags? And, world.isRemote is false for the server thread. It does exist on the Combined Client.

Nope, I said that ShapedOreRecipe will do the trick. It will accept every items registered as the ore.

I said that you should use World#markAndNotifyBlock, or something similar.

You can easily change your code, because the constructor of ShapedOreRecipe gets the same parameter as GameRegistry#addRecipe that you used.

Something like Proxy#getDefaultPlayer() with implementation on clientproxy only?

Normal recipes and Ore recipes are different. You should register ShapedOreRecipe instead of just using normal recipe registration.