Air resistance... in space?

[BlueTemplar]

By just adding flat ±10 km/s after all the calculations you will get exactly that. For the purposes of this "friction" we can just ignore that shift.

You won't, and you can't, because the equations have non-linear velocity components. (EDIT : rather than 'non-linear', I think the proper term is 'non-translation-invariant' ? They are neither though.)

It doesn't matter relative to what the speed must reach zero, since the force of friction is calculated based on that very same relative speed.

Yes, that's my theory now, but it's just a theory, and the above equation is insufficient to confirm or refute for certain this theory.

If there is no constant component, then at near-zero speeds the drag will also be near-zero, and the sequence will never converge.

At some point the difference would be lower than the displayed precision though.

[Pithlit]

I did some experiments with the forumla to find out what units are used.
I used the editor and some lua commads to read the speed and weigt values used by the game.

speed is in km/tick (=km/sec/60)
weight is in kg (=1000*ton)
When I assume that thrust is in KN (=1000*MN), the space_platform_acceleration_expression formula matches the values I meassured with a ship.
The +10/-10 km/s pull towards the nearest planet seems not to be included in the speed and acceleration used in the formula.

Here are some details of my meassurements:
Built a minimal ship with only the hub, one thruster fuelled with infinity pipes on a 8*12+4 tiles platform.
With 40t for the hub and 0.2t per tile, the weight is exactly 60t (60000kg)
The maximum shown speed after starting is 196.08.
The speed used in the formula is 196.08km/s + 10km/s = 206.08km/s = 3.43483 km/tick
The thrust is 102MN = 102000KN
When inserted in the foruma above, I get an equilibrium between drag and final_thrust at my maximum speed.
The calculated acceleration seems to be 1/60 of the acceleration per tick. So we need to multiply the result with 60 to get the correct acceleration per tick.

[Locane]

Ok, but why is there drag at all.... it's space.

[Locane]

There's a mod for this for anyone who's wondering:
https://mods.factorio.com/mod/Rocs-Impr ... tform-Drag

[IsaacOscar]

This is all very bizzare, why the platforms weight right next to the speed, when it's the width noth the weight that matters.

Also, other than by looking at this forum or the lua code, how is a player supposed to know how to make a faster space platform?

I suspect the dependence on width is to give diminishing returns to adding more thrusters (as the maximum number of thrusters you can have depends on the width, not the height or mass). However I also suspect that they made a typo or two in the formula, and didn't intend to have it work the way it actually does where weight is practically irrelevant.

[BlueTemplar]

Note that it was always more or less obvious that there was some kind of drag, and that it depended on speed : because speed is limited even with non-zero thrust.
It's that this drag would also only depend on width alone (and also a constant) which is somewhat less obvious.
But yeah, makes sense due to both width being a 2-dimentional equivalent to IRL's cross-sectional area and to the thruster placement requirements
(they do still require a bit of mass, and some extra area — which could mean width or height, for the refueling).

Also, other than by looking at this forum or the lua code, how is a player supposed to know how to make a faster space platform?

By experimenting with different platforms ? (You would probably still notice this, it would just take more time.)

----

Ok, but why is there drag at all.... it's space.

Gameplay reasons :

As someone who has it's own game developed with a space theme. Let me tell you: Newton's first law makes for really complicated unintuitive gameplay. It works for [Kerbal Space Program], because the whole game is about it. For Factorio, it's just a "scene", so having more intuitive mechanics make sense, and people understand "amount of fire = amount speed".

