Friday Facts #382 - Logistic groups

[FuryoftheStars]

They'd also have to use more fuel in space when the platform is moving.

-1

Wrong. Velocity doesn't require fuel.
They can land if they want to accelerate with the platform.

In reality, you are correct: it is the change in velocity that requires fuel. But that's not how they depict/designed the platform, so the bots (if included, etc) should be consistent. While the platform's engines are firing and using fuel, the bots should be using more fuel as well to "keep up". While landing could work as an alternative, this is still an added layer of complexity for just space con bots to utilize, plus it means all construction work halts so long as the engines are firing.

[Qon]

They'd also have to use more fuel in space when the platform is moving.

-1

Wrong. Velocity doesn't require fuel.
They can land if they want to accelerate with the platform.

But if one wants bots to move relative to the platform in case they carry item or repair packs from one side to another they will have to change their velocity to either go a little bit faster than the platform when trying to go to the front, or a little bit slower, if they want to move toward the back of the platform which would require energy. Though at this point one can admit the platform emit some kind of tractor beam to levitate the drones and is the source of energy. It's the most documented way of alien abducting people !

You also missed my point. Velocity doesn't require fuel (energy). Acceleration does.

If bots want to move relative to the platform then they need to accelerate to start moving and decelerate (can be done by just landing) to stop moving relative to the platform.

But that's true both when the platform is in planet orbit ("not moving" (moving in absolute is a contradiction)) or not (traveling between planets. The trajectory of the platform doesn't matter, only if it's accelerating or not matters.

I think logistic bot would remove the puzzle part of the space platform, and the constructions ones would remove the "asteroid fields are dangerous to navigate" feeling. But i wonder how the reparation function, if you need to send repair pack in orbit and they are used somehow, or if you need to deconstruct some platforms that were not well equiped enough for a travel through many asteroids debris, or run the risk of sending one that is not full health, if there is some auto-repair with repair pack maybe it's slow enough so that a platform still need to be protected against debris or you need to stop and repair maybe ?

I haven't argued against this.

They'd also have to use more fuel in space when the platform is moving.

-1

Wrong. Velocity doesn't require fuel.
They can land if they want to accelerate with the platform.

In reality, you are correct: it is the change in velocity that requires fuel. But that's not how they depict/designed the platform, so the bots (if included, etc) should be consistent. While the platform's engines are firing and using fuel, the bots should be using more fuel as well to "keep up". While landing could work as an alternative, this is still an added layer of complexity for just space con bots to utilize, plus it means all construction work halts so long as the engines are firing.

Yes, I'm correct.

And it's true that if there was an atmosphere in space then the bots would need to accelerate to compensate for the drag to follow the space platform on the outside. But why would the factory not be enclosed in an atmospheric space? And we don't even have bots in space at all now so kind of weird to discuss the
fuel consumption of bots (which are electric and rotor based in game)
in atmospheric space (the WIP has some sort of drag but that is probably just "gameplay" without explanation)
on a space platform not designed for the current bots or the hypothetical other bots (open "air" design)
etc etc

We are so far from discussing the game now.

[FuryoftheStars]

They'd also have to use more fuel in space when the platform is moving.

-1

Wrong. Velocity doesn't require fuel.
They can land if they want to accelerate with the platform.

In reality, you are correct: it is the change in velocity that requires fuel. But that's not how they depict/designed the platform, so the bots (if included, etc) should be consistent. While the platform's engines are firing and using fuel, the bots should be using more fuel as well to "keep up". While landing could work as an alternative, this is still an added layer of complexity for just space con bots to utilize, plus it means all construction work halts so long as the engines are firing.

Yes, I'm correct.

And it's true that if there was an atmosphere in space then the bots would need to accelerate to compensate for the drag to follow the space platform on the outside. But why would the factory not be enclosed in an atmospheric space? And we don't even have bots in space at all now so kind of weird to discuss the
fuel consumption of bots (which are electric and rotor based in game)
in atmospheric space (the WIP has some sort of drag but that is probably just "gameplay" without explanation)
on a space platform not designed for the current bots or the hypothetical other bots (open "air" design)
etc etc

We are so far from discussing the game now.

