Cadiboo

Show your build.gradle.

Short answer: No. Long answer: Json models are loaded and baked into objects that can easily be uploaded to your GPU for rendering. It is possible to animate these models but it is hard. What exactly are you trying to do, from a player's perspective?

I would also clean up your code: Use hex for the colors and field access for the constants like 3042 (GL11.GL_BLEND)

Extending ArrowEntity fixes some of this. More info here and here.

Did you run the genEclipseRuns gradle task?

The rendering code has changed massively since 1.7.4 so that snipped of code is no longer usable. However, the intent of the code can still be implemented. I'm not sure how this could be implemented with the current rendering changes (I would wait till 1.15 stabilises before attempting it) but unless the smooth lighting code has changed a lot you would likely be looking at changing AmbientOcclusionFace. Pictures from MC-43968:

Hint: BlockRendererDispatcher#renderFluid (func_228794_a_). Look at ChunkRenderDispatcher.ChunkRender.RebuildTask#rebuild (func_228940_a_) for more context (previously RenderChunk#rebuildChunk / ChunkRender#rebuildChunk).

I think that all you need to do is remove the ".obj" from "apply": { "model": "brassnsteam:block/pipes/attachments/pipe_core_valve.obj" } and it should work.

You probably want to use the hex representation of your color number. Also why not pass in a BlockPos instead of a Vec3d?

Post your logs + BlockState json & model

Depends on how you’re extending the arm. If you’re doing it with the player model, IIRC model parts contain UVs.

Goes to a 404 for me. The old docs are still accessible at https://mcforge.readthedocs.io/en/1.12.x/ and https://mcforge.readthedocs.io/en/1.13.x/ but aren't visible on the main page.

You don't need to do that call anymore, it just works™️ if you reference the model from your blockstate json

You need to override transferStackInSlot. Heres a dynamic version that some Modder made ages ago and that I've updated. Copy pasta code. Just pop it in your container class. Example of it being used. /** * Generic & dynamic version of {@link Container#transferStackInSlot(EntityPlayer, int)}<br> * Handle when the stack in slot {@code index} is shift-clicked. Normally this moves the stack between the player inventory and the other inventory(s). * * @param player the player passed in * @param index the index passed in * @return the {@link ItemStack} */ @Override public ItemStack transferStackInSlot(final EntityPlayer player, final int index) { ItemStack itemstack = ItemStack.EMPTY; final Slot slot = this.inventorySlots.get(index); if ((slot != null) && slot.getHasStack()) { final ItemStack itemstack1 = slot.getStack(); itemstack = itemstack1.copy(); final int containerSlots = this.inventorySlots.size() - player.inventory.mainInventory.size(); if (index < containerSlots) { if (!mergeItemStack(itemstack1, containerSlots, this.inventorySlots.size(), true, this)) { return ItemStack.EMPTY; } } else if (!mergeItemStack(itemstack1, 0, containerSlots, false, this)) { return ItemStack.EMPTY; } if (itemstack1.getCount() == 0) { slot.putStack(ItemStack.EMPTY); } else { slot.onSlotChanged(); } if (itemstack1.getCount() == itemstack.getCount()) { return ItemStack.EMPTY; } slot.onTake(player, itemstack1); } return itemstack; }

This is also the solution I found. Please note this only occurs for Eclipse, IntelliJ has no such problem.

Its logical server side (per-world) and syncs to the client on connection. You register it on all distributions. Using a "proxy" or "baked" value is much better. You can see and/or profile the performance of the get method yourself. It's (possibly nested) Map#get calls so isn't extremely slow but is a lot slower than direct field access. Forge registers its client & server configs on all distributions, however they only use simple config values like booleans and numbers. If you're using a class that only exists on a specific distribution (for example an enum) you might want to look into only registering that config on that distribution. The config types contain some documentation. I've got a tutorial on configs here if you'd like some info. It's not very in-depth though (yet).

Yeah and FastTESR is gone in 1.15.1 anyway - everything changed and is more like a FastTESR with the new render system.

See

The forge docs just got 1.14.4 and 1.15.1 “updates”. I’ve got a list of resources for modding here, an example mod here and tutorials here.

But World already is an IBlockReader, you don’t need to cast.

The block pos is used for gathering extra data + randomising the model. Passing in BlockPos.ORIGIN (or ZERO, it might have been renamed) is likely to not cause any noticeable bugs. In 1.14.4 there was a method that just took in a BlockState and rendered it, I think it was called renderBlockBrightness and you might want to replicate its logic.

Post your logs

I think you’ll probably want to modify the player model.

Have you looked at BlockRendererDispatcher#renderBlock?

Yes, look at Forge blockstates