Better Thrust Control for Planets

Slushtrap Gamer shared this feedback ago

Submitted

*May have been posted already but could'nt find*

A small issue regarding thrusters in atmospheres is that if a weight is attached on the ship, through landing gear, rotor or connector (i.e anything that isnt part of the actual grid) will make the ship slowly sink even if it has more than enough thrust to hover with the added weight.

It's not a huge deal it's just annoying to constantly have to add small vertical thrust inputs to keep it level when carrying loads, even though the ship is more than capable of handling said load. Some scripts such as rotor thruster scripts seem to easily overcome this issue, however most builds don't feature these.

Take this more as a suggestion rather than a bug as it only affects planetary equipment and is not hard to deal with.

I like this feedback

Replies (2)

Chris Dusto ●

Going by this report, the dampening seems to directly take the mass of the grid into account (which is why it fails on subgrids). However, it might be interesting to see an implementation of a PID-based dampening system; this would allow for automatic dampening of additional forces (gatling fire, gravity "thrusters", etc.) in addition to accounting for subgrids automatically, while theoretically only using an insignificant increase in CPU time. It's also realistic, in that PID controllers are used all the time in robotics for things such as balancing.

Reply URL

Slushtrap Gamer ●

I will run some tests to see what the game actually considers as "Ship Mass".

Update: As it turns out the game calculates even the subgrids mass into the actual mass of the ship, be it through rotors, landing gear or connectors (note that this was done through scripts). But i don't think thats where the original system fails either. The real issue is (imo) in that subgrids don't behave the same way as they would were they part of the actual grid. If you attach a mass to the end of a rotor that mass behaves like a seperate entity, only it cannot move from the rotor's position. I think that because they are seperate entities the thrusters don't calculate their mass contrary to the script, which would mean that your theory is also correct

Reply URL

Chris Dusto ●

I think I've heard that there are many different definitions of "mass" for a ship: the physical mass (used for planetary gravity and inertia calculations), the grid mass (shown in info and when controlling a ship; this doesn't scale down inventory mass), the artificial mass (used for artificial gravity)... If the wrong mass is being used for the calculation, stuff won't work correctly (assuming the calculation is otherwise correct).

The root problem, to an extent, is how physics work, but this specifically is not a bug, and just a quirk of simulators like Havok. If we assume a simple case of a mothership (1,000,000kg) and daughtership (10,000kg) in a gravitational field of 10 m/s/s with dampening active on the mothership (which has enough thrust), Havok doesn't see a single entity with mass 1,010,000kg; it sees two entities, with their own forces from gravity (10,000kN and 100kN respectively). But also consider that gravity scales down with distance; if the daughtership is only experiencing 9.9m/s/s, that's only 99kN of force. If the mothership takes the mass of the daughtership into account, it would accelerate upwards at 0.0009901m/s/s (insignificant with these particular numbers, but if there's a steeper gravitational falloff the effect becomes more pronounced).

To properly fix this using a discrete system, one would need to be able to compute the total intertia of the connected-grid-system (which would effectively be the sum of the physical masses), but also compute the total planetary weight (sum for each grid physical mass times grid p-gravitational pull vector) and artificial weight (sum for each artificial mass block mass times artificial mass block a-gravitational pull vector). While this is all being done already, it might be internal to Havok or VRAGE (depending on where gravity is computed) and so harder to access at the level needed for implementing velocity dampening.

URL

Slushtrap Gamer ●

Needless to say this is nothing we can do much about other than hope that the developers step in and try to work for a solution. You brought up good points regarding as to what could potentially be the problem so i will add my knowledge to the pack. I think not only mass is what matters but also the origin of the forces. If we have the grid in equilibrium but then add a rotor on one side and add a mass there that mass is going to drag down the grid on that end but not the other. Since the system cannot make proper adjustments due to how the physics work this could explain why it is unable to correct the deviation and the grid starts sinking.

URL

Chris Dusto ●

Actually, if one can get the sum of the forces applied to an entity from Havok (I don't quite know if this is supported, but it is possible in several other physics engines) and expose it to a level that the dampening logic can access it, that coupled with the current inertia vector (mass * velocity) would be sufficient for a nearly-discrete system. If a copy of the total force vector is obtained from just before the velocity updating step, and the forces applied by the velocity dampening system are correctly accounted for from that vector, the logic can work with just a single physics frame of latency (which it technically is already doing, since the velocity it sees is from the previous physics frame).

URL

Slushtrap Gamer ●

The problem likely comes forth due to how thrust is applied to an entity. You can make a 100m long rod and put a single thruster on one end and that thruster will act as if the thrust is affecting the whole entity the same way, even though thrust is only applied to one corner. And this could be the key to solving this mystery. Let's assume that all thrust is calculated from the center of mass of the object, and then you have a mass dragging one side down. But as we know, there is no way to compensate for this since thrust cannot be applied to one corner or the other, only the center of mass. This results in the aformentioned dipping effect, since the game cannot apply thrust in such a way that would be required. Now this *could* be solved by a combination of gyroscopes and thrusters but maybe this corelation is lacking from the physics engine at this point.

URL