Brainstorm This Perfect turning system - no half-assed solution

[Megacrafter127]

Using chunks as discrete masses in the inertia calculation would probably be the best way to go. It wouldn't be nearly as computationally intensive as calculating the inertia of every single block (instead using chunks as massive 'blocks') and would also take into account negative space up to a certain degree of accuracy.

The total mass of a chunk would be calculated and the center of said chunk would be the location of the mass point. So basically, an empty chunk would rate as 0 mass, a filled one for 409.6 and then there's every value in between. Smaller ships wouldn't really be affected by the rather low accuracy (16x16x16 chunks) as they already have good turning speeds. A system like that would require something like 4000 times less points to be calculated and would still retain decent accuracy.

I don't code btw, so this is all just speculation. I am fairly familiar with the concepts though.

Tbh, it is possible to do the inertia for every block with some tweaks. First, calculate the inertia and center of mass of each individual chunk, and save those within the chunk. Then one can proceed as keptick suggested, and if a block is added/removed, only the affected chunk(s) are calculated in detail.

 

[Neon_42]

This. I have been thinking about this for a while now and this seems like the only viable and reasonably realistic solution. Using every individual block isn't doable since you'd have to recalculate inertia abd centre of mass for every block added or subtracted. Which is especially nasty for the subtraction part. Using a shipsized block is still quite unrealistic.
A few additions to the above post. I would suggest calculating the moments of inertia of each chunk as a cube of variable size but constant density, since moments of inertia scale linearly with mass but quadratic with size. Only changing the mass would have a 'dampened' effect.

Also using the full inertia tensor would cause some *interesting* things to happen if you think of user inputs as torques on the ship. Asymmetric ships would start start rotating about a different axus than the one you apply the torque to for example.

I'd say only use the x y and z moments of inertia and their 2d rotation equations. If you use the 3d set of equations you also have to take the rotational velocity about all other axes into consideration. This may give a more realistic feeling but is also most likely harder to implement.

Tl;dr: use chunkbased moments of inertia and center of mass calculation, calculate individual chunk values with mix of inferred size and mass of a cube, use only the principle momenta of inertia.

I think this could work. It still might be computationally expensive for extremely large ships.

 

[Megacrafter127]

I think this could work. It still might be computationally expensive for extremely large ships.

Once the ship gets that large, the same aspect can be done over "regions"(a block of 16x16x16 chunks)

 

[Malacodor]

Using every individual block isn't doable since you'd have to recalculate inertia abd centre of mass for every block added or subtracted. Which is especially nasty for the subtraction part.

Nothing has to be recalculated. Adding the hundredth block doesn't require more operations than adding the first block.

Also using the full inertia tensor would cause some *interesting* things to happen if you think of user inputs as torques on the ship. Asymmetric ships would start start rotating about a different axus than the one you apply the torque to for example.

Doesn't happen if the code only allows rotations about the desired axes.

Edit:
Calculating the inertia tensor and center of mass can be done when a ship is built, either when the player designs it or during construction in a shipyard. The performance impact shouldn't be notable.

 

[Megacrafter127]

Calculating the inertia tensor and center of mass can be done when a ship is built, either when the player designs it or during construction in a shipyard. The performance impact shouldn't be notable.

generally true, unless the ship is being built.

 

[jayman38]

Calculating the inertia tensor and center of mass can be done when a ship is built, either when the player designs it or during construction in a shipyard. The performance impact shouldn't be notable.

Don't forget that these things will need to be recalculated in the heat of battle, when the player's computer is already lagging due to all the other calculations. Even if it takes a while to calculate the changes, we are going to want to see changes in performance when we blow out a chunk of our enemy. Like it or not, they should suddenly become more maneuverable when half their ship is gone, as long as they have sufficient thruster blocks to move.

 

[EtherEel]

Similarly to the rest of the posters in this thread, this "New Turning Dynamics" has gotten stuck in my head. Amid the debates and formula and real-world physics, I find myself prompted to remind you all that this is Science Fiction and not the real world.

In our real world, we do not have starships, faster-than-light travel, anti-matter cannons, cloaking devises, or artificial gravity. In fact, the human body itself is not suited to life unbound from the earth. Why then, in our imaginary playground where science is merely the door, do we not think that should we be "advanced" enough in our mastery of "science" that we would have set physics on it's ear several times over?

