SerpentDagger

Matrix transformations actually take effect in the opposite order from that of multiplication, which means that it is indeed how I described. I think the way ModelRenderer works means that you could have a parent instance whose yRot is set based on block rotation, and then add your current ModelRenderer with addChild, but only set its zRot. The child should be rendered when the parent's render method is called.

It looks like the code in ModelRenderer applies rotations X→Y→Z, then translation (Matrix transformations definitely have an order. Sorry, I wasn't thinking). That's why your problem is presenting itself. On the bright side, I think* ModelRenderers can have children which inherit the rotations and translations of the parent. This means that you should be able to have a parent ModelRenderer with the Y rotation, and then the child can have the Z rotation, which is then independent of the block's direction. *Never used them before, sorry.

What code is processing these angles? To me, it looks like the rotations are processed in the order X, then Y, then Z. This would make it impossible to get the desired skew result in the East/West directions. Here's what I think is happening: Your model starts with the face pointing to Z+, and the tip to Y+. To get it into a skew for the North/South position, you rotate around Y to account for the flip, then around Z for the skew. All good. To get it into a skew for the East/West, you would have to rotate around Y ± π/2, then around X. Problematic, since the X rotation happens first. If you try to rotate around X first, you just tilt the piece forward or backward, as you've seen. If you try and rotate around Z after, the piece is already pointing face to X±, tip to Y+, and at that point the Z rotation will just tilt it forward/back, as you've seen. If this is the case, you need to process the rotations in a more useful order, namely with Y first. If you need a more flexible system: I don't think matrix transformations have a specific order*, which would prevent this problem from occurring. *Not true. They have a specific order. They take effect in the order opposite that of the original multiplications.

I was going to make a tweak in a 1.12.2 mod. (The graphing calculator linked to in my signature.) I've done that now, and everything works. The 1.12 version of LWJGL didn't overwrite the 1.16 one (Their file paths diverge at the version number of LWJGL), which left me somewhat puzzled as to what happened to the 1.12 stuff to begin with. Between these two Minecraft projects, I ported the graphing calculator to a standalone Java application, and installed my own version of LWJGL to work with. I think that must have overwritten the 1.12 set, and then was overwritten by the 1.17 set before I missed the 1.12, leaving me to think that 1.17 was responsible for both. All very irritating. lol I ought to apologize for this post, then, since it isn't really a Forge issue. When I do more work with my personal LWJGL projects, I'll install the libraries to a different directory from the one Forge uses, since apparently the installer has the same default. Thanks for the help!

I want to develop my 1.16 mod on and off (and update to 1.17), but also be able to tweak mods in older versions of the game, without having to re-download the LWGJL dependencies every time I switch. This would be accomplished by having each version of Forge download LWGJL to an independent directory, instead of the default (which is what causes the new version to overwrite the old). Indeed. I'm not asking for help in outdated versions, just trying to work with more than one at a time. I do that also, but the problem is that the dependencies (LWJGL3, to be specific) of the new version of Forge overwrite the dependencies of the old one, since they're downloaded to the same workspace-external directory. The build path is also set up to expect them there, so if I were to move the files, I'd have to manually reconfigure the build path to point to the new location. That would be tedious to do for every single file, and the problem would rear up again if I ever had to re-run setup for some other reason. This is interesting. In truth, I haven't re-run setup for the older version, because doing so would overwrite the newer LWGJL files, and I'd rather be able to keep developing in the current version. I was mostly expecting it to work, however, when I tried it. Does this mean that it isn't possible to develop in old versions at all, or simply that the new resulting file structure wouldn't necessarily match the expected build path of my old project? If the latter, wouldn't re-running setup also reformat the build path to match? I thought that was automatic.

I've long-since switched over to Forge 1.16, but recently got a feature request on an older mod, which I wanted to look into implementing. I opened up my old workspace, and discovered that the build path is no longer valid, because the new Forge dependencies overwrote the old ones. I suppose I could rerun the setup tasks every time I switched workspace (right?), but that seems like an impractical solution. Is there any way to have non-colliding build paths for the two workspaces, so that I can develop in multiple versions simultaneously?

I've done some testing, and there are 3 things that cause the item to move. The first is when you return a success, the item will swing. Updating the returns as previously discussed achieves the desired result in this context. The second is when you return a consume, the item will bob if it is not in use. This means that if you try to use the pan while not able to do any panning, it will bob repeatedly (but not jarringly quickly). If you don't want this, you can return a pass, which has no visual effect. The third is when you set the damage value every tick. This is what causes the glitchy-looking vibration, and it would seem you can fix it by setting the damage less frequently (once every 3 ticks eliminated all unwanted movement in my experiments).

This is your problem. The boolean parameter of ActionResult<T>#sidedSuccess is whether or not the game is running on the logical client, and so returns success on true, or consume on false. Your condition will usually be true, so a success is usually returned, which causes the item to swing. I don't think it's necessary to use sidedSuccess for this, but if you do, you should pass in World.isClientSide, or an equivalent. Regardless, the condition should be updated.

Please post your code, so that I can see what might be causing this (I won't be able to respond until tomorrow, though, since I need to sleep now). I've never done this before, so my knowledge is limited. Here is a link to the documentation on the topic, though, which seems fairly straightforward.

Yup, that's about right. The exact details of when you should do what depend on how you want it to work and look. Ultimately, that's up to you, so you should try to set something up using these tools, experiment a bit, and figure out what produces the best result. It seems like you mostly understand what's going on here, so that ought to go fairly well.

It is responsible for determining how the hand moves, but it also does a bit more. Each ActionResult<T> has an ActionResultType and an object T. In the case of the ActionResult<ItemStack>, the ItemStack object of the returned ActionResult<ItemStack> is set as the held item. Additionally, these ActionResultTypes dictate what happens after your Item's logic has been run. They are queried with the ActionResultType#shouldSwing and ActionResultType#consumesAction methods. The former is self-explanitory, while the latter dictates whether or not the click will be further processed. For example, ActionResultType.SUCCESS both consumes the action and swings. This means that if you held an ender pearl in your offhand, and clicked with an item that returns a successful ActionResult<ItemStack>, the main item would swing, and no ender pearl would be thrown. ActionResultType.PASS doesn't swing or consume, so returning that would result in no animation of the main item, and an unblocked, thrown ender pearl. ActionResultType.CONSUME consumes the action, but doesn't swing, so that's probably what you want here. ActionResultType.FAIL behaves as PASS, but is used more in the context of Block placement, I think, and as a message to prevent a behaviour. For your purposes, I would probably recommend returning CONSUME unless LIvingEntity#getUseItemRemainingTicks (this is the value passed into Item#onUseTick) fits your requirements (you could also use LivingEntity#getTicksUsingItem), in which case you would return SUCCESS. It might also be helpful to return true from Item#useOnRelease, so that your item is used when released, in addition to initially.

Within Item#use, you should call PlayerEntity#startUsingItem. This will start using the item when the item is used. You can set the maximum number of ticks that the item can be used for with the return value of Item#getUseDuration. While the item is being used, Item#onUseTick will be called every tick, and its integer parameter is the number of ticks left in the use duration. This is probably where you want to put your logic, since you mentioned that the player should be able to keep holding the item to keep the process going. At some point, the player will release the item, which calls Item#releaseUsing. Its integer parameter is the number of ticks that the item was used for, so you could also put some logic there.

You should almost certainly use the Capability system for this purpose. Here is a link to its documentation.

This is a warning that no category in the recipe book corresponds to those IRecipeTypes. The method that determines that is hardcoded for vanilla types only, so this is to be expected. It doesn't mean you've done anything wrong, or that the recipes will fail to work, and I don't think there's any way to get rid of it for custom IRecipeTypes.

This effect is hardcoded for the Nether portal only. If you wanted to recreate the effect, I think you could perform similar operations on the projection matrix before rendering, which would be done in the EntityViewRenderEvent.CameraSetup. Unfortunately, this event is fired after the projection matrix is already loaded into RenderSystem, and with no reference to the general-purpose new MatrixStack that is passed around for rendering. In order to modify it, then, you would use RenderSystem#multMatrix() with your effect matrix. This method is marked as deprecated, which means it's not supposed to be called in general. I don't know what the consequences of doing so are.