Well, the factory obviously isn't enclosed in an atmosphere, otherwise the engineer would be able to move around on it (presumably the center structure is the only place with O2), the platform would look different (there'd be some semblance of a dome and couldn't be arbitrary shapes (we can't have holes, but that doesn't mean we can't have something like a flying "E" or squiggly line)), and there'd be no reason why we couldn't have current bots on it other than arbitrary reasons.

But the discussion of thruster based bots and fuel usage is because some people are questioning why there can't be bots on the platforms in the first place. I'm attempting to explain that, from a reality stand-point, the current bots being rotor based with no atmosphere wouldn't work. As such, the devs would need to design a new space bot (thrusters) that would potentially use fuel (or say screw it and stick with electricity - there's enough other stuff in the game that bends reality well past the breaking point), and there would be added layers of complexity for the devs to decide on this like:
are these in addition to current bots or replace, and if in addition how do you keep current bots relevant without arbitrary reasons?
when the platform is using fuel (accelerating/moving), should the bots use more energy? (for consistency, yes)
how to handle when the bots are out of fuel/energy, thus moving slowly, and the acceleration/movement of the platform changes?
etc etc

And only so half of the bot network can be used on platforms.

It's not an issue of being far from discussing the game. It's an issue of trying to explain realistic reasons - both from an in-game lore and from the devs "omg that's going to be a headache to deal with" standpoint - to those that are questioning why there can't be bots on the platform.

[XT-248]

I'm not moving anything and I'm well aware of what they were criticizing and thus why they were suggesting the bot alternatives.

The previous post was moving the goalpost by adding several "buts!" to a simple concept of using something that WUBE is planning to have on the space platform to power rocket engines, which could have been re-used for space construction drones or not.

Then I saw that you moved the goalpost to talk about logistic bots, quoted below, which is immaterial to the constructive criticism that the other guy and I posted in this thread, which was about how to improve the construction in space animation by using construction drone to show where the actual building is coming from, as opposite to 'magic-y' appearing out of other existing space platform sections.

The behind the scenes reasoning, as the devs stated, are because they wanted to increase the logistics puzzle complexity (encourage spaghetti) and they didn't want the player the ability to buffer resources at the machines (so no chests, which includes all logistic chests). With this in mind, this means that logistic bots are immediately out the window, leaving only construction. So what then? Do they throw realism out the window for construction bots, likely getting more complaints & questions and causing confusion on why logistic bots can't be used? Or do they take the time in creating a new bot style for only construction bots, really? Do they make them run on fuel, causing other complexity issues, or do they throw that realism out the window, too (for even more complaints)? Do they make these new style bots in addition to the original (now having one bot style that's planet side only and another that logically could be either unless they arbitrarily restrict them to space only to keep the original's relevant) or replace? With having bots in space in general, they'd also have the increased complexity of having the bots change their flight patterns and (realistically... if they don't throw that out the window, too) consuming more fuel/electricity when the platform moves (and what happens when they hit the low fuel/power point and fly slowly while the platform is still speeding along?). (There may be other considerations with bots that I haven't even thought of, yet.)

Or... do they come up with a bot-less construction method (using the already improved remote tools for planets) where they attempt to add some animation elements so things aren't just appearing out of thin air? I imagine they didn't want to just put bots as they are in space, but neither did they want to take the time to rework bots simply so we could have plausible looking construction bots in space. Thus, we have what they've given us. Is it the best way/looking? I don't know and I have no arguments on those points. But I understand the reasoning of not using bots and that's what I'm attempting to explain.

And the platform routing of goods itself I've attempted to give an explanation for that feels legit. Realistically and from a gameplay perspective, the platform needs a way of being told where to route the resources (otherwise there's no puzzle), and simply setting up logistic queues (like schedules) has no challenge to it, so that's what you can look at the belts and inserters as: it's you designing the "inner workings" of the platform on where and what resources it directs around. They're not inside of the platform for gameplay reasons: visibility and puzzle (if you could route the belts under the machines, then there's no challenge).

I feel this line of thought is missing the forest for the trees.

Let's fall back to what we do know.

Some entities can't be constructed on platforms at all. For example:

Robots so the platform remains a belt logistic puzzle.
Chests to prevent excessive buffering.
Vehicles including trains and spidertrons for various reasons.
Burner entities for a bit of realism as there's no atmosphere in space.

