Unexpected Motion

1

Keen Support ●

Hello, Engineer!

Both video and a save would help us reproduce the issue, please send them.

Kind Regards

Keen Software House: QA Department

Reply URL

1

Bill L ●

They are both big files.

Save is 21 MB and video is 3.5 GB.

How do I send them to you?

Regards,

Bill

Reply URL

1

Bill L ●

Decided to just try upload. Here are files:

Files:

URL

1

Bill L ●

Video won't attach. Is there another way to get it to you?

\

Bill

URL

1

error 404 ●

Put it on youtube and post a link.

URL

1

andersenman ●

Might I just say that that is a ton of subgrids, all constrained and locked to each other and the immovable ground, and with stubborn pistons that don't have a "freewheeling" options like rotors or hinges have that could allow for equalisation into to an overall internally force-free state. (Even with all forces set to 0, a piston will still not freely extend or retract under external force.) It's a miracle this thing doesn't tear itself apart.

Also, maybe re-encode the video to something more reasonable? To see the issue in action, it doesn't need a three-hour, 4K Let's Play, you know …

URL

1

andersenman ●

Also, maybe strip and trim your saves for investigation? There is no reason why you couldn't transplant the grid in question into a modless vanilla world, or keep it and delete everything else. Also, your save may be "only" 27 MB in size but it has like a gigabyte of mod dependencies! Granted, they can be disabled before loading, but come on.

Issue reproduced, video attached, stripped save attached. Video: 6 MB instead of 3.5 GB. Save (zipped): 700 KB instead of 27 MB.

Took me, what, ten minutes to clean up, shoot, cut, and render, so you can, too. That computer in front of you? It's actually useful for things beyond collecting dust, heating air, and moving virtual space blocks. As in, unlike a console.

Files:

URL

1

Bill L ●

Thank You for the effort. I did try re-rendering the video and I could make it much smaller without losing too much detail. I'll remember that for the future.

I might point out that "cleaning" a data set before the analysis is done is a sure way to end up with a conclusion that the "problem" is not reproducible. That is because the problem was "cleaned away".

The second issue is I just play the game I have no idea what a "mod dependency" is.

Now to the comments on the structure. This game appears to be a simulation of a structure that is built out of blocks. So a real world steel structure in a gravity field would have down forces due to gravity, side forces due to windage and dynamic forces due to a person or a vehicle moving on the structure. A steel structure has compressive and tensile strength as well as flexibility.

Now the game displays no evidence of windage effects on a structure other than a spinning windmill. The structure will fall in a gravity field so there are down forces simulated. The structure has a some flexibility, as a long unsupported horizontal structure will sag a bit. The strength of the blocks is simulated very high as an unsupported steel structure with spans this large would fail.

The hinge at the bend is a connector only, once everything was set it was locked. The pistons were set by low forces that just took out the sag then locked against stops. Your comments did point out that maybe there was a way to assure none of the piston supports were applying any odd force, so I went back and checked.

I reset the hinge so it is locked and all forces and velocity are set to zero.
I released all the mag plates and backed off the pistons.
I released and reset the merge block. This took out the sag and added a tiny bit of lateral force. This is because the abutment was not perfectly aligned with the span.
I then set the piston supports so that they were positioned with very low force (Axial Imp = 1000 N) the mag plate was allowed to auto-lock. Then set the pistons at Vel = 0, Min/Max stops set at actual position (locking piston in place). Set non-axis imp at 50 kN as this appears to set lateral stiffness.

The above settings should put the span in a slightly pre-stressed condition and the span is supported so it should not flex between the hinge and the merge block when loaded by a person or vehicle.

Redid test by walking out onto this part of span. The problem still exists but to a lesser degree.

Starting from the merge block end there is a tiny vibration that starts when the character steps on to the span. This can be seen in the velocity number which oscillates. It gets worse as the character approaches the hinge. If the character stands still the oscillation amplitude remains the same.

So it seems there is a resonance in the structure induced by the character's presence. The resonance does not seem to diverge but the amplitude is larger by the hinge and at some point the character can't walk any more and just bounces. This appears to be a calculation anomaly within the simulation. In relation to the mass of the structure, the character should not provide sufficient excitation to start a resonance. (1 person is not a marching army).

Thank You for the effort. I did try re-rendering the video and I could make it much smaller without losing too much detail. I'll remember that for the future.

I might point out that "cleaning" a data set before the analysis is done is a sure way to end up with a conclusion that the "problem" is not reproducible. That is because the problem was "cleaned away".

