Chisels & Bits - For Forge

Chisels & Bits - For Forge

108M Downloads

EnderIO Glass compatibility

xenoflot opened this issue ยท 19 comments

commented

Hi,

Not sure whether this is something for you or for Crazypants but I've found that with C&B ver 12.1 and EIO ver 3.0.1.95 (ECore 0.4.1.51b) I'm unable to chisel Ender IO's glass. It would be nice to be able to do so.

Discovered tonight that we can make dual texture blocks. So much love! Thank you for a great mod!

commented

Perfect, thank you.

commented

And Botania's mana/alfglass!

commented

If you want to chisel someone else blocks please ask them to mark it as compatible,

I don't manage a white-list of blocks, and glass normally doesn't meet the requirements that C&B uses to auto-detect compatibility, for glass they have two options,

either they can return true for isFullBlock, which in my testing seems to work fine for glass.

Or they can send an IMC to C&B to tell C&B that the block can be chiseled, Example:
https://github.com/SlimeKnights/TinkersConstruct/blob/0076db29be2ad1c8ec84989e86866d1b738a1542/src/main/java/slimeknights/tconstruct/plugin/ChiselAndBits.java#L32

commented

I tried it with the IMC. Sadly our glass's textures aren't picked up correctly:

2017-01-13_18 37 05

That is the item (update: correct) texture with the transparency missing on the south side, no texture on the other sides, and it is detected as solid. So, any ideas how to tell c&b what the correct texture and tint values are "manually"? It isn't that hard for our glasses, there are only 2 textures and 16 tints...

(update: the texture is the right one, I forgot that we only render the borders and to save texturemap space we re-use the item texture. That'd be easy for me to change.)

PS: Also, the Reinforced Obsidian block isn't picked up quite correctly:

2017-01-13_18 52 56

The up and down sides are flat colored instead of textured and the texture of the other 4 sides is mirrored. Again, anything I can to to help c&b pick up the block correctly?

commented

C&B detects the textures from the sides, if there are multiple textures in play per side, or if it cannot find the model for the state it will likely be confused. As long as the block renders normally with just the standard state from the world and its a simple cube it should be fine.

I assume that this is not the case?

commented

No. The glasses are a complex connected model and the "world state" is just a dummy that holds the smart model that computes the real quads by combining the json models from the other 26 (or so) blockstates as needed.

The obdisian has a complex json model, but it's just one model with no special states and just one texture.

commented

I guess I'll have to find some time to look into it the code has worked pretty well so far, but I don't have much else to offer except for "it might be too complex" but you say its not.

And as for detecting transparency, I've never seen it fail at that, I don't know why it would be rendering glass as opaque.

commented

It might be easiest if I could IMC you a texture for all sides, so you don't need to guess. And about the opaqueness, um, one variant is dark glass, but that shouldn't effect that. What are you calling to find out? Maybe it's failing on my side because some blockstate/world data is missing from the parameters? In that case, it'd be easy for me to change the "failure case answer"...

I'm actually a bit more concerned for the obsidian (honestly, why c&b a glass block that is 99% clear?). I may have a different texture rotation than expected because I made a complex model of one face and use it with rotations for all sides. Now, how to communicate that to c&b...

commented

canRenderInLayer(state,layer) is used to determine what layer to render the faces in.

As for an IMC for textures, maybe if there is a reason, I'd prefer if the calculations worked, and based on what you said, theres no reason it shouldn't.

commented

canRenderInLayer(), oh that explains that part. Our glass renders in layer SOLID because we only render the frame, so we don't need any transparency...

commented

Yeah.. I suppose that would do it, CUTOUT might solve the issue?

commented

yeah, no reason not to go to CUTOUT. Combine that with a new texture that actually is blank in the center, and we have solved half of the problems. That leave the fact that the only texture that is picked up is SOUTH...

commented

Yeah, it might be related to the issue with the obsidian as well, That part I'll have to look into.

commented

Yes, setting CUTOUT solves the transparency and opacity problems. BUT, colored fused quartz (which looked just like the normal one but tinted correctly before) now is invisible:

CUTOUT:
2017-01-13_20 04 31

SOLID:
2017-01-13_20 07 30

commented

Looking at the data as its based to C&B seems to indicate that the UV's at the corners reflect some unusual usage, it looks like some of the corners are using almost the same UV's either that or something else is confusing it greatly, threes a lot of faces involved and its hard to read the raw data.

However this is an example, each point is from a completely different face on the top of the model ( up facing )
X: 0 Z: 0 U: 0.9984379 V: 0.061813354
X: 1.0 Z: 0.0 U: 0.9984379 V: 0.061813354
X: 1.0 Z: 1.0 U: 0.9984379 V: 0.061813354
X: 0.0 Z: 1.0 U: 0.9984379 V: 0.061813354

Take note that every single U V matches, and each is a completely different corner, to me this sounds like the texture usage on the top of the Model is arbitrary, each face not reflecting its position on the model via the texture.

commented

Yes, that's because each of the 12 edges and 8 corners is one submodel. There are 5 models (north_up, north_west_up, north_west, north_west_down, north_down), these are rotated around y to get all 20 variants edges and corners. Those edges and corners are then then combined in code depending on the connections to its neighbors. (You can see that better on the reservoir which uses the same code but has solid edges, not those L-shaped ones.)

So on the top and bottom you get the same one edge and one corner with the same piece of texture in 4 rotations.

(for reference: https://github.com/SleepyTrousers/EnderIO/blob/1.10/resources/assets/enderio/blockstates/blockFusedQuartz.json )

commented

Well that explains the issue, it thinks that the entire top consists of a single pixel, thus the grey. This probobly requires some kind of override to get around, since the source model doesn't make much sense to C&B.

commented

um, were you talking about the obsidian? I was talking about the glass, where all sides but the south one are empty.

But obsidian isn't that different. a side model rotated 4 times and 1 top/bottom model rotated into 2 positions. It's just much more static.

commented

I was talking about obsidian yes. I seemed to have removed that fact in my edit by accident. I haven't had time to test the glass yet, I needed to look up the ids to white list them. So I could check.