I find my thoughts returning to the concept that Inertia and Mass would become quite irrelevant (or at least much less relevant). That large ships would be nimble, and small craft limited in usefulness thereby. The latter opinion no one else need share, but the former would certainly go a long way to making the game more playable, enjoyable, & hopefully programmable.

Simpler really is better. (Although I recognize that "Simple & Elegant" are often difficult to achieve.)

 

[Mered4]

The current system is an obvious undersiplification of the problem. You all seem to think that including dimensionality is a bad thing. This cant be further from the truth. If you want realistic turning then you need to include the dimensions of an object. This is basic physics. A solely mass based system doesn't work either. as for the swiss cheese cubes as I called them. To quote the OP:


It should be clear that calculating the real inertia tensor for a ship will be overly complicated(look at the wiki page), THUS A SIMPLIFICATION IS NECESSARY. If you simplify all ships to a box this works. More realistic turning than what we have with the appropriate scaling. Yes it is more realisitic Mered4 . It's amazing how many people claim to know more about my field than I do.

In terms of BALANCE and GAMEPLAY it should be clear that solely a mass based system is a more of a boost to the doom cubes, and they need to be balanced some other way.

I'm not claiming anything. I agree it would be more realistic to use box dims IF (and this is a big if) we were using thrusters like Space Engineers. There, turning is based on gyros, not thrusters.

In terms of balance and gameplay, your argument is flawed.
Right now, we have a size based turning system. It is monumentally more efficient to build a doom cube of X mass and Y volume than an equivalent, aesthetically pleasing (and possibly super-cool) ship of X mass and 2Y volume. In many cases, this is stretched to ships of X mass and 6-7Y volume.

However, if you went to mass only, ships of similar weight classes (and thus, similar stats) would all be rendered equal, no matter how efficient their block placement. It would level the playing field between cubes and everyone else.
[DOUBLEPOST=1426193823,1426193715][/DOUBLEPOST]

Similarly to the rest of the posters in this thread, this "New Turning Dynamics" has gotten stuck in my head. Amid the debates and formula and real-world physics, I find myself prompted to remind you all that this is Science Fiction and not the real world.

In our real world, we do not have starships, faster-than-light travel, anti-matter cannons, cloaking devises, or artificial gravity. In fact, the human body itself is not suited to life unbound from the earth. Why then, in our imaginary playground where science is merely the door, do we not think that should we be "advanced" enough in our mastery of "science" that we would have set physics on it's ear several times over?

I find my thoughts returning to the concept that Inertia and Mass would become quite irrelevant (or at least much less relevant). That large ships would be nimble, and small craft limited in usefulness thereby. The latter opinion no one else need share, but the former would certainly go a long way to making the game more playable, enjoyable, & hopefully programmable.

Simpler really is better. (Although I recognize that "Simple & Elegant" are often difficult to achieve.)

In regards to large ships, I really don't think making them *nimble* should be an easy task. It needs to cost a lot in terms of combat ability, because it really is a huge advantage against non-missile focused builds.

 

[EtherEel]

it really is a huge advantage against non-missile focused builds.

Non-missile weapons need to be made more effective, clearly. In the same light -- are there any non-missile focused builds? In the short time I've been around, seems like all I ever see are Missile-build ships. But this is off-topic, sorry....

And I'm sticking to my Star-Trek dynamic of big and nimble. That's why it's called an opinion. =)

 

[spacie]

Nothing has to be recalculated. Adding the hundredth block doesn't require more operations than adding the first block.


Doesn't happen if the code only allows rotations about the desired axes.

Edit:
Calculating the inertia tensor and center of mass can be done when a ship is built, either when the player designs it or during construction in a shipyard. The performance impact shouldn't be notable.

I seem to have made a slight misstep in my pondering about moment of inertia calculation when removing blocks. Though it's still wouldn't be very comfortable to have to wait for the calculations on every block you place, certainly when it's using advanced build mode where things can overlap and you don't end up with nice box-shapes. There could be an option to only calculate changes in inertia and c.o.m. (center of mass) when entering/exiting ships and/or entering/exiting buildmode and alleviating some of the computation by only calculating the changes/additions by new blocks. For small ships this might work, but if you place a couple thousand blocks it would probably get significantly more time consuming. It would probably require some testing to see how long it would actually take.
You most likely wouldn't be able to take battle damage into account because of computational requirements so there's that.

For the second part. When you derive the rotational equations of motion for an object, you get some really crazy stuff if your inertia tensor has entries outside of the diagonal. These are the equations you end up with:

where the I's are the entries in the inertia tensor, the omegas are the angular velocities of your object and the omegas with a dot are the angular accelerations. The M's are the input moments/torques. Basically, it's a giant mess of intermingledness. I can't remember a.t.m. if it's one or two planes of symmetry you need for a completely diagonal inertia tensor (i.e. where everything is 0 except for Ixx, Iyy and Izz), but you need symmetry nonetheless.
Notice how the angular velocity is only expressed in the directions of the x, y and z axes, so "only allowing rotation about the desired axes" wouldn't help a bit.
You can get rid of those pesky xy, yz, xz, etc, parts of the inertia tensor with some clever matrix transformations, but that also means you're no longer calculating rotations about your original axes, which isn't useful at all.

Now if you just completely disregard all parts of the inertia tensor except for the ones about the x y and z axes you get this:

Which is a lot easier to read for one and also a lot easier to implement and use. The parts on the left are the 2d rotational inertia basically: (moment of inertia about center of mass)*(angular accelleration)=(applied torque about center of mass).
The middle bit is where stuff gets interesting, a nice quirk of physics where if you are rotating about more than one axis, those rotations also influence your angular acceleration about other axes.


Now, something I had been thinking about was varying the size of the previously suggested "inertia chunks" so to speak. Having them at full chunk size when your ship is sufficiently large (i.e. is made up of more than 30 chunks for example) If it's smaller you would cut each chunk into 8 chunks of 8x8x8 blocks and use those for inertia approximation, if you go even smaller calculate for 4x4x4 chunks, after that you might want to jump to single block calculation. That way you end up with a reasonable approximation for pretty much every ship size and you don't need the massive computations for edits of thousands of blocks.

That is all for now, I hope it wasn't too confusing.

 

[whooplaah]

To start with: I didn't read all the posts in this thread. I'm not a physics major, so it's all above me in that regard and I just didn't understand most of it.

