draconicus

Okay, so it's a globally inclusive statement. Anything that is not straight triggers it. Gotcha.

Well thank you very much for showing me that code, Grum.

I'm a little surprised though. It looks like "UP" is now the "unless it's straight" choice.
I find it most interesting that it specifically is set ONLY when "!level.isEmptyBlock(pos.above()))", as in "isEmptyBlock" (air/null block), is NOT true.

If I'm interpreting that correctly, the following conditions make it a pole:

1. It's NOT "true" for boolean "straight". (not a straight segment N/S or E/W segment of wall)
2. The "pos.above()" block (block above neutral/~0 point) in the chunk/level data does NOT match the definition of "isEmptyBlock". (the block above is NOT empty)

So how, exactly, does the pole show up in situations where the empty block is true, as in "level.isEmptyBlock(pos.above()))"?
I'm not 100% familiar with the syntax, but I suspect that would be:

.setValue(UP, !straight || level.isEmptyBlock(pos.above()))

This seems more likely also because putting a non-empty block above the "straight" segment adds a pole.

How are "air" tiles handled these days? Would "isEmptyBlock" match for "air" or only "null"? I think "null" tiles don't exist in the chunk format, so "isEmptyBlock" must mean "minecraft:air". We know it can't mean "any transparent block" because things like glass and vines also trigger the pole.

I greatly respect your position on the matter, and your cooperation in helping me understand has been wonderful.
It would be a clearer picture for me if I also understood the criteria for "isEmptyBlock".

EDIT: I understand that || may be a way to invert two booleans to match two true conditions. Even so, nothing accounts for a stand-alone pole in the code provided.

redstonehelper: It's notable that any block above activated the "up" attribute previously. I would suggest consulting with person who first implemented these models to get clarification about the intended context. It seems consistent with context used for stairs and other neighbor-dependent objects.

You can see the problem I'm having with my resource pack as a result of this change. Any suggestions? I'm not willing to give up on the design.

Mustek, redstonehelper: Please tell me what "up" was supposed to mean in 1.8.x.

I suppose it would be appropriate to rename it to "has a pole" or something then.

Previously it was possible for "up" to be false while "west" and "east were true.

My resource pack (and others I've seen) will depend on being able to control models based on whether or not "up" is true without compromising on other directions.

This feels very much like a regression to an older format. In pre-1.8 implementation, an early version of the cobblestone wall model could not support unique "up" variants on corners.

To be clear: This is NOT a bug report about model implementation.
This is all about detecting neighboring blocks and correctly identifying those neighbors in block data.

Kumasasa, each screenshot is showing a different version of the game with the same condition.

Grum, I appreciate your response. I'm afraid I don't understand what you mean.

The neighboring-block attribute called "up" refers to having a block above, yes?
Why is it being flagged under the described conditions, with no block above?

If this issue exists, I also worry about texture culling on north/south sides of other blocks.