impossible to place mushroom stems next to each other with the builder process

[Redhawk18]

How to reproduce

place 3 mushroom stem next to each other, each one will have different nbt tags. Baritone sees the directional nbt tags and tries to find the exact block that matches it. However a mushroom_stem isn't counter as a mushroom_stem[north=false]

This has to be a problem in the builder process somewhere, I'm not that familiar with it but I wouldn't mind trying to tackle this.

[ZacSharp]

The easy solution: #buildIgnoreProperties north,south,west,east,up,down

This has to be a problem in the builder process somewhere, I'm not that familiar with it but I wouldn't mind trying to tackle this.

Baritone uses Minecrafts placement logic to predict what will be placed and if the resulting state doesn't match the required state it won't place. There is no place where it anticipates state changes (e.g. due to placing the next stem) so I guess that's the part you would need to change. (Also the way approxPlaceable is used doesn't play well with directional / locational blocks)

[Redhawk18]

The easy solution: #buildIgnoreProperties north,south,west,east,up,down

This has to be a problem in the builder process somewhere, I'm not that familiar with it but I wouldn't mind trying to tackle this.

Baritone uses Minecrafts placement logic to predict what will be placed and if the resulting state doesn't match the required state it won't place. There is no place where it anticipates state changes (e.g. due to placing the next stem) so I guess that's the part you would need to change. (Also the way approxPlaceable is used doesn't play well with directional / locational blocks)

it feels like bad practice, but ignore those blockstates for only mushroom stems would seem to fix the problem. Also making it easier to support new blocks that act similar with "impossible" states baritone cannot place.

[Ali90922]

Baritone's having a rough time with those mushroom stems and their different NBT tags, huh? It's messing up the whole direction thing. Sure, ignoring some block properties might patch things up for now, but we gotta get down to the nitty-gritty and find a real fix

[ZacSharp]

it feels like bad practice, but ignore those blockstates for only mushroom stems would seem to fix the problem

Yeah, when I made the setting I considered making it per-block but since I didn't anticipate how useful it would be I thought it would be "overkill". Changing buildIgnoreProperties per block in a backwards incompatible manner is easy, as is adding a new setting. Do you think once there is a per-block setting there will be much use for the current buildIgnoreProperties?

@Ali90922 if you don't even know the problem, can you please not tell others to fix it? (mushroom stems have no nbt attached to them)

[ZacSharp]

Hardcoding some cases like "ignore north for mushroom_stem if there will be a block north of it" would also be a simple short term solution, but I don't like it at all. Currently validity checking is almost completely independent of the rest of the builder and this simple fix would add a weird edge case to accommodate a quirk in other parts of the implementation.
(the only thing you could currently consider an entanglement is the itemCheck parameter switching between "valid to keep there" and "valid to place there")

[Redhawk18]

Hardcoding some cases like "ignore north for mushroom_stem if there will be a block north of it" would also be a simple short term solution, but I don't like it at all. Currently validity checking is almost completely independent of the rest of the builder and this simple fix would add a weird edge case to accommodate a quirk in other parts of the implementation. (the only thing you could currently consider an entanglement is the itemCheck parameter switching between "valid to keep there" and "valid to place there")

could you expand on this?

[ZacSharp]

It's just further narrowing down the cases in which the property is ignored and having the behavior hardcoded rather than as a default configuration value.

[Redhawk18]

It's just further narrowing down the cases in which the property is ignored and having the behavior hardcoded rather than as a default configuration value.

oh like manually doing the checks minecraft currently does for mushroom stems and blocks but with the selection or schematic baritone has load?

[ZacSharp]

oh like manually doing the checks minecraft currently does for mushroom stems and blocks but with the selection or schematic baritone has load?

Sort of? The intention would be checking whether the state will be corrected by placing the surrounding blocks and that's pretty similar.
Also I still don't think this is a good idea.

[Redhawk18]

recently I was trying to use baritone to build redstone and i found that I have the same issue here, a lot of the blocks blockstate are powered in the schematic but no redstone besides power sources are powered when place by themselves. Another use for this idea