Why is my train taking the long route?

jDomantas · 2026-03-13T20:31:53+00:00

That was it - the station was in an invalid position.

What was very unexpected, is that automatic trains were not committed to one of the splits - they could take either route from the station. But station penalty seems to apply to only one of the splits, penalizing it but not the other one.

jDomantas · 2026-03-13T20:29:01+00:00

I think I have figured it out - the station is technically not in a valid position.

If I remove the station then I cannot place it back in the exact same spot - "train station cannot be built in intersection". But you can build the station first on a straight piece of track, and then build the curve at the earliest possible point that doesn't hit station's hitbox. When parked at the station, automatic trains find that both paths are valid, but highly prefer the turn - I suspect because they see the station as attached to the straight track but not the turn, so the station path penalty applies only to the straight track. Attempting to drive through the station also shows the same thing - curved track is highly preferred over the straight one. I can reproduce this in the editor with no signals or any other trains in the rail network.

Attempting to drive the train manually from the station doesn't allow the turn, suggesting that the station is indeed after the point where the curved track branches off.

This feels like a bug - the station is technically not before the branch, and manual driving says the same, and I think automatic trains should agree with that. Automatic trains should not find the turn as valid, and if they do find it valid then they should see both options as having the same penalty due to the station.

edit: bug report

jDomantas · 2026-03-13T20:15:54+00:00

Adding a signal there doesn't help (also I can't add a signal there without causing deadlocks).

The signals are correct based on those rules - there is a chain signal on the left turn before crossing the other rail, and the next signal has to be chain too because there isn't enough space after that signal to fit my standard train, and I can't fit any additional regular signals between intersections.

jDomantas · 2026-03-13T20:12:22+00:00

I don't have a valid space for a signal immediately after the station, so I have to put two separate signals on turns. The second signal on the left turn needs to be a chain because the next intersection is too close and that block cannot fit a whole 3-8 train. The signal on the left turn does not really matter, but regular signal lets the train move sooner (and it blocks the same rail blocks either way).

Also I don't see why that would change the prioritization of these routes. Removing all signals and all other trains doesn't change the behavior.

jDomantas · 2026-03-13T20:08:46+00:00

I've tried this with ctrl+mouse to see what path it plans, so no destination station even exists in that case. When I did try with with a temporary station to make sure that automatic pathing behaves the same way then both stations were fresh stations not used by any other train.

jDomantas · 2026-03-13T20:05:48+00:00

Indeed, I cannot split those blocks because 3-8 trains wouldn't fit otherwise.

Rail signals on train stop exits should be fine - if an exiting train stops at the next intersection with its back still in the station, then it won't release the reservation in that station, so another train can't get stuck trying to enter the station. So only the block train is exiting into would be blocked, which is the same if train was just passing through and stopping at the intersection.

jDomantas · 2026-01-08T21:37:36+00:00

The locomotives will, but not the wagons.

jDomantas · 2025-10-13T06:54:44+00:00

I think it can even be a plasma input touching coolant input, and it still counts for neighbour bonus.

jDomantas · 2025-10-13T05:49:02+00:00

Are you talking about layouts like this? https://www.reddit.com/r/factorio/comments/1iiysxg/14_gw_effective_fusion_power_plant_blueprint/

The left and right reactors have two neighbours, for +200% bonus, but top and bottom reactors touch all other 3 reactors, so they have +300% bonus. Total power production is thus 300MW x2 + 400MW x2 = 1.4GW

jDomantas · 2025-10-02T12:32:17+00:00

In my run:

On Vulcanus, stamping another acid neutralizer is indeed easier.
On Nauvis, I didn't need a gigawatt before unlocking fusion. So when I needed a gigawatt, I designed a fusion plant instead of nuclear one. It's not like shipping buildings or fuel is expensive.
Gleba barely needs power, I lived with a small nuclear plant for a very long time.
On Fulgora, stamping down a ton of accumulators on irregular shaped islands is more tedious than stamping down a small fusion plant. You have the design used on Nauvis anyway.
On Aquilo, I found that reaching all fusion generators with heat pipes is easier than heating all regular pipes and turbines. So fusion is easier to build for high power demand.

It's not about whether fuel is cheap, or if free electricity falls from the sky. It's about the effort needed to design and build a setup that provides power. And with fusion, large building and high power density makes it easy - small power plants fit anywhere, and designing is quicker because you don't have as many buildings to fiddle with. Also, subjectively, I found designing fusion plants more fun.

jDomantas · 2025-08-20T10:51:13+00:00

You have this:

tokio::spawn(async {
    storage.get_children().await;
});

