Signal Monitoring of thruster fuel levels and Platform hub paused state

[Khazul]

TL;DR

1. Add signal support to thrusters to read fuel amount and oxidizer amount (similar to monitoring two storage tanks as that is what the underlying implementation seems to be).

2. Add a signal to the platform hub to enable specific determination of thrust paused/automatic state. I note that the underlying SDK API reports many more states, some of which may also be useful. Those state returned as an int signal would be fine too.

What?

In order to precisely control fuel flow you need to control how much fuel is in the tanks or specifically the flow rate while thrust in on and suspend flow when it is paused. When a ship is in thrust paused state there is no current way to immediately detect this, thus is is not possible to suspend delivery of fuel. The end result in the tanks will fill, and when thrust is re-enabled, the ship will apply full thrust until the fuel is used up and the actual delivery flow can have its impact.

Why?

If a ship is paused and is restarted say in the outer system routes, then there may be a high chance that a fast ship running at reduced flow will be destroyed as there can be no limiting of thrust until the fuel level drop lows enough on its own.
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]

(Moved to OP)

[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.

[Khazul]

...
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.

Did I even say fixed speed control? Have you ever tried to do precision reactive speed control in this with circuits? Any idea what PDM is? or a PID?

You cannot hard code speed control, that fact that you assume that suggests you are clueless about the how. You can hard code flow rate the relationship between speed and flow rate is complex. As it happens this is fully reactive, including to ammo consumption rate changes, not just rate or levels and of course handles gravity shifts and other stuff.

Anyway, I wasn't going to make anything about it, just mentioned in passing as a why I am so interested in such signals, but it seems to have attracted the attention of the gestapo. There is a post in another thread about one of the ships it is on if you want to know what it can currently do - large constructions section I think. It should still be one of the recent posts.

[bullipatty]

Did I even say fixed speed control? Have you ever tried to do precision reactive speed control in this with circuits? Any idea what PDM is? or a PID?

then i've misinterpreted "speed per route", sorry. and no, i'm just solving everything from scratch, i've no idea how those automation problems would be tackled in the industry or the terms it has for problems and solutions. i've mostly worked on other stuff, closest is probably gamebots i wrote as a teen.
for me a PDM is a Product Data Management and a PID is a Process ID, but i think that's not what you mean as they don't have much to do with this. 3 letter acronyms are very ambiguous tho, maybe i'm just not recalling the right stuff.

You cannot hard code speed control

if you have a constant combinator witch maps routes to speeds, that is hardcoded speedcontrol to me, and well, that's what i thought you meant with "speed per route".

[Khazul]

Did I even say fixed speed control? Have you ever tried to do precision reactive speed control in this with circuits? Any idea what PDM is? or a PID?

then i've misinterpreted "speed per route", sorry. and no, i'm just solving everything from scratch, i've no idea how those automation problems would be tackled in the industry or the terms it has for problems and solutions. i've mostly worked on other stuff, closest is probably gamebots i wrote as a teen.
for me a PDM is a Product Data Management and a PID is a Process ID, but i think that's not what you mean as they don't have much to do with this. 3 letter acronyms are very ambiguous tho, maybe i'm just not recalling the right stuff.

You cannot hard code speed control

if you have a constant combinator witch maps routes to speeds, that is hardcoded speedcontrol to me, and well, that's what i thought you meant with "speed per route".

I threw them at you as if you were familiar with doing this kind of thing, they would have meant something to you and the a-hole nature of your attack deserved such an a-hole response and this isnt a thread to discuss details of ship speed control, just a missing feature in the game that would help it and speed control is just part of the why is the feature useful.

PID - https://en.wikipedia.org/wiki/Proportio ... controller
PDM - https://en.wikipedia.org/wiki/Pulse-density_modulation

I expect the mods would be happy if a discussion of how best to control ship speed in response to route conditions happened in its own thread.

[mmmPI]

note that using a PID controller for speed is already possible and that wouldn't require the signal suggested in this thread

[Khazul]

note that using a PID controller for speed is already possible and that wouldn't require the signal suggested in this thread

Any kind of control (error feedback based or even just simple fixed limited flow) is broken when you don't know that thrust is paused and tanks fill up, so yes it does require such a signal in order to pick up from where it left off when thrust is resumed.

The method is irrelevant and isn't the point. The problem is whatever method you use, thrust paused state is invisible to circuits and so they will not stop fuel flow and so thrusters will fill up. Later when thrust is resumed, the ship will accelerate towards max speed. If that happen on outer system routes - then likely it will just face plant into asteroids and be destroyed because it ends up going far too fast for that specific route.

If you don't want this, this is fine, at least say why, ie how it will break your game, or impact a build in some way.