Open collaborative project - "Hard-code physics mode" (Realistic Physics?)

Reference:
http://forums.keenswh.com/threads/thrusters-applying-force-relative-to-center-of-mass.6577869/
(and other threads!)

Goals:
To mod the source code enough to add a "Hard-core physics mode" option to the world settings, and rewrite the thrust/gyro/etc. code to incorporate this setting.
To allow people who want the challenge of building balanced ships (in terms of center of mass and thruster placement) that option.
(Optional) To push the modified code back to KSH as an update to vanilla.

Methods:
I don't have all of the skills or capabilities to finish this project, but I imagine it will be popular enough that other modders want to participate or even take lead. Suggestions are welcome here, as long as they are related to a project goal.

 

Relevant Files:
SpaceEngineers-master\Sources\Sandbox.Game\Game\GameSystems\MyGridGyroSystem.cs
SpaceEngineers-master\Sources\Sandbox.Game\Game\GameSystems\MyGridThrustSystem.cs
SpaceEngineers-master\Sources\Sandbox.Game\Engine\Utils\MyFakes.cs

In MyFakes.cs:

Code:

        // To make player experience better, slowdown will be faster than acceleration by this ratio
        public static float SLOWDOWN_FACTOR_THRUST_MULTIPLIER = 10.0f;
        public static float SLOWDOWN_FACTOR_TORQUE_MULTIPLIER = 5.0f;
        public static float SLOWDOWN_FACTOR_TORQUE_MULTIPLIER_LARGE_SHIP = 2.0f;

Dropping these all to 1.0 would be realistic, and not have dampeners provide "magic thrust" to stop faster.

 

Is it going to be dumb hardcore mode, like in, say, Robocraft, where the thrust has to be perfectly balanced and there is no way of adjusting *anything* to fix a problem?

Or one where if say, left side has one more engine than right side, it's not going to use it, and in order to achieve high efficiency the thruster will have to all balance out around the center of mass.

No one would build a system with thrusters which would become unbalanced and unable to fix itself if one thruster conks out.

____________________________

The mathematics of turning and moving ships are all quite simple, but actually implementing them correctly for 3d , another thing entirely.

 

Hi, I'm happy to see this. We thought about this kind of physics but it seems to hard-core for all players
Imho there should be some intelligent system which would translate movement/rotation commands to thruster power.
So say you want to fly forward by pressing 'W' and rotate left by slightly moving mouse left. The system will choose optimal thruster combination and output to achieve best performance possible.

 

Like it was mentioned in many threads before this one - such change must also go with "balancer" block that would automatically balance thruster output and use gyros to keep ship straight, or at least attempt so.
I would also like to have ability to manually balance output of each thruster in relative %.

 

Having these exposed in the advanced settings would be pretty neat too. So people could pick if they either want 1.0f, 2.0f, default 10.0f, high 100f or even hand control over to manual again with 0.5f
Same for gyros of course.

Either exposing them one by one, which of course is more work for the implementation, or do a multiplier for all of them in the range of like 0.01 to 10f.
Having thrusters affect either their position or the center of mass would of course be a individual checkbox.

So yeah i fully support this idea. Options are always great.


Sadly however i am new to git and thus am not even able to properly push my own changes for the ingame programming API. Thus even though that project interests me, i am not able to properly contribute myself. (Beside the fact that i am not done with ingameAPI changes too)

 

Yes! I've been wanting this for ages. Sadly I'm crap at modding, so I can't help you, but I look forward to seeing it finished!

 

I'd be interested in helping out with this. Here's my current idea:

In addittion to its force value, each thruster would have 3 values (x,y,z) for the torque it will apply to the parent grid. Each axis will be calculated from the thrusters force, direction, and distance from center of mass (I don't know the formula for this, so i'll need help there). To save on cpu load, it will only be calculated when the ships center of mass changes (moving cargo, adding blocks, exploding, etc).

When the player presses a move button, it will add up the torque values for every thruster on that side, and tell the gyros to apply the exact opposite torque (If the gyros aren't strong enough, it's time to redesign your ship!)

For turning, the game will need a list of all thrusters in each quadrant(above, below, to the left, and to the right of the center of mass) on each side of the ship. When the player wants to turn, the ship will fire thrusters on opposite sides and quadrants as well as gyros to provide torque.

I can't currently get to the source code right now, so I'll check if all of this is possible when I get home.

 

Ok, I've figured out most of how I can implement this, but first, I'll need someone to explain to me how torque works as if I was a six year old ops:.

 

I'm not well versed in what physics implementations are out there. What would this actually do to gameplay?
It sounds like it would just alter the effectiveness of dampers and Gyros. Is there more to it?
I get what you are saying about the CoM but, I'm having difficulty translating that into its gameplay effect...

 

It looks like
SpaceEngineers-master\Sources\Sandbox.Game\Game\Entities\BlocksMyShipController.cs
is also important - it translates player input into movement and rotate commands. It also updates the HUD data for people who are interested in that...

 

The biggest effect would be the point where thruster forces act on.

Right now you can have any shape as ship, place all thrusters for one direction at the outmost point and it would still fly forward because the thruster forces actually act on the center of mass and not there they actually originate.
With the changed model you had to evenly balance the thrusters un order to not spin around.


The main difficulty i see here though is that it would require an interpreter layer inbetween the user inputs at where we want to fly to and the actual output that drives the thrusters.
Thus an algorithm is needed that gets all potential moments and forces and then balances them out so that the userinputs are met with the highest possible output each.

A very simple example for that would be a ship with two thrusters and a center of mass that is not within the middle of them.


As you can see, both thrusters are at the same "heigt" as the center of mass and perpedicular to the direction vector to the center of mass location.
Now if both thrusters would have the same force F1 = F2 = 10 N and d were 1 m, the moment M around the center of mass would be: M = 2d * F2 - F1*1d = 1 m * 10 N = 10 Nm.
As you can see, to have a moment of 0 Nm around the center of mass, you had to solve the solution M = 2d * F2 - F1 * 1d = 0 -> 2d * F2 = 1d F1 -> 2 F2 = F1.
And that is of course just a simple example for two thrusters. Imagine that for 100 thrusters like many ships got.

So if you would blindly fire all thrusters with the above setup, you would permanently spin to the left. In a real scenario, without evening the thrusters out and compensating them with gyro moments, you almost always had a spin in any direction much like it is right now with off-grid masses like rotor/piston added centers of mass.

I hope that kinda explains the possible impact and difficulty for implementation for you.

 

I love the whole having to balance a craft realistically, it is both challenging and fun, I will certainly be watching to see what comes of this.

Kerbal Space Program is fun for this reason

 

Don't forget that the limits on thrusting and turning due to the amount of power available on the ship is also handled in the thrust and gyro system code.

Possible algorithm:
1. Calculate linear thrust from blind-firing thrusters when direction key is pressed, and apply to center of mass.
2. Calculate torque from sum of thrusts (a single vector) about the center of mass. Reduce this torque by the amount of available gyro capacity (look at how this is handled currently in the gyro grid system w.r.t. overridden and controlled gyros).
3. Apply the reduced torque to the grid. EDIT: if it hasn't been reduced to zero.
4. (optional A) ships that could be unbalanced at high thrust could have a mode to reduce thruster output to the maximum safe amount that the gyros can handle.
5. (optional B) ships could enable a mode to use thruster output to boost turning and add fake extra gyro capacity. For sanity reasons this will not use the thrusters that are currently controlled by the player.

Gameplay changes:
If your ship is very unbalanced and doesn't have enough gyros to compensate for that, it will spin when thrusting. Ships that have enough gyros (that are not being used for something else) will fly straight.
(optional A) ships with a mode selected would always thrust straight, but thrust output would be kept to a level such that gyros could null the torque.
(optional B) A ship tries to accelerate straight forwards, but the rear thrusters are below the center of mass, so it would pitch up. The ship doesn't have enough gyros to null the turning, but with this option the Top Front and Bottom Rear thrusters flare up to keep the ship accelerating and pointing in the pilot's intended direction. If the pilot tried to press "w" and "space" at the same time, the ship would pitch up because the top/bottom thrusters couldn't be used to null the turn.

An interpreter could figure out that an unbalanced ship will turn in a direction, but that the pilot is commanding the gyros to turn in that direction, so it doesn't need to be resisted. This may cause ships to turn faster up than down, or faster left than right, for example.

 

Also, sub-grids. The algo should compensate for added mass, right now put a piston with something heavy on it and see the world spin.

 

< Outdated code snippet removed >

 

Ya see, I don't really see the point of getting thrusters to apply torque, and then just magically countering it using gyros. It's like an awful lot of work to go to, for not much actual game play change.
How about this, forgive me if I miss something obvious (it's early). If thrusters apply torque, could you not change gyros completely. And stop them applying torque at all, but instead turn them into a kind of thruster control computer or something like.
So stealing plaYer2ks pic to illustrate:


If the player presses W for forward, the gyro gets the thruster on the left to fire at max, and the thruster on the right enough to balance it (whats that? F2 = F1/2?). If you wanted to turn right, it would fire F1 and not F2 etc.
This would mean that there's an actual point to having thruster torque. It would encourage balanced thruster layout, as whilst you could achieve linear motion with unbalanced thrusters, you wouldn't be using them as efficiently as you could.

 

You've never played KSP have you? KSP also has/had multiple variations of a magic-like SAS system that regulates basic movements.
What you propose is just a vanilla hardcore-lite approach that has the benefit of not worrying about gyro dampening power, which I feel would come into play in the other system.

Your idea sort of diminishes the role of gyros as a regulating device into no role at all. I personally prefer the idea that the system would be fully fleshed out and have gyros put into a regulatory SAS-type role while in this mode. It has massive gameplay implications on a creative level and on an in-combat level. Don't forget those gyros can be destroyed, thus losing your compensation for your design flaws. As you take damage, you would continue to lose your regulatory control system. Ships would need good pilots and crew to handle these dynamic changes depending on the design of the ship.

On another note:
The balance this would bring to PvP...of which there is none when it comes to close ship-to-ship combat, is a big deal beyond just the skill.
So regardless of how this is implemented...it just needs to be an option.
Applying yields via gyros is the biggest bane to the idea of PvP in Space Engineers and SE will never have good combat until this system is fixed. It enables far too much trolling and ridiculousness.

Sure, it is fun for creativity and simplicity, so leave it as an option.
However, no survival server with intentions of having PVP would ever use the current system where gyro's can be stacked to the point of spinning massive ships like they are a fan-blade.
People with no regard for thruster placement, power, or structural integrity realism will continue to do what they have always done. Which is just slam their ships into you as fast as they can move their mouse.
That's not at all fun for those of us who see SE as having the potential to be the ultimate space RPG.

 

Realistic thruster physics?

 

I get what you're saying it would have a big impact. I have not played KSP. But there's a few points.
This thread is about hardcore physics mod, not vanilla in any way as far as I am aware. People are talking about making thrusters apply torque already, so take that as moot.
But then they are also talking about keeping the current gyro, which as far as I am aware are complete nonsense in a hardcore physics view. To provide magic counter torque against the natural torque that thrusters would cause if they were asymmetrical and all just fired at max. That just doesn't make sense to me.
If you instead made the gyro into a "nav computer" kind of thing (that contained an actual gyroscope to maintain an idea of it's orientation). And then it would have a very important function, that is managing thruster outputs to maintain various vectors. This control system would help make it user friendly as the pilot shouldn't have to worry so much about what each thruster is doing.

 

Interesting ideas.
For reference: http://en.wikipedia.org/wiki/Control_moment_gyroscope

Within your idea,
1. Would there be a benefit to having more than one gyro? If so, how would performance change as gyros were destroyed or shut down?
2. Would grids be unable to rotate unless they had (enough) thrusters?
3. Would you accept gyroscopes being able to apply torque, if some type of gyroscope saturation and desaturation was modelled? How do you think the HUD/UI could communicate to the player that saturation had occurred?

Knsgf's experiment (see video above) may help in this regard.

Part of the issue is that, AFAIK, sub-grids have their own instance of the power, gyro, and thruster systems.
Another issue might be to distinguish between rotor/piston subgrids and connector subgrids. There can be situations where a subgrid has its own player pilot (player turrets or docked ships) that are trying to do something the big ship doesn't necessarily agree with.


EDIT:
SpaceEngineers-master\Sources\Sandbox.Game\Game\MyPerGameSettings.cs includes:

Code:

		public static float DefaultLinearDamping = 0f;
		public static float DefaultAngularDamping = 0.1f;

This is the source of the magic space friction that stops grids from rotating eventually, as well as making it more difficult for large ships to turn.
0.1 means that, each simulation step, the angular deceleration is the angular velocity (in radians) divided by 10. With this enabled (by default), ships rotating at 3.1 radians per second need to exert enough torque against the angular space friction to counter the 0.31 radians/s2 deceleration.

 

part of issue is center of mass.

and yes, there will need to be difference between subgrids with "fixed" connection and "temporary" connection.

no nitpicking, i know, that rotors can be dettached. but essentialy "temporary" connections are connectors and landing gear, othere are more or less in "fixed" category (even merge block)

 

Thruster torque has been added in its raw form. So let's try taking some of the stock ships for a spin. I mean, literally.

 

Now, how would this be implemented in a game or server once its done? Can it be done like a mod?

 

So... @Knsgf, did i get this right, all the ships get balanced automatically by gyros, but consume more energy by gyroscopes/are slower? that would be optimal, that way you can build optimized ships by centering / mirroring the thrusters, but unbalanced thrusters get you a slower / more power consuming ship

 

Sandbox.Game.GameSystems.MyGridThrustSystem includes this excerpt:

Code:

                if (Thrust.LengthSquared() > 0.001f)
                {
                    if (m_grid.Physics.Enabled)
                        m_grid.Physics.AddForce(MyPhysicsForceType.ADD_BODY_FORCE_AND_BODY_TORQUE, Thrust, null, null);
                }

The definition of AddForce from Sandbox.Engine.Physics.MyPhysicsBody:

Code:

        /// <summary>
        /// Applies external force to the physics object.
        /// </summary>
        /// <param name="type">The type.</param>
        /// <param name="force">The force.</param>
        /// <param name="position">The position.</param>
        /// <param name="torque">The torque.</param>
        public override void AddForce(MyPhysicsForceType type, Vector3? force, Vector3D? position, Vector3? torque)
        {
            force.AssertIsValid();
            position.AssertIsValid();
            torque.AssertIsValid();

            System.Diagnostics.Debug.Assert(IsInWorld == true);

            if (IsStatic)
                return;

            switch (type)
            {
                case MyPhysicsForceType.ADD_BODY_FORCE_AND_BODY_TORQUE:
                    {
                        if (RigidBody != null)
                        {
                            Matrix tempM = RigidBody.GetRigidBodyMatrix();
                            tempM.Translation = Vector3.Zero;

                            if (force != null && !MyUtils.IsZero(force.Value))
                            {
                                Vector3 tmpForce = Vector3.Transform(force.Value, tempM);

                                //RigidBody.Activate(true);
                                //RigidBody.ApplyForce(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, tmpForce * 0.0001f);
                                RigidBody.ApplyLinearImpulse(tmpForce * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                                //RigidBody.ApplyCentralImpulse(tmpForce);
                            }

                            if (torque != null && !MyUtils.IsZero(torque.Value))
                            {
                                Vector3 tmpTorque = Vector3.Transform(torque.Value, tempM);
                                //SharpDX.Vector3 tmpTorque = SharpDXHelper.ToSharpDX(torque.Value);

                                // RigidBody.Activate(true);
                                //RigidBody.UpdateInertiaTensor();
                                //RigidBody.ApplyTorque(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, tmpTorque * 0.0001f);
                                RigidBody.ApplyAngularImpulse(tmpTorque * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                                //RigidBody.ApplyTorqueImpulse(tmpTorque);
                            }
                        }
                        if (CharacterProxy != null)
                        {
                            Matrix tempM = Entity.WorldMatrix;
                            tempM.Translation = Vector3.Zero;

                            if (force != null && !MyUtils.IsZero(force.Value))
                            {
                                Vector3 tmpForce = Vector3.Transform(force.Value, tempM);

                                CharacterProxy.ApplyLinearImpulse(tmpForce * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                            }
                            if (torque != null && !MyUtils.IsZero(torque.Value))
                            {
                                Vector3 tmpTorque = Vector3.Transform(torque.Value, tempM);

                                CharacterProxy.ApplyAngularImpulse(tmpTorque * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                            }
                        }
                        if (Ragdoll != null && Ragdoll.IsAddedToWorld && !Ragdoll.IsKeyframed)
                        {
                           
                            foreach (var rigidBody in Ragdoll.RigidBodies)
                            {

                                if (rigidBody != null)
                                {
                                    Matrix tempM = rigidBody.GetRigidBodyMatrix();
                                    tempM.Translation = Vector3.Zero;                                   
                                    if (force != null && !MyUtils.IsZero(force.Value))
                                    {
                                        Vector3 tmpForce = Vector3.Transform(force.Value, tempM) * rigidBody.Mass / Ragdoll.Mass;

                                        //RigidBody.Activate(true);
                                        //RigidBody.ApplyForce(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, tmpForce * 0.0001f);
                                        rigidBody.ApplyLinearImpulse(tmpForce * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                                        //RigidBody.ApplyCentralImpulse(tmpForce);
                                    }

                                    if (torque != null && !MyUtils.IsZero(torque.Value))
                                    {
                                        Vector3 tmpTorque = Vector3.Transform(torque.Value, tempM) * rigidBody.Mass / Ragdoll.Mass;
                                        //SharpDX.Vector3 tmpTorque = SharpDXHelper.ToSharpDX(torque.Value);

                                        // RigidBody.Activate(true);
                                        //RigidBody.UpdateInertiaTensor();
                                        //RigidBody.ApplyTorque(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, tmpTorque * 0.0001f);
                                        rigidBody.ApplyAngularImpulse(tmpTorque * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                                        //RigidBody.ApplyTorqueImpulse(tmpTorque);
                                    }
                                }
                            }
                        }
                    }
                    break;
                case MyPhysicsForceType.APPLY_WORLD_IMPULSE_AND_WORLD_ANGULAR_IMPULSE:
                    {
                        if (RigidBody != null)
                        {
                            var offset = MyPhysics.Clusters.GetObjectOffset(ClusterObjectID);

                            if (force.HasValue && position.HasValue)
                            {
                                //this.RigidBody.ApplyImpulse(force.Value, position.Value);
                                //RigidBody.Activate(true);
                                RigidBody.ApplyPointImpulse(force.Value, (Vector3)(position.Value - offset));
                            }

                            if (torque.HasValue)
                            {
                                //RigidBody.Activate(true);
                                //RigidBody.ApplyTorque(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, torque.Value * 0.0001f);
                                RigidBody.ApplyAngularImpulse(torque.Value * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED);
                            }
                        }

                        if (CharacterProxy != null && force.HasValue && position.HasValue)
                        {
                            CharacterProxy.ApplyLinearImpulse(force.Value);
                        }
                        if (Ragdoll != null && Ragdoll.IsAddedToWorld && !Ragdoll.IsKeyframed)
                        {
                            foreach (var rigidBody in Ragdoll.RigidBodies)
                            {
                                if (rigidBody != null)
                                {
                                    var offset = MyPhysics.Clusters.GetObjectOffset(ClusterObjectID);

                                    if (force.HasValue && position.HasValue)
                                    {
                                        //this.RigidBody.ApplyImpulse(force.Value, position.Value);
                                        //RigidBody.Activate(true);
                                        rigidBody.ApplyPointImpulse(force.Value * rigidBody.Mass / Ragdoll.Mass, (Vector3)(position.Value - offset));
                                    }

                                    if (torque.HasValue)
                                    {
                                        //RigidBody.Activate(true);
                                        //RigidBody.ApplyTorque(MyEngineConstants.PHYSICS_STEP_SIZE_IN_SECONDS, torque.Value * 0.0001f);
                                        rigidBody.ApplyAngularImpulse(torque.Value * MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS * MyFakes.SIMULATION_SPEED * rigidBody.Mass / Ragdoll.Mass);
                                    }
                                }
                            }
                        }
                    }
                    break;
                case MyPhysicsForceType.APPLY_WORLD_FORCE:
                    {
                        if (RigidBody != null)
                        {
                            var offset = MyPhysics.Clusters.GetObjectOffset(ClusterObjectID);

                            if (force != null && !MyUtils.IsZero(force.Value))
                            {
                                if (position.HasValue)
                                {
                                    Vector3 point = position.Value - offset;
                                    RigidBody.ApplyForce(MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS, force.Value, point);
                                }
                                else
                                    RigidBody.ApplyForce(MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS, force.Value);
                            }                               
                        }
                        if (Ragdoll != null && Ragdoll.IsAddedToWorld && !Ragdoll.IsKeyframed)
                        {
                            foreach (var rigidBody in Ragdoll.RigidBodies)
                            {
                                if (rigidBody != null)
                                {
                                    var offset = MyPhysics.Clusters.GetObjectOffset(ClusterObjectID);

                                    if (force != null && !MyUtils.IsZero(force.Value))
                                    {
                                        if (position.HasValue)
                                        {
                                            Vector3 point = position.Value - offset;
                                            rigidBody.ApplyForce(MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS, force.Value * rigidBody.Mass / Ragdoll.Mass, point);
                                        }
                                        else
                                            rigidBody.ApplyForce(MyEngineConstants.UPDATE_STEP_SIZE_IN_SECONDS, force.Value * rigidBody.Mass / Ragdoll.Mass);
                                    }
                                }
                            }
                        }
                    }

                    break;
                default:
                    {
                        Debug.Fail("Unhandled enum!");
                    }
                    break;
            }
        }

We can see that APPLY_WORLD_IMPULSE_AND_WORLD_ANGULAR_IMPULSE type allows the "position" input (currently NULL for the thrusts, which use the BODY force type) for ApplyPointImpulse. ApplyImpulse (without a position) applies at the center of mass. Point impulses make Havok calculate the torque for us, we don't need to specify an additional torque.

If we want an unbalanced flight effect when trying to move in a direction, we would calculate the "center of thrust" (this concept may be familar for KSP players) and use that as the position for the force input.

 

I stand corrected to a certain degree. I still do not feel they would be used in that way on actual space craft that would require constant vector changing, rather than "holding position" like the ISS. Or that they would be necessary if powerful cheap electrically powered thrusters were available. For like... extremely small adjustments to keep things in whole numbers if that makes sense. But at a level where it could be abstracted out.

1. It seems obvious that thrusters would still operate per axis or facing. In my paradigm, gyros would be a Nav computer. If I was making this, I would probably go with requiring one nav comp per axis, so would require 3 for anything you want to move. The nav comp for an axis would control all the thrusters aligned to that axis. They would then have three things they could do. Create positive/negative linear motion along their own axis, or create positive or negative torque around the other two axes. Each of which should be a fairly simple calculation based on each thrusters distance from the centre of mass on that axis. Losing/damaging them would lose control over the relevant axis. But any additional nav comps you built on that axis could automatically assume control. Having more than 1 on any axis wouldn't have any additional effect beyond redundancy. Handling the thrusters that way would be simplifying reality, but in a way I feel I could accept at least. And would allow you to have thruster torque and still be able to fly things reasonably.

2. Yes, things without thrusters wouldn't be able to rotate on their own. Manually firing a thruster that was off the line of centre of mass would make things spin. And things that were already rotating would require thrusters and a nav comp on the relevant axis (or component) to stop. This would have quite bad implications for things like player turrets etc. But to me, the natural way those would work would be thru the rotors that connect it to the hull. Gyros have to be used for it now as a bad work around for poorly working rotors. Maybe stations should require gyroscopes to be able to be stations and remain "motionless". But that's one whole can of worms I don't really want to get into heh.

3. Honestly if it was down to me, I would scrap gyro torque and have no player indication of what's going on, beyond things like at the moment. I build a massive ship slap some gyros in it, try and turn and see what happens. But I'm getting the general feeling I would be in a minority there. And maybe instead of replacing gyros, you could have nav computers instead. Or something. Whatever really. Was just throwing my thoughts out there

 

Finally, I've slapped together a very basic RCS.

Before someone asks, no, RCS is not a practical solution for small ships. Thus it's not a good idea to remove gyroscopes from the game entirely.

 

Cool, but then I must ask...why not? And if they did have it, I feel like gyro's could still have -some- purpose.

 

Why not? Is it so hard to put thrusters at the edges of ships?