Question / possible issue: Wire Clutch rotational friction may be unstable when used as a vehicle brake on moving base entities
Purpose of this issue
I would like to ask whether the current Wire Clutch behavior is expected, or whether there may be an issue with how its rotational friction axes are resolved when one of the connected entities is a moving vehicle base.
This report is based on repeated vehicle-brake tests using Wire Clutch as a friction brake between a rotating wheel/sprocket prop and a moving base/chassis prop.
Short summary
When Wire Clutch is used as a brake between:
Entity 1: rotating wheel / sprocket / brake wheel prop
Entity 2: moving vehicle base / chassis prop
Friction input: constant value, for example 6000
the clutch sometimes resists wheel rotation, but the braking effect appears to depend heavily on the vehicle/world angle.
The main concern is that the clutch friction may not be consistently resisting the intended wheel local rotation axis while the base entity is moving or changing orientation.
In this vehicle setup, the intended wheel rotation axis is the wheel/sprocket local Y axis.
Expected behavior
If a wheel/sprocket prop is rotating around its local Y axis, and a Wire Clutch is connected between that wheel and the vehicle base, I would expect the clutch to consistently resist that relative rotation when a high Friction value is supplied.
Expected result:
Friction = 6000
-> wheel local Y rotation relative to the base is resisted
-> braking behavior remains consistent across vehicle/world angles
Observed behavior
The braking effect appears angle-dependent.
Observed during testing:
0 / 90 / 180 / 270 degrees:
brake barely works or does not work
45 / 135 / 225 / 315 degrees:
brake sometimes catches briefly, then weakens or releases
around 58~60 degrees:
brake works closer to expected behavior, but not perfectly
around 130 degrees:
brake appears strongest / most consistent
This is not just a weak-friction issue. In several tests, the script-side brake state was active and the friction command should have been high, but the vehicle still continued rolling or only braked at certain orientations.
Important test observations
1. E2 output value does not appear to be the main cause
The original E2 engine chip outputs a Caliper value intended to control the external Wire Clutch friction input.
The original output includes:
@outputs Throttle Caliper Clutch W_SV W_Iner E_Aver Ratio Light
The original Caliper calculation includes:
Caliper = (((Gear == 0 & !HasTurnInput & !Back) | StopHold) | (Brake & abs(B_Vx) < 10) ? 1 : Brake) * 6000
Logs showed cases where brake was active and Caliper reached 6000, but the vehicle still did not brake consistently.
2. The internal E2 torque-brake term was tested separately
The original E2 also contains internal torque terms such as:
clamp(Caliper * LeftSpin,-BrakePower,BrakePower) * 1000
clamp(Caliper * RightSpin,-BrakePower,BrakePower) * 1000
These were removed during testing.
Result:
There was no meaningful difference from the original behavior.
This suggests that the internal torque term is not the main braking mechanism in this setup. The main braking path appears to be the external Wire Clutch driven by the Caliper/Friction value.
3. A direct constant Value input can appear to work in simple/static tests
Connecting a constant Value 6000 directly to the Wire Clutch made the clutch appear to work in a simple wheel-rotation test.
However, additional testing showed that when the center/base prop moves, even the direct Value 6000 setup can repeatedly lock and release.
This suggests the issue is not simply whether the Friction input receives 6000. The behavior seems related to the moving base / relative orientation condition.
4. Splitting the brake output left/right did not solve the issue
A separate working ABS brake controller was tested. It outputs individual brake values per wheel, for example:
The C6 E2 chip was modified to output separate left/right brake values:
These were connected to separate left/right clutches.
Result:
The behavior did not meaningfully change.
Braking was still angle-dependent.
This suggests that the issue is not only caused by using a single shared brake output.
5. Multiple brake points may make the issue look better without fixing the root cause
The reference ABS brake chip seemed to work better, but after comparing behavior, it appears possible that using multiple brake points only increases the chance that some clutch points happen to align with orientations where the clutch currently works.
In other words:
more brake/clutch points
-> more chances for at least one point to catch
-> may look better
-> but does not necessarily fix the underlying clutch-axis issue
Suspected cause
The suspected issue is that Wire Clutch friction may not be consistently applied in the wheel's intended local-axis frame.
The vehicle's wheel/sprocket rotation is handled in E2 as local Y-axis angular velocity:
LeftSpin = Sprocket_L:angVelVector():y()
RightSpin = Sprocket_R:angVelVector():y()
The desired braking target is therefore:
resist the wheel/sprocket local Y rotation
relative to the Base entity
However, the observed angle-dependent behavior suggests that the effective clutch friction axis may be based on some other frame, such as:
world axes
constraint creation frame
entity relative orientation at creation time
internal ball-socket angular friction axes
another frame that does not remain aligned with the wheel local Y axis
Why this may not be an E2 formula issue
The following were tested or ruled out as likely root causes:
- E2 output not reaching the desired value
- internal E2 torque-brake term being too weak
- single shared brake output instead of left/right outputs
- ABS/brake formula differences
- insufficient friction value alone
The issue remained angle-dependent even after changing the output formula and splitting the output left/right.
Suggested minimal reproduction
A simplified reproduction may be:
1. Create a rotating wheel/sprocket prop.
2. Create a moving base/chassis prop.
3. Connect a Wire Clutch between the wheel/sprocket prop and the base prop.
4. Feed the Wire Clutch Friction input with a constant value, for example 6000.
5. Rotate or move the base entity while the wheel/sprocket is rotating.
6. Observe whether the clutch consistently resists the wheel's intended local Y rotation.
7. Repeat at several world angles, for example 0, 45, 60, 90, 130, 180, and 270 degrees.
Expected:
The clutch consistently resists the wheel's local-axis rotation.
Observed:
The clutch appears to brake at some angles and release or fail at others.
Questions for maintainers
Could you please clarify the following?
1. Which coordinate frame does Wire Clutch use for rotational friction?
- world axes?
- Ent1 local axes?
- Ent2 local axes?
- constraint creation frame?
- another internal frame?
2. Is Wire Clutch intended to provide stable rotational friction for a chosen local wheel axis while the other connected entity is moving?
3. Is angle-dependent braking behavior expected in this type of setup?
4. Is there currently any way to force Wire Clutch friction to act around a specific local axis, for example Ent1 local Y?
5. If not, would it be possible to add an option such as:
- FrictionAxis = local X / local Y / local Z / all axes
- AxisEntity = Ent1 / Ent2
- Use Ent1 local frame / Ent2 local frame / constraint creation frame
Possible useful debugging feature
It would be helpful if Wire Clutch could expose or visualize:
- current effective friction axes
- angular velocity component being resisted
- per-axis friction contribution
- whether friction is saturated or inactive
This would make it easier to confirm whether the clutch is resisting the intended wheel axis.
Current workaround status
No reliable workaround has been found so far for this specific vehicle-brake setup.
Tested or rejected workaround directions include:
- applyTorque braking
- -SpinY damping
- constant reverse torque
- propSetFriction / material changes
- Axis/BallSocket create/remove on brake input
- single Caliper output
- left/right Caliper outputs
- ABS-style Caliper output formula
These either do not behave like true clutch/friction braking, or they do not solve the angle-dependent clutch behavior.
Practical goal
The practical goal is to make a vehicle brake where:
wheel local Y rotation relative to the base
is reliably resisted by Wire Clutch friction at any world angle and while the base entity is moving.
Question / possible issue: Wire Clutch rotational friction may be unstable when used as a vehicle brake on moving base entities
Purpose of this issue
I would like to ask whether the current Wire Clutch behavior is expected, or whether there may be an issue with how its rotational friction axes are resolved when one of the connected entities is a moving vehicle base.
This report is based on repeated vehicle-brake tests using Wire Clutch as a friction brake between a rotating wheel/sprocket prop and a moving base/chassis prop.
Short summary
When Wire Clutch is used as a brake between:
the clutch sometimes resists wheel rotation, but the braking effect appears to depend heavily on the vehicle/world angle.
The main concern is that the clutch friction may not be consistently resisting the intended wheel local rotation axis while the base entity is moving or changing orientation.
In this vehicle setup, the intended wheel rotation axis is the wheel/sprocket local Y axis.
Expected behavior
If a wheel/sprocket prop is rotating around its local Y axis, and a Wire Clutch is connected between that wheel and the vehicle base, I would expect the clutch to consistently resist that relative rotation when a high Friction value is supplied.
Expected result:
Observed behavior
The braking effect appears angle-dependent.
Observed during testing:
This is not just a weak-friction issue. In several tests, the script-side brake state was active and the friction command should have been high, but the vehicle still continued rolling or only braked at certain orientations.
Important test observations
1. E2 output value does not appear to be the main cause
The original E2 engine chip outputs a Caliper value intended to control the external Wire Clutch friction input.
The original output includes:
The original Caliper calculation includes:
Logs showed cases where brake was active and Caliper reached 6000, but the vehicle still did not brake consistently.
2. The internal E2 torque-brake term was tested separately
The original E2 also contains internal torque terms such as:
These were removed during testing.
Result:
This suggests that the internal torque term is not the main braking mechanism in this setup. The main braking path appears to be the external Wire Clutch driven by the Caliper/Friction value.
3. A direct constant Value input can appear to work in simple/static tests
Connecting a constant Value 6000 directly to the Wire Clutch made the clutch appear to work in a simple wheel-rotation test.
However, additional testing showed that when the center/base prop moves, even the direct Value 6000 setup can repeatedly lock and release.
This suggests the issue is not simply whether the Friction input receives 6000. The behavior seems related to the moving base / relative orientation condition.
4. Splitting the brake output left/right did not solve the issue
A separate working ABS brake controller was tested. It outputs individual brake values per wheel, for example:
The C6 E2 chip was modified to output separate left/right brake values:
These were connected to separate left/right clutches.
Result:
This suggests that the issue is not only caused by using a single shared brake output.
5. Multiple brake points may make the issue look better without fixing the root cause
The reference ABS brake chip seemed to work better, but after comparing behavior, it appears possible that using multiple brake points only increases the chance that some clutch points happen to align with orientations where the clutch currently works.
In other words:
Suspected cause
The suspected issue is that Wire Clutch friction may not be consistently applied in the wheel's intended local-axis frame.
The vehicle's wheel/sprocket rotation is handled in E2 as local Y-axis angular velocity:
The desired braking target is therefore:
However, the observed angle-dependent behavior suggests that the effective clutch friction axis may be based on some other frame, such as:
Why this may not be an E2 formula issue
The following were tested or ruled out as likely root causes:
The issue remained angle-dependent even after changing the output formula and splitting the output left/right.
Suggested minimal reproduction
A simplified reproduction may be:
Expected:
Observed:
Questions for maintainers
Could you please clarify the following?
Possible useful debugging feature
It would be helpful if Wire Clutch could expose or visualize:
This would make it easier to confirm whether the clutch is resisting the intended wheel axis.
Current workaround status
No reliable workaround has been found so far for this specific vehicle-brake setup.
Tested or rejected workaround directions include:
These either do not behave like true clutch/friction braking, or they do not solve the angle-dependent clutch behavior.
Practical goal
The practical goal is to make a vehicle brake where:
is reliably resisted by Wire Clutch friction at any world angle and while the base entity is moving.