Cobblestone Wall: incorrect block detection for "up"

Please do not mark unreleased versions as affected.
You don't have access to them yet.

--- I am a robot. This action was performed automatically.

Do not understand your issue. The block state up:true of the cobblestone wall is set at every corner (see screenshot)

That is how it works right now, it's all ok 😃

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.

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.

The ticket is assigned to Grum, he probably gets an email for every one of our comments, so consider him notified. However, the current behavior is working as intended, so I don't know what else he could have to add.

The code says (and it is correct):

final boolean north = connectsTo(level, pos.north());
        final boolean east = connectsTo(level, pos.east());
        final boolean south = connectsTo(level, pos.south());
        final boolean west = connectsTo(level, pos.west());
        final boolean straight = (north && !east && south && !west) || (!north && east && !south && west);

        return state
            .setValue(UP, !straight || !level.isEmptyBlock(pos.above()))
            .setValue(NORTH, north)
            .setValue(EAST, east)
            .setValue(SOUTH, south)
            .setValue(WEST, west);

It probably should be renamed to 'pole' but that is how it works now.

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.

In case you aren't aware: || is logical OR, not logical AND. Cobblestone walls are poles/point up if either of the conditions are met: There's a non-air block above it or it's not a straight piece.

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