buildSkipBlock - a Schematic block that says, I do not care what is in the world -- Ullage for Schematics

[HoratioGamer]

Describe your suggestion

buildIgnoreBlocks and buildIgnoreExisting do the opposite of what I am suggesting. They ignore blocks in the world that do not match what is in the schematic.

I want the opposite, I want to pre-process the blocks in the schematic, interpret the blocks in the schematic. I want to add a new concept, that a particular block in the schematic tells baritone not to change anything in the world. I do not want that to be a fixed block like Air. I want it to be a settable block. When this block is found in the schematic, baritone should take no action, baritone should say, I do not care what is in the world, it is OK as it is, do not try to change the world at that point. I call this the I-do-not-care variable. Usage would be:

I-do-not-care [{block_ID}/clear]

Usage to see what the I-do-not-care block is set to.

I-do-not-care

Usage to set the I-do-not-care block to be sand

I-do-not-care sand

Usage to clear the previous definition of the I-do-not-care block so Baritone returns to interpreting schematics literally.

I-do-not-care clear

When a designer intends a schematic to use an I-do-not-care block they must choose the block at design time, and communicate this choice to users of the schematic. The author of the schematic might save the name of the schematic to signal to the user what to set the I-do-not-care block should be:

My_favorite_schematic_IDC_Sand.schematic

There are so many blocks available in Minecraft that it is possible to choose any buildable block that does not appear in the intended build of the schematic. So say I want sand to be my I-do-not-care block. I can save the schematic, and use the schematic without the I-do-not-care-block set, and I see the oak planks being built -- this allows me to see what is in schematic. Then I set

I-do-not-care sand

and I build the schematic again -- this time not only does it not build the sand, it does not do anything at the locations that there were sand in the schematic.

At run time, the user would know they are using a schematic with an IDC block, and they would have to set the I-do-not-care block variable appropriately before running the schematic.

The use I would put IDC blocks to is, when I want to build a schematic box to enclose a large structure, where part of the structure contains Air, I can fill the portion of the box that I do not really care about with IDC blocks. It means I can create schematics that are effectively not right-prisms. It means I can build triangles or pyramid-shaped schematics, and that part of the shape that is not used in the bounding-prism box is just filled with IDC blocks. This would allow me to make effectively non-prismatic schematics with any current design tool for creating schematics.

For instance, but certainly not limited to this use, when I am building highways in 2b2t, on axis-aligned highways, I make my schematics 6 blocks long in the highway direction. An axis-aligned highway is a right-cylinder. I only need to define its shape in a right-cross-section, which for minecraft, is a one-block-wide slice across the highway. Unfortunately, one experiences glitches where blocks are laid and then disappear. Baritone's behavior is to re-place blocks in the current schematic image that are no longer present, however, if one uses #buildrepeat, when the Baritone advances by the increment, when blocks from the last lay of the schematic, that are not in this lay of the schematic disappear, they stay as a defect after the passage of Baritone. HighwayTools (the KAMI/Blue module) uses 2-block wide schematics, and under some conditions will leave glitches behind. With a 6-block long schematic, every block is in 5 consecutive advances of the schematic... In practice, only the blocks on the leading edge of the schematic are laid in a given cycle. If there are no glitches, there is no need to re-place any blocks. As glitches appear later and later, they may be replaced in one of the 5 previous lays. This is a solved problem -- glitch-free axis-aligned highways -- just make the schematics longer than they have to be.

This does not solve the problem for any highway at any angle where one does not want to determine what appears in certain blocks in the schematic -- if one does not have the use of IDC blocks. Without IDC blocks, there is no way to have an entirely overlapping schematic that advances with buildrepeat 1,0,1 for instance without including a lot of other blocks that either Baritone must place sometimes or must remove sometimes. When the schematic is limited only to blocks that must be determined, the blocks in the wing columns of the schematic only appear in one lay of the schematic as it advances along the other diagonal. With the presence of glitches, there are a lot of blocks not proper in these wing columns after the pass of baritone. The problem can be solved by enlarging the bounding prism to contain multiple appearances of all blocks in every column but then the wings of the prism extend into spaces we really do not care what is there. No strict interpretation of the schematic will solve this problem.

I could set a schematic for a large underground installation, and set only wall skins blocks and the contained Air blocks to be the desired block in the schematic... all the space between rooms and between tiers could be made IDC blocks, and then, if I base my schematic on a save from a world, and try to build it again at a different part of the world, Baritone is not trying to rebuild the random mineral deposits that might have appeared between rooms or between tiers in the original schematic. Anyone who has tried to make a schematic from an existing underground build has encountered this problem. One would be able to make standardized secret entrances (useful in Vanilla minecraft for sure) where all elements needed in some odd geometry are specified, but all unimportant parts of the bounding box are IDC blocks.

