Rigidity slider breaks when trying to move it at exactly 0 MP #4150
Comments
|
This can be 0. I remember we discussed before that MP should be a float instead of int. When that is done this bug should go away. |
|
I guess that is kind of unavoidable anyway with MP discounts etc. Though, we absolutely don't want to show really long decimal values to the user in the MP bar or tooltips. |
CNR_RigidityBug.mp4Can't seem to reproduce this, the membrane slider doesn't move with 0 MP. |
|
A possible(?) division by zero, I guess, would be this costPerStep: if (cost > Editor.MutationPoints)
{
int stepsToCutOff = (int)Math.Ceiling((float)(cost - Editor.MutationPoints) / costPerStep);
data.NewRigidity -= (desiredRigidity - previousRigidity > 0 ? 1 : -1) * stepsToCutOff /
Constants.MEMBRANE_RIGIDITY_SLIDER_TO_VALUE_RATIO;
// Action is enqueued or canceled here, so we don't need to go on.
UpdateRigiditySlider((int)Math.Round(data.NewRigidity * Constants.MEMBRANE_RIGIDITY_SLIDER_TO_VALUE_RATIO));
return;
}But if we want, we could just do, if (cost > Editor.MutationPoints && costPerStep > 0)
{
int stepsToCutOff = (int)Math.Ceiling((float)(cost - Editor.MutationPoints) / costPerStep);
data.NewRigidity -= (desiredRigidity - previousRigidity > 0 ? 1 : -1) * stepsToCutOff /
Constants.MEMBRANE_RIGIDITY_SLIDER_TO_VALUE_RATIO;
// Action is enqueued or canceled here, so we don't need to go on.
UpdateRigiditySlider((int)Math.Round(data.NewRigidity * Constants.MEMBRANE_RIGIDITY_SLIDER_TO_VALUE_RATIO));
return;
}Because the cost no longer matters, if the step cost is 0. |
|
The slider is disabled when at 0 MP, but I think you can still trigger this bug by moving the slider while you still have MP but running out at exactly the mid point. Or a more reproducible way to trigger this is probably to modify new game settings to reduce the mutation costs so that steps are sometimes free and sometimes cost MP. Also there exists a full fix for this problem here, but this PR was never finished: #4154 |
|
Seems like there's a new variant:
This is the repeating callstack: So the problem is that |
hhyyrylainen
moved this from started but stuck (help wanted)
to High priority bugs / issues
in Thrive Planning
|
If step is too big, we can decrease it to fit mutation points modifier (0.4), and min/max slider values to keep proportion. Is this approach good or am I missing something? |
|
When dragging with the mouse the slider emits value change events for each step, meaning that decreasing step size will dramatically increase the number of rigidity change events that are generated. And also for keyboard input it will become impossible at some point to use the left / right arrows to change the value in a reasonable amount of time (so this will make future controller input not usable). So those are the problems, which is why I have not suggested trying to modify the minimum step size, but instead I think something else needs to be done. |
It looks like rigidity slider does a divide by zero to end up with ridiculously wrong numbers when it tries to move when there's exactly 0 MP left. This can be triggered with a very specific MP cost multiplier to be able to place parts to reach 0 MP and then trying to move the rigidity slider.
https://community.revolutionarygamesstudio.com/t/membrane-rigidity-visual-bug/6059
Video: https://youtu.be/9c4ekW5QNI8
The text was updated successfully, but these errors were encountered: