Skip to content
This repository has been archived by the owner on Apr 22, 2021. It is now read-only.

AutoHighway #1083

Open
7 tasks
5HT2 opened this issue Jul 30, 2020 · 12 comments · May be fixed by #1226
Open
7 tasks

AutoHighway #1083

5HT2 opened this issue Jul 30, 2020 · 12 comments · May be fixed by #1226

Comments

@5HT2
Copy link
Member

5HT2 commented Jul 30, 2020

Automatically sets up the baritone instructions to build a highway

  • rendering preview
  • detect direction and type
  • option to disable when you don't have any food or picks
  • custom block ignore list for digging
    • ignore signs
    • ignore obsidian
  • fix Baritone lava management

Instructions to do it manually (example)

  • Select the areas with #s 1 and #s 2>
  • #buildrepeat and set it to what ever direction you are going to (If X+ then 1,0,0)
  • #buildrepeatcount -1 so it keeps building it until runs out of blocks
@5HT2 5HT2 self-assigned this Jul 30, 2020
@5HT2 5HT2 added this to the v1.1.7 milestone Jul 30, 2020
@jumboman32
Copy link

Schematic files for the build command.

@5HT2
Copy link
Member Author

5HT2 commented Aug 2, 2020

thanks

@5HT2
Copy link
Member Author

5HT2 commented Aug 2, 2020

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway would Cure Ghost Blocks left by Digging Diagonal Highways using Prizmatic Baritone Schematics

The problem is, baritone schematics are prizmatic. Advancing a schematic one buildRepeat at a time, on a diagonal means the edge blocks from the road are only in the schematic for one lay of the schematic. Courier Font would make this
easy to show in ascii art. Not all blocks in the schematic intersect with blocks in a later lay of the schematic. For instance, blocks down the centerline of a far out diagonal highway are in 4 consecutive lays of the schematic. The blocks in the columns furthest from the centerline of the diagonal highway are only in one lay of the schematic.

If the server is lagging, and blocks are breaking and reappearing, baritone can believe it is finished with a schematic, advance the buildRepeat, and then in the last schematic, a block can re-appear. For blocks also in the second lay of the schematic, they will get cleaned up. The blocks in the columns furthest from the centerline of the highway -- the blocks next to the walls, are only in one lay of the schematic, so, are more likely to glitch back and not get caught, and be left as a defect in the digging.

The main problem is, schematics are prizmatic, that is shaped like a box, not like a tetris piece. Instead of changing the shape of schematics, there is another solution that would allow Autohighway to continue using schematics. Introduce a new block type called "I do not care". Instead of trying to make a tetris piece shaped schematic, make the bounding box that would contain the tetris piece, and then all the parts of the box outside the tetris piece, make those blocks "I do not care".

Instead of using a 4x4 schematic for PosPosDig, one uses a 6x6, but the parts that would lay outside the roadway, one uses "I do not care" blocks in that part of the schematic. All blocks one cares about would be in successive lays of the schematic, virtually ending blocks glitches.

That is only one possible solution, some other solution similar to a diagonal schematic, or a check ahead and behind algorithm, if anything is ever found glitched back behind you, step back 2 steps and do the dig overlay again. There are many ways to end glitched blocks when digging diagonals.

Glitched blocks are not such a problem on axis-aligned highways because a 4-block-long schematic will overlap by 3 blocks each time the schematic is advanced. The block would have to glitch back 3 full cycles later, instead of a fraction of one cycle for the last block mined on a diagonal schematic.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will burn Netherrack when Tunneling.
500 made a complaint on IIS, that people who were digging were leaving disposed floating stacks of netherrack on the highways after digging. https://discord.com/channels/605665373890543627/624115049275064330/733766248734654464 The logic was, people will come along and use it to make barriers to flying and grief for people on foot. Xiaro disagreed. https://discord.com/channels/605665373890543627/624115049275064330/733781731198369904

The problem is, 5OO is right, people do pick up stuff and use it to grief. The accepted process to dispose of blocks is to burn them. It is a tedious job to go around and gather up all the floating stacks of netherrack because of the lag in the game picking them up while you are standing over them. Also, going to them some on the right, some on the left, leaves one wandering back and forth across the highway while gathering. Where digging using a bot took 5-player sessions, most AFK, burning netherrack for the same stretch of highway takes about 10 player-sessions, one one has to pick it up.

