Signal control/monitor for improved control of platform speed

[Khazul]

TL;DR

1. Add signal support to thrusters to read:
Fuel amount and Oxidizer amount

3. Add a signal to the platform hub to enable specific determination of thrust paused/automatic state.

2. Add signal support to thrusters to control:
A mean to precisely and immediately control the thrust amount or fuel consumption rate - one of, no need for both. Dont mind the units - but in either case, a percentage (0-100 with 0 being off) is probably easiest. Otherwise could be actual fuel consumption rate which may be more in keeping with the underlying design of thrust vs efficiency.

4. Add a signal to platform hub to set the paused/automatic state.

What?

The use case for this is controlling the speed in a much more responsive manner than is currently practical (or even possible). For example, I have a ship that monitors its different ammo consumptions to get an idea of what sizes of asteroids it is facing and uses this information (as well as ammo consumption vs production rate) to slow the ship down from its default speed to a slower speed to give it time to destroy asteroids. I also precisely control (via a PWM controller circuit) the fuel delivery, however this is imprecise and requires assuming the internal invisible state of the thrusters with respect to fuel. Additionally there can be considerable lag between cutting fuel delivery rate and the unknown amount of fuel the thruster falling to a low enough level for the speed to sufficiently reduce so ideally a more direct method of control and more complete monitoring is desired.
Additionally while attempting to control fuel delivery it is also useful to know if thrust is active avoid excessively filling the thrusters, therefore it is desirable to be able to know the travel state of the platform, specifically a means to read the pause/automatic state.

Why?

From the discord, I get the impression there are many people trying a variety of method to control the speed and/or fuel efficiency of their platforms via circuits. A considerable part of the design challenge in factorio is circuits and adding full signal monitoring and control to thrusters and more complete monitoring adds to the mechanisms available for more advanced players to engage with as well as the possibility of more satisfying results of one's platform designs.

[bullipatty]

+1. had the same idea. alternatively, if the thrusters would be part of the pipe segment and had the same fill, we could read from a connected tank and use a pump to separate segments, similarly to how it works with accumulators and power switches.

[credomane]

You can already mosly do this. Circuit wire up some pumps to the platform hub. Set the hub to "read current speed as V" then set pumps to enable when "V < 100". It will launch with max thrust (because thrusters are full) then slow down and maintain roughly 100 km/s speed. That is the most basic method. You can wire up combinators for more complex control. My platforms take slightly longer while traveling but they are ready to launch again soooo much quicker.

I saw one platform designed for the shattered planet trip that would entirely cut off fuel to the thrusters if the supplies got too low.

[Tinyboss]

Have you tried using a fluid tank between the pump and thrusters, and using circuits to maintain a desired level in the tank? The higher the tank level, the faster the fluid will flow into the thrusters, and vice-versa. It may even flow out of thrusters into the tank if the tank level is lower. I haven't tested that, though.

With a pump in and a pump out, it should be pretty responsive, *much* more so than direct pump-to-thrusters which in my experience always overfills by a lot before your speed changes enough to trigger the pump to turn off.

[bullipatty]

You can already mosly do this. Circuit wire up some pumps to the platform hub. Set the hub to "read current speed as V" then set pumps to enable when "V < 100". It will launch with max thrust (because thrusters are full) then slow down and maintain roughly 100 km/s speed. That is the most basic method. You can wire up combinators for more complex control. My platforms take slightly longer while traveling but they are ready to launch again soooo much quicker.

I saw one platform designed for the shattered planet trip that would entirely cut off fuel to the thrusters if the supplies got too low.

that is what i'm already doing, that makes the thrusters fill entirely while waiting at the planet and then dash right into large asteroids.

[bullipatty]

Have you tried using a fluid tank between the pump and thrusters, and using circuits to maintain a desired level in the tank? The higher the tank level, the faster the fluid will flow into the thrusters, and vice-versa. It may even flow out of thrusters into the tank if the tank level is lower. I haven't tested that, though.

With a pump in and a pump out, it should be pretty responsive, *much* more so than direct pump-to-thrusters which in my experience always overfills by a lot before your speed changes enough to trigger the pump to turn off.

it doesn't flow back into the tank... if the thruster volume was part of the pipe segment it would work yes...

[thoorium]

Adding a way to read the automatic/paused thrust state of the platform would complete any setup where speed is automatically configured via reading the speed of the platform and pumps to control thrust fuel. Without this, when a platform is paused, pumps just fill the thrusters without control.

[credomane]

that is what i'm already doing, that makes the thrusters fill entirely while waiting at the planet and then dash right into large asteroids.

You might need more defense then. You can still try this thread out. Basically solved the efficiency problem on thrusters. Which also makes your platform move a little slower. And it doesn't fill up the thrusters when the platform is idle either.

118009

[Tinyboss]

You might need more defense then. You can still try this thread out. Basically solved the efficiency problem on thrusters. Which also makes your platform move a little slower. And it doesn't fill up the thrusters when the platform is idle either.