Freeing Schematics from the Strictly-Duplicated Right-Prism Prison is what IDC blocks are about.

As a further extension, I propose a second variable, As-long-as-it-is -- the full sentence would be I-do-not-care As-long-as-it-is (one of a list):

Usage:

As-long-as-it-is [{list of block_IDs}/clear]

Usage to list the list of blocks that Baritone will apply IDC filtering to:

As-long-as-it-is

Usage to set the list of blocks that Baritone will apply IDC filtering to:

As-long-as-it-is Air Obsidian

If the IDC block maps to a place in the world that is Air or Obsidian, do nothing.

Usage to clear the list of blocks that Baritone will apply IDC filtering to:

As-long-as-it-is clear

The behaviour would be, if

I-do-not-care sand

As-long-as-it-is Air Obsidian

If the place in the world that sand maps to is Air or Obsidian do nothing. In the case that the location in the world is neither Air nor Obsidian the IDC algorithm does care and makes the block the first element of the #As-long-as-it-is list, in this case Air.

I would use this particular feature for, but not limited to, when I want to dig an area in preparation to laying Obsidian. If there is Obsidian in the schematic, and I do not have any, Baritone will fail. If there is no Obsidian in the schematic and Obsidian is encountered in the world, Baritone will spend a lot of time mining it.

With IDC variable, set to sand, I can just put sand in the schematic where I might eventually want to put Obsidian, and then say #As-long-as-it-is Air Obsidian -- Baritone would clear away any blocks which are not Obsidian. I could use the build schematic, but set the IDC variable to Obsidian and the #As-long-as-it-is Air Obsidian, and get the same effect.

Therefore:

As-long-as-it-is Air Obsidian

is different from:

As-long-as-it-is Obsidian Air

In the first case, the world gets more air for non-matching blocks, in the second more obsidian.

This cannot be done by buildIgnoreBlocks and buildIgnoreExisting because those interpret the schematic literally and then perform judgements on the world, and only with Air either in the schematic or in the world:

buildIgnoreBlocks
public final Settings.Setting<java.util.List<net.minecraft.block.Block>> buildIgnoreBlocks
A list of blocks to be treated as if they're air.
If a schematic asks for air at a certain position, and that position currently contains a block on this list, it will be treated as correct.

buildIgnoreExisting
public final Settings.Setting<java.lang.Boolean> buildIgnoreExisting
If this is true, the builder will treat all non-air blocks as correct. It will only place new blocks.

To do what I want to do, one has to interpret the schematic with a filter, and apply it to the world, regardless of what is in the world at that location, or only if the world does not contain certain blocks.

[HoratioGamer]

So then, winding back to your original question:

Do you think there would be use for an additional setting that just changes which blocks are valid (the same as the above but without placing)?

I guess the answer is no. That leaves:

Next I want to do a setting to replace blocks with other blocks, e.g. for your long highway you could use namePending obsidian->obsidian,air,cobblestone->cobblestone,stone,netherrack,dirt to make the obsidian optional (it prefers blocks in the order they are listed in) and place some more blocks than just cobble where the schematic wants cobble.

That would meet all the needs I can anticipate.

Just to be clear, I could also say

set namePending Oak_Planks*->Obsidian,Air

And that would implement the as-long-as-it-is functionality completely separately from buildSkipBlocks, which now is just a not-in-the-schematic marker.

This would allow me to do schematics that can do two different things at once -- one of the observations you had before, that I could only use i-do-not-care-blocks for one of the several applications at a time. With this I could do two. What incredible flexibility that would provide.

* Edit: This will not work because oak_planks is not a valid designation. Only "planks" works, and then Baritone will not distinguish between planks in a schematic.
https://github.com/cabaletta/baritone/issues/2323#issuecomment-774129439

[ZacSharp]

I think I found a rare use myself: when building something like a base partially intersecting with rocks you want it to leave the andesite where your schematic contains stone but obviously it shouldn't build the stone statue in the backyard out of andesite.

For buildSubstitutes (yes, named it) I ran into a little issue: I want it to prioritize placing the first blocks on the list but at the same time don't want it to break already placed correct blocks that are further behind. When just checking if the current block is on the list it obviously doesn't place anything if air is a substitute, but when first checking placeables and then the current block it will break correct blocks in order to replace them with higher priority blocks. I guess the answer is accepting every correct block except air before checking placeables and then check if it is air and air is correct.

