Fix linear actuator offset logic and fix clamps to be of more logical value

[nopeless]

Known issues

breaks various quarries that run at 256 rpm due to timing issues

---

This is a three part fix

1. There exists 3 clamp(getSpeed(), -.49, .49) around the code base for

• LinearActuatorBlockEntity
• MechanicalPistonBlockEntity
• GantryShaftBlockEntity

Collectively, these affect:

• PulleyBlockEntity extends LinearActuatorBE
• MechanicalPistonBlockEntity extends LinearActuatorBE#getMovementSpeed
• GantryShaftBlockEntity has its own clamp

However, this clamp affects rpms above 250 because convertToLinear divides rpm by 512, which means 0.49 * 512 = 250.88.

Slightly related, but this 0.49 clamp is also responsible for the incorrect block speed in the fandom wiki as they used (0.49 * 20) / 256 = 0.03828125

https://create.fandom.com/wiki/Gantry_Carriage

However, this clamp value did not make sense, so I changed it to 1 (as in maximum movement speed is 1 blocks per tick), and any value above 1 was unstable from my testing.

2. This clamp change made it so that blocks would not properly stop at the edge of other blocks, and it was because of a nonexistent offset correction at

Create/src/main/java/com/simibubi/create/content/contraptions/piston/LinearActuatorBlockEntity.java

Lines 317 to 325 in e0c859a

	protected void collided() {
	if (level.isClientSide) {
	waitingForSpeedChange = true;
	return;
	}
	offset = getGridOffset(offset - getMovementSpeed());
	resetContraptionToOffset();
	tryDisassemble();
	}

where the code uses a newOffset, offset pair

Create/src/main/java/com/simibubi/create/content/contraptions/piston/LinearActuatorBlockEntity.java

Lines 124 to 130 in e0c859a

	if (sequencedOffsetLimit > 0) {
	sequencedOffsetLimit = Math.max(0, sequencedOffsetLimit - Math.abs(movementSpeed));
	locked = sequencedOffsetLimit == 0;
	}
	float newOffset = offset + movementSpeed;
	if ((int) newOffset != (int) offset)
	visitNewPosition();

3. There exists a movement direction check for anchors and I noticed this when contraptions were stopping early in only the positive axes.

Create/src/main/java/com/simibubi/create/content/contraptions/ContraptionCollider.java

Lines 715 to 719 in e0c859a

	// Blocks in the world
	if (movementDirection.getAxisDirection() == AxisDirection.POSITIVE)
	gridPos = gridPos.relative(movementDirection);
	if (isCollidingWithWorld(world, contraption, gridPos, movementDirection))
	return true;

Removing this check seems to produce correct behavior

This is incorrect behavior. Imagine a contraption that is perfectly aligned with the world. It intersects only one block, not two. this is because positive direction requires ceil while negative direction requires floor. This pr implements the ceil part

---

I have tested RPMS up to 512 by changing the game config and rope pulleys, mechanical pistons, and gantry carriages all worked fine up to 512RPM.

However, this PR includes a rather big line change in ContraptionCollider and I have not tested how the other contraptions will behave to this change.

TL;DR: fixed offset logic which allows linear actuator contraptions to stop at the correct block, especially at high rpms, adjust clamp so that it scales linearly up to 512RPM instead of 250RPM, removed possibly broken check for contraption colliding

TL;DR 2: there were more bugs related to integer alignments, specifically when contraptions were exactly aligned with the block, causing 256rpm to not behave correctly with linear actuators. That has also been addressed

[nopeless]

this change broke behavior at low rpm

im looking into it

[nopeless]

If anyone does want to test this, please check the following entries

• low rpm: (1~255rpm)
• high rpm: (256~512rpm) (you need to edit config to test above 256)
• sequenced gearshift

against

• rope pulleys
• elevator pulleys
• mechanical pistons
• sticky mechanical pistons
• mechanical bearing block
• clockwork bearing block

for pulleys and pistons, make sure to also check behavior when it does not fully extend nor retract

[nopeless]

I am pretty sure this pr also fixes the "up" bias that exists with rope pulleys but I only empirically verified this

[adaliszk]

Hmm, would probably be also good to double-check technical hacks around them and see how those are affected. Would not be happy to say goodbye to the 2gt cobblegen :D

[github-actions]

@nopeless, this pull request has merge conflicts with the target branch. Please merge the latest changes and leave a message here so we can continue with the process of reviewing and merging this pull request. Thanks!

[nopeless]

this feature branch is actually complete, I just haven't gotten around to fully testing it in game because I don't have extensive knowledge on how this changes will interact with other mechanisms. I'll get around to rebasing to fit main tho

[donywang922]

I've tested 8 machines from https://www.creativemechanicserver.com/ with Contraption and some common tricks.
Low speed
So far, I've confirmed that at 265 RPM, the Clamp modification didn't break any production machines, but it did break one large decorative item (the gantry moved an extra block) due to the increased speed limit.
Other changes.
Changes in ContraptionCollider.java broke this extrusion structure, which is no longer used in any schematics from creativemechanicserver.com but was previously used for falling block duplicates and end obsidian platform extrusion.

Also, although it's unclear if this change is responsible, the following extrusion structure now runs reliably at a higher speed (132 → 160 rpm).

All three quarry structures are currently operational. The modifications to the ropes are considered correct.
High speed
Of the machines I tried, the ones that relied on timing all broke, so I didn't test further more. As expected, most machines needed their timers readjusted due to the clamping modifications.

[nopeless]

@donywang922 thank you so much for testing this out.

Also, although it's unclear if this change is responsible, the following extrusion structure now runs reliably at a higher speed

It is likely that this change is responsible, as it also fixes contraption collider detection for linear actuators accurately.

Also, I am guessing that you ran these tests for all 4 orientations?

[adaliszk]

@adaliszk Note to myself: test the Aurover 2GT cobblegen to see if it still works with the modifications.

[donywang922]

Also, I am guessing that you ran these tests for all 4 orientations?

Sorry but no, most schematics don't work correctly when rotated so I can't be sure about that, but the two structures in the screenshot above have been tried in all four orientations.