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.
Duplicate of: https://support.keenswh.com/spaceengineers/pc/topic/55881-wheel-override-propulsion-direction-differs-based-on-cockpit-entry-history
Duplicate of: https://support.keenswh.com/spaceengineers/pc/topic/55881-wheel-override-propulsion-direction-differs-based-on-cockpit-entry-history
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.
It's not just SWCS/skid steering:
* It'll break existing builds of of timer block cranes on rails - if you have an action relay/button/sensor to move the crane remotely, it now operates differently depending on if anyone got in the cockpit in that session.
* All scripts: I have a wheeled drone script and basically it will instantly and permanently break (until server restart or game reload) if anyone gets in the cockpit or controls it remotely.
There's no way to correctly detect if the propulsion is reversed or not either - if you check for "person in the cockpit" you can't save that at the session level, so if you recompile the script, you have to now enter/leave the cockpit to "break" it again, since it's "stuck" in new reversal mechanism due to the missing ReleaseControl code.
It breaks so much of the automation potential of the game since even if you leave it in and resolve the ReleaseControl issue, you now need to detect if the cockpit is occupied or not, which is not possible to reliably do with an Event Controller, and you then need additional timer blocks - one for occupied, one for not occupied.
Just take it out please, we never had problems with this before. It was an annoying quirk at most that could be solved with a single timer block and 2 groups. The fix is worse than the original problem.
It's not just SWCS/skid steering:
* It'll break existing builds of of timer block cranes on rails - if you have an action relay/button/sensor to move the crane remotely, it now operates differently depending on if anyone got in the cockpit in that session.
* All scripts: I have a wheeled drone script and basically it will instantly and permanently break (until server restart or game reload) if anyone gets in the cockpit or controls it remotely.
There's no way to correctly detect if the propulsion is reversed or not either - if you check for "person in the cockpit" you can't save that at the session level, so if you recompile the script, you have to now enter/leave the cockpit to "break" it again, since it's "stuck" in new reversal mechanism due to the missing ReleaseControl code.
It breaks so much of the automation potential of the game since even if you leave it in and resolve the ReleaseControl issue, you now need to detect if the cockpit is occupied or not, which is not possible to reliably do with an Event Controller, and you then need additional timer blocks - one for occupied, one for not occupied.
Just take it out please, we never had problems with this before. It was an annoying quirk at most that could be solved with a single timer block and 2 groups. The fix is worse than the original problem.
Yes! Therefore, we need Keen Software House to add flags such as:
bool SteerInvert{get; }
bool RevolveInvert{ get; }
Or a switch that can automatically reverse direction, such as:
bool EnabledAutoInvert{ get;set; }
Yes! Therefore, we need Keen Software House to add flags such as:
bool SteerInvert{get; }
bool RevolveInvert{ get; }
Or a switch that can automatically reverse direction, such as:
bool EnabledAutoInvert{ get;set; }
Does it normally take this long for Keen to look into these kinds of issue’s? Just curious more than anything because me and some friends are waiting for them to investigate it and this is the first time I’ve ever had a major known issue game side? With respect to Keen and their support staff.
Does it normally take this long for Keen to look into these kinds of issue’s? Just curious more than anything because me and some friends are waiting for them to investigate it and this is the first time I’ve ever had a major known issue game side? With respect to Keen and their support staff.
My world of 200 hours is now basicaly useless most of my vehicles use these subgrid wheel controlers. im finding myself having to find a whole new way of playing this game as i mostly played on planets and moons only traveling to space for uranium and platinum. i also have many machines i use which use wheels on subgrids to move parts of the machine around. all this is useles now. probably 300 hours lost if this isnt fixed
My world of 200 hours is now basicaly useless most of my vehicles use these subgrid wheel controlers. im finding myself having to find a whole new way of playing this game as i mostly played on planets and moons only traveling to space for uranium and platinum. i also have many machines i use which use wheels on subgrids to move parts of the machine around. all this is useles now. probably 300 hours lost if this isnt fixed
Keen please consider assisting in fixing this. I have nearly 2k hours. Most of my land creations which account for 1700 of the hours, rely on these scripts. This will be a game killer for myself, and I'm sure others.
Keen please consider assisting in fixing this. I have nearly 2k hours. Most of my land creations which account for 1700 of the hours, rely on these scripts. This will be a game killer for myself, and I'm sure others.
The hotfix has been released, but Keen doesn't seem to intend to fix it.
The hotfix has been released, but Keen doesn't seem to intend to fix it.
The default behavior of the propulsion override did seem raw and arbitrary, making it more rational is not unreasonable.
If Keen wants a new default behavior for the wheels, we're all for it. It doesn't matter if everyone has to rewrite their mods or rebuild their grids, that's trivial.
But cutting modders off from the necessary variables and functions and making it out-rightly impossible for them to create the invaluable features we have all come to depend on is outwardly hostile to the player base.
Please expand the API to enable code control of the wheels.
The default behavior of the propulsion override did seem raw and arbitrary, making it more rational is not unreasonable.
If Keen wants a new default behavior for the wheels, we're all for it. It doesn't matter if everyone has to rewrite their mods or rebuild their grids, that's trivial.
But cutting modders off from the necessary variables and functions and making it out-rightly impossible for them to create the invaluable features we have all come to depend on is outwardly hostile to the player base.
Please expand the API to enable code control of the wheels.
Hello Engineers,
Thank you for reaching out to our forum.
We have created an internal ticket and linked it to this report.
Kind Regards,
Keen Software House: QA Department
Hello Engineers,
Thank you for reaching out to our forum.
We have created an internal ticket and linked it to this report.
Kind Regards,
Keen Software House: QA Department
For SETB admins and others:
https://github.com/highlyunavailable/WheelControlFix
I created a torch patch that reverts the behavior until Keen fixes this gamebreaking bug. All issues disclaimed, feel free to modify it to fix it but it works on my box:tm:.
For SETB admins and others:
https://github.com/highlyunavailable/WheelControlFix
I created a torch patch that reverts the behavior until Keen fixes this gamebreaking bug. All issues disclaimed, feel free to modify it to fix it but it works on my box:tm:.
Patch 1.210.014 claims to resolve this. Thanks!
Patch 1.210.014 claims to resolve this. Thanks!
Replies have been locked on this page!