Robots, to be more precision logistic drones, are barred because of conflicts with the belt logistic puzzle gameplay.

Yet, a new construction-ONLY space drone, no logistic drones allowed, would not have any impact beyond giving players something to watch while the space platform grows.

The space platforms are barred from having any logistic chests and chests even if you place logistic bots in space. How would they move items around? So, the logistics continue to be restricted to belts even with this third type of space-bounded construction drone. Therefore, the original intention of the belt logistic puzzle gameplay remains intact.

[Koub]

[Koub] Kind reminder that the discussion, while interesting in itself, has drifted away almost completely from the FFF's topic. Please keep the discussion in this thread on the FFF's topics.

[FuryoftheStars]

This all is derailing too far, so this'll be the last I'm going to say about this subject.

I'm not moving anything and I'm well aware of what they were criticizing and thus why they were suggesting the bot alternatives.

The previous post was moving the goalpost by adding several "buts!" to a simple concept of using something that WUBE is planning to have on the space platform to power rocket engines, which could have been re-used for space construction drones or not.

I made a mention of possibly using fuel for the space bots
Reply to me about how we're already making fuel on the platforms so "problem solved"
I replied about the unreliability of that fuel's manufacturing process

That's not moving of goalposts.

Then I saw that you moved the goalpost to talk about logistic bots, quoted below, which is immaterial to the constructive criticism that the other guy and I posted in this thread, which was about how to improve the construction in space animation by using construction drone to show where the actual building is coming from, as opposite to 'magic-y' appearing out of other existing space platform sections.

You obviously did not read the whole quote? Only the first 2 sentences are on logistic bots. All the rest except the last paragraph is about construction bots and everything the devs would have to do to make their use on the platforms plausible all to accommodate half of the bots.

The last paragraph was addressing the direct concern/question of why the platforms can't just move the items itself vs us making belts everywhere.

And still none of that is moving of goalposts:

unfairly alter the conditions or rules of a procedure during its course

[mmmPI]

Then I saw that you moved the goalpost to talk about logistic bots, quoted below, which is immaterial to the constructive criticism that the other guy and I posted in this thread, which was about how to improve the construction in space animation by using construction drone to show where the actual building is coming from, as opposite to 'magic-y' appearing out of other existing space platform sections.

I think logistic bot would remove the puzzle part of the space platform, and the constructions ones would remove the "asteroid fields are dangerous to navigate" feeling. But i wonder how the reparation function, if you need to send repair pack in orbit and they are used somehow, or if you need to deconstruct some platforms that were not well equiped enough for a travel through many asteroids debris, or run the risk of sending one that is not full health, if there is some auto-repair with repair pack maybe it's slow enough so that a platform still need to be protected against debris or you need to stop and repair maybe ?

I haven't argued against this.

Please do ! that was my attempt at keeping the discussion on tracks

I got your point about velocity, i think i failed to convey what i had in mind in my previous sentence, because i don't think what you say is different than what i had in mind, maybe i shouldn't have used the word "side to side" , but rather an image like when astraunaut do a sortie they use little thrusters to move around relative to the already moving fast space station which if one wants to argue on the realism of the means to convey to the player the idea that building are not magically appearing on the platform could have been used for little robots.

Realism aside, one could use tractor beam, i don't think realism is the main "problem" or cause for the absence of construction robots rather the gameplay implications.

What do you think about the repair ? Which unlike in the real life space station will probably not be done by the engineer in thruster suit

[XT-248]

The previous post was moving the goalpost by adding several "buts!" to a simple concept of using something that WUBE is planning to have on the space platform to power rocket engines, which could have been re-used for space construction drones or not.

I made a mention of possibly using fuel for the space bots
Reply to me about how we're already making fuel on the platforms so "problem solved"
I replied about the unreliability of that fuel's manufacturing process

That's not moving of goalposts.

The third post discusses "treating something as should not be introduced because of realism."

Yet, my counter-point before that did not cite realism as a reason to have construction drones. The rationale is to make space platform animation look better, which is not relevant to how unreliable rocket fuel is.

You obviously did not read the whole quote? Only the first 2 sentences are on logistic bots. All the rest except the last paragraph is about construction bots and everything the devs would have to do to make their use on the platforms plausible all to accommodate half of the bots.

The last paragraph was addressing the direct concern/question of why the platforms can't just move the items itself vs us making belts everywhere.