It would be much better if the digging bot took care of burning the netherrack that was mined out, as it is mined out, when it is in your inventory and one has generally faster game-response to tossing it in a hole to burn.

An auto-burn feature would use a bucket of lava over a flint and steel because a bucket of lava never wears out.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway Digger will leave a Smooth Continuous Floor.
The only way to do this is to assure that the layer under the lowest layer of the dig is continuous. One way to do this is to use schematics that are one block deeper in the ground and define the lowest layer as all netherrack. Using this schematic ran me into problems. See: Better Bridging (or jumping in pits of fire), Lack of Resources (bridging a huge chasm), Any Competent Block Will Do (don't dig out cobblestone or obby from the underlayer).

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will be competent at Bridging Using the Shift-extend floor under your feet method, not the Jump-Pillar method.
I was using Impact with its built-in Baritone. It did not seem to know how to use the shift key to crouch/sneek/advance out over the edge of the floor and add another block to the floor under your own feet to make a bridge. It wanted to jump into pits of fire and pillar up from the bottom of the pit to get a one block in the deck of the bridge. It was virtually unusable. I watched GATECRASH of MEG and he was clearly using a different piece of software. His baritone knew how to extend the floor out over a chasm and he never jumped into pits to pillar up.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will not suffer from a lack of an abundant resource.
The diagonal highway schematics include netherrack in their side walls, under the obby that makes up the walls. If one is using a dig schematic that includes the underlayer, then one has netherrack in this schematic also. The problem is, when one's bot reaches a chasm, one can run out of netherrack on the hotbar pretty quickly. The Impact bot running schematics would freeze and get kicked from the game. It seemed silly to me that a bot, with a pick, in need of netherrack, would not just go mine some and use it.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will do what it can with what it has.
When one runs out of obby, and the server has not restarted, and one's bot is just standing there, it should automatically switch over to just digging/preparing/clearing obstacles using a digging schematic.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will have an {obby or air} block in its schematics.
The problem with Impact/baritone schematics is, at every point in the schematic, the type of block is exactly specified. If one is running a dig schematic, then there is air in the blocks that will eventually be laid as obby when the obby paving crew comes through. The problem is, because the dig schematic contains air where there will be road, when it encounters a piece of road that is already made, it will mine out the obby to make those blocks in the schematic air. If it finds a few stray obby blocks, it mines them too. It should have a new block type in the place where the paving will go -- {obby or air}. If there is already obsidian, do not mine it. If there is air, do not freeze up because the bot has no obby to lay there.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will have an {any competent block will do} block in its schematics.
This is again a way to not break blocks that will serve the purpose. This is particularly important if one is running a schematic that is laying an underlayer over chasms. Sometimes one finds the chasm has already been bridged with cobblestone. It is a waste of time to mine that out and lay in netherrack. Same with obby below the level of the highway -- the bot should not mine it out to produce a flat floor of netherrack. In a schematic with an underlayer, any competent block will do for the underlayer.

@HoratioGamer
Copy link

This is a suggestion.
Good Autohighway will Automatically Move Portals off the Highway.
Portals on the highway are an impediment to flying. Running a digging schematic down the highway mines out portals. The problem is, the overworld side of the portal still remains. If anyone comes through the portal from the overworld side, it will be remade, in the middle of the highway, automatically, again becoming an impediment to flying. The solution is, to rebuild the portal just off the highway, moving the portal at most 4-5 blocks. This creates a linked pair of portals and if someone comes through from the overworld, the nether-side portal does not regenerate on the highway. Problem permanently solved. I have been solving this problem manually.

@5HT2 5HT2 modified the milestones: v1.1.7, v1.1.8 Aug 24, 2020
@5HT2 5HT2 linked a pull request Aug 27, 2020 that will close this issue
57 tasks
@5HT2 5HT2 removed their assignment Nov 23, 2020
@Luna5ama Luna5ama modified the milestones: unplanned, long-term Mar 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants