Wheel override propulsion direction differs based on cockpit entry history
InitControl runs once per wheel after a cockpit takes control.
MatrixD matrixD = controller.WorldMatrix * base.PositionComp.WorldMatrixNormalizedInv; Vector3 vector = /* selected controller axis based on alignment */; double num = Dot(controller.Forward, wheelPos - COM); float num2 = Dot(wheel.Forward, vector2); RevolveInvert = (wheel.Up - vector).Length() > 0.1;The method transforms the cockpit world matrix into wheel local space. The code selects a controller axis from the alignment of the cockpit and the wheel. `RevolveInvert` becomes true when the wheel points against that axis. The wheel mounts upside-down relative to the cockpit.
Without a Cockpit or never entering the cockpit:
The old behavior persists from the prior patch. No cockpit or no cockpit entry prevents a call to InitControl. All wheels keep RevolveInvert = false, and for wheels on one side, positive override spins backward/negative override spins forward.
The bug:
ReleaseControl contains no code. m_wheelInversions receives one assignment inside InitControl. The values persist after a cockpit ends control and the system never resets them to default.
Actual behavior:
If you ever touch a cockpit, wheel override direction swaps and gets stuck.
Expected behavior:
Wheel overrides properly reset to their old behavior (one side inverted) with no occupied cockpit.
Consider rolling this change back. It breaks timer blocks as well - one side works differently now based on if a player is in or out of the cockpit. Basically, anything that touches wheel propulsion overrides will now work differently depending on cockpit occupancy.
I have the same bug
I can confirm that this introduction of MyWheelInversions has completely broken my scripts that use wheel propulsion and steering overrides. There is no way for a script to compensate for this new logic, and even if they could, this breaks timer block contraptions irreversibly.
Also, this happens (to a lesser extent) with the steering override as well as it is governed by the same logic.
I don't think that even with ReleaseControl resetting things that the change in override behavior will be intuitive for any automation (timer or script driven). A rollback may be the only workable solution and would be congruent with how overrides for gyros and velocities for rotors/hinges are ship orientation agnostic.
I can confirm that this introduction of MyWheelInversions has completely broken my scripts that use wheel propulsion and steering overrides. There is no way for a script to compensate for this new logic, and even if they could, this breaks timer block contraptions irreversibly.
Also, this happens (to a lesser extent) with the steering override as well as it is governed by the same logic.
I don't think that even with ReleaseControl resetting things that the change in override behavior will be intuitive for any automation (timer or script driven). A rollback may be the only workable solution and would be congruent with how overrides for gyros and velocities for rotors/hinges are ship orientation agnostic.
I run a tank combat server and without the ability to Skid Steer via script this change has completely bricked our ability to create tanks without completely overhauling our builds and creating a new tank steering system if such a system is even possible now.
I run a tank combat server and without the ability to Skid Steer via script this change has completely bricked our ability to create tanks without completely overhauling our builds and creating a new tank steering system if such a system is even possible now.
I can also confirm that this causes major issues for scripting rovers. Specifically when using propulsion override. It basically makes subgrid wheel control completely unpredictable and unreliable. This sucks, especially since this cripples a core feature of a newscript ("LandSystems") I am working on. Propulsion overrides behavior should be consistent with the MyMotorSuspensions themselves (like how it was before).
Critical code change in MyMotorSuspensions below:
// From this (pre prosperity update)
bool flag = (double) this.PropulsionOverride == 0.0 ? this.m_wheelInversions.RevolveInvert == forward : forward;
// to this (post prosperity update)
bool flag = this.m_wheelInversions.RevolveInvert == forward;
Previously, propulsion override would completely ignore RevolveInvert, which makes since as propulsion override is a manual "override". Unlike standard propulsion which responds to player input (from the controller) and thus makes since to automatically adjust.
I agree with Whiplash141 on this, the only workable solution is to rollback this change.
However, this also raises the question of why the internal steering angle for wheels is decreased based on current speed. This greatly nerfs a rover's ability to turn. However, it does make rovers more stable. The problem is that forcing it on everyone prevents you from having full control over your rover which is highly infuriating. This should be an optional toggle in the terminal UI. This happens inside of the Steer() method. Critically, these lines of code:
float num1 = 1f - maxSpeedRatio;
float num2 = num1 * num1 * num1;
float num3 = MathHelper.Lerp((float)maxSteerAngle, (float)(maxSteerAngle / 10.0), 1f - num2) * destIndicator;
maxSpeedRatio cubes down toward 0 as speed rises, which pulls the Lerp weight toward 1, which pulls your effective max steer angle down toward 1/10th of its set value. num2 also speeds up how fast the wheel interpolates toward the target steering angle. Testing with a simply harmony patch, setting maxSpeedRatio to 0 eliminates the effects.
I can also confirm that this causes major issues for scripting rovers. Specifically when using propulsion override. It basically makes subgrid wheel control completely unpredictable and unreliable. This sucks, especially since this cripples a core feature of a newscript ("LandSystems") I am working on. Propulsion overrides behavior should be consistent with the MyMotorSuspensions themselves (like how it was before).
Critical code change in MyMotorSuspensions below:
// From this (pre prosperity update)
bool flag = (double) this.PropulsionOverride == 0.0 ? this.m_wheelInversions.RevolveInvert == forward : forward;
// to this (post prosperity update)
bool flag = this.m_wheelInversions.RevolveInvert == forward;
Previously, propulsion override would completely ignore RevolveInvert, which makes since as propulsion override is a manual "override". Unlike standard propulsion which responds to player input (from the controller) and thus makes since to automatically adjust.
I agree with Whiplash141 on this, the only workable solution is to rollback this change.
However, this also raises the question of why the internal steering angle for wheels is decreased based on current speed. This greatly nerfs a rover's ability to turn. However, it does make rovers more stable. The problem is that forcing it on everyone prevents you from having full control over your rover which is highly infuriating. This should be an optional toggle in the terminal UI. This happens inside of the Steer() method. Critically, these lines of code:
float num1 = 1f - maxSpeedRatio;
float num2 = num1 * num1 * num1;
float num3 = MathHelper.Lerp((float)maxSteerAngle, (float)(maxSteerAngle / 10.0), 1f - num2) * destIndicator;
maxSpeedRatio cubes down toward 0 as speed rises, which pulls the Lerp weight toward 1, which pulls your effective max steer angle down toward 1/10th of its set value. num2 also speeds up how fast the wheel interpolates toward the target steering angle. Testing with a simply harmony patch, setting maxSpeedRatio to 0 eliminates the effects.
Please resolve this issue one way or another as Subgrid Wheel control and Skid steer are 2 core scripts used by (nearly) everyone for their tanks and aircraft. without it everyone at Wavebreaker (but I suspect that other ground/naval/aircraft servers are facing the same issue) would need to completely overhaul their grids if that would even be possible.
Please resolve this issue one way or another as Subgrid Wheel control and Skid steer are 2 core scripts used by (nearly) everyone for their tanks and aircraft. without it everyone at Wavebreaker (but I suspect that other ground/naval/aircraft servers are facing the same issue) would need to completely overhaul their grids if that would even be possible.
Same here. Nearly 80% of my ground builds use the skid steering and I currently have no work around due to how base game steering works since the update.
Same here. Nearly 80% of my ground builds use the skid steering and I currently have no work around due to how base game steering works since the update.
Replies have been locked on this page!