[HoratioGamer]

if (schematic block==buildSubstitutes.block_id) {
   if (world block in buildSubstitutes.list) {  skip this block like it is not part of the schematic; }

   set no_stock = 1;
   foreach {substitute in buildSubstitutes.list} {
      if {substitute == Air} {
        set desired world block = substitute; 
        set no_stock = 0;  
        break; 
      }
      if {substitute present in hotbar (inventory)} { 
        set desired world block = substitute; 
        set no_stock = 0;  
        break; 
      }
   }
   if {no_stock==1} { 
     throw baritone error "Unable to do, no stock of buildSubstitutes.list"
   }
} 

Put that right beside

if {schematic block == buildSkipBlock} { skip this block like it is not part of the schematic; }

and right before

make world block = desired world block

It seems everywhere you have put buildSkipBlocks code, is a place to put buildSubstitutes code too.

If buildSubstitutes was intended to be a list of elements of block_id->Sub1,sub2,sub3, describing multiple substitutes, then you would have to wrap the entire thing in another foreach substitute in buildSubstitutes.

[ZacSharp]

It seems everywhere you have put buildSkipBlocks code, is a place to put buildSubstitutes code too.

Sadly only when dealing with logic based pseudocode. In reality it is a little more complex.

I'll quickly push what I used to get this and go to bed

buildSkipBlocks sand buildSubstitutes obsidian->obsidian,air,stone,stone,cobblestone,dirt,netherrackLittle tip (didn't try it myself yet, but I guess it will work): when doing the 2-task schematic, make the first one or two advances paving-only, so it has to place the road bed before the obsidian. Otherwise it will sometimes place the obsidian first and have a hard time reaching below if it's over water.

[ZacSharp]

It's pushed. Tomorrow I'll try to preserve block properties when changing their type (e.g. preserve rotation when changing stair type) and allowing one to substitute specific blockstates only (e.g. flip all stairs upside down), don't know if I can do that though.

[HoratioGamer]

What you say is true, the orientation of things is a twist that is not included in my code, and in this case is not something that concerns me, however, in a different case, it came down to orientation here:

https://github.com/cabaletta/baritone/issues/2039

So, I understand, in other cases, I might find it important, and others might.

Thank you Zac

[ZacSharp]

I definetly won't add the possibility to specify blockstates instead of blocks in the near future because that would require more complex parsers (blockstate string representation contains ",", so list and mapping can't simply split at "," anymore). Preserving block properties when changing the block is still on my list, though. It is limited to SubstituteSchematic.

2039 seems to be a little more difficult, unless there are no performance constraints for builder pathing (then I can simply do the blockstate prediction when checking if a block is inside the goal).

Nothing to thank for.

[HoratioGamer]

I have tested the second build a little more with the 5-advance diagonal schematic. I ran it down a tunnel that was already mainly dug, with a single-advance schematic. The schematic with buildSkipBlocks cleaned up all the glitches, but it did something odd. Ever few hundred blocks while it was running down a reasonably glitch-free section of highway, like 1024 and 512 exactly once each, but then other numbers that were not so obviously binary, baritone paused and was highlighting a path of blocks into the wall, and just stood still. It would then start moving again and continue cleaning up the glitches. I never noticed this when it was advancing slowly into the dig face. No other misbehaviour, but, I have not challenged it with an odd environment yet.

I have made the orthogonal diagonal schematic. Tomorrow I try it on another highway.

[ZacSharp]

What you described fits my observations. For me, when running to blocks out of render distance, it sometimes failed because it had no materials for the buildSkipBlock (sand in my case), which obviously shouldn't happen. I think what you saw is the same bug, but it somehow corrected itself fast enough to not fail. The spots where it fails were all out of render distance when it started walking to them, right?

[ZacSharp]