Yes, space-soup (as I've started to call it) isn't realistic. But it makes a lot of gameplay sense.

There is a lot of unrealistic stuff in Factorio, and that is fine. "Never let realism get in the way of good gameplay"
(putting a 1000 cargo wagons in a cargo wagon, inventory in general, making steel without carbon, nothing needing maintenance)


Note that I've tried Newtonian physics in my own space game, and the problem quickly becomes that a major part of the gameplay then becomes about managing that, instead of the other gameplay you envision for your game. Speeds can go off the charts, causing all kinds of other problems.


Changing Factorio to Newtonian physics would cause problems with the asteroid mining as well, slamming into an asteroid at 5km/s wouldn't be fun. Or, the asteroid mining becomes even more unrealistic if you have them match your speed and then you would have a new thing to complain about.

(from Dissapointed Space Age doesn't do Space correctly)

(Thanks for the mod link !)

----

I did some experiments with the forumla to find out what units are used.
I used the editor and some lua commads to read the speed and weigt values used by the game.

speed is in km/tick (=km/sec/60)
weight is in kg (=1000*ton)
When I assume that thrust is in KN (=1000*MN), the space_platform_acceleration_expression formula matches the values I meassured with a ship.
The +10/-10 km/s pull towards the nearest planet seems not to be included in the speed and acceleration used in the formula.

Here are some details of my meassurements:
Built a minimal ship with only the hub, one thruster fuelled with infinity pipes on a 8*12+4 tiles platform.
With 40t for the hub and 0.2t per tile, the weight is exactly 60t (60000kg)
The maximum shown speed after starting is 196.08.
The speed used in the formula is 196.08km/s + 10km/s = 206.08km/s = 3.43483 km/tick
The thrust is 102MN = 102000KN
When inserted in the foruma above, I get an equilibrium between drag and final_thrust at my maximum speed.
The calculated acceleration seems to be 1/60 of the acceleration per tick. So we need to multiply the result with 60 to get the correct acceleration per tick.

Thanks a lot !
(Sigh, I should have realized that the /60 was about the seconds <=> ticks conversion...)

Glad to see my latest theory confirmed !

Have you tried it on the last half of the journey, to see how maximum shown speed changes there ? I think it might be 216.08km/s (- 10km/s = 206.08km/s), but I'm getting confused — I would need to lay down the equations on paper again first.

(I guess surviving asteroids until then might be a challenge... good news walls are OP now !)

And/or could you please share your blueprint ?

[BraveCaperCat]

I suspect the dependence on width is to give diminishing returns to adding more thrusters (as the maximum number of thrusters you can have depends on the width, not the height or mass).

Wrong. With enough additional height, you can add more thrusters vertically. I mean, you do need to make a very "tall" space platform though, so it isn't super viable.

A better way to implement this "feature" would be to provide the amount of thrusters as a variable in the MathExpresion used for the equation:

Code: Select all

    -- drag_coefficient = width * 0.5
    -- drag = ((1500 * speed * speed + 1500 * abs(speed)) * drag_coefficient + 10000) * sign(speed)
    -- final_thrust = thrust / (1 + weight / 10000000)
    -- acceleration = (final_thrust - drag) / weight / 60
    
    space_platform_acceleration_expression = "(thrust / (1 + weight / 10000000) - ((1500 * speed * speed + 1500 * abs(speed)) * (width * 0.5) + 10000) * sign(speed)) / weight / 60",
    

Replacing the above with something more like this:

Code: Select all

	space_platform_acceleration_expression = "(thrust / (1 + weight / 10000000) - ((1500 * speed * speed + 1500 * abs(speed)) * (thruster_count) + 10000) * sign(speed)) / weight / 60",

Though you'd want to keep the width and height properties to maintain compatibility with mods which modify this calculation.

[mmmPI]

By just adding flat ±10 km/s after all the calculations you will get exactly that. For the purposes of this "friction" we can just ignore that shift.

You won't, and you can't, because the equations have non-linear velocity components. (EDIT : rather than 'non-linear', I think the proper term is 'non-translation-invariant' ? They are neither though.)

It seem to me that adding a flat 10 km/s or removing it is indeed what is happenning.

Have you tried it on the last half of the journey, to see how maximum shown speed changes there ? I think it might be 216.08km/s (- 10km/s = 206.08km/s), but I'm getting confused

It is the opposite that make sense. The second half of the journey you ADD 10km/S.
the first half you remove them.

If the speed for the first half is 216 kms then the second half would be a flat 20 km/s above so 236.

[BlueTemplar]

You seem to have confused Pithlit's reported ship's displayed celerity (which I before called 'speed' for short) ?

The maximum shown speed after starting is 196.08.

And ship's celerity used in the calculations (which I assume is relative to the interstellar æther flow, which I before called 'velocity' for short) :

The speed used in the formula is 196.08km/s + 10km/s = 206.08km/s = 3.43483 km/tick

----

I think the 'nonlinearity' should show here (but where exactly ??), but I need to look at the laid down equations first (and should have posted them in a more readable form than the code above too, but I'm somewhat embarrassed that my handwriting in pencil wouldn't be clear enough... and I didn't get around to use TeXmacs yet).

[mmmPI]

You seem to have confused Pithlit's reported ship's displayed celerity (which I before called 'speed' for short) ?

The maximum shown speed after starting is 196.08.

And ship's celerity used in the calculations (which I assume is relative to the interstellar æther flow, which I before called 'velocity' for short) :

The speed used in the formula is 196.08km/s + 10km/s = 206.08km/s = 3.43483 km/tick

----

I think the 'nonlinearity' should show here (but where exactly ??), but I need to look at the laid down equations first (and should have posted them in a more readable form than the code above too, but I'm somewhat embarrassed that my handwriting in pencil wouldn't be clear enough... and I didn't get around to use TeXmacs yet).

I don't think i have, i'm not mentionning anything related to the aether flow, i'm just saying that the calculations of drag = acceleration to calculate the terminal velocity of the ship gives you an answer a max speed which you have a + or - 10 km/s flat to add to make up for that little constant the devs added for gameplay reason = platform get less stuck, which mimick the direction of the gravitatonnal pull.

For such gameplay 10 km/s flat rules to work, the physic isn't necessarily respected, and so is for optimization of math, drag is only air resist at constant pressure and temperature for example , IRL it would be more complicated.

[BlueTemplar]

Their max shown speed on first half was 196.08 km/s, not 216 km/s.

I still haven't gotten to the equations again yet, but I've been paying attention to my first nuclear powered ship ( ), and it indeed switches from max 155.70 km/s in the first half to max 175.70 km/s in the second one.

[mmmPI]

Their max shown speed on first half was 196.08 km/s, not 216 km/s.

I still haven't gotten to the equations again yet, but I've been paying attention to my first nuclear powered ship ( ), and it indeed switches from max 155.70 km/s in the first half to max 175.70 km/s in the second one.

As was said what matters is the 20 km/s differential since it's a flat +10 and - 10 km.s This is particularly visible when you pause thrusters. I have never managed to stop at the lagrange point yet x)