Conversation
…y offset after ground locking, fix ground locking logic
| buildTask?.cancel() | ||
| val posStateMap = | ||
| obiPositions.associateWith { | ||
| TargetState.Block(Blocks.OBSIDIAN) | ||
| } + portalPositions.associateWith { | ||
| TargetState.Air | ||
| } | ||
| //ToDo: implement non placement interactions like flint and steel in the build sim, in turn, simulating portal lighting too. | ||
| // + portalPositions.associateWith { | ||
| // TargetState.Block(Blocks.NETHER_PORTAL) | ||
| // } | ||
| buildTask = posStateMap | ||
| .build() | ||
| .thenOrNull { | ||
| if (light) LightTask(currAnchorPos.up(), walkIn) | ||
| else null | ||
| } | ||
| .finally { | ||
| buildTask = null | ||
| } | ||
| .run() |
There was a problem hiding this comment.
Probably better to extra this logic into a method
There was a problem hiding this comment.
how so? Having it here makes it clear and concise what it does. Putting it in another function just makes it more confusing when navigating how the module works
| } | ||
| private val corners by setting("Corners", false).group(Group.General) | ||
| private val light by setting("Light", true, "Attempts to automatically light the portal after building").group(Group.General) | ||
| private val walkIn by setting("Walk In", true, "Automatically paths into the portal with baritone") { light }.group(Group.General) |
There was a problem hiding this comment.
Why hide when light is off?
There was a problem hiding this comment.
because theres not much point walking into the portal when its not lit. Helps keep the setting bloat down by assuming what most people would want
| private val sidewaysOffset by setting("Sideways Offset", 0, -5..5).group(Group.General) | ||
| private val yOffset by setting("Y Offset", 0, -5..5).group(Group.General) | ||
| private val lockToGround by setting("Lock To Ground", true).group(Group.General) | ||
| private val allowUpwardShift by setting("Allow Upward Shift", true).group(Group.General) |
There was a problem hiding this comment.
Missing setting description on allowUpwardShift
There was a problem hiding this comment.
didnt bother adding it because lockToGround implies that its locking down to the ground. allowUpwardShift would imply youre letting it rize to the top of some blocks.
| } | ||
| .forEach { posAndBox -> | ||
| box(posAndBox.second, outlineConfig) { | ||
| colors(obiColor.setAlpha(0.3), obiColor) |
There was a problem hiding this comment.
Would be nice to be able to change the alpha value of the render
There was a problem hiding this comment.
was trying to keep down on the setting bloat and wasnt sure if i should add this. Seems very niche and i doubt people would bother changing it most the time but ig i can
| Direction.UP, | ||
| Direction.DOWN -> Direction.EAST |
There was a problem hiding this comment.
playerHorizontal is always one of the 4 horizontal directions never UP or DOWN. So this when is redundant.
There was a problem hiding this comment.
You would need to make a separate check to handle up and down
| var scanPos = baseAnchorPos | ||
| if (blockState(scanPos).isNotEmpty) { | ||
| if (allowUpwardShift) { | ||
| while (blockState(scanPos).isNotEmpty && scanPos.y < 320) { |
There was a problem hiding this comment.
Why 320 specifically? Max build height is 319, and I am pretty sure you won't be able to build a portal if the lowest block is already at build height. Maybe just fail if the y level is to heigh?
There was a problem hiding this comment.
i based the y levels off where it would be technically possible to place the base blocks of the portal with a support. I chose 320 because i need a way to see if the upward shift was successful, and as 319 could be a valid placement, there would be no way to know if it failed or not.
| scanPos = scanPos.up() | ||
| } | ||
| } | ||
| if (!allowUpwardShift || scanPos.y >= 320) { |
| } | ||
| swapPacket() | ||
| if (walkIn) { | ||
| BaritoneManager.setGoalAndPath(GoalXZ(pos.x, pos.z)) |
There was a problem hiding this comment.
Should be a GoalBlock. Preferably a
| BaritoneManager.setGoalAndPath(GoalXZ(pos.x, pos.z)) | |
| BaritoneManager.setGoalAndPath(GoalComposite(GoalBlock(...), GoalBlock(...))) |
so baritone walks into either portal block.
There was a problem hiding this comment.
ah yeah. I tried goal block but i assumed at the time it only walked near that position. Turns out i was telling it to walk into the anchor pos obsidian
…n statement, and use GoalBlock instead of XZ goal
2 participants
Automatically places, lights, and walks into a nether portal using the given configuration.
Once the module is enabled, you can bind the previewPlace setting which once pressed shows you a preview of where the portal will be placed. Once released, the module will place the portal and do other actions if configured for such.