bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.0

[ӔO]

^ good luck with expanding your network. When you do connect, you will want to make sure your lines can handle it, as there is a slight delay, I think around 2 to 3 months currently, before the taps really open up.


---
Lindley lines is stuck in two spots. Currently, there is a backlog of some 500,000 pax that I'm trying to sponge up and squeeze into the ocean.

[sdog]

Instead of properly using the opposite platform, the trains will try and loop back to use the designated platform.

used to be super finnicky from the very beginning. Since for the reverse route it will calcluate the way to the designated platform. When it passes over another appropriate platform of the same station it would call there: unless there is a way to get to the designated platfom in x tiles.

The problem comes from three things: if departing journey and return journey aren't connected the trains won't move (issue with ring lines) Since x is a bit high, trains often have one station where the distance to the next connection is close eough to send it to the next platform. After loading trains 'forget' to call at the next station and go to the designated platform. The latter seems to be the main issue for online games with lots of load and save.

Trams are not bad if they are configured properly, but they require costly signals to have great volume.
Loop lines that don't have a reverse route will quickly become overloaded, as pax must take the long way around.

Basically, they eat more money in infrastructure than they can produce, so they are a money sink

Don't you build you tram lines bi-directional, so every stop is called on the way there and the way back? Either accepting two tiles distance between two platforms or doing some bulldozing to get parallel streets to be closer together?

[ӔO]

I build tram lines as bi-directional, but some players do not, probably due to financial issues.

[asaphxiix]

two reasons -
1. Trying to avoid housing removal - making two roads to run side by side will usually require removing many houses.
2. Bigger coverage - I get to greatly extend the number of stops on each side of the way.

The way to mitigate the long way around effect is to create inner circles with joint stops at their ends, for instance, A-B-C-D-E-F-G, then back - G-H-I-D-J-K-A. So pax going from A to H for instance, will first travel to D, then take a convoy in the opposite direction to H. Also, another line could be 1-2-3-4-5-3-7-8, and then back 8-9-3-10-11-3-12-1, so pax going from 1 to 8 can drop off at the at (1-2)-3, and take the convoy ahead of the convoy on which they came, coming from (4-5)-3, thus the pax can skip the redundant travel through 4-5.

I guess this makes the lives of pax a bit miserable (but then, they rarely have to wait more than 5 minutes for the next convoy), but it makes my life a lot easier, and is rather efficient at intra-city travel, although less efficient than a direct route of course.

[asaphxiix]

I had removed stops at aylston and reddingchester, and was starting to rebuild them, when the server apparently restarted.

[Felix]

I was modifying signals at my tram line, just before the server restarted.

[ӔO]

The crashes might have something to do with stops being connected in walking distances of one another and the linux version.

Also, you shouldn't be able to delete the public player stop as a different player.

[jamespetts]

Hmm - I noticed that my client also crashed, but I was not running in debug mode, so couldn't trace the source. I haven't been able to reproduce this in a debugger, sadly, even when deleting and replacing 'bus stops in Aylston.

[jamespetts]

The crashes might have something to do with stops being connected in walking distances of one another and the linux version.

Interesting - why do you say that?

[ӔO]

Interesting - why do you say that?

I think, although I'm probably wrong, it may be related to this bug: http://forum.simutrans.com/index.php?topic=11227.0

I'm trying various things to crash the game locally, but I can't seem to do it. It may be a linux only thing.

[jamespetts]

That was fixed, though. Why do you think it the same?

[asaphxiix]

I can't seem to stay connected this evening, getting desynched after a few seconds. I did check and there don't seem to be overwhelming numbers of waiting pax. There aren't any other connected players either - anyone else having this?

Reopening the client does not help this time, I don't think this has happened before.

[jamespetts]

I have to say, I can't reproduce this - I have been able to connect for some time.

[asaphxiix]

and stay connected as well? this is troubling. I was able to stay on for 10 minutes before. I guess if no one else is having a problem, it must be me (though I have a feeling other people are having it as well). I reopen the client, and I can join again, until someone else joins, then I'm kicked.

[jamespetts]

Since I last posted, I did have some difficulties staying connected, culminating in a client crash a few minutes after desync. I am currently connected with a debug build and seeing whether I can trace the crashes.

[asaphxiix]

i'll keep joining as well. I suspect maybe one is kicking the other out?

[jamespetts]

Yes, please do keep trying to connect - I suspect that the problem may be caused by some activity, but I am currently unsure what.

[Felix]

I had the same problem yesterday evening. I could connect, but got a desync after a few seconds. The client did not crash and could run the -- now local -- game for several minutes. (I am using the 32-bits Linux version compiled from source.)

[ӔO]

I suspect these desyncs are caused by the, rather excessive build up, of pax around jammed lindley lines.
There are some 200k~500k pax in and around bushing.

