When calling a TNfP train, my friends in multiplayer get huge lag spikes until the train arrives.
I can see their latency go up from 3 to almost 30 in show-multiplayer-statistics, and the game becomes near-impossible to play for them.

As the host, I don't notice it at all.

I'm running with a section of mods, including Space Exploration + Krastorio 2 + Logistic Train Network, so the game is far from vanilla.
I can post a specific list of all mods if that helps, or let me know anything else to debug if that helps narrowing it down.

I've had a quick look over the codebase again and I'm wondering where in the flow it is and whether the lags in a specific area.

There's sort of four parts to it, dispatching a train to a player, waiting for a player to board with an active request, handling the gui interactions around destinations and then finally delivering a player to that destination. It'll be useful to know if its happening throughout the entire request flow (i.e. more probably the train state handling logic) or only for some part of it (e.g. tracking arrival timeouts, or players boarding vehicles).

For me it feels like it would be in the dispatching; it already happens before someone enters it. There was no issue during the waiting or when it was driving back. Hope that helps!

(keep in mind that with Space Exploration there are multiple surfaces/planets/maps and most of them are huge and fully explored/rendered)

Small update after doing some more testing:
- When moving the host from my local PC to a headless server, all players encounter the lag
- The lag is during the entire request flow, not just when the train arrives - including when it's waiting, all the way till its back to its parking spot
- My latency and that of the others to the server is usually 3 ticks behind, goes up to about 20 when the request flow is active. Server is pretty much next to me on 1/1Gbit

Interesting, I've pushed 0.12.6 which should improve things, let me know if that does anything for the lag spikes.

When dispatching the mods looking at train stops rather than trains -- it polls the players current surface for a list of all train stops, then iterated over all signals the stops receiving to check for the special tnp signals. I can imagine situations in SE where lots of signals are being sent to train stops and that'd be some pretty heavy processing -- I've swapped it over to a more direct "is it receiving X signal", but its still a fairly dumb iteration over all train stops.

The other potential candidate is having lots of potential tnp trains -- as theres iterations with math to work out which is the "closest" to the player.

Looking at old saves.. I've got a K2 one with 217 trains and 446 stations and in single player that was ok, though it only had ~10 tnp trains available. If its no better with the circuit fixes, I'd be interested in some numbers for comparison -- let me know how it goes with 0.12.6 tho.

Ah, crossed replies -- the entire request flow makes it unlikely 0.12.6 will do much then. I'll try and find some time over weekend to have more of a thorough dig, I can definitely see some ups issues in my old K2 save with time usage debugging on, and I can imagine they'd be a lot worse in multiplayer.

We have only about 10 stations and 4 TNfP trains, if that helps. But the save file is almost 300MB in size. Will try some more testing later when I'm online alone, to not annoy too much friends :D Thanks a lot already!

Small update from my side!

I tried the update, and it is a little better! The latency still shoots up from the usual 2-3 ticks, but only to about 16, no longer the high 20's. It surely made a difference, but the lag/stuttering is still quite intense.

Hope this helps with some insight!

I've knocked up a bit of a debug version here: https://github.com/leehuk/misc/raw/main/TrainNetworkForPlayers_0.12.99.zip . It uses the inbuilt profiler to spam factorio-current.log with profiling timings for each of the events that gets fired. Its not something you'd want to run for very long, but I'd be interested to see the numbers if you get chance for some brief testing. I can work without it like, its just whether there's something SE specific going on.

Looking at the numbers from my SP K2 save its fine ups-wise dealing with "background" events, its the train dispatching (~54ms) and the stationselect gui drawing (~125ms) that hurt. I suspect the lag you're seeing is around that stationselect gui, though I'm not exactly sure how guis work in MP.

Easiest way to test it is to walk to a tnfp train waiting at its normal station, board it and then hit the tnfp request button -- it'll shortcut straight into the gui without going through any dispatching logic and should in theory trigger the worst of the lag spikes. If it does and you wait for the lag to clear and then select a destination, it should be pretty stable for the journey.

Fixing the stationselect code could be an interesting challenge though, this K2 save spends 67ms waiting for player.surface.find_entities_filtered({type = "train-stop"}) to get a list of train stops and that part is sort of unavoidable, but well over the 16ms for everything per-tick. There's another ~56ms drawing the station buttons within the three tabs, but I can drop that to ~2ms by hacking out the 'All' tab and it might be possible to do proper lazyloading there.

Certainly some things to go at.. none of them as easy as the circuit fix though, so I'll have to see when I get some more time.

Thanks, I will give that a go later this week to try and debug it more!