I managed to get some simple property copying (doesn't even work when target and source property have different possible values e.g. torch and end_rod) and noticed it is bad for highway building because stone, diorite, andesite and granite are all minecraft:stone, so Baritone can't build the variants when the variant property is preserved to be stone from the schematic.

[HoratioGamer]

The spots where it fails were all out of render distance when it started walking to them, right?

I will pay more close attention this time.

UPDATE: I have not observed it again. It could be as you say, a render distance thing. My seeing it at binary numbers, might just arise from chunks being 16 blocks wide -- it appeared in the chunk just outside render distance. This only caused a pause in the second tests, and, has not been observed while digging in the 3rd tests.

My second buildSkipBlocks schematic has worked perfectly in my 3rd round of testing. Again, my schematic only includes netherrack, air and sand -- the environment only netherrack, air, fire, lava, nether quartz and glowstone. It has not been severely tested. I should take my schematic to a desert with a shovel and see if it screws up with sand in the schematic and sand in the world.

[HoratioGamer]

Is there a buildSubstitutes modification I can try ? And if so, what do I give as the git command to get both the buildSkipblocks and buildSubstitutes code at the same time ?

$ git checkout buildSkipBlocks buildSubstitutes ????

or ?

And finally, what is the command line syntax for buildSubstitutes, and can you give an example of substituting Oak_planks to be Obsidian or Air ?

[ZacSharp]

I pushed the buildSubstitutes to the buildSkipBlocks branch, so if your branch is up-to-date you already have them (if not do git pull) The syntax is key->value,value,value,key->value,value,value,value,key->value,value, so basically everything before a -> is a key and the rest is comma separated values. For you example that would be #buildSubstitutes oak_planks->obsidian,air.

[HoratioGamer]

I have re-built baritone with both buildSubstitutes and buildSkipBlocks and will be testing schematics with those today.

When I copy and paste the text you have above:

oak_planks->obsidian,air

I can see it has no spaces, whereas the rendering in the code formatting makes it look like there are spaces after the commas ...

oak_planks->obsidian,air

Is it important there are no spaces ?

[5HT2]

doesn't look like spaces to me

[HoratioGamer]

Google "kerning around commas". The render I see, it is either a lot of kerning and no space, or a reduced-sized space and no kerning. I illustrated the difference with my post.

The point is, I have had a lot of people ask me, is there a space there in some baritone commands, so when there are spaces, I put in a lot to be sure they see spaces, so there are simply no questions.

build my.schematic    ~    118    ~

Well, again the render of github has betrayed me.... I had to put   to make that look right.

When there are no spaces, I ask if it is important. In retrospect if I had really understood this:

I can't use spaces because Baritone's command system uses them to split arguments and settings only accept one argument (that's why lists like acceptableThrowawayItems use "," and not ", " as a seperator)

I would have had my answer despite the ambiguity of the rendering.

Update on testing.... (still authoring)

So I have to report my first problems in making this work. I created the schematic pictured below. The intent was to use:

#set buildSkipBlocks Sand #set buildSubstitutes obsidian->obsidian,air

#cancel #build My_OA.schematic    ~-7    118    ~

where _OA means designed for use with Obsidian or Air. I forgot to run the #set buildSubstitutes command the first time, so the schematic was calling for obsidian for sure, and the schematic just did nothing. There was no warning about unable to do, nothing about not having the obsidian blocks needed, nothing. I ran my regular schematic that just uses the sand, and it ran. Then I realized that I had not set the buildSubstitutes variable, so, I did that as above and repeated the build....

(Note the torches above are not part of the schematic, they were added after for the screenshot.) Again, it did nothing:

Then I went back to my regular buildSkipBlocks schematic, it is working fine. So, I am not sure of the proper response when I try to build a schematic for which I do not have all the needed blocks at the first invocation, but I seem to remember when it has run properly, then you run out, it does give a message. When I did the buildSubstitutes, nothing changed -- it should have taken air as an acceptable substitute for the obsidian in the schematic above and done it as though there was no obsidian in the schematic. Like this:

It did not. There were no warnings, no comments nothing I can give you to help diagnose what is going on here. buildSubstitutes did not seem to function.

[ZacSharp]

You could give me the schematics so I can try reproducing it myself. And if you want I can create a branch with the new builder settings and #2357, so you know what (and if?) blocks are missing when it fails. Wouldn't help when it just stalls though.

[HoratioGamer]

Sure

PMDB_Sand5_OA_zm7.zip PMDB_Sand5_zm7.zip

Just rename them from .zip to .schematic.

Not that it is important, but the filename format I am using:

• PlusMinus heading,
• it is primarily a Digging schematic which automatically Bridges chasms
• Sand is the buildSkipBlocks,
• it covers 5 advances,
• z = ~-7 is the offset when facing +-, which means the offset is x = ~-7 when facing -+,
• where offset means, if you stand in the center of the highway this is the offset to make the schematic center on the center of the highway also
• _OA means Obsidian or Air ==> #buildSubstitutes obsidian->obsidian,air

Can you give me the commands to make a new branch for #2357 ?

[ZacSharp]

if you wanna do it yourself, here you go:

1. git checkout buildSkipBlocks
2. git branch 'whatevernameyouwant'
3. git merge builderMaterialLogging
4. hope to not get conflicts / resolve them if they appear you are working in a clone of my repo, so there's nothing to do to get the branches

[HoratioGamer]

$ git checkout buildSkipBlocks Already on 'buildSkipBlocks' Your branch is up to date with 'origin/buildSkipBlocks'.

$ git branch 'Horatio_Gamer_Test'

$ git merge builderMaterialLogging merge: builderMaterialLogging - not something we can merge

Did you mean this? U

???? very gitty.

[ZacSharp]

maybe try to checkout builderMaterialLogging once before doing it

[HoratioGamer]

$ git checkout builderMaterialLogging Branch 'builderMaterialLogging' set up to track remote branch 'builderMaterialLogging' from 'origin'. Switched to a new branch 'builderMaterialLogging'

$ git branch 'Horatio_Gamer_Test' fatal: A branch named 'Horatio_Gamer_Test' already exists.

$ git merge builderMaterialLogging Already up to date.

$ ./gradlew

$ mv baritone-standalone-forge-1.2.14.jar baritone-standalone-forge-1.2.14_HG4.jar

I will load it up before my next session.

[ZacSharp]

uh, when you have run git branch Horatio_Gamer_Test once that branch already exists and you can check it out like any other branch

[HoratioGamer]

I have no precise idea what these commands do so, I am am just following instructions. Does this mean what I did will work -- _HG4 is viable for a test, or that it will not work, and I have to do it a different way ? With the queue to get into 2b2t, I ask instead trial and error.

[ZacSharp]

Imma make the branch myself

[ZacSharp]

Pushed it it's git checkout horatioTesting or if that doesn't work git fetch git checkout horatioTesting (I think)

[HoratioGamer]

I just want to underline what a huge contribution buildSkipBlocks has been to the use of schematics for making highways in 2b2t. This is just one of the applications of using a schematic that does not completely fill a box. For illustration, this is what a single-advance schematic for baritone leaves behind when the server conditions are poor -- there should be a wide clear path down the middle.

Even though I have only been testing version 2 and 3 of the buildSkipBlocks code, and the 5-advance schematic I am using is likely overkill, it has completely erased this problem with no loss of Baritone performance. For comparison, this is what buildSkipBlocks leaves behind in identical server conditions (two different accounts digging on 2b2t at the same time using different mods for comparison):

Night and day, with the addition of a few lines of code.

[ZacSharp]

I can confirm it targets skipped blocks outside render distance. I'm now thinking about whether I try to add a check to every spot were the content of the schematic is accessed without calling valid() or turn buildSkipBlocks into a wrapper schematic like buildSubstitutes and mapArtMode.

However I did not get any wrong behaviour with buildSubstitutes (it placed obsidian as long as possible and then continued without) and the only occasions where it stalled (eternal pathing) were when it could not reach a block, which is nothing new.

To prevent it from placing the obsidian before the netherrack without it breaking already present obsidian I successfully used a schematic where the first advance had gravel instead of obsidian with buildValidSubstitutes gravel->obsidian,air.

[HoratioGamer]

Sorry for being slow, I will be re-testing buildSubstitutes with the new build tonight.

About the render distance thing... is it not possible to just put a limit of how far away from the current position it checks ? I hate to say, make another variable ... I do not see how one will make the code happy to play on an art/show-piece server with really big baritone builds with a render distance of 16+ say, and 2b2t with a render distance of 6, and at the same time avoid the build function examining things outside render distance unless there is an adjustable limit beyond which it will not check. A buildCheckDistance variable? If > buildCheckDistance --> skip. If the schematic is contiguous (with build skip blocks, a schematic no longer needs to be contiguous), then in building some closer bit of the schematic, the previously skipped part is now within render distance. An example of a non-contiguous schematic I converted over from a 3d design file, a Colossus of Rhodes, broken off at the knees, reportedly like the original, to decorate a coastal city's harbor:

[ZacSharp]

The problem is my new code, not what was already there. Baritone automatically marks blocks out of render distance as invalid (if they aren't known to be correct) and that's why it walks there at all. If I were to restrict the scanning radius around the player, even things like repairing a highway with nothing to do for one scan radius would break.

It does scan within builderTickScanRadius blocks every tick and does a full scan if there's nothing invalid it knows of, but if you have a lot of skipped blocks, they might be to far away for baritone to rescan them before breaking blocks to get there. So I have to prevent it from marking them as invalid.

[HoratioGamer]

OK, so the question is, is the scan done frequently, or just once ? If it is done frequently, nothing will break if out of range blocks are scanned when they come in range on a subsequent scan. With the road schematics, something is happening where baritone is getting far ahead of the player's location. The schematic itself is small. There is nothing wrong with keeping baritone from buildrepeating too far ahead of the player. It just means it will scan again later.

[HoratioGamer]

Success (mostly) buildSubstitutes is tested functional ! In total 4 tests were done. The first was a small test, just 40ish blocks of highway, but this was done with just one schematic using buildSubstitutes of obsidian->obsidian,air. It laid obsidian until it ran out, and then just dug which is the exactly correct behaviour. It switched over seamlessly, no hesitation whatsoever.

An important part of buildSubstitutes is that when it comes upon an acceptable block from the list of substitutes already existing in a correct position in the world, it is OK with that block and does nothing. The road building application of this is, when tunneling, and one comes upon obsidian that is correctly placed for the eventual road, it does nothing with it. This is very important because separate Dig or Pave schematics will do something undesired -- Dig schematics that need there to be Air at that location will uselessly mine out correctly placed Obsidian. Pave schematics will simply not dig if there is no obsidian in inventory. buildSubstitutes allows one schematic to both Dig and Pave, and revert to just digging when it runs out of obsidian, and when digging, never mines out correctly placed obsidian.

This is an essential feature of buildSubstitutes when using any schematic underground to ignore all of the variance that might be there, so long as the block is one of a select list of competent blocks. It would be important in making a grading schematic that makes railways and their beds in the overworld. On the subject of railway schematics, I envision two.... one is a tunnel and berm schematic, that makes a wide-base trapezoid cross-section berm under the rails when going through low areas, and an arched tunnel shape when going through hills. The second schematic would make instead a classic stone railway viaduct bridge with a repeated series of arches. The buildSubstitutes would make arches as tall as needed only to replace Air and incompetent blocks, sinking pillars to stone. It would leave Air around the bridge and in the vaults of the arches where it already exists -- two schematics to make the railway line seen in the first Harry Potter movie, or recreate some famous railway line. A long list of buildSubstitutes would make it possible to do landscaping on the slopes, among other things. buildSubstitutes has a lot of potential in any ground-engagement schematic. I am really excited about the potential of buildSubstitutes outside of building nether highways in 2b2t.

So I tested it by putting correctly placed obsidian in the road ahead. buildSubstitutes correctly did that too:

Here comes the mostly part. Unfortunately, the schematic refused to start running, unless one had a little obsidian on the hot bar. The picture above is from the second attempt. It did not start the first time because I had no obsidian. I put a little obsidian on the hotbar, it started up OK and once it was running, then when it ran out, it was OK it tunneled, and then when it found obsidian already laid ahead, but in the correct position for the eventual road, it just left it there and continued. 2 out of 3 ain't bad ! When I went to get a screenshot of it failing again, it did not fail... it started properly despite having no obsidian.

Finally, here is the schematic I was using:

I was using these settings:

;b set buildSkipBlocks sand
;b set buildSubstitutes obsidian->obsidian,air
;b buildrepeat 1,0,1
;b build PPDB_Sand5_OA.schematic ~ 118 ~

And this is the schematic, just rename it from .zip to .schematic:

PPDB_Sand5_OA.zip

Now, the remaining misbehaviours, buildSubstitutes not starting without some obsidian in the hotbar, and the tendency for buildSkipBlocks to pause to think about blocks that were originally outside render distance, these are not show-stoppers, so long as they are documented. The buildSubstitutes not starting could be very confusing to baritone users when there is buildSubstitutes set from the last session, and users forget, and they load up a schematic that is not intended to use buildSubstitutes, because even with the builderMaterialLogging set up, it did not give an explanation for why it was not starting, it just sat there. Again, I was unable to get a screenshot of a failure to prove this but I did get a screenshot of when, inexplicably to me, it did it properly in the 4th test.

[HoratioGamer]

Here is an example of the first of two railway schematics that would utilize both buildSkipBlocks and buildSubstitutes

the settings would be, and standing on the intended rail bed:

;b set buildSkipBlocks sand
;b set buildSubstitutes oak_wood_planks->cobblestone,stone,granite,diorite,andesite,air,spruce_wood_planks->dirt,stone,granite,diorite,andesite,cobblestone->cobblestone,stone,granite,diorite,andesite,dirt,dirt->dirt,cobblestone,stone,granite,diorite,andesite,gravel->gravel,cobblestone,stone,granite,diorite,andesite *
;b buildrepeat 3,0,0
;b build RR3.schematic ~ ~-4 ~-5 

* Edit: This will not work because oak_wood_planks is not a valid designation. Only "planks" works, and then Baritone will not distinguish between planks in a schematic.
This will not work because granite, diorite and andesite are not valid specifiers here.
https://github.com/cabaletta/baritone/issues/2323#issuecomment-774129439

It builds berms with dirt sides that will grass-over in time when building in low areas, and will tunnel through hillsides. The order of appearance of dirt in the buildSubstitutes options lists is important -- we want to conserve dirt mined out to use it in the places were dirt is specified in the schematic -- to give grassy sides for our berm. This is the power of buildSubstitutes.

This would be the second schematic, to build a series of arches over ravines and oceans -- it is half-filled with sand so that one can see the structure that will be built, yet also see how sand fills the remainder of the bounding box. One would have to manually switch over from the tunneling and berming schematic to the bridging schematic:

;b set buildSkipBlocks sand
;b set buildSubstitutes stone->stone,cobblestone,granite,diorite,andesite,gravel->gravel,cobblestone,stone,granite,diorite,andesite *
;b buildrepeat 11,0,0
;b build RR_bridge11.schematic ~ ~-23 ~-2

* Edit: This will not work because granite, diorite and andesite are not valid specifiers here.
https://github.com/cabaletta/baritone/issues/2323#issuecomment-774129439

Neither schematic uses any orientable blocks to make it more architectural, or landscaped, like stairs or flowers, and the actual rails are omitted because they are orientable too, and baritone sometimes does not do well with orientable things.

[ZacSharp]

The behaviour when it walks to blocks outside render distance seems to be normal Baritone behaviour, as it occured with a cleararea schematic, repeated along a long cleared path, shows it as well. However I still did something against marking skipped blocks that are out of render distance as invalid (pushed to horatioTesting). I did not have any issues with it not starting without obsidian (had no obsidian during all tests) and I don't have any idea on why it might do nothing (not even eternal pathing) at all.

[HoratioGamer]

Ok, I have tested for the 4th time and now three times it started properly, only once did it seem to need obsidian... I will consider the first time might have been operator error and I will continue testing. In my next session I will update to the latest testing image.

[HoratioGamer]

When I did

$ git checkout horatioTesting

it did not say anything about downloading changed files from your git ?

At what stage would I see it downloading changed files ?

[ZacSharp]

The commands you might need for testing: git clone -> download repository, set it as remote "origin" and do some stuff making it easier to pull/push changes git checkout -> switch to a (local) branch, doesn't download anything git pull -> pull new commits from remote repo, that's were the downloads happen. git fetch -> download commits but don't do more, needed to checkout branches that only exist on the remote so far And the onthers I mentioned here: git branch -> new branch from current git merge -> merge a branch into the current branch

[HoratioGamer]

I got an error in the build, tried twice, decided to flush my directory and start over, still getting an error:

$ git clone https://github.com/ZacSharp/baritone.git

Cloning into 'baritone'... remote: Enumerating objects: 35755, done. remote: Total 35755 (delta 0), reused 0 (delta 0), pack-reused 35755 Receiving objects: 100% (35755/35755), 9.37 MiB | 1.74 MiB/s, done. Resolving deltas: 100% (19548/19548), done.

$ cd baritone

$ git checkout horatioTesting

Branch 'horatioTesting' set up to track remote branch 'horatioTesting' from 'origin'. Switched to a new branch 'horatioTesting'

$ ./gradlew build

Task :buildSrc:compileJava Note: /home/username/Desktop/Minecraft/Baritone/baritone/buildSrc/src/main/java/baritone/gradle/task/ProguardTask.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details.

FAILURE: Build failed with an exception.

• What went wrong: A problem occurred configuring root project 'baritone'.

  Could not resolve all artifacts for configuration ':classpath'. Could not resolve org.spongepowered:mixingradle:0.6-SNAPSHOT. Required by: project : Could not resolve org.spongepowered:mixingradle:0.6-SNAPSHOT. Unable to load Maven meta-data from http://repo.spongepowered.org/maven/org/spongepowered/mixingradle/0.6-SNAPSHOT/maven-metadata.xml. Could not HEAD 'http://repo.spongepowered.org/maven/org/spongepowered/mixingradle/0.6-SNAPSHOT/maven-metadata.xml'. Received status code 520 from server: Origin Error

• Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

• Get more help at https://help.gradle.org

BUILD FAILED in 1s

$

OK, is this me, or has some external source changed since I last tried to rebuild this ?

(yes, I deleted the entire local repository on my computer rm -R style, thinking I might have messed up some config file with a bad gitty command.)

[scorbett123]

This is an error happening in all projects using mixin's at the moment.

[5HT2]

I got an error in the build, tried twice, decided to flush my directory and start over, still getting an error:

Flushing your cache was a bad idea. Mixin is offline, if you hadn't flushed your cache you could do ./gradlew --offline build

[ZacSharp]

I think he flushed the repo, not the cache.

[HoratioGamer]

So is this a situation that is likely to correct itself ? I intend to recompile when I am able, move the new baritone to the mods folder, so it is in place before entering Q.

[scorbett123]

The latest pull fixes it. If you go into the build.gradle and change line 29 and 83 to : url = 'https://repo.spongepowered.org/repository/maven-public/'

[5HT2]

make sure it's https, not http

[HoratioGamer]

That worked thanks. I will do more testing with the latest version.

[ZacSharp]

Can you please test buildValidSubstitutes as well?

[HoratioGamer]

OK so I have to be clear.... buildSubstitutes is a mapping from schematic blocks to admissible world blocks.
buildValidSubstitutes is another mapping. Does one do its mappping first and the other second? So say that buildSubtitutes said oak_wood_planks->obsidian,air* and buildValidSubstitutes is obsidian->gravel,sand ... is Baritone intended to lay down gravel or sand in place of oak_wood_planks in the schematic ? The larger question is, what order are the mappings applied ? Can you give me an example that uses both ?

* Edit: This will not work because oak_wood_planks is not a valid designation. Only "planks" works, and then Baritone will not distinguish between planks in a schematic.
https://github.com/cabaletta/baritone/issues/2323#issuecomment-774129439

[ZacSharp]

buildSubstitutes is applied before every other setting affecting the schematic, except for mapArtMode. buildValidSubstitutes specifies blocks to ignore if they happen to be there (e.g. stone->gravel,sand will still only place stone, but will accept gravel and sand as well). buildSubstitutes does almost the same, except that it will not accept the original block, unless it is listed explicitly and that it will consider all listed blocks for placing, prioritizing from start to end of the list (e.g. stone->gravel,sand will place gravel and sand, preferring gravel and accepting nothing else, unless changed by another setting) I use it with a block I definitely can't place (e.g. torches and don't have torches) and set obsidian and air as valid substitutions, so it would keep obsidian that is there without placing new obsidian (can't use buildSubstitutes because torch->obsidian,air always prefers placing and torch->air,obsidian won't ever place anythin). Then I put torches instead of obsidian into the first row of a highway schematic, forcing baritone to always place the netherrack before the obsidian while still keeping already present obsidian.

[HoratioGamer]

OK, so that is a valid use of both buildSkipBlocks and buildValidSubstitutes at the same time. It requires an area where there is no highway yet, and there is a void that needs bridging. I do not have one handy in 2b2t right now for testing (without making a highway to nowhere). So here is another idea: A highway repair and de-grief schematic. Use the buildSkipBlocks sand to keep it from worrying about areas beyond the road bed, but then use buildValidSubstitutes air->sign,banner so it does not break signs and banners placed along the highway ? There are about 5.8 million blocks of existing highway I can use that schematic on. Am I understanding the logic correctly, that this is supposed to do will do what I think it will ? If so, this is a valid test of buildSkipBlocks and buildValidSubstitutes. I could then use buildSubstitutes air->air,sign,banner to do the same thing with buildSubstitutes too.

Can you give me the literal command to clear these variables to be the empty value? I still do not know how to do that.

* Edit: this will not work because sign is wall_sign or standing_sign, and signs have rotation, only rotation 0 signs will match this specification. https://github.com/cabaletta/baritone/issues/2323#issuecomment-774129439

[ZacSharp]

In replacing buildValidSubstitutes with buildSubstitutes only works for optional blocks (i.e. they should be air unless there is something) and if there are no block state properties that can be copied. In my example it is possible and I'm not sure whether it will accept signs with any rotation in your example. Two more examples where you have to use buildValidSubstitutes (I think) are allowing any meta of a block (e.g. stone->stone) and when you are building a house, you might want it to ignore the different underground materials but still build things like statues using the correct material (e.g. stone->dirt,obsidian,dirt->stone,obsidian,obsidian->dirt,stone in buildSubstitues would be awful, but in buildValidSubstitutes it's mostly fine).

There is no command that specifically clears them, but since they are empty by default you can just use #reset buildSkipBlocks, #reset buildValidSubstitutes and #reset buildSubstitutes