Please remove the Spidertron screen wobble

[Pi-C]

The wobble isn't an animation, it is the spidertron actually physically moving in a wobbly way to another coordinate. It's basically a fairly simple physical model where the legs and body are attached with simulated springs.

[…]

The wobble isn't really programmed in, and it might be tricky to remove it in a way that looks good and doesn't alter the movement of the spidertron too much.

Technically, setting SpiderVehiclePrototype.html::torso_bob_speed to 0 should stop the wobbling. That's what DMV - Directional Movement Vehicles does with the car-prototypes it converts to spider-vehicles. But those spider-cars have just one invisible leg -- not sure how this would look with the vanilla spidertron.

[BrainGamer_]

Technically, setting SpiderVehiclePrototype.html::torso_bob_speed to 0 should stop the wobbling.

torso_bob_speed is not affecting the camera location at all, its just an animation of the spider-vehicle torso bobbing up and down over time (all the time). The actual position of the spider-vehicle does not change.

The problematic wobble is as Qon described caused by all the legs needing to figure out where they need to end up at once you want to stop moving + their spring like physics coming to an equilibrium which takes some time.

[Tertius]

As long as the camera is centered on the Spidertron, not on some map position, there is probably no chance to get anything changed. Actually, not the Spidertron is wobbling. Its screen position is never changed and always fixed to the center of the screen. Instead, the world is wobbling (and that's actually the reason for this motion sickness uneasiness and the issues with mouse positioning).

A different camera mode has to be implemented, that freezes the map positioning as soon as the engine knows no Spidertron foot will move any more. As soon as every foot has its final position, the body just swings to the center of the foot locations as visual effect, with no real movement any more. If this final swinging could just move the Spidertron body (freeing it from the screen center) and not the whole map any more, just as the up-and-down idle bobbing, this would be nice.

[Qon]

A different camera mode has to be implemented, that freezes the map positioning as soon as the engine knows no Spidertron foot will move any more. As soon as every foot has its final position, the body just swings to the center of the foot locations as visual effect, with no real movement any more. If this final swinging could just move the Spidertron body (freeing it from the screen center) and not the whole map any more, just as the up-and-down idle bobbing, this would be nice.

Wrong.

Your "solution" is missing details, like what would actually happen to the camera when you release your keys. Will it teleport when you release they keys or when you press your keys again after having stopped? Or some kind of interpolation? Isn't that going to be annoying as well? If you want the camera to just stop and not deal with that then the spidertron has to stop immediately as well. But that can't happen with the current model. Well of course you can stop it, but it would look really bad, and it would start being pulled towards the feet when you try to move again, flinging you away from where you are. To stop that issue the legs would have to move back towards the head while it is "frozen", which might not actually be possible if there are no footholds that would keep the head stable at the location it is at. And I could keep going, but soon I will have to program my own spidertron movement to explore and show all the details.

[LackadaisyFrog]

First, I know almost nothing about how the spidertron's movement is programmed, but I believe what is happening here is that some people are focusing on the symptoms resulting from a jarring interaction between aggressively terminating momentum from movement and the camera following the resulting underdamped second-order differential equation, while others are seeing the underdamping as working as intended as a result of the fantasy of pneumatic-spring-legs and thus reasonably immutable.

The spidertron seems to follow a relatively constant and straight curve of motion while a movement input is held, but when the input is released, it seems to attempt to simulate the process of gently breaking momentum and then coming to rest very close to the place where the input was released. The mathematical simulation for this breaking action is very predictable, and results in an oscillation in one dimension through the endpoint. With a spidertron with some exoskeletons, the high speeds that can be achieved combined with this underdamping stop can result in some severe camera movement that looks like screen shake.

Contrast this to the overdamping of car-prototype vehicles, where the endpoint of motion is necessarily beyond the point where the input is released, resulting in smooth stopping with no return movement, and no camera oscillation at all.



It's clear, then, that there are two possible solutions:

• fix the spidertron's movement calculations to dynamically break with critical damping, or

• find a way to momentarily divorce the camera from the spidertron whenever a movement input is released, since the camera is already very close to where the spidertron is trying to end up, and then smoothly reattach the camera when the underdamping oscillation is complete

Both these solutions actually require solving the same second-order differential equation, just for different variables, the first for the correct critical damping force or the second for the time until the oscillation wave amplitude will fall below some reasonable threshold (such as when the game rounds it off).

However, both those variable depend on the speed of the spidertron, which can vary, but falls within reasonable limitations. We can determine discrete chunks of speed from the game engine that can be precalculated and get a very good approximation of the correct damping force or time to eliminate the problem, then include a tiny little table for the game to lookup up what force or time to use based on the spidertron's speed when the movement input was released.

The end result would essentially be the same, but fixing the game engine requires fewer technical changes. There would still be a little wiggle from the spidertron as it comes to a stop, differentiating its movement from car-prototype vehicles and preserving that fantasy of a pneumatic-spring-legs, but the oscillation could be reduced to an emphatic shift back to where the spidertron meant to stop, but couldn't without "excessive g-force".

[causa-sui]

For me, a fix would require that my camera stops moving immediately (from the point of view of subjective "human time") after I have fully depressed all directional movement keys.

I have no position on what the best way to achieve that would be.

[fwyrl]

For me, a fix would require that my camera stops moving immediately (from the point of view of subjective "human time") after I have fully depressed all directional movement keys.

I have no position on what the best way to achieve that would be.

As much as this is a cop-out answer, I would recommend using map mode zoomed in for almost everything if you're on a spidertron. I don't have the same problem, but I *have* misplaced buildings a lot because of that wobble, so I just use remotes to move and map view to place. The only time I leave map view is to open interfaces for changing recipes etc.

[Taipion]

I see this is a place were people overthink and overengineer, but it's really not necessary.

One simple solution would be, to not have the camera stuck pinpoint on the player/vehicle for the case of the spidertron,
and allow some distance between them, which in itself would probably already fix the issue.

Another solution is:
The moment you set your spidertron in motion (hit a key, click), or stop the motion (release a key),
the motion is known in it's speed and direction, the time it will take and the destination are all known at this point already,
and the camera can just adapt to this without janky movement.

[Taipion]

For me, a fix would require that my camera stops moving immediately (from the point of view of subjective "human time") after I have fully depressed all directional movement keys.

I have no position on what the best way to achieve that would be.

As much as this is a cop-out answer, I would recommend using map mode zoomed in for almost everything if you're on a spidertron. I don't have the same problem, but I *have* misplaced buildings a lot because of that wobble, so I just use remotes to move and map view to place. The only time I leave map view is to open interfaces for changing recipes etc.

Yes, I, too prefer using the map view and remotes for 3 reasons:
- less spidertron noises
- no camera stutter
- easier movement (you know, it feels like an advancement to just go where you want to, especially longer distances, by just one click instead of WASD the way yourself, and it frees up time you can spend elsewhere)

...but there are a lot of things you can't do (yet) in map view, like adjusting combinators, accessing chests and inventories and the like

[Qon]

I see this is a place were people overthink and overengineer, but it's really not necessary.

Written by someone who doesn't think.

Your suggestions are incomplete. You are continuing the well established pattern in this thread of underthinking and underengineering and just repeating things said before without reading the replies pointing out the issues. Saying "and then magic happens that solves the issues" isn't the genius move you think it is.

[Taipion]

I see this is a place were people overthink and overengineer, but it's really not necessary.

Written by someone who doesn't think.

Your suggestions are incomplete. You are continuing the well established pattern in this thread of underthinking and underengineering and just repeating things said before without reading the replies pointing out the issues. Saying "and then magic happens that solves the issues" isn't the genius move you think it is.

Yes, it totally helps if you unleash your attitude on other people in this forum/thread... -.-

If you are unable to provide anything constructive or at least detail, then just don't.

[Koub]

[Moderator me here] I'd rather not see things escalate beyond this point, thank you.

[Qon]

I see this is a place were people overthink and overengineer, but it's really not necessary.

Written by someone who doesn't think.

Your suggestions are incomplete. You are continuing the well established pattern in this thread of underthinking and underengineering and just repeating things said before without reading the replies pointing out the issues. Saying "and then magic happens that solves the issues" isn't the genius move you think it is.

Yes, it totally helps if you unleash your attitude on other people in this forum/thread... -.-

If you are unable to provide anything constructive or at least detail, then just don't.

I didn't come in with the attitude. You said that the constructive posts I wrote before were not necessary. I'm plenty capable, would you mind reading what I wrote before? I wrote a reply to you before detailing the things that were left out. But you never answered. You need to specify enough what should actually happen to solve the whole problem instead of solving it partially with wishes and making new problems with undefined behavior that's potentially worse than what we have now.

The reason I'm pointing out issues with incomplete suggestions is that they are unlikely to be implemented otherwise. I'm the most constructive person in this thread and your lax attitude to detail is not helpful.
"Can we think less about discussing good solutions and just hope something happens even though the devs can see we don't even seem to care enough to try to understand the problem?"
It's just not very constructive. If you are able to provide anything constructive, please do that instead.

[Taipion]

I see this is a place were people overthink and overengineer, but it's really not necessary.

Written by someone who doesn't think.

Your suggestions are incomplete. You are continuing the well established pattern in this thread of underthinking and underengineering and just repeating things said before without reading the replies pointing out the issues. Saying "and then magic happens that solves the issues" isn't the genius move you think it is.

Yes, it totally helps if you unleash your attitude on other people in this forum/thread... -.-

If you are unable to provide anything constructive or at least detail, then just don't.

I didn't come in with the attitude. You said that the constructive posts I wrote before were not necessary. I'm plenty capable, would you mind reading what I wrote before? I wrote a reply to you before detailing the things that were left out. But you never answered. You need to specify enough what should actually happen to solve the whole problem instead of solving it partially with wishes and making new problems with undefined behavior that's potentially worse than what we have now.

The reason I'm pointing out issues with incomplete suggestions is that they are unlikely to be implemented otherwise. I'm the most constructive person in this thread and your lax attitude to detail is not helpful.
"Can we think less about discussing good solutions and just hope something happens even though the devs can see we don't even seem to care enough to try to understand the problem?"
It's just not very constructive. If you are able to provide anything constructive, please do that instead.

#1: You are apparently very short tempered / thin skin, taking something I obviously said in jest (I even put an appropriate smiley next to it) and assuming tons of bad intentions and whatever else on my end.
This is not constructive, this is personal and emotional, this does not belong here and I refuse to "discuss" on that level, so just drop it already.

#2: The specifications of what should happen and how it should work are very, VERY simple and I layed that out in probably enough detail already,
if you missed that, then sorry, try to read it again and not overthink it too much.

#3a: Solution 1 - if and only if the player is using a spidertron (or similar vehicle), determine the max "wobbling" distance than can appear, add some low % as buffer just in case, and set the camera to not be fixed on the exact player position but with a buffer of that distance (read: camera only moves if it is further than this distance away from the player), which effectively will land the camera slightly ahead in movement direction, but stop wobbling and will likely be pretty much not noticeable, but definitely not as bad as the wobbling

#3b: Solution 2 - whenever spidertron movement is stopped (read: final destination through remote, or release of WASD keys), calculate the final position of the spidertron and move the camera there with the speed of the moving spidertron, and lock it in place there until the spidertron moves again (read: through WASD or remote), ignoring "wobble movement"
Yes, calculating the final resting position of a spidertron is simple as the game is utmost deterministic in nature, which is essential to its stability in multiplayer,
unfortunately I don't know the code so that's the best I can give as description.

[edit:] I know there are more cases than this, which need to be considered, like the spidertron following another entity or completely different movement possibilities through mods, but they all boil down to the same use case that is: spidertron stops moving, so this can be applied there as well

[edit2:] This is basically the same that LackadaisyFrog said without leaning into differential equations as that's not necessary as you just need to use the code that already is there to determine the spidertrons final position, just run it in a different way to get the end position instead of "per tick" updates to the position.
I may note that I clearly disagree with him on the point that the camera should be, in solution 1, be "re-attached" at some point as that again would cause problematic movement.

[edit3:] And as a side note for implementation, even though I, personally, do not share the "need" for "simulated spring legs movement", this should ofc be an optional change, so you can turn the old/new camera behaviour on/off in some way.
In my work on a client of some indie game I always do it the same, optional, as I learned that there will always be people who prefer either way for whatever reason, understandable or not.

[Tertius]

As far as I see, you all have incorrect assumption on how the Spidertron moves. Or at least you didn't describe it so I understand it. You seem to assume the origin of all computation around movement is the spidertron body. Actually, it's two levels more.

First, the Spidertron body is moved by the movement keys. This builds tension in the legs, which act like springs. Second, to resolve the tension, all feet are checked if they can be moved to a position in reach where the tension of its corresponding leg is smaller. If this is possible, the position is chosen where the tension is smallest and the foot is moved there.
Third, the powers that control the position of the Spidertron body (it's the current accumulated tension of the legs, additionally the tension by some movement key) pull the body to a position where the accumulated leg tension is minimized.

This is not visually apparent, because the camera is centered on the body, and the map moves around it. If you center the map and move the body around it, it would be more clear. But to where could the map be centered? It's the point between the legs where the leg tension is minimized, if the body would be in that position. The body would come to rest in this position, if there is no external tension by the movement keys.

The crucial point is, this position isn't wobbling around, because the Spidertron body has no momentum. It's just following the weighted average of the foot positions (weighted by the tension). It's only moved by minimizing (releasing) the leg tension, not by momentum. A momentum would build tension after the player releases the movement keys, but this doesn't happen, since there is no momentum.
If the game put the camera on this position instead of always use the body position, the wobbling would be avoided.

[Taipion]

As far as I see, you all have incorrect assumption on how the Spidertron moves. Or at least you didn't describe it so I understand it. You seem to assume the origin of all computation around movement is the spidertron body. Actually, it's two levels more.

First, the Spidertron body is moved by the movement keys. This builds tension in the legs, which act like springs. Second, to resolve the tension, all feet are checked if they can be moved to a position in reach where the tension of its corresponding leg is smaller. If this is possible, the position is chosen where the tension is smallest and the foot is moved there.
Third, the powers that control the position of the Spidertron body (it's the current accumulated tension of the legs, additionally the tension by some movement key) pull the body to a position where the accumulated leg tension is minimized.

This is not visually apparent, because the camera is centered on the body, and the map moves around it. If you center the map and move the body around it, it would be more clear. But to where could the map be centered? It's the point between the legs where the leg tension is minimized, if the body would be in that position. The body would come to rest in this position, if there is no external tension by the movement keys.

The crucial point is, this position isn't wobbling around, because the Spidertron body has no momentum. It's just following the weighted average of the foot positions (weighted by the tension). It's only moved by minimizing (releasing) the leg tension, not by momentum. A momentum would build tension after the player releases the movement keys, but this doesn't happen, since there is no momentum.
If the game put the camera on this position instead of always use the body position, the wobbling would be avoided.

I'm sorry, maybe its just because I'm a programmer and I tend to not overcomplicate things and use what works / is there already instead of rewriting or re-imagining it all over again, if it is good enough.

It does not matter how many components is has, and it does not matter how many calculations or methods are involved.
You have a definitive start state (release of movement keys) and a definitive end state (spidertron stopped all movement) with no player interaction and no randomness in between, the transition between these two states is strictly deterministic (which is, as I already pointed out, a necessity of multiplayer stability) and is computed anyways.

You just need to do this computation ahead of time, and you got the exact, deterministic result you need.
And if you were to save all the movement relevant values along the way, you would not even have to calculate it twice for the actual movement, unless there is more player interaction in between.

And even if you do the calculation twice, you only need to do this for the players spidertron and only for each manual stop, so it is basically impossible for this to be anyhow relevant performance wise.

[edit:] I like your idea, Idk if that would actually work but it sounds nice

[Koub]

viewtopic.php?f=6&t=104637 TLDR: there is no built in "sway" it's simple byproduct of how spidertrons move with legs and not something that can just be turned off.

Source

[Koub] Moving this thread in Mon't implement

[Taipion]

viewtopic.php?f=6&t=104637 TLDR: there is no built in "sway" it's simple byproduct of how spidertrons move with legs and not something that can just be turned off.

Source

[Koub] Moving this thread in Mon't implement

What is "Mon't implement"?

...but seriously, is there anything a lowish player like myself can do, to get this fixed someday?

[Taipion]

I'm seriously asking:

Is there anything I can do about this issue, to get it somewhere on the list for future considerations?!

Apparently it is bad as it is, and there is no way to fix it, not even with modding (right?), and I doubt that the current state is anyhow acceptable for the perfectionist people that make this game.

[Koub]

Is there anything I can do about this issue, to get it somewhere on the list for future considerations?!

When the devs say "No", it's usually "No". Until they are bothered enough by the thing to get out of their way, and fix it - if that happens. Or if there is an opportunity to fix things without jeopardising the rest of the development.