I did indeed read the whole quotation and went back to re-read it.

As I have indicated previously, I was attempting to give you a good reason for not barring construction bots from being used as part of space platform construction as they are incapable of moving items for logistics in both scenarios: in space platform and on planets except given for moving object to be built on-site.

Then you processed to attempting to cite realism as a reason to bar construction drones. Despite having no elements of realism in my rationale.

And still none of that is moving of goalposts:

unfairly alter the conditions or rules of a procedure during its course

I am afraid I have to disagree with you.

[kitters]

Rocket silo in a rocket is too much, but hundreds of chests insiade a chest is absolutely fine

[Khagan]

Rocket silo in a rocket is too much, but hundreds of chests insiade a chest is absolutely fine

It's called flat-pack .

[Cerberus]

I see many people complaining about the maximum of one landing pad per planet. While I do not care about that myself because I don't build megabases (I only play to win the game), I do see their point AND also the developer's point, and I propose this solution:
Only allow planets to have multiple landing paths AFTER finishing the game. Then, players still have to win the game using the one landing pad restriction. And people that want to build megabases can do so after the game is won. Similar to how research queues used to be only activated when winning the game.
This can be easily implemented without being weird too, because the developers already implemented the "research triggers" system. The trigger for unlocking the "multiple landing pads per planet" research can be set to be the same as the victory condition for Space Age. You only need to find some kind of logical sounding reason for why that research unlocks then (I can't help because I don't know the victory condition) but that can not be too hard. Something along the lines of the player character knowing so much about space travel by then the player character figured out how to do multiple landing pads safely on the same planet.

[mmmPI]

This can be easily implemented without being weird too, because the developers already implemented the "research triggers" system. The trigger for unlocking the "multiple landing pads per planet" research can be set to be the same as the victory condition for Space Age. You only need to find some kind of logical sounding reason for why that research unlocks then (I can't help because I don't know the victory condition) but that can not be too hard. Something along the lines of the player character knowing so much about space travel by then the player character figured out how to do multiple landing pads safely on the same planet.

I like the idea, but i think it also introduce something maybe unforeseen, because in Nauvis there is a "starting location" which is your respawn point when you die, i suppose in other planets the respawn point will be the 1 landing pad, or if you die in space, though that could also be the area with 0:0 coordinate. so if you "unlock" more, then the devs may need to add a GUI so you can "select" where you respawn. The same kind of logic may then also be required to select which landing pad one wants to interact with from the space platform.
If you have several landing pad, they need a system to be identified, rather than just the name of the planet.

It could add some complexity which may not be to the liking of the devs for the vanilla expansion. Although reducing the logistic challenge around 1 landing pad, that kind of complexity could be fun in its own way. Hence i like the idea, that there would be an option, to "disable landing pads limitation after the game is won" or "never" or "always". But maybe this is something modders could do ?

[FromageChaud]

This is just an appreciation post. Everything has been exciting so far! I keep refreshing https://www.factorio.com/blog/post/fff-383, hoping that it will come up sooner than usual.

[Niyu.Cuatro]

I see many people complaining about the maximum of one landing pad per planet. While I do not care about that myself because I don't build megabases (I only play to win the game), I do see their point AND also the developer's point, and I propose this solution:
Only allow planets to have multiple landing paths AFTER finishing the game. Then, players still have to win the game using the one landing pad restriction. And people that want to build megabases can do so after the game is won. Similar to how research queues used to be only activated when winning the game.
This can be easily implemented without being weird too, because the developers already implemented the "research triggers" system. The trigger for unlocking the "multiple landing pads per planet" research can be set to be the same as the victory condition for Space Age. You only need to find some kind of logical sounding reason for why that research unlocks then (I can't help because I don't know the victory condition) but that can not be too hard. Something along the lines of the player character knowing so much about space travel by then the player character figured out how to do multiple landing pads safely on the same planet.

Or to make it a bit less arbitrary. Make it an infinite late game research. Getting exponentially more expensive and allowing one more landpad on each planet per research level.

[Cerberus]

