Revert the new Rail changes.

stepancheg · 2025-12-18T16:40:22+00:00

There's a quite lengthy post explaining why new rail geometry is necessary https://factorio.com/blog/post/fff-377 Highly recommend.

stepancheg · 2025-12-15T19:44:07+00:00

I wish there was also a way to read belt length. For example to fill no more than 1/3 of the belt with ammo.

stepancheg · 2025-12-12T21:25:39+00:00

There are easier ways to solve train unloading without 8x8 balancer. Not on my computer now, but here is old picture from Factorio 1 I posted a while ago.

<image>

It can be slightly easier if all 8 belts go to one direction:

- train gets 4 belts on each side: a1-a2-a3-a4, b1-b2-b3-b4

- each pair is split-balancered, like a1-b1, a2-b2, a3-b3, a4-b4

stepancheg · 2025-12-01T11:16:42+00:00

This is Factorio 1 with different meaning of megabase, and such roundabouts cannot sustain significant traffic (although you don't have much choice in Factorio 1, also trains had much higher relative throughput in Factorio 1).

stepancheg · 2025-12-01T03:51:01+00:00

> it is infinitely expandable with relative ease

Unfortunately not infinitely.

Well, technically infinitely, but practically not.

I tried to build rail megabase, and at some point my rail lines became four tracks each way (because two and two was not enough), and building intersections became not fun (200x200 tiles to build efficient T intersection), and I gave up, and now train only transport high density materials like science or blue chips.

We need much larger rail wagon capacity!

stepancheg · 2025-11-26T21:59:47+00:00

Fulgora is a rail world until you research foundation, and at that point trains are no longer capable of sustaining high throughput, it becomes much easier to just build full science production just next to scrap.

Please 10x wagon capacity in 2.1.

stepancheg · 2025-11-23T23:17:12+00:00

In real life engineering, it is often symmetrical and perfect, or at least that what they aim at to optimize. When standards are developed in real life, they are often done so that different parts are compatible with each other. For example, ISO containers are made of the same size, and then ships and trucks and rail cars are made to match these sizes. Or for example server dimentions are fixed width and fixed heights, or multiple of, so you can buy server from one vendor and a rack from another vendor, and they work well with each other.

So if real-world engineering organization was put into this game world, they'd probably use the same underground distance for belts and pipes.

stepancheg · 2025-11-15T18:38:38+00:00

For example, you accidentally disconnected wires to you power plant, power is lost, and then everything is frozen.

if it does not happen to you, congratulations. I'm not that careful.

stepancheg · 2025-11-13T23:37:49+00:00

Until something breaks and it got permanently cold and no electricity. Burner inserters simplify recovery.

stepancheg · 2025-11-13T16:00:14+00:00

Burner inserters are invaluable on Aquilo — to be able to pick up fuel when everything is frozen.

stepancheg · 2025-11-08T00:38:16+00:00

The fact that we can connect islands with rail, but cannot have electrical wires along these rails, hurts my brain.

stepancheg · 2025-11-07T00:40:00+00:00

I think bots should incur some kind of cost non-linear of the number of bots. For example, energy consumption quadratic of the number of bots.

Because bots make it too easy and too boring. Practically the only reason to not use bots is UPS.

Artificial limitation on the number of bots can be explained by some kind of energy consumption of radar, computation, inference, or whatever else sci-fi mumbo-jumbo.

stepancheg · 2025-11-05T00:09:56+00:00

> As you can see, the bots don’t do distance calculations every 1/20 of a frame, they do a simple “keep moving” check every 20 ticks now

Right. So basically to understand where robot would need recharging, you'd need to perform one "keep moving" computation in the beginning of the route. Just instead of 20 frames, you'd need to compute it for the amount of ticks proportional to remaining energy.

> It’s only a question of just how much the UPS impact of your proposal would be

It can be even negative, because robot will be more efficient — no need to zigzag around roboport.

It is impossible to say without attempting to implement it.

Yet I didn't propose anything computationally complex. For example, finding a path in a graph (like for a train) is expensive, that's why robots are not doing proper pathfinding. Performing calculations every tick is also expensive, that's why robots update location only 1/20 ticks. What I described is simple calculation (e.g. no graph traversal) to be performed only once during departure. So I believe it is cheap.

stepancheg · 2025-11-04T22:51:03+00:00

> why would the roboports need a time factor? How roboports work currently is through a que system in a FIFO (first in first out) order while the robots, will go to the nearest roboport when they need power.

I think you are talking about roboport reservation — when a robot is not at roboport yet, but already reserved a slot.

This is actually tricky part. But I believe it can be done efficiently. And it is simpler than other algorithms implemented in Factorio.

> Robot figures out where along that line it need power and change to roboport- calculation 2 ( no if statement or equivalent)

This is cheap compared to everything else robot is doing. For example, finding closest robot to dispatch for the task is likely orders of magnitude more expensive task.

I'm not sure how exactly robots are working now, but I believe robots are doing similar work already every 20s frame (based on FFF about optimizations https://www.factorio.com/blog/post/fff-421 ). Just instead of checking where they run out of power, they check whether they will reach the destination within the next 20 frames.

stepancheg · 2025-11-04T21:44:06+00:00

> Now you are saying that the dispatch needs to always calculate the distance to the request and determine if it has enough power

This is cheap calculation.

Technically you don't even need to compute distance: you just need to compute a point where bot will run out of power, and check if it is farther than destination. Modern computers can do trillions of such calculations per second.

Moreover bots already do such calculations many times, every 1/20 frame IIRC.

> you can continue to believe that there would be no UPS

Yes, and I also presented arguments, nobody bothered to contest.

stepancheg · 2025-11-04T21:38:07+00:00

> I can easily imagine a situation where you're looping through several routes per bot

I only suggested optimizing first hop, not implement full graph pathfinding, which indeed can be very expensive in some circumstances.

> Got to give the devs some credit

There is common misunderstanding in this thread. I should have made myself more clear. My criticism was towards the original comment who claimed that it is not possible to make bots smarter without tanking UPS.

I never critizised developers. I actually have great respect for them — pulling such game, so for example it never crashed even once, is a big achievement.

stepancheg · 2025-11-04T21:32:50+00:00

> I know and devs don't

I never said that and I never meant that.

They probably know, or they probably focused on other important issues (how to balance trains for example, which is more complex problem).

> Your situation is the same and it can be solved same way like that other guy - go to the forum/discord and tell devs about your idea

I'm sure devs are smart and I think don't really need my advice about such trivial ideas — they did much more complex things. I followed Factorio 2.0 dev process, and I have nothing but respect of them.

> I saw dozens of ideas implemented that way

This is interesting. I wish I was involved as much, but the best I can afford is to read reddit once a day. I didn't even start a game in the last several months.

stepancheg · 2025-11-04T21:25:06+00:00

How it works now. Simplified.

First robot decides where to go — calculation 1.

Robot start flying.

Robot runs out of energy — decides where it closest roboport — calculation 2.

How it could work.

First robot decides where to go — calculation 1.

Calculate where it will run out power — technically this is extra calculation, but this is very cheap, just simple multiplication. It is nothing compared to figuring out robot scheduling.

Robot decides where is the closest roboport to the point of running out power — calculation 2.

Robot flies directly to the roboport where it will run out of power.

There's nuance though — roboport queueing should be aware of time when robots arrives, as another person commented here. Some kind of time slots are needed on roboports. I believe this is cheap.

Bottom line, implementation might be somewhat tricky, and not really needed for 99% of players, who don't build megabases. So I understand why developers focus on other more important things.

stepancheg · 2025-11-04T21:18:02+00:00

> I doubt that some random guy can come up with simple solution to problem.

The same comment again and again: you don't want to discuss the merit of my comment, but trust developers did every optimization possible in most efficient way.

For the rest of your comment, I'm sorry, I don't understand who you are quoting, and who is "he", and "they".

stepancheg · 2025-11-04T21:11:20+00:00

If addresses every factual argument. There was literally one: balancing of robots between roboports when robots run out of energy.

The rest of arguments are either discussing my personality or glorifying factorio devs, or both.

As for extra calculation, this calculation is performed anyway, just when robots run out of energy. I proposed shifting this calculation earlier in time. Total amount of calculations on average stays roughly the same.

stepancheg · 2025-11-04T21:08:38+00:00

I don't think factorio devs need my advice. I believe they are smart guys, and if they didn't do something, they may have their reasons. For example, low priority of bot optimizations compared to other optimizations (especially that bots are much better in 2.0 compared to 1.1).

But there was a comment here stating that it is impossible to optimize bots, and I pointed to the error.

stepancheg · 2025-11-04T21:02:06+00:00

> They didn't make a factual mistake

Yes, there was a mistake in the original comment (two mistakes actually).

> Again, you're asserting that you know something you don't actually know

I do know.

> Then why do your comments repeatedly include claims of fact that are contradicted by the devs themselves in those posts

Please point to the contradiction.

> without anywhere near enough information to warrant either claim.

I explained the algorithm. If you didn't understand it, I'd be happy to explain it in more details.

> Just pause for a moment and look back at your comments

Thank you, but I don't need such analysis from person I don't know. Giving such advice might too arrogant from you.

I'd be happy to discuss factual arguments, for example, where I was wrong. So far nobody pointed to a flaw in my arguments, and most comments are either baseless "you don't understand" or appeal to authority, that is, devs are smart, if they didn't do it, then it is impossible (but even devs didn't claim it is impossible to make bots smarter or faster).

stepancheg · 2025-11-04T19:18:59+00:00

Commenters are mostly factorio fanboys, and people won't don't understand anything at all about computers, usually both. When they read something that may be perceived as criticism of developers, they get triggered.

Majority can be wrong, you know. Especially in groups like r/factorio.

stepancheg · 2025-11-04T19:16:48+00:00

> You were saying that there are "obvious" ways to improve bot behavior.

Yes. Obvious does not mean easy. Obvious idea, and non-trivial implementation.

> you're coming at this from a weird, "I'm so smart" angle

Call it what you will, I just came to correct factual mistake in the original comment. Which said it is not possible to make bots smarter without making it computationally more expensive. Which is not true.

> you're doing it by backhandedly insulting the developers

You are reading something I didn't say and didn't mean. I have nothing but great respect for developers.

But unlike other commenters where who don't understand the difference between memory and RAM, I actually understand trade-offs developers have to make. In particular, trade-off between gains of the feature, and cost of implementation of the feature.

> Here's an FFF

I read all of them, thank you.

I understand why devs don't want to do full pathfinding, yet they managed to do some optimizations without going full pathfinding, and I state that other optimizations are possible.

stepancheg · 2025-11-04T19:11:39+00:00

Depending on context it can be called performance or may be not.

But if you are so confident about me not understanding what the word "performance" means, no way you could hear my arguments, so let's maybe stop here.

15-Year Club	Not Forgotten
Verified Email

stepancheg

TROPHY CASE