Every time they reroute, it uses more CPU cycles than the server can handle, which causes the game to slow down, which causes clients to desync. The game is somewhat slow even when loaded locally, but fixes itself if you fix the jam.


maybe there needs to be a custodian who fixes jams on other people's lines?
Although, ideally, the jam shouldn't happen to start with.

[asaphxiix]

aeo, I have seen this happen while I was looking at everybody's stop lists - the maximum was 40K at one place, other than that, a few Ks here and a few Ks there, nothing serious - shouldn't slow the game down. Also, the game was not slow, only desynching.

Maybe there are two issues here - one is slowness and desyncs when many pax are waiting, the other, what we had yesterday.

[jamespetts]

May I ask - is the desyncing continuing, or has it stopped? I was connected for some time last night with a client running the debugger, and it did not either desync or crash; yet, I do not think that anyone else was connected at the time. The issue seems to have been related to activity, although it is hard to be sure.

[ӔO]

for me, the desyncs seem to cluster themselves. several with less than 5mins between and then a big gap for a good 1hr.

[jamespetts]

Interesting. Does any particular activity commonly precede the cluster?

[asaphxiix]

to me it also clusters - although yesterday the cluster seemed to span the entire evening/night with infrequent uptimes of 0.5-1 hour.

However, when I would join as the only player on the server, I would desync immediately, without performing any activity.

[jamespetts]

Hmm - very odd. Did the clusters themselves follow any particular activity, can anyone detect?

[ӔO]

I am not doing anything in particular, other than building tube stations which are not in service yet.

[jamespetts]

Hmm. If you connect and build things other than underground stations, does this still sometimes occur?

[asaphxiix]

perhaps there's a connection to something else that seems to have started to occur pretty much at the same time - when I first try join the server after coming back from somewhere or waking up, I get the protocol error message, and can only connect at the second try. I think this usually happens when the client had stayed open since the last time I was playing, but maybe this isn't always the case, but it happens most often, if not always when I haven't been logged on for a while. I'll try to keep track of it.

[jamespetts]

Please do - any clear patterns that are consistent are helpful for tracking down issues.

[asaphxiix]

when someone joins - I get disconnected, this is constant. then if I try to connect I get disconnected after 6 seconds. I must reopen the client to reconnect. We spoke about this about a week ago, I was thinking this could strangely be a local problem of mine, but now I'm thinking that it maybe related to the general issue. This, and not being able to connect on the first try I mentioned above.

[Felix]

I still get an instant desync when I try to connect. Locally the game is running extremely slow for me. The severity of the problem might be related to the weakness of my machine.

[asaphxiix]

aye, nobody seems to be able to play today.
recap of this afternoon:

I left the client open right at the beginning of december (99% sure about this)
Went to sleep, woke up a few hours later, the client is still open, I try to join:
protocol error
I closed the client, try to connect
It's still the first minutes of December, but now it says 2 clients are connected??
instant desync
try again
stay connected for 50 seconds, desync.

A while later I try again - this time the client was closed, I open it and try to join - protocol error
I reopen the client and try again - desync after ~20 seconds.

This time I check - there doesn't seem to be a great deal of waiting pax anywhere (no more than 10K at a single stop), so I don't think this is the reason.

[ӔO]

sometimes, the server will still see the disconnected client, or not see a connected client, and give back the wrong amount of clients connected.

You're probably seeing your own ghost(s). It happened to me a few times, but they eventually disconnect.

Hmm. If you connect and build things other than underground stations, does this still sometimes occur?

Yes, it still does it when nothing is being done either.


---

I will ask wlindley for his password, but only for fixing jams that occur on his line. I suspect his PC may not be up to snuff for this amount of CPU load.

[jamespetts]

This looks like some specific error that needs fixing, although it's not clear what caused it - perhaps city electrification (which, although present for some time, has, I suspect, only just become effective, as electricity.tab was configured wrongly). Alas, I do not have much time to debug this week-end. In the meantime, if anyone can run tests (including with a local "server" with another instance of Simutrans running and connecting to it as a client (use net:127.0.0.1 in the load dialogue to do this) to see whether there is any discernible pattern (for example, save an instance of the server game, open it locally, delete all the substations in cities, then run it as a local server and try to connect a client to it to see whether it disconnects; if not, try a local server again with the original server save, etc.), that would potentially save me a great deal of time.

Thank you very much for your feedback - it really is most helpful, and I am sorry that you are having trouble.

Edit: Further research shows that a debug build will stay connected whereas a release build (both from the current 10.x branch) will not. Odd...

[Felix]

With another (faster) computer I did not encounter any problems this evening.

This machine is running a 64-bit Linux. Simutrans is compiled from source, too.

Edit: I think, I am using the release build on both computers. The one causing trouble is definitly a release build.