Use a list of placements instead of one. (faster builder)

[Redhawk18]

This allows us to have multiple placement locations at once to speed up building.

[leijurv]

Interesting. Does this work on 2b2t?

[Redhawk18]

Interesting. Does this work on 2b2t?

It should, but not tested.

[Redhawk18]

@leijurv @ZacSharp thoughts?

[Redhawk18]

erm, what the sigma

[ZacSharp]

Is there something I need to do for this to have an effect? I just tried testing this and can't tell whether I was placeboing myself or it's actually faster.

[Redhawk18]

Is there something I need to do for this to have an effect? I just tried testing this and can't tell whether I was placeboing myself or it's actually faster.

The best example I can find is placements that were already fast are just faster.

[ZacSharp]

For example, if I let Baritone place a ring of blocks, all placeable from the initial position, does this pr make it faster?

I'm wondering because InputOverrideHandler clicks once per tick so it should only actually click on the last block for which the builder set the rotations.

[Redhawk18]

For example, if I let Baritone place a ring of blocks, all placeable from the initial position, does this pr make it faster?

I'm wondering because InputOverrideHandler clicks once per tick so it should only actually click on the last block for which the builder set the rotations.

It's been over two months since I made those changes but I believe it does. Because it's running the right click function more often because it returns a list of blocks to place.

[ZacSharp]

It's been over two months since I made those changes

Yeah, sorry for being a slow-ass reviewer. I had some higher priority things to spend my time on, so couldn't test this properly.

it's running the right click function more often

That's specifically the part I'm concerned about. The function it calls only sets a flag which says "RMB is pressed" and the packet will actually be sent later when InputOverrideHandler ticks (and is not on cooldown).

[Redhawk18]

It's been over two months since I made those changes

Yeah, sorry for being a slow-ass reviewer. I had some higher priority things to spend my time on, so couldn't test this properly.

it's running the right click function more often

That's specifically the part I'm concerned about. The function it calls only sets a flag which says "RMB is pressed" and the packet will actually be sent later when InputOverrideHandler ticks (and is not on cooldown).

You're the fastest maintainer I wouldn't worry about speed, its not like you record videos of you clipping your toe nails like leijurv either. But I don't think I have a way to test this, but I remember it was visibly faster. However its been so long I don't remember. Likely @mankool0 could explain why, he's the one that gave me the tip that this could be slow.

[leijurv]

What exactly is the problem with toe nail clipping videos??? 😂

[Redhawk18]

What exactly is the problem with toe nail clipping videos??? 😂

Oh so now you respond, 😈

[ZacSharp]

@mankool0, do you have anything to say on this?

[mankool0]

@mankool0, do you have anything to say on this?

I'm not sure if this would work on 2b2t. I just know from testing on constantiam that in some cases you can place 2 blocks in a single tick if the rotation between them is minimal. I also haven't tested it with different blocks, but I imagine you'd have problems trying to place 2 different blocks at once. Since baritone is mostly 2b2t related I feel like this pr still needs changes to make sure the blocks it's trying to multi place are the same, otherwise it'll be placing the wrong blocks and will constantly be breaking and replacing.

It should also be tested on 2b2t to see what the limit on rotations is and if this works there at all.
Maybe also create some sort of schematic to speed test different settings to have a good default value.

I'm not currently able to test this pr so I'm not sure if other changes are needed.

[Redhawk18]

Is there anyone willing to test on 2b?