I like the idea, but i think it also introduce something maybe unforeseen, because in Nauvis there is a "starting location" which is your respawn point when you die, i suppose in other planets the respawn point will be the 1 landing pad, or if you die in space, though that could also be the area with 0:0 coordinate. so if you "unlock" more, then the devs may need to add a GUI so you can "select" where you respawn. The same kind of logic may then also be required to select which landing pad one wants to interact with from the space platform.
If you have several landing pad, they need a system to be identified, rather than just the name of the planet.

I think the first time you travel to a certain planet, you will also have a starting point no? Which will be your respawn point just like on Nauvis. Spawn point can not be the landing pad, because the landing pad might not exist (deconstructed/destroyed).
The GUI for selecting the specific spawn point likely exists already (but hidden now), because the the devs experimented with having multiple landing pads.

Or to make it a bit less arbitrary. Make it an infinite late game research. Getting exponentially more expensive and allowing one more landpad on each planet per research level.

I think that is a good solution too, if infinite research only starts after game completion like in the original.

[mmmPI]

I think the first time you travel to a certain planet, you will also have a starting point no? Which will be your respawn point just like on Nauvis. Spawn point can not be the landing pad, because the landing pad might not exist (deconstructed/destroyed).
The GUI for selecting the specific spawn point likely exists already (but hidden now), because the the devs experimented with having multiple landing pads.

I don't know how the respawning logic is handled, nor if it is related to the landing pad. And you reminded me of devs experimented with having multiple landing pads, so maybe there is also a GUI to select which one receive cargo from the platform.

Or to make it a bit less arbitrary. Make it an infinite late game research. Getting exponentially more expensive and allowing one more landpad on each planet per research level.

I think that is a good solution too, if infinite research only starts after game completion like in the original.

Agreed that infinite research for additionnal landing pad could be meaningful. At this point though you may create several combos, with research locked behind "end goal" or available from the start or not at all which may be more suited to small mods that does just 1 thing.

[Cerberus]

Also, I am having a hard time deciphering how this combinator system works in this screenshot from the FFF:



I figured the arithmetic combinator multiplies the contents of the chest by -2, but I have not figured out how this helps the filter inserter decide which items to pick (which is probably set to let the circuit network decide which items to pick).
If you set the constant combinator to require 150 wall, and there are already 150 present in the red chest, it will add -300 (result from arithmetic combinator) and 150 (from constant combinator), resulting in -150. But if the red chest only has 148, the circuit network will add -296 and 150 resulting in -146. How does -150 and -146 help the filter inserter?
I am maybe wrong about the numbers but I can not figure it out apparently. My knowledge about circuit network is pretty basic, but I want to learn more about it and some google searches did not give me the intended results.
What am I missing?
It would make more sense to me if the arithmetic combinator multiplies by -1, then "what we have in the red chest" is substracted from "what we need defined by the constant combinator", but the screenshot shows otherwise looking at the input and output.

[kovarex]

By default you will multiply the contents by -1, not -2. You sum this with the required values, this means, only the positive values are the missing values (You need more than you have).
And the filter inserter, when configured to set filter based on circuit signals only works on positive values, so it only picks items that are needed.

The multiplication by -2 is used in a more advanced setup, where you only want to call the supply train when there is more than 1/2 of items missing, so it doesn't come for a single individual missing item.

[computeraddict]

I see many people complaining about the maximum of one landing pad per planet. While I do not care about that myself because I don't build megabases (I only play to win the game), I do see their point AND also the developer's point, and I propose this solution:
Only allow planets to have multiple landing paths AFTER finishing the game. Then, players still have to win the game using the one landing pad restriction. And people that want to build megabases can do so after the game is won. Similar to how research queues used to be only activated when winning the game.
This can be easily implemented without being weird too, because the developers already implemented the "research triggers" system. The trigger for unlocking the "multiple landing pads per planet" research can be set to be the same as the victory condition for Space Age. You only need to find some kind of logical sounding reason for why that research unlocks then (I can't help because I don't know the victory condition) but that can not be too hard. Something along the lines of the player character knowing so much about space travel by then the player character figured out how to do multiple landing pads safely on the same planet.

I ran the numbers somewhere in some thread and it came out to like 20k spm can be supported from a single 6x6 landing pad without logi bots, which I think in retrospect should probably be 30k since I now believe the landing pad to be 9x9 and not 6x6

[kovarex]

How did you calculate the numbers? Did you take into consideration legendary inserters AND logistic bots at the same time?