[2.0.15] Very weird behaviour with trains

[dev-cyprium]

I found this very weird behaviour. It has happened multiple times, I though it was me, but, I can't explain what's going on. I though it was my signaling, but I think it's something else.

This is the 3rd time I find my base with no ore, and I go diagnose and I find a random detached rouge wagon from the train... with no explanation, no idea what happaned, and wasn't there to see. I'm deep into late game, but this has happaned several times. I use L-C-C trains in my Nauvis system, and this is just bizzare.

Here are some screenshots of when it happens:






As you can see super weird, and no idea... So I guess it's a bug?

Thanks!

[dev-cyprium]

Note, it is also running in "manual" mode when this happens! So it breaks everything (obviously)

[boskid]

Thanks for the report. Could you provide a save file where i could take a look to see what happened?

[dev-cyprium]

Sure, but you should know that I fixed it manually... And then carried on to play normally. Can't reproduce it, and my save from THAT time got overriden so... Anyway, here's the save:

[boskid]

In that case there is not much i can do, other than pasting some random picture from statistics showing that some locomotives and cargo wagons were lost recently due to unknown cause.

11-09-2024, 04-07-38.png (36.98 KiB) Viewed 1034 times

[dev-cyprium]

I'll keep an eye on it and if it happens again, hopefully get you a state from where you can debug. Thanks anyway...
What you could try though is using developer tools send some bitters to attack the elevated rails, my elevated rails were in rare cases under attack, so that can lead you to a case where a bitter attack deataches the wagon if it happens off-screen if that makes sense?

Because when this happens it's usually right after an attack, the wagon is damaged, and then deataches itself from the rest of the train.
Hope that helps a bit!

[dev-cyprium]

The train also gets switched to "manual" mode, so hopefully that narrows down the case.

[boskid]

Trains switch to manual always when train composition changes so that fact carries no information.

[FGenious]

Same problem, but I used to think it's some new biters tactics. Guess train pushes them while they're going to attack something, then train stops before signals, biters change they attitude to revenge the train — and here we go, bitten off locomotive.

[dev-cyprium]

If it's intended game mechanic I'm fine with it... But it usually broke my immersion by me having to MANUALLY go back and fix it on Nauvis, wherever I am, which is a drag. Right now it's a non issue anymore, I just have a spidertron filled to the brim with rails and guns, and I just send it off to repair, and dismantle the train in question.

To me it seems disruptive and not fun, but if it's intentional, I guess that's fine too. If I may give my own feedback, I'd ideally code the biters to steer away from trains at all costs... Put it in their AI blacklist if possible? I would do it for elevated rails as well. But rails are fine even, what is "not fun" is seeing your trains stopped hours after you notice no basic materials in your base.

At least when they chew on rails, you get the "NO PATH" thing. When this happens to a train, you just have to wait and notice it via some other method, which is usually too late, as this hinders your production.

I've solved it "my own way" by placing a few alarms on key resources in my base, but it seems a bit too aggresive gamemechanic wise?

So if I can make a few suggestions OR/AND:

• Make the trains blacklisted on bitter attacks at all times
• Make a notification when a train gets switched to "manual" mode
• At least don't detach the wagon from the train if this happens if possible

Anyway, hopefully that's enough feedback

[dev-cyprium]

Here it is happening again, I caught it in a save just now!

Trains are stuck. Don't know for how long...
I even updated to experimental just in case. Still happaned

[FGenious]

Agreed, it’s so frustrating to return to Nauvis after hours only to find a dozen trains stalled in deadlock — not even giving a "No Path" alert. They’re just silently waiting for a destroyed train to clear the segment, left there by biters after an attack. But honestly, I respect the biters’ hatred for trains, especially those that run them over. It’s quite immersive that they target factories for the noise and pollution they create. Fuel trains do the same.

I actually appreciate, though couldn’t withstand the challenge of, the Rampage mod, where biters don’t just attack assemblers — they actively tear apart your logistics, rails, and power poles.

In fact, biters sometimes even do this without mods. As far as I can tell, it’s usually a reaction to the artillery train; when it fires, they rush toward it. If it’s already moved on, they attack anything you've built in that spot. I’ve even noticed some funny behavior where, if they can’t reach me or the turrets mid-battle, they start attacking rocks. Not sure how that works, but maybe it’s because they’re already partially damaged by the turrets or me and are closer.

Everything in the last paragraph seems odd to me. Power poles, rails, rocks — they’re static, don’t make noise or pollution. Those, I’d definitely put on a blacklist for biter attacks. But I’d leave trains off it, though. Their aggression toward trains (or revenge for being hit by them) makes sense.

Maybe I’d just add a separate indicator for when a train gets split up and switched to manual mode?

[dev-cyprium]

If it's too OP to just ignore trains, an indicator would be fine, or some sort of way of working around it when it happens.

[robot256]

Trains have always been vulnerable to biters (and flame turrets, and other trains). It's much less likely if you use longer trains with more destructive energy out in the wilderness. Keep the 1-1 trains inside your base perimeter and add defenses at junctions where trains might need to stop.

It would be pretty easy to make a mod that detects when biters destroy a piece of rolling stock and puts a map tag on the resulting manual trains. That way it would persist longer than the normal "entity destroyed" warning.