Sheeted Frame Revamp/ Improvements

[EightXOR8]

Revamp Sheeted Frames to have all the same functionality you would expect from frame blocks. Does not force frame boxes to treat sheeted frames as if they were equivalent to frame boxes themselves, but sheeted frames will treat frame boxes specially.

[MCTian-mi]

I'm always wondering why Sheeted Frame box isn't extending MaterialBlock

[MCTian-mi]

I don't really think the function of framing a pipe/cabe deserves such amount of mixins
and also since pipenet is going to receive a rewrite in 2.9 (which also means that all those mixins will not work any more), I'd suggest either a PR to ceu itself expending the framing mechanism to allow custom blocks, or not using that at all

[EightXOR8]

I don't really think the function of framing a pipe/cabe deserves such amount of mixins and also since pipenet is going to receive a rewrite in 2.9 (which also means that all those mixins will not work any more), I'd suggest either a PR to ceu itself expending the framing mechanism to allow custom blocks, or not using that at all

The reasons for not using MaterialBlock is both because these were created before that and because MaterialBlock is very much focused on material variant properties only. I would likely need to do a non-negligible amount of work to force MaterialBlock to function as sheeted frames do, which doesn't resolve the issue of requiring mixins. The mixins used were only those strictly necessary for the desired functionality, from my understanding/

A pr to ceu is beyond the scope of what I am willing to do at the moment for a number of reasons. For one, I would need to formalize all previous work, which would likely be significantly more work on its own. Additionally, I suspect such a pr to be rejected due to work being done on pipes, as you said. If I were to be permitted to include my changes alongside the pipenet rework, generalizing the implementation sufficiently would be a significant amount of work on its own, which puts the completability/ expected date for this feature up in the air, not including the potential time for the pipenet rework itself to be completed.

[MCTian-mi]

This is not how it works, adding remap = false will stop this mixin from working in obf environment
this is fixed alr in #303

[MCTian-mi]

should remove this file, it's auto generated but we aren't using it

[MCTian-mi]

better replace this with an accessor and a invoker ig

[MCTian-mi]

seems one can't r-click a pipe using a sheeted frame box to frame it
also pipes will still try to connect a pipe in a sheeted frame when you r-click to place a pipe next to a sheeted framed pipe

[MCTian-mi]

they cause z-fighting

you might need to disable covers on sides as well

[MCTian-mi]

should move this to JEI info category, I don't quite like nuking tooltips with infos like GTNH

[MCTian-mi]

I like this placement quite much, it's just like placing shafts in create mod I mean even if this PR is not getting merged I'd be glad to get an separate PR for this feature to get merged. This is just, a tiny issue that you can't extend a sheeted frame box downwards by looking down and r-click it, it will just extend 1 block downwards and extends upwards afterwise.

[MCTian-mi]

apart from these, declared features seem to work fine for me

[EightXOR8]

I like this placement quite much, it's just like placing shafts in create mod I mean even if this PR is not getting merged I'd be glad to get an separate PR for this feature to get merged. This is just, a tiny issue that you can't extend a sheeted frame box downwards by looking down and r-click it, it will just extend 1 block downwards and extends upwards afterwise.

Replying to all the above comments, I can work on making the data used smaller. An accessor wouldn't work as I need to force unique data onto the class to distinguish between frame orientations and the default frame boxes. In my testing, right clicking a pipe with a sheeted frame worked, alongside pipes not connecting on off sides. I could do more testing on this though, and attempt to replicate it on my end.

In regards to placing downwards, and as explained in the tooltip, once you place a block downwards both directions will no longer have air, and so the positive placement direction will be preferred. If you want to place downwards, place an omnidirectional sheeted frame, then place a frame below it. Any frames connected to an omni frame will place in the opposite direction. This is intended behavior, as there is no non-arbitrary way to determine the direction the player wants, without having them place at the end of the block (this currently works), using the omni frame (also currently works), or using the hit x, y, and z, which I recall seeing being passed as zero occasionally, and so may not be reliable. It is a feature I could add, though.

Disabling covers on sides would definitely be something worth adding, and which I had not initially considered. In regards to the z fighting for what is presumably a nonuple pipe, I believe pipes of a certain size already cannot be placed within frames, so I would need more details on how exactly you are getting that z fighting. From all my testing, a pipe will refuse to extend in the direction of frame walls.

I can of course implement the solution to all these issues, and test out your reported bugs more thoroughly to see if I can personally replicate them, though if the pr won't be merged subsequent to this, I don't see the point.

[MCTian-mi]

I like this placement quite much, it's just like placing shafts in create mod I mean even if this PR is not getting merged I'd be glad to get an separate PR for this feature to get merged. This is just, a tiny issue that you can't extend a sheeted frame box downwards by looking down and r-click it, it will just extend 1 block downwards and extends upwards afterwise.

Replying to all the above comments, I can work on making the data used smaller. An accessor wouldn't work as I need to force unique data onto the class to distinguish between frame orientations and the default frame boxes. In my testing, right clicking a pipe with a sheeted frame worked, alongside pipes not connecting on off sides. I could do more testing on this though, and attempt to replicate it on my end.

In regards to placing downwards, and as explained in the tooltip, once you place a block downwards both directions will no longer have air, and so the positive placement direction will be preferred. If you want to place downwards, place an omnidirectional sheeted frame, then place a frame below it. Any frames connected to an omni frame will place in the opposite direction. This is intended behavior, as there is no non-arbitrary way to determine the direction the player wants, without having them place at the end of the block (this currently works), using the omni frame (also currently works), or using the hit x, y, and z, which I recall seeing being passed as zero occasionally, and so may not be reliable. It is a feature I could add, though.

Disabling covers on sides would definitely be something worth adding, and which I had not initially considered. In regards to the z fighting for what is presumably a nonuple pipe, I believe pipes of a certain size already cannot be placed within frames, so I would need more details on how exactly you are getting that z fighting. From all my testing, a pipe will refuse to extend in the direction of frame walls.

I can of course implement the solution to all these issues, and test out your reported bugs more thoroughly to see if I can personally replicate them, though if the pr won't be merged subsequent to this, I don't see the point.

normal pipes will also have z-flighting
just most obvious for huge ones so I use it to show the issue

[bruberu]

Honestly, I feel like this PR is just too likely to break things, given how invasive these mixins seem to be in the code. I would really rather prefer this to be either done after the pipe rework or done with way less mixins.