Draco18s

Hey, at least it isn't the soul-eating abyss of java bytecode.

That's the one. Welcome to needing Reflection.

You'd have to offset by the player's eye height too, rather than just position.

return new ModelResourceLocation(stack.getItem().getRegistryName() + "_" + Math.min(stack.getCount(),3), "inventory");

Its called "reach" as it applies to all forms of the player interacting with the world. Placing blocks, digging blocks, hitting mobs...

Not really, no. If the block isn't fully opaque, the game assumes it is transparent, and begins rendering the sides of neighboring blocks.

Well, this is about as far as I can get. I can't get the color/transparency right. Both the int color variable (which is set by the TE as the biome water color) and the faceData[i + 6] = 0x7F00; have an effect on what renders. Changing the 7F00 value "too much" causes the quad to become opaque, but its more of a magic bitflag thing (I can't tell which bit(s) are involved, just that some values are Fine and some values are Not Fine). @Override public List<BakedQuad> getQuads(BlockState state, Direction side, Random rand, IModelData extraData) { ArrayList<BakedQuad> list = new ArrayList<BakedQuad>(); float[] corners = new float[4]; corners[0] = extraData.getData(SluiceTileEntity.LEVEL_CORNERS_0);//NW corners[1] = extraData.getData(SluiceTileEntity.LEVEL_CORNERS_1);//SW corners[2] = extraData.getData(SluiceTileEntity.LEVEL_CORNERS_2);//NE corners[3] = extraData.getData(SluiceTileEntity.LEVEL_CORNERS_3);//SE int color = (0xFF000000) | extraData.getData(SluiceTileEntity.WATER_COLOR); int red = (color & 0xFF0000) >> 16; int green = (color & 0x00FF00) >> 8; int blue = color & 0x0000FF; color = (0xFF000000) | (blue << 16) | (green << 8) | red; FaceBakery faceBakery = new FaceBakery(); BlockFaceUV uvs = new BlockFaceUV(new float[] {0, 0, 8, 8}, 0); BlockPartFace partFace = new BlockPartFace(Direction.UP,0,"",uvs); ISprite isprite = new BasicState(ModelsCache.DEFAULTMODELSTATE,true); BlockPartRotation rotation = new BlockPartRotation(new Vector3f(0,0,0), Direction.Axis.Y, 0, false); boolean diffuseLight = true; BakedQuad q0 = faceBakery.makeBakedQuad(new Vector3f(0,corners[1]*16,0), new Vector3f(16,corners[1]*16,16), partFace, atlasSpritesWater[1], Direction.UP, isprite, rotation, diffuseLight); //list.addAll(waterFlow.getQuads(state, side, rand, null)); int[] data = new int[28]; bakeQuad(data, new Vector3f[] { new Vector3f(0,corners[0],0), new Vector3f(0,corners[1],1), new Vector3f(1,corners[2],1), new Vector3f(1,corners[3],0) }, atlasSpritesWater[1], uvs, color); /*int[] data = new int[]{ 0, 1063423836, 0, -1, 1023434916, 960579630, 32512, 0, 1063423836, 1065353216, -1, 1023434916, 1031749304, 32512, 1065353216, 1063423836, 1065353216, -1, 1031774044, 1031749304, 32512, 1065353216, 1063423836, 0, -1, 1031774044, 960579630, 32512};*/ q0 = new BakedQuad(data, 0, Direction.UP, atlasSpritesWater[1], diffuseLight, DefaultVertexFormats.BLOCK); list.addAll(basePlate.getQuads(state, side, rand, null)); list.add(q0); return list; } private void bakeQuad(int[] dataOut, Vector3f[] verts, TextureAtlasSprite sprite, BlockFaceUV faceUV, int tintIndex) { for(int i = 0; i < 4; i++) { storeVertexData(dataOut, i, i, verts[i], tintIndex, sprite, faceUV); } } private void storeVertexData(int[] faceData, int storeIndex, int vertexIndex, Vector3f position, int shadeColor, TextureAtlasSprite sprite, BlockFaceUV faceUV) { int i = storeIndex * 7; faceData[i] = Float.floatToRawIntBits(position.getX()); faceData[i + 1] = Float.floatToRawIntBits(position.getY()); faceData[i + 2] = Float.floatToRawIntBits(position.getZ()); faceData[i + 3] = shadeColor; faceData[i + 4] = Float.floatToRawIntBits(sprite.getInterpolatedU((double)faceUV.getVertexU(vertexIndex) * .999 + faceUV.getVertexU((vertexIndex + 2) % 4) * .001)); faceData[i + 5] = Float.floatToRawIntBits(sprite.getInterpolatedV((double)faceUV.getVertexV(vertexIndex) * .999 + faceUV.getVertexV((vertexIndex + 2) % 4) * .001)); faceData[i + 6] = 0x7F00; } Mainly it acts like its not taking into account light levels (at night it looks like a very pale cyan color!?), but setting diffuseLight to false doesn't change anything.

There's also the tags system, but I don't feel that "ore or ingot" makes for a good tag (you're probably the only person that would use it and tags are meant to before inter-mod compatibility).

4 recipes or write your own IRecipe implementation.

func_225319_b looks like the one I want. Thanks. Still trying to work out the other stuff, but fortunately I found an example and will just have to beat my head against it for a while.

It would be better if you posted your code as a git repo rather than file attachments. In any case, you don't need your TinPickaxe and CopperPickaxe classes. They override none of the PickaxeItem class methods and pass their constructor arguments to super without modification. There is nothing "coppery" about your CopperPickaxe class.

Go look at the code that is the kill command?

What has world.markBlockRangeForRenderUpdate(pos, pos); been replaced by?

I have no input over there. I can't tell what the problem is.

That's their problem and they should fix it.

Already did, it is not sufficient for my needs. Waterlogged blocks can only be completely full of water ("source blocks") not flowing (as of the current version) and I specifically need flowing water (and that flow needs to "decay" twice as fast). I even attempted to return a different fluid state that contained level information, but it did not work. Thanks.

All the prefixes became postfixes. Its BlockItem now, not ItemBlock. (BlockDirt -> DirtBlock : ItemBlock -> BlockItem)

In 1.12 I had a block that used extended states in order to render flowing water over the top of its regular model. I managed this using the forge:fluid model: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/blockstates/basic_sluice.json#L7 That model is no longer available in 1.14, so how would I go about doing this instead? Currently I get this error: Additionally, getExtendedState no longer exists and I don't see a replacement, even though the update notes mention it. More pictures of what it looks like can be found on the mod wiki.

And this is why you don't used numerical IDs anywhere ever.

Almost certainly not.

One's used for players, one isn't.

Show your code.

Well, of course, because TEs are culled when they are outside the view frustum. I was assuming that this was true: You don't need to *store* the cables anywhere. Inside the event you get the world from the Minecraft instance, query the TE cache that already exists, find your TEs, get their cables, render them.

Oof. You might be better off just querying the nearby area for all instances of your TE (there's a chunk TE cache, don't examine every block) and render all* the cables all the time. *I would only look at the 9 or 16 chunks directly around the player, if you have cables longer or farther away than that, fuck'em. (1) don't let cables be that long and (2) if they're that far away you don't need to be able to see them. Additionally you can cull any cables that aren't within 32 vertical blocks of the player as well (you'll need to write a check for this). Culling for things behind the camera will be too difficult and not worth it.

Here's an example: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/recipe/RecipeTagOutput.java My recipe returns an output based on tags (as all things tagged as iron (copper, steel, tin...) ingots (dust, nuggets...) are all functionally iron ingots, and all I want is to have an iron ingot output, find all items tagged as iron ingot and get the first one), but the general process would be the same for grabbing enchantments by registry name.