Depending on the number of thrusters and the desired fuel level, their initial burst of engines-full speed could be very large. So their defenses now could be perfectly adequate if the engines are prevented from filling while idle.

I really need to set that up on my ships, too.

[bullipatty]

You might need more defense then. You can still try this thread out. Basically, solved the efficiency problem on thrusters. Which also makes your platform move a little slower. And it doesn't fill up the thrusters when the platform is idle either.

118009

thanks, but I'm pretty good circuits myself. the problem with that build is written below in that post. "Read Moving From" and "Read Moving To" read wich route the ship is already on including orbits, not on wich it is supposed to be, so it's rather useless.

i could also make another layout with more combinators that fills the thrusters a little at the end of each trip to ensure it can hop from the planet, but i feel like it's not worth it. it feels like working on implementation instead of specification and from experience that's 99% time waste, cause i'll have to or i'll want to fix it as soon as the underlying implementation is changed...


and about the current implementation, there is literally symbols for routes in the game already...
but start and target for whatever reason effectively read the location instead of... well target and start... and then outputs it as different planets instead of a just a signal for the route...

sending a location as a single signal that represents the route and sending the actual start and target planet the ship started from and wants to go to at the end, would make much more sense.


if i hadn't been about 100% sure there is no stable and nice solution I wouldn't have come here.

[Khazul]

Please add a signal from the hub to indicate that the platform thrust is in paused state. Suggest P as the default signal, value 1 when paused.

Use case:
Those implementing fuel flow control via circuits need to limit the flow of fuel to stop the tanks filling up to limit the fuel use (and hence speed) increasing beyond a desired flow amount. If the tanks are allowed to fill, then the platform will operate at max thrust for a considerable time which could be a serious problem is entering high density asteroid field. Those using different weapons and therefore different ammo to target different types of asteroids can detect density (ammo use) and asteroid types/sized (via ammo types used) and use that to slow the platform if needed.

It is currently possible to detect the states of in transit or at stopped planet and can use that to stop flow to avoid tanks filling up. If however the player manually pauses the thrust, there is no indication of that and it still appears that the platform is in transit and so fuel continues to be delivered. Using the speed (V) is no use as it takes too long to slow down during which time fuel will be over-delivered. There needs to be a signal that indicates the paused state. P is a suggestion but could equally be a new value on the planet signals.

While I have a working circuit to do the above, it fails as soon as thrust is paused because it cannot detect this state and therefore cannot prevent tanks from being filled. Detecting the paused state would allow such adaptive circuits to properly function.

Edit: having had a look at the API docs, there is space_platform_state in the API. It would have been useful had all of the states been reflected on the planet signals as signal type of the planet and number indicating the state as this includes pause along with waiting to depart etc. One could add these values in after 3 (stopped at planet).

@Devs: I just want to highlight that you obviously gave a lot of thought as to how thrusters behave through the way in which the amount of fuel in the thruster controls the fuel consumption and hence thrust and there appears to be some serious maths behind it from external observation of its behaviour. All of this well thought out and excellent functionality goes out the window the moment someone switches thrust to 'paused' simply because the situation cannot be detected and therefore tanks will fill up beyond intended amount which in turn prevents timely thrust control. I therefore submit that this sub-feature request is a MUST in order to make the intended behaviour of the existing thruster feature complete and fully usable by players.

[rfvgyhn]

I'd like to see this as well for the same reasons.

Not sure if there's an official thread for this request as it appears in these threads as well.
viewtopic.php?f=23&t=119994&p=633547
viewtopic.php?f=6&t=119047&p=637847

[Khazul]

I should have amended this post when I made another request about the paused state signals.
Since the time of posting this I have come to understand the thrust system far better and have implemented a good speed per route control system. However what remains is still the lack of indication of the paused state which is the real missing feature.
Having done a complete and accurate speed control system, it is a big circuit and not something for smaller ships. Simplifying it would maybe be better adressed by more advanced combinator types rather than a simple speed signal or similar.

This is a link to the revised request:
viewtopic.php?f=6&t=121386

Mods may wish to merge them in some appropriate way that keeps the essentials clear.

[Koub]

[Koub] Merged into an older thread with the same suggestion.
[Edit]

Mods may wish to merge them in some appropriate way that keeps the essentials clear.

haha Didn't even notice you were the OP of both threads

[bullipatty]

...
Since the time of posting this I have come to understand the thrust system far better and have implemented a good speed per route control system. However, what remains is still the lack of indication of the paused state which is the real missing feature.
...

fixed speed per route is not what i call full automation. full automation is when the platform measures it's performance (like ammo and fuel drain) and adjusts it speed on it's own. i don't know how you see it, but for me automation means NOT having to set everything up manually. maybe i've become some sort of programming-nazi, but what you do sounds awfully like hardcoding to me.