I'm not sure if this post was started before Dev's announced that thrust was going to be tuned to a Thrust-Allocation method. [[http://starmadedock.net/threads/thrust-mechanics-explained.2696/]] I've posted something relevant in other forums [[http://starmadedock.net/threads/titanomachie.6222/#post-90257]]

My 2-Cents:
When I look at a ship, I should be able to tell on sight what it's maneuverability is like. A sphere will turn equally in all directions; a hot-dog will have some trouble; a small ship will be nimble; a large ship will be slow. Because of this the calculation should be realistic and intuitive.

However, we don't have to capture real-life physics. It's a game, and it's sci-fi, and it's freakin space so we can make some exceptions and be OK.

Assumptions:
1. The longer a ship is in any direction, the slower it will accelerate when turning in that direction.
2. The heavier a ship is, the slower it will turn.
3. Thrusters on the side of a ship can help turn as well as move sideways (from upcoming feature).
4. All objects can reach a maximum speed, but some objects accelerate faster.
5. We want to keep the game balanced between big ships and small ships.

Solution:
Turn Acceleration = ( (thrust along axis) / (length along axis) / (mass) ) * (an integer that brings it to a usable value)

There is a different value for each direction that the ship can turn (similar to the upcoming thrust change). Small ships have a huge advantage in maneuverability over large ships. Among fighter sized ships, the difference in adding 10 blocks means a huge change in speed. This also means that battleships will have to rely on their turrets to fend off fighters, but will be able to hit same-size and larger ships without much trouble.

Graph:

Spoiler

Each step on this graph is a linear increase in mass by +1000. That means that step 10 is about 10x the size of step 1. This graph also assumes that each ship is a perfect cube. Step 10 is 10,100 mass with turn speed of .205. At 450k mass turn speed is .091. At 900k mass turn speed is .078.

Math:

Spoiler

First, I assume that:
Thrust = (sum of dimensions of thruster array) - 3 + (number of thrusters)^1.125. This was once how thrust was calculated, is it still accurate?
Each ship is a solid doom-cube
All blocks weigh 1 mass
The ship balances it's thrust to all directions (that the thrust changes [link above] happen)
A random number (50) is used in the equation - it can be any positive number.

Ship 1:
Dimensions: 5x5x10
Mass: 250
Thrusters (20%): 50
Thrust: (5+5+2)-3+(50^1.125) = 9 + 81.5 = 90.5
Thrust per Mass: .062
Thrust/6 = 15.5
TURN ACCELERATION:
X/-X = (15.5 / 5 / 250) * 50 = .0124 * 50 = .62
Y/-Y = (15.5 / 5 / 250) * 50 = .0124 * 50 = .62
Z/-Z = (15.5 / 10 / 250) * 50 = .0062 * 50 = .31

Ship 2:
Dimension: 10x10x20
Mass: 2,000
Thrusters (20%): 400
Thrust: (10+10+4)-3+(400^1.125) = 21 + 845.9 = 866.9
Thrust per Mass: .07
Thrust/6 = 140.98
TURN ACCELERATION:
X/-X = (140.98 / 10 / 2000) * 50 = .007 * 50 = .35
Y/-Y = (140.98 / 10 / 2000) * 50 = .007 * 50 = .35
Z/-Z = (140.98 / 20 / 2000) * 50 = .0035 * 50 = .17

Ship 3:
Dimensions: 15x15x30
Mass:6750
Thrusters (20%): 1350
Thrust: (15+15+4)-3+(1350^1.125) = 33 + 3323.73 = 3356.73
Thrust per Mass: .08
Thrust/6 = 559.46
TURN ACCELERATION:
X/-X = (559.46 / 15 / 6750) * 50 = .0055 * 50 = .27
Y/-Y = (559.46 / 15 / 6750) * 50 = .0055 * 50 = .27
Z/-Z = (559.46 / 30 / 6750) * 50 = .0028 * 50 = .14

Compare:
Ship 1 -> Ship 2
Dimensions: x2
Mass: x8
Turn Acceleration: x0.56

Ship 1 -> Ship 3
Dimensions: x3
Mass: x15
Turn Acceleration: x0.43

Ship 2 -> Ship 3
Dimensions: x1.5
Mass: x3.375
Turn Acceleration: x0.77

Extrapolate:
The calculation of thrust is exponential, therefore this calculation of turn acceleration is also exponential. As the size of the ship increases, the amount of turn speed lost is decreased - eventually hitting a limit around .05

Aside:

Spoiler

If we make it so that mass affects your accuracy (by giving your lasers a random offset to trajectory and making it harder to lock-on to small ships with missiles) then we can let huge ships have more turn speed and maneuvering. Accuracy changes by mass will be offset by the fact that ships of equal size are big, and just as inaccurate.

 

[spacie]

To reply to whooplaah on why using only the maximum dimensions and mass would be a bad idea, let me give you an example:

We have two ships here with equal mass and equal maximum dimensions:
Ship A

and Ship B

if you now look at their length from side to side and their mass and only use that for turning acceleration, you would come to the same number for both of these, which is also what starmade seems to do a.t.m. (turningspeeds being 5 5 and 3.9 for both "ships")
Now if you take each block as having length 1 and mass 1, you can quite easily calculate each ship's moment of inertia about the axis pointing towards you, to the right. After some reasonably simple math we arrive at a value of 1439.5 for A and a value of 369.5 for the second ship. Meaning that ship A should be turning about 4 times slower (1439.5/369.5=3.98) than ship B in reality.

If it was just a 20% or so difference between the current system and actual moment of inertia calculations, I wouldn't mind. But as this example demonstrates, the differences can be massive. This is mainly a bad thing when building ships with long bits sticking out; wings, antennae, basically stuff people like to stick on spaceships. Which is why I personally think that the current system or any other based only on overall dimensions/mass is not sufficient.

 

[Malacodor]

Don't forget that these things will need to be recalculated in the heat of battle, when the player's computer is already lagging due to all the other calculations. Even if it takes a while to calculate the changes, we are going to want to see changes in performance when we blow out a chunk of our enemy.

A missile explosion turns blocks into debris, which still hampers ship rotation for a short while until it flys away.

Now if you just completely disregard all parts of the inertia tensor except for the ones about the x y and z axes you get this:
View attachment 9947
Which is a lot easier to read for one and also a lot easier to implement and use. The parts on the left are the 2d rotational inertia basically: (moment of inertia about center of mass)*(angular accelleration)=(applied torque about center of mass).
The middle bit is where stuff gets interesting, a nice quirk of physics where if you are rotating about more than one axis, those rotations also influence your angular acceleration about other axes.

This looks good.

Solution:
Turn Acceleration = ( (thrust along axis) / (length along axis) / (mass) ) * (an integer that brings it to a usable value)

This severely punishes the use of decorative elements that have low mass but increase ship dimensions like antennas.

 

[Mered4]

Again, the original idea would work beautifully IF we had unlimited computation power. It addresses the issue with antennas and the like, while also keeping ships with equal mass on the same footing, even if their weight distribution is drastically different.

That said, we don't have unlimited computational power.
What we CAN do, however, is limit the computation necessary to solve the algorithms. There are plenty of programmable ways to do this, and I'm sure schema knows far more on that front than I or anyone else on this forum.

 

[Trekkerjoe]

Now, something I had been thinking about was varying the size of the previously suggested "inertia chunks" so to speak. Having them at full chunk size when your ship is sufficiently large (i.e. is made up of more than 30 chunks for example) If it's smaller you would cut each chunk into 8 chunks of 8x8x8 blocks and use those for inertia approximation, if you go even smaller calculate for 4x4x4 chunks, after that you might want to jump to single block calculation. That way you end up with a reasonable approximation for pretty much every ship size and you don't need the massive computations for edits of thousands of blocks.

That is all for now, I hope it wasn't too confusing.

^This^And I was just about to suggest that.

 

[whooplaah]

What if the mass of a block was modified by it's distance from the ship core? I thin that captures the idea of spacie 's post.

When we place a block, we calculate it's distance from the ship core. We then multiply it's mass by that distance to get how much it affects the maneuverability. We then take the ship's total maneuverability and divide it by the total blocks in the ship.

This means that two ships of equal mass but different shape will have different turn speeds. A ship that concentrates heavy blocks around the core turns faster than one that has an empty heart but heavy skin. It also means that long antenae will only have large impacts on turn speed if the antenae offsets the concentrated weight of the ship. When a block is destroyed, it's maneuverability value is removed from the ship's equation (just like removing it's mass and block count). We can use the maneuverability to calculate turn speed based on thrust allocation for that axis (upcoming feature).

This is difficult for me to calculate with spreadsheets, so this is a very loose example:

Ship A:
A hollow box measuring roughly 9x9x10
Blocks are as close as 4.5 and as far as 5.6
Total Blocks: 521
Maneuverability: between 2344 and 2917
Average: 5261

Ship B:
Solid cube 8x8x8
Blocks are as close as 1 and as far away as 4
Total Blocks: 512
Maneuverability: between 560 and 2240
Average: 1400

Ship C:
Solid box 8x8x8 with an antenna 1x1x9
Body: Blocks are as close as 4.5 and as far as 5.6
Antenna: Blocks are as close as 5 and as far away as 14
Total blocks: 512 (body) + 9 (antenna)
Maneuverability: between 560 and 2240 (body) plus between 45 and 126 (antenna)
Average: 1485.5

 

[Megacrafter127]

What if the mass of a block was modified by it's distance from the ship core? I thin that captures the idea of spacie 's post.

When we place a block, we calculate it's distance from the ship core. We then multiply it's mass by that distance to get how much it affects the maneuverability. We then take the ship's total maneuverability and divide it by the total blocks in the ship.

This means that two ships of equal mass but different shape will have different turn speeds. A ship that concentrates heavy blocks around the core turns faster than one that has an empty heart but heavy skin. It also means that long antenae will only have large impacts on turn speed if the antenae offsets the concentrated weight of the ship. When a block is destroyed, it's maneuverability value is removed from the ship's equation (just like removing it's mass and block count). We can use the maneuverability to calculate turn speed based on thrust allocation for that axis (upcoming feature).

This is difficult for me to calculate with spreadsheets, so this is a very loose example:

Ship A:
A hollow box measuring roughly 9x9x10
Blocks are as close as 4.5 and as far as 5.6
Total Blocks: 521
Maneuverability: between 2344 and 2917
Average: 5261

Ship B:
Solid cube 8x8x8
Blocks are as close as 1 and as far away as 4
Total Blocks: 512
Maneuverability: between 560 and 2240
Average: 1400

Ship C:
Solid box 8x8x8 with an antenna 1x1x9
Body: Blocks are as close as 4.5 and as far as 5.6
Antenna: Blocks are as close as 5 and as far away as 14
Total blocks: 512 (body) + 9 (antenna)
Maneuverability: between 560 and 2240 (body) plus between 45 and 126 (antenna)
Average: 1485.5

This system of yours can easily be caused have a lot less impact on performance, how is explained in the following 3 quotes:

Using chunks as discrete masses in the inertia calculation would probably be the best way to go. It wouldn't be nearly as computationally intensive as calculating the inertia of every single block (instead using chunks as massive 'blocks') and would also take into account negative space up to a certain degree of accuracy.

The total mass of a chunk would be calculated and the center of said chunk would be the location of the mass point. So basically, an empty chunk would rate as 0 mass, a filled one for 409.6 and then there's every value in between. Smaller ships wouldn't really be affected by the rather low accuracy (16x16x16 chunks) as they already have good turning speeds. A system like that would require something like 4000 times less points to be calculated and would still retain decent accuracy.

I don't code btw, so this is all just speculation. I am fairly familiar with the concepts though.

Tbh, it is possible to do the inertia for every block with some tweaks. First, calculate the inertia and center of mass of each individual chunk, and save those within the chunk. Then one can proceed as keptick suggested, and if a block is added/removed, only the affected chunk(s) are calculated in detail.

Once the ship gets that large, the same aspect can be done over "regions"(a block of 16x16x16 chunks)

 

[Malacodor]

What if the mass of a block was modified by it's distance from the ship core?

That's basically how the inertia tensor is calculated.

 

[mrsinister]

what if we went with a more simpler approach.... now this is just of the top of my head mind ya's
we still use what's current BUT if you can manage to get over thrust to mass ratio have it lessen turn time based on how much over mass the thrust is? ya know like a % base and if you go double or more over mass then you can almost turn as fast as a heavy fighter? I really don't want my 300m long ship turning like a fighter but dang, it has to turn a hell of a lot faster than it is now....lol I feel like i am waiting 4 years for it to turn.

 

[NeonSturm]

In our real world, we do not have starships, faster-than-light travel, anti-matter cannons, cloaking devises, or artificial gravity. In fact, the human body itself is not suited to life unbound from the earth. Why then, in our imaginary playground where science is merely the door, do we not think that should we be "advanced" enough in our mastery of "science" that we would have set physics on it's ear several times over?

True, true, true, false, false. That`s why we enhance our abilities with technology.

4> We have cloaking devices, but just for one single point of view per side.
We can even easily enhance this by converting light to radio-waves and these back to light at the other side of an object, or using lenses/mirrors to bend the light around some mass.
The only downside is that this does not work for the whole bandwidth of frequencies and has some weight + requirements on hull materials.

5> Just use centrifugal force.

My 2-Cents:
When I look at a ship, I should be able to tell on sight what it's maneuverability is like. A sphere will turn equally in all directions; a hot-dog will have some trouble; a small ship will be nimble; a large ship will be slow. Because of this the calculation should be realistic and intuitive.

This!

Assumptions:
1. The longer a ship is in any direction, the slower it will accelerate when turning in that direction.
2. The heavier a ship is, the slower it will turn.
3. Thrusters on the side of a ship can help turn as well as move sideways (from upcoming feature).
4. All objects can reach a maximum speed, but some objects accelerate faster.
5. We want to keep the game balanced between big ships and small ships.

1> WITH that direction. Turning affects 2 axis.

5> Big ships should be rare. Only this preserves the awesomeness of planets and stations, which needs balance (and some love) too (for their immobility).

To reply to whooplaah on why using only the maximum dimensions and mass would be a bad idea, let me give you an example:

We have two ships here with equal mass and equal maximum dimensions:
Ship A
View attachment 9982
and Ship B
View attachment 9983
if you now look at their length from side to side and their mass and only use that for turning acceleration, you would come to the same number for both of these, which is also what starmade seems to do a.t.m. (turningspeeds being 5 5 and 3.9 for both "ships")
Now if you take each block as having length 1 and mass 1, you can quite easily calculate each ship's moment of inertia about the axis pointing towards you, to the right. After some reasonably simple math we arrive at a value of 1439.5 for A and a value of 369.5 for the second ship. Meaning that ship A should be turning about 4 times slower (1439.5/369.5=3.98) than ship B in reality.

If it was just a 20% or so difference between the current system and actual moment of inertia calculations, I wouldn't mind. But as this example demonstrates, the differences can be massive. This is mainly a bad thing when building ships with long bits sticking out; wings, antennae, basically stuff people like to stick on spaceships. Which is why I personally think that the current system or any other based only on overall dimensions/mass is not sufficient.

I fully agree.

_____________________________________
What do you think about inertia-based engines?

1. Accelerate the sideways-rotation of a gyroscope (f0->f1)
2. Accelerate it toward the ship`s rear (f1->f2 (forward force) = HypotenuseOf(1, 1) = 1.4 ).
3. Break the sideways-rotation of the gyroscope (f2->f1 Does not affect the speed to the ship`s rear).
4. Break the movement toward the ship`s rear (f1->f0 (backward force) = just 1 )
5. Difference between backward and forward force = 0.4