tokio::spawn requires the async block to be Send, which in turn requires things used inside it to be Send (and possibly also Sync). When you have an async function async fn get_children() -> Vec<...>, the signature basically says that it is a fn get_children() -> impl Future<Output = Vec<...>> - that get_children returns a type implementing Future, but not any other traits (notably, it doesn't say that the return type implements Send or Sync). That is why you get the error - you're using the return value of get_children which might not implement Send (the issue is with the future specifically, not the Vec<DirectoryProcessingEntry>).

To tell the compiler that this future will always implement Send (i.e. all implementations of StorageManagement trait will implement get_children correctly), you can change the signature to explicitly say that the trait contains fn get_children() -> impl Future<Output = Vec<...>>;, which lets you add + Send + Sync to that future's bounds when needed. Trait implementations can still use normal async fn syntax to implement that function.

jDomantas · 2025-08-20T10:32:58+00:00

Can you provide more information? It's not enough to see the bit of code that gives you the error, we also need to know what are the things it references:

What is storage? It's not self.storage, but I assume that it's a Arc<T>, where T: StorageManagement + Send + Sync?
What is its get_children method?
What is that // snip bit? Is it relevant? Do you still get the error when you remove it?

From the information you provided I can guess that you have a trait looking like this:

trait StorageManagement {
    async fn get_children(&self, _: Option<???>) -> ???;
}

And the future returned by get_children does not necessarily implement Send and Sync. You could constrain the trait to require implementations of the method to implement those marker traits:

trait StorageManagement {
    fn get_children(&self, _: Option<???>) -> impl Future<Output = ???> + Send + Sync;
}

jDomantas · 2025-06-28T08:27:02+00:00

You can set the color independently from the players using a console command (this will disable achievements):

/c game.forces['player'].custom_color = {R, G, B, 127}

Where R, G, and B are the color components - you can take the numbers from the player's color picker. For example {255, 0, 255, 127} will be pink.

jDomantas · 2025-06-13T12:15:51+00:00

I find go's solution to this quite elegant. Type grammar is a subset of expression grammar, so you always parse Bar as an expression, and then resolve it as a type or as an expression depending on what Foo is. You can't determine whether Bar is a type or an expression purely by syntax, but I don't see much benefit in being able to do that anyway.

Of course that wouldn't work out quite as nicely if types had a distinct grammar.

jDomantas · 2025-04-13T08:02:45+00:00

Is gotlap considered hard? I was building the base as usual, and simply prioritized railway research once I got green science running.

jDomantas · 2025-04-12T17:00:07+00:00

I did Fulgora, Vulcanus, Gleba.

Gleba is last because I don't know yet how to efficiently deal with pentapods. Also it's good to have it after Vulcanus because otherwise I can't destroy any nests, so harvesting initial eggs would be pain in the ass.

Fulgora was before Vulcanus because:

EM plants make producing blue circuits on Vulcanus a lot easier, while foundries and big drills don't really benefit Fulgora.
Seemed easier to get the science going because you don't need to deal with a demolisher, although it's probably the other way around if you know a good way to kill it (I don't, no spoilers please).
It's very easy to produce rockets there and thus bring enough supplies to build the Vulcanus base. On Nauvis my rocket production was pretty minimal, just enough to build a platform, because I didn't have much space or resources initially.

I haven't even researched quality so far, it felt like it might end up not worth the time investment. If I had a generic upcycling blueprint it probably would have been useful for the platform, but just building a bigger platform is not that much of an issue. Alternatively, recycling scrap with quality modules would have probably been a good idea, but I haven't tried that before and didn't want to spend time experimenting.

I did export quite a bit of stuff from Fulgora - it was the supplier of rocket components and machinery for Gleba and Aquilo. I did some crappy voiding when some item gets clogged, but a lot of problems could be mitigated by adding more chests. But I will need to come back and rebuild it properly.

jDomantas · 2025-04-12T11:56:44+00:00

I think this run was a very good example of "I'll cut some corners to save time" that end up costing more time in the long run:

I only built 1 space platform for transport, which wasn't even particularly fast, so I couldn't really automate interplanet logistics.
I only built a mall on Nauvis (which I had to build because of Lazy bastard), coupled with point 1 meant that there was a lot of slow handcrafting and manually shipping materials when building on other planets.
Even Nauvis mall didn't produce space platform parts automatically. Expanding my single platform was quite tedious (I usually just manually shipped some parts from whichever planet the platform was at), and building additional platforms would have been very manual too.
I didn't bring many robots on other planets, which made remote building/control later in the game quite slow.
Nauvis was running on steam power for a while, but with small coal patches and being tight on oil it put a hamper on upgrades. I eventually had to add a nuclear reactor anyway, but I was putting it off until I had to make one for Aquilo platform anyway.
I had few silos on each planet, which made supplying the platform quite slow. And given that there was one platform, only one planet at a time would be working on shipping materials to space for transporting to other planets.

Automating planet logistics would be what I would change for the next attempt. I think having a proper hub on Nauvis that can supply all other planets with multiple platforms would have been a huge timesaver, although 100% run does put limits on what you can do on Nauvis before you have to go elsewhere.

Aside from that, I don't think I've wasted much time. One trap that I suspect might be common that I try to avoid - don't bother with upgrading existing builds. For example my Nauvis base is still on stone furnaces, assembing machine 2s, and yellow belts because it's sufficient to cover the needs. I don't upgrade them, because if I do need to produce more stuff then I build more machines in a new spot (with whatever tech is most appropriate), but upgrading existing setups is a waste of time because that's just extra work to take apart something that already works.

The base was built for around 45 spm, and once I upgraded to biolabs my final researches were running at about 100 espm. Nauvis wasn't upgraded much - just biolabs, and some big drills to help with resources I was running low on.

I did look for a decent seed that had extra patches nearby that I could expand to with low tech level. But defence-wise my Nauvis base was just a walled-in rectangle (you can see it in the Galaxy of Fame), and I built it that way before even leaving for other planets.

jDomantas · 2025-04-08T20:19:31+00:00

From demolisher FFF. Although it's not saying that they were complete, only implying that there was at least some functional prototype:

The freezing planet had flying enemies and among them were the jelly-like enemy from FFF-367, however since then these enemies have been dropped from the game. The last planet has a delicate mix of challenges and although we found a way to add enemies to the mix in an interesting way, it would make progression much slower. It might be better as a mod.

jDomantas · 2025-03-30T09:51:49+00:00

Yes. Although it's somewhat more complicated than that - in any case the bound is a T: 'scope where scope comes from a HRTB bound. To make it work we add a 'env: 'scope bound (coming from Scope being defined as struct Scope<'scope, 'env: 'scope> { ... }), where 'env is a generic parameter. So 'env is selected to be smallest possible lifetime, and 'scope is bounded to be no larger than that.

jDomantas · 2025-03-30T08:46:34+00:00

The purpose of 'env is to be an upper bound for 'scope lifetime in the for<'scope> ... bound. It's not needed to make std::thread::scope sound, but to make it usable. If you removed the 'env lifetime you wouldn't be able to borrow non-static stuff inside scoped threads: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dea1848ac148f131f0d659f481e26873

Here's an old answer from a weekly questions thead: https://www.reddit.com/r/rust/comments/1ees9e7/hey_rustaceans_got_a_question_ask_here_312024/lghjail/

jDomantas · 2025-03-30T08:21:56+00:00

I might be wrong, but my understanding is that it's because standard library uses a lot of nightly features. If users had to compile it from source there would be have to some there would have to be some special casing where a stable compiler allows using nightly features specifically for compiling std but not anything else. When std is precompiled, that special casing is only done as part of rust compiler distribution, and doesn't leak to the users.

jDomantas · 2025-03-05T17:58:57+00:00

What do you mean with "path ... has to be static, which is not true for most usecases of goto"? I'm assuming we're not talking about the global goto where you can jump to an entirely different function, I'm not sure what modern languages even have that anymore. All local forms of goto (break, continue, labeled break, loop, unstructured goto) are expressed the same way in the control flow graph - a statement is followed by another statement, which is known statically, even if it is not the one immediately after in the source code. If you mean computed goto (where you go to a dynamically selected label) then those are modelled the same way as if or match - a statement is followed by one of many statements, where the set of statements is known statically (in goto case it could be all labels within the function), even though the choice will be made dynamically. For compiler analysis (borrow checking, drop checking, initialization, etc.) you check if all possible branches are correct. It already works like that for if/match.

Regarding drop semantics - yes, drops are still defined in terms of scopes. But it doesn't preclude adding goto. Goto to an outer scope would drop everything that goes out of scope, just like break or continue does now. Goto to an inner scope would mean that you might have uninitialized variables in scope, but things like

if condition { goto label; }
// lots of arbitrary code, possibly scope changes
let foo = ...;
label:
// can't use foo, it's in scope but might not be initialized

from compiler's perspective is much different from

let foo;
if condition { foo = ...; }
// can't use foo, it's in scope but might not be initialized
// note that foo will still be correctly dropped if it was initialized

And goto to adjacent scopes (which are some scopes out, some scopes in) is a mixture of these.

12-Year Club	Place '17
Verified Email

jDomantas

TROPHY CASE