Factorio Forums

TL;DR: I would like to read or calculate the travelled distance of my space plattform.

My motivation:
Different areas in space have different densities of asteroids and asteroid chunks.
I would like to automatically adjust the thrust of my space platform, depending on the area of space it is travelling through. (Slower in resourche-rich environments, faster in dangerous areas.)

My approach:
At first, I thought I could just read the distance travelled from the hub and use some combinator logic. Unfortunately the hub does not provide the travelled distance, but only values from and to where the platform currently travels. But there is one promising value: speed

So I can detect the moment, where the travel begins when the destination signals change, and I get the current speed - so I can calculate the distance traveled by constantly adding the speed value. Together with the values of the travel source and destination I could calculate where the space platform currently is. At least that's what I thought.

My combinators:
Hub: read speed (in km/s) -> V
Distance: D + V -> D (loops back to it's own entry, so D is increased)
Distance (in km): D / 60 (because speed is read every tick but unit is km/s)

My problem:
When implementing this, I noticed, that my calculated travel distance is way lower then my actually travelled distance. When at the 15000 km mark, my distance calculator only shows about 8100 km.

When looking closer, I can see the platform speed in the speed display on the right side of the screen shows speed with a higher precision (e.g. 284.35 km/s), while the signal from the hub only uses integers with lower precicion (e.g. 284 km/s). So the signal from the hub is rounded down. I believe this is the root cause of my problems.

Since I limit the fluid supply for my thrusters to limit thrust depending on the distance travelled, my current speed also fluctuates, so I can not just assume it will rise continuously until some limit is reached.

Where I need help:
Does anyone here have an idea how to get the correct value of the currently travelled distance for a space plattform?

A good absolute way to determine distance would be the solar cell efficiency. But I have no idea how to read that in space since everything is connected. Although if you find a steady-state power consumption for your platform you could try aiming for a specific average accumulator recharge rate, I kinda doubt it will be precise enough though.

This would really call for some sort of bayesian filter with frequently-updated but imprecise speed data and rarely-updated but very precise on average accumulator recharge rate. Sounds like there would be a lot of combinators involved... and much fine tuning.

I tried a "speed this tick" summnation, but it is hampered by the fact that a speed of, say, 125.47 is reported truncated, as 125, which leads to the odometer running slow.

Worse, my "clever fix" of using speed*100 (to get the fractions) doesn't work. In the above example, 125.47 * 100 = 12500.

Honestly, just making "distance along route" available to circuitry would be an immense QoL update; they already did it for scripting; I just want to see it for non-programmers/scripters!

Here's my Feature Request about it; feel free to "me too!"

You can wire the inserters providing ammo to your gun turrets to pulse the ammo they move, then use this to calculate the current ammo throughput. Create a circuit to make the ammo throughput constant. The less ammo is being consumed, the higher the velocity should be. Or thruster supply, since this is what results in velocity.

Pithlit wrote: Tue Nov 05, 2024 3:10 pm My combinators:
Hub: read speed (in km/s) -> V
Distance: D + V -> D (loops back to it's own entry, so D is increased)
Distance (in km): D / 60 (because speed is read every tick but unit is km/s)

My problem:
When implementing this, I noticed, that my calculated travel distance is way lower then my actually travelled distance. When at the 15000 km mark, my distance calculator only shows about 8100 km.

When looking closer, I can see the platform speed in the speed display on the right side of the screen shows speed with a higher precision (e.g. 284.35 km/s), while the signal from the hub only uses integers with lower precicion (e.g. 284 km/s). So the signal from the hub is rounded down. I believe this is the root cause of my problems.

Circuit network values are integers, if the source of a value is a float it gets truncated first.
So yeah, it's probably your root cause, but depending on your travel speed an error of ~85% sounds like there's an additional issue (the faster you travel the higher the accuracy should be).

Where I need help:
Does anyone here have an idea how to get the correct value of the currently travelled distance for a space plattform?

No, but you can calculate a range where the correct value must be within.
Due to the nature of the circuit network, the exact speed is within [v, v+1) (or (v-1, v] when traveling backwards). So you can use your accumulator for both sides to at least get an idea of your accumulated error.

I tried to integrate velocity to get the distance. It turns out the value is accurate enough to get a valid distance. The algorithm in the OP is correct; if it results in 8100 km for them when the distance is actually 15000 km, this is due to a bad implementation. If you do it right, the distance is within a reasonably small error range.

My implementation:

• calculates distance to the edge of the solar system while flying to the shattered planet or returning from the shattered planet only
• distance increases while flying to the shattered planet
• distance decreases while returning from the shattered planet
• returns nothing for every other route

1: determine if we're flying from or to the shattered planet. If we read from the platform, we get planet=2 if we're flying to the shattered planet and planet=1 if from the shattered planet. We want a sign +-. So output planet=-3 if we're returning, so if we add this to the platform signal, we get planet=2 if we're flying to the shattered planet and planet=-2 if we're returning. This sign is being used to increase and decrease distance accordingly. Since there is a factor of 2, we need to divide by 2 later.

2: apply sign to velocity

3: integrate. This combinator has the loopback wire. Do counting only while we're flying from or to the shattered planet. This resets the distance and starts counting at the edge of the solar system only.

4: Normalize. We need to divide by 60, since we integrate every tick but want the value per second (=60 ticks). And we need to divide by 2 because of the sign we applied as +-2 and not +-1, so we finally divide by 60*2=120.

Check:


Example, platform is on its way back from the shattered planet. Return condition was S>142000 and the distance has already decreased:

Real distance: 4000000-3867450 = 132550 km
Calculated distance: 132298 km
Error = 132550 km - 132298 km = 252 km

In percent: |132550 - 1532298| / 132550 * 100 = 0.19%

That's good enough for my purposes. It's quite accurate.

Accuracy is achieved due to the distributive law: x * (a + b + c) = (x*a + x*b + x*c)
You don't need to normalize (divide and lose precision) while integrating.

Copy blueprint