The second issue is I just play the game I have no idea what a "mod dependency" is.

Now to the comments on the structure. This game appears to be a simulation of a structure that is built out of blocks. So a real world steel structure in a gravity field would have down forces due to gravity, side forces due to windage and dynamic forces due to a person or a vehicle moving on the structure. A steel structure has compressive and tensile strength as well as flexibility.

Now the game displays no evidence of windage effects on a structure other than a spinning windmill. The structure will fall in a gravity field so there are down forces simulated. The structure has a some flexibility, as a long unsupported horizontal structure will sag a bit. The strength of the blocks is simulated very high as an unsupported steel structure with spans this large would fail.

The hinge at the bend is a connector only, once everything was set it was locked. The pistons were set by low forces that just took out the sag then locked against stops. Your comments did point out that maybe there was a way to assure none of the piston supports were applying any odd force, so I went back and checked.

I reset the hinge so it is locked and all forces and velocity are set to zero.
I released all the mag plates and backed off the pistons.
I released and reset the merge block. This took out the sag and added a tiny bit of lateral force. This is because the abutment was not perfectly aligned with the span.
I then set the piston supports so that they were positioned with very low force (Axial Imp = 1000 N) the mag plate was allowed to auto-lock. Then set the pistons at Vel = 0, Min/Max stops set at actual position (locking piston in place). Set non-axis imp at 50 kN as this appears to set lateral stiffness.

The above settings should put the span in a slightly pre-stressed condition and the span is supported so it should not flex between the hinge and the merge block when loaded by a person or vehicle.

Redid test by walking out onto this part of span. The problem still exists but to a lesser degree.

Starting from the merge block end there is a tiny vibration that starts when the character steps on to the span. This can be seen in the velocity number which oscillates. It gets worse as the character approaches the hinge. If the character stands still the oscillation amplitude remains the same.

So it seems there is a resonance in the structure induced by the character's presence. The resonance does not seem to diverge but the amplitude is larger by the hinge and at some point the character can't walk any more and just bounces. This appears to be a calculation anomaly within the simulation. In relation to the mass of the structure, the character should not provide sufficient excitation to start a resonance. (1 person is not a marching army).

URL

1

andersenman ●

Don't worry, I made sure to test and double-check after cleaning. I've not exactly hatched just yesterday.

Mod dependency is simply what you select as mods to be included in the world that you create the save from.

As for the rest of your thoughts, remember SE's physics is a necessarily flawed and incomplete approximation, simplification, and discretation of RL physics. Some poor soul had to implement within reasonable frames of time and money what thousands of scientists had to work hard for understanding, and still do. (Okay, maybe not so much on classical mechanics anymore, but certainly still on material science, among others.) You can't necessarily take your RL physics and expect things in game to happen just as naturally emergent as resting a stick on two other sticks. For example, static loads and buckling aren't a thing. (At least they're not exposed to normal gameplay.) You can rest any weight (within the game's and your computer's capability) on a single block, same grid or otherwise (through a landing gear, for example) without so much as a creak or groan. Then there's finite precision, clock speed, and parallelisation. Inaccuracies compound, and some force and position calculations invariably end up happening after or before others, leading to conflicting results. It's like trying to calculate the shape of a triangle (on a flat, non-curved surface) where you try to constrain all angles such that their sum is not exactly 180°. And because the material in SE doesn't give, everything is infinitely rigid. And what does infinite rigidity between multi-point constraints of finite precision cause? Correct, infinite forces, and those infinities cause calculations to break down and exhibit weird things if you don't catch them.

… like characters jumping on an outwardly perfectly still structure. The game loop probably somehow calculates some ridiculously huge forces acting across minutely tiny distances and durations which effectively results in an invisible, purely calculatory vibration near the limits of available computational precision that in turn makes the logic that calculates character movement on surfaces think it's shaking. And since the grid is slightly angled against local gravity, that shaking also makes the character drift like sand grains on a sheet of paper held too shallow for them to slide or roll on their own until you start tapping it.

Point is, I'm not saying the observed behaviour should be accepted and lived with, just that if you do construct things to the not necessarily obvious limits or inherent weak points of the game, expect things to break, and that in the meantime you are probably best advised to at least partly suspend your expectations from RL physics and construct things with in-game physics in mind instead: As said earlier, things (grids) are infinitely rigid, so you don't need any support or suspension of structures. But if you do decide to use support or suspension, because it looks nicer, make absolutely certain that they are only cosmetic and have null physics attached. Or if they have, that they don't interfere with the physics of the rest of the structure.

Try converting all segments and subgrids of that bridge to a station. If that helps, there's your solution. If you can't even click the button, well, there's your problem.

And in the future, if and when you build subgridded structure segments like bridge spans again, convert the subgrids to station right from the first block, even if that's the hinge head or (advanced) rotor head or piston head, before you build the rest of the span, to avoid having to deal with things like sag in the first place. Second block at the latest. Add sacrificial block and control panel, if needed. (Sacrificial because if you accidentally grind off the control panel together with the new subgrid's first block, you'll have to do it again.)

Good luck.

Don't worry, I made sure to test and double-check after cleaning. I've not exactly hatched just yesterday.

Mod dependency is simply what you select as mods to be included in the world that you create the save from.

As for the rest of your thoughts, remember SE's physics is a necessarily flawed and incomplete approximation, simplification, and discretation of RL physics. Some poor soul had to implement within reasonable frames of time and money what thousands of scientists had to work hard for understanding, and still do. (Okay, maybe not so much on classical mechanics anymore, but certainly still on material science, among others.) You can't necessarily take your RL physics and expect things in game to happen just as naturally emergent as resting a stick on two other sticks. For example, static loads and buckling aren't a thing. (At least they're not exposed to normal gameplay.) You can rest any weight (within the game's and your computer's capability) on a single block, same grid or otherwise (through a landing gear, for example) without so much as a creak or groan. Then there's finite precision, clock speed, and parallelisation. Inaccuracies compound, and some force and position calculations invariably end up happening after or before others, leading to conflicting results. It's like trying to calculate the shape of a triangle (on a flat, non-curved surface) where you try to constrain all angles such that their sum is not exactly 180°. And because the material in SE doesn't give, everything is infinitely rigid. And what does infinite rigidity between multi-point constraints of finite precision cause? Correct, infinite forces, and those infinities cause calculations to break down and exhibit weird things if you don't catch them.

… like characters jumping on an outwardly perfectly still structure. The game loop probably somehow calculates some ridiculously huge forces acting across minutely tiny distances and durations which effectively results in an invisible, purely calculatory vibration near the limits of available computational precision that in turn makes the logic that calculates character movement on surfaces think it's shaking. And since the grid is slightly angled against local gravity, that shaking also makes the character drift like sand grains on a sheet of paper held too shallow for them to slide or roll on their own until you start tapping it.

Point is, I'm not saying the observed behaviour should be accepted and lived with, just that if you do construct things to the not necessarily obvious limits or inherent weak points of the game, expect things to break, and that in the meantime you are probably best advised to at least partly suspend your expectations from RL physics and construct things with in-game physics in mind instead: As said earlier, things (grids) are infinitely rigid, so you don't need any support or suspension of structures. But if you do decide to use support or suspension, because it looks nicer, make absolutely certain that they are only cosmetic and have null physics attached. Or if they have, that they don't interfere with the physics of the rest of the structure.

Try converting all segments and subgrids of that bridge to a station. If that helps, there's your solution. If you can't even click the button, well, there's your problem.

And in the future, if and when you build subgridded structure segments like bridge spans again, convert the subgrids to station right from the first block, even if that's the hinge head or (advanced) rotor head or piston head, before you build the rest of the span, to avoid having to deal with things like sag in the first place. Second block at the latest. Add sacrificial block and control panel, if needed. (Sacrificial because if you accidentally grind off the control panel together with the new subgrid's first block, you'll have to do it again.)

Good luck.

URL

1

QA KeenSWH ●

Hello, Engineers!

It´s already quite long time from when this issue was originally posted as well as from the last comment.

Are you still experiencing it? Or was it fixed in the meantime.

Thanks in advance for confirming me current situation.

Kind Regards

Keen Software House: QA Department

Reply URL

1

QA KeenSWH ●

Hello, andersenman,

your ticket was incorrectly logged in our system, on its discovery we reached out immediately. Our apologies for any inconvenience and thank you for your patience.

Kind Regards

Keen Software House: QA Department

URL

1

Bill L ●

Here is the same version of test file, run today and the odd motion still occurs. Open world and walk character forward past grating. Character will begin to vibrate and slide off road deck. Turn on jetpack to lift off of deck.

Regards,

Bill

Files:

URL

1

QA KeenSWH ●

Hello, Bill,

thank you so much for going through this process with us.

The issue is really observable on the provided save and grid there.

Issue has been reported into our internal system.

Kind Regards

Keen Software House: QA Department

URL

Unexpected Motion

Replies (3)