Leaderboard

It works now, thanks!

That's basically what Ingredient.fromTag is. It doesn't make sense to query the item registry, the item registry doesn't know or care about tags. Try also: new ItemTags.Wrapper(new ResourceLocation(...));

Aren't you the one who wrote the recipe -> packetbuffer code in the first place? Yes, yes you are. Your buffer doesn't contain that information. The only thing you write are the ingredients and the output.

Don't search the whole project for that string, search in RedstoneWireBlock. Or go to BlockColors and look at how RedstoneWire's color gets registered and work backwards.

That is not valid json. Currently you have an array with keys. Either it should be an array of objects "[ { ..." or it should be an object with keys of "one, two,...". I would suggest going for the first option (especially as that is what you support in your code):

You would have to detect the jumping with for example a KeyInputEvent, and then send a packet to the server to inform the server that it should perform a jump action on a player. EDIT: Turns out there is a better way to do this, see diesieben's answer above.

Forge overrides vanilla. Any override you create therefor must override Forge. Note this is not a "I would like to override Forge" conscious decision. It is forced upon you by the very nature of the system's design.

This is exactly the problem I was trying to solve in this thread. A recipe is only actually overridden if the shape and ingredients are the same. In other words, if you create an identical recipe to the wooden pickaxe but set the output to air, you will find that it is impossible to craft a wooden pickaxe. So the steps to take if you want to change or replace a recipe are: 1. create a recipe with the desired ingredients and output 2. create a recipe identical to the vanilla recipe, but outputting air 3. create an identical advancement to the vanilla and have it reward your custom recipe (and change criteria as needed) 4. create an impossible advancement to override the vanilla one, since the vanilla advacement will give the player a recipe that no longer works. In step four the .json file must be named the same as the vanilla advancement and be placed in the same location in the data folder. Like I said before you can find all the vanilla advancements if you go to your external libraries and look under net.minecraft:client:extra:1.16.1. These are the steps that I went through in this thread and should get you the same result.

Whatever recipe you're using to replace the vanilla recipe needs to be named the same and placed in the same location (so, you have the location correct, I assume you've named it correctly). I am aware of, but thought it got fixed, that any recipe forge overrides from vanilla could not, itself, be overridden.

The forge version overrides the vanilla version already.

Use the debugger, check what object is coming back as the TrueSource and why its triggering your boolean check incorrectly.

Do you have java?

Try to run "gradlew --refresh-dependencies", then "gradlew clean" and then setup your project again with the genEclipseRuns task

Is this what you did?

Don't tell ppl "do your research before posting here" as the README.txt file that comes with the MDK of Forge 1.13.2 25.0.9 and 25.0.10 says to use setupDecomWorkspace its obvious that the README.txt file was not updated but you don't have to be a dick.

Hi, I've been trying to make a third person camera mod similar to the camera in the Dark Souls games, that is the camera can rotate around the player and movement is relative to the current view. At first I used the EntityViewRenderEvent.CameraSetup event to set the pitch and yaw of the camera but chunks behind the player's view were not rendered until the player moved. I fixed this by changing the location of the player by a very small amount each tick. However I wanted more control over the camera (e.g. zoom) so I adapted the MineShot camera coremod to suit my needs and transformed the camera using GlStateManager in the EntityViewRenderEvent.RenderFog event. This works ok but has reintroduced the missing chunks issue and moving the player no longer forces these missing chunks to render. I believe that using setRenderViewEntity with a dummy entity set to my third person camera's position should fix this problem in theory as the renderWorldPass method in EntityRenderer uses the current render view entity for its calculations. Below is the code I have used to attempt this. GameProfile gameProfile = new GameProfile(UUID.randomUUID(), "FakePlayer"); camEntity = new FakePlayer(DimensionManager.getWorld(0), gameProfile); camEntity.noClip = true; camEntity.setPositionAndRotation(adjustedSpherePos.x, adjustedSpherePos.y, adjustedSpherePos.z, MathHelper.wrapDegrees(yRot), MathHelper.wrapDegrees(xRot)); MC.setRenderViewEntity(camEntity); System.out.println(MC.getRenderViewEntity().toString()); //outputs name: FakePlayer, level: world, coords same as adjustedSpherePos (camera) System.out.println(MC.getRenderViewEntity().getPositionVector().toString()); //outputs (0, 0, 0) for some reason The result of adding this code was that the majority of the world disappeared, with a few parts flashing occasionally, and the position of the new game view appeared to shake between 2 points in an area of around 10 blocks despite the fact its position is not modified by my code after being declared. I also think the getPositionVector() output of (0, 0, 0) is a bit strange. Now I know you guys don't support coremods, but seeing as the rendering goes back to normal as soon as I set the render view entity back to the player I don't think that it being a coremod is necessarily to blame. It would be greatly appreciated if anybody could help by either: 1. identifying any flaws with my implementation using a FakePlayer (e.g. wrong entity, need to set some extra properties) or 2. suggesting how I might implement the hackier solution of forcing all chunks to be rendered all the time (maybe ChunkRenderContainer.addRenderChunk?) Thanks!

Setting the EntityViewRenderEvent.CameraSetup event yaw and pitch to that of my camera rotation and putting the FOV up to quake pro actually works well enough for my needs and I expect it will still render enough chunks even when the camera is offset from the player centre by some small amounts. Looks like the setRenderViewEntity problem will have to remain a mystery. Edit: Entities e.g. signs still disappear sometimes presumably because their visibility is calculated using the hardcoded third person zoom amount 4.0 rather than my camera's zoom level. I might look into how the shoulder surfing mod changes this value but I suspect it will go over my head. Ideally I just want a way to make all clipping frustum checks for chunks and entities return true always.

1.12 is no longer supported on this forum. Update to a modern version of Minecraft to receive support.