Issue Description

Game crashes.

What Happens

When I right-click the table with an item, the game crashes. It probably has to do with mods i have or Forge version.

Crash Log

https://paste.ee/p/8C7Rw

Affected Versions

• Minecraft: 1.12.2
• Forge: 14.23.5.2804
• Dropt: 1.14.0
• Pyrotech: 0.0.0-1242-g908d71b
• Athenaeum: 1.16.0-56-g7c4c589

For reference:

[14:00:25] [Client thread/FATAL] [minecraft/Minecraft]: Unreported exception thrown!
java.lang.ClassCastException: com.codetaylor.mc.pyrotech.modules.tech.basic.tile.TileWorktable cannot be cast to com.codetaylor.mc.pyrotech.modules.tech.basic.tile.TileChoppingBlock
	at com.codetaylor.mc.pyrotech.modules.tech.basic.tile.TileChoppingBlock$InteractionShovel.allowInteraction(TileChoppingBlock.java:282) ~[TileChoppingBlock$InteractionShovel.class:?]
	at com.codetaylor.mc.pyrotech.interaction.spi.InteractionUseItemBase.interact(InteractionUseItemBase.java:33) ~[InteractionUseItemBase.class:?]
	at com.codetaylor.mc.pyrotech.interaction.spi.ITileInteractable.interact(ITileInteractable.java:106) ~[ITileInteractable.class:?]
	at com.codetaylor.mc.pyrotech.interaction.spi.IBlockInteractable.interact(IBlockInteractable.java:35) ~[IBlockInteractable.class:?]
	at com.codetaylor.mc.pyrotech.modules.tech.basic.block.spi.BlockWorktableBase.func_180639_a(BlockWorktableBase.java:57) ~[BlockWorktableBase.class:?]
	at net.minecraft.client.multiplayer.PlayerControllerMP.func_187099_a(PlayerControllerMP.java:423) ~[bsa.class:?]
	at net.minecraft.client.Minecraft.func_147121_ag(Minecraft.java:1579) ~[bib.class:?]
	at net.minecraft.client.Minecraft.func_184117_aA(Minecraft.java:2254) ~[bib.class:?]
	at net.minecraft.client.Minecraft.func_184118_az(Minecraft.java:2020) ~[bib.class:?]
	at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1808) ~[bib.class:?]
	at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1098) ~[bib.class:?]
	at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:398) [bib.class:?]
	at net.minecraft.client.main.Main.main(SourceFile:123) [Main.class:?]
    [...]

Yeah, now i can't reproduce it eather. Maybe it has to do with shoulder surfing reloaded since it's a coremod that changes a bit of raycasting i believe with crosshair. I'll report back if I stumble upon this crash again.

Ok, i have tested it now with only pyrotech+dependecies with shoulder surfing reloaded. You need to move the camera a bit to right and then go to the table and right click with the item on the right side of it, like this:

It's kinda hard to do. If it doesn't work try putting a chopping block next to it and do the same thing(try both taking and puting the item).
Here's the crashlog just in case: https://paste.ee/p/z9U9f

Thanks for the report!

I am unable to reproduce this crash.

Are you able to reproduce it?

This is my current understanding of the problem:

1. Player clicks BlockWorktableBase (BWB) with item
2. BWB retrieves the Worktable TileEntity (WTE) at its position and calls interact on the WTE
3. The WTE raytraces the player look vector and retrieves a list of interactions from the result
4. The list of interactions belongs to the ChoppingBlock (CB), not the Worktable
5. The CB interactions expect a CB tile and instead get a Worktable tile
6. ClassCastException

This indicates a discrepancy between the raycast result stored in mc.objectMouseOver (used to trigger the block interaction) and the raycast result returned from World#rayTraceBlocks (called from ITileInteractable#interact to retrieve the list of interactions).

If the position of the second raycast result is checked against the position of the first raycast result (the position of the block being interacted with) this crash could probably be prevented. I hesitate to make the change without more information, understanding the problem better, or a way to reliably test the solution. Investigation leads me to believe that this is a rare case and it may be difficult to reliably reproduce.

Thank you for helping me narrow down the cause of this issue.

I don't know if Pyrotech (Pt) will be compatible with Shoulder Surfing Reloaded (SSR).

Pt's interaction system is built on the assumption that the server-side and client-side raycasting behave the same.

SSR uses ASM to override Entity#getPositionEyes in the EntityPlayer class on the client-side only. The raycasting for Pt's interaction system uses Entity#getEyeHeight instead, which SSR doesn't modify. Entity#getPositionEyes is called to resolve mc.objectMouseOver producing a different result than when Pt calls World#rayTraceBlocks using Entity#getEyeHeight.

This could be rectified by changing Pt's raycasting to use Entity#getPositionEyes instead of Entity#getEyeHeight, however, this solution is only viable for the client because SSR injects on the client-side only. Server-side raycasts would still have the possibility of returning the wrong object depending on how the camera is oriented.

Could this be solved on SSR's side?

Ok, i'll write an issue there.

Could this be solved on SSR's side?

I think that is a question best answered by the developers of SSR.

Isn't it possible for you to raycast on the client and send the raycasted position for interaction to the server (or the slot for the table) ? SS is intended to be client only.

I agree. There is not much i can do to change the code of SS without trimming some features.
The mods will remain incompatible

Yes, that solution would work.

That said, I'm not too keen on the idea of refactoring the interaction system, adding another layer of complexity, adding another point of failure, and adding additional network traffic to circumvent a problem that only occurs when the code that the mod depends on to function correctly is modified at runtime.

If SSR is intended to be a client-side only mod, then it should stay that way. I'm not suggesting that it change as I'm sure it's a lot more useful that way. Additionally, Exo, I'm sure that even if the mod wasn't client-side only, you wouldn't be too keen on the idea of refactoring, adding complexity, adding another point of failure, and adding network traffic to circumvent a problem that only occurs with one mod.

The cost-benefit ratio here is heavily skewed toward cost from both perspectives, probably more so from SSR's perspective.

In summary, I am not going to implement this. If, at some point, this solution becomes viable for more than just this problem, ie. the benefits increase, then I may reevaluate. For now, the mods remain incompatible.