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

[rsdworker]

May I ask - can you describe your problem in more detail? If this is a bug, I'd like to be able to fix it. You were able to set up the company, but the name and password don't seem to have registered. You weren't able to click on the green button? The name of the company in the game is "Player 13".

Sadly, Lindley Lines has been liquidated after its revenues fell away precipitously after 1805.

the slot was empty when i joined so i clicked on grey square button on left of drop down box

[jamespetts]

the slot was empty when i joined so i clicked on grey square button on left of drop down box

That's how it ought to work - but I don't understand what the problem that you had is; would you mind elaborating?

[rsdworker]

That's how it ought to work - but I don't understand what the problem that you had is; would you mind elaborating?

when i clicked on it and didn't create the slot - its was stuck being empty slot

[jamespetts]

Hmm, that's odd: player 13 has indeed been created. Have you tried connecting again? It might just have been a little lag, perhaps? What ping do you get to http://bridgewater-brunel.me.uk?

[ӔO]

on slower computers, you may have to wait a few minutes for the command to take effect, as the client will run behind the server.

I would recommend a celeron G500 series, Pentium G series or better for large maps in experimental.

[rsdworker]

Hmm, that's odd: player 13 has indeed been created. Have you tried connecting again? It might just have been a little lag, perhaps? What ping do you get to http://bridgewater-brunel.me.uk?

here my ping results
--- PING bridgewater-brunel.me.uk (46.32.231.222) 56(84) bytes of data. ---
64 bytes from 46.32.231.222: icmp_req=1 ttl=55 time=29.3 ms
64 bytes from 46.32.231.222: icmp_req=2 ttl=55 time=28.7 ms
64 bytes from 46.32.231.222: icmp_req=3 ttl=55 time=28.4 ms
64 bytes from 46.32.231.222: icmp_req=4 ttl=55 time=28.2 ms


--- bridgewater-brunel.me.uk ping statistics ---
packets transmitted    4
received    4
packet loss    0 %
time    3005 ms


--- Round Trip Time (rtt) ---
min    28.243 ms
avg    28.707 ms
max    29.373 ms
mdev    0.438 ms

[jamespetts]

Hmm - that's a good ping. It can't be that. It might well be the issue that AEO mentioned. What are your system specifications (in particular, your CPU specifications)?

[wlindley]

I tried connecting with another system, this one a dual-core 3.4GHz with 1GB RAM off a 7Mbps net connection, but the game itself seems to take about 2GB--! So it instantly descended into Swap Thrash h-e-double-hockeystick. 

Could someone please delete "Lindley Lines" for me?  Much obliged. 

[jamespetts]

Hmm - 1Gb of RAM is not much these days. My current computer has 6, and the Pentium 4 machine that it replaced in December 2010 by then had 2Gb, which it had had for several years. I am afraid that large maps do take up quite a bit of RAM, although on the server, it is reported as taking up 31.5% of the 3Gb available on that (virtual) machine, which is fractionally under 1Gb, albeit in that case without any graphics. Indeed, when I run the Windows 10.14 binary and connect to the server, my reported usage is 663.4Mb, although that may well be enough to cause swap usage if you only have 1Gb and have a full modern OS running, too.

[asaphxiix]

for me, it's no longer possible to run the game with other applications open such as firefox etc. (I usually have quite a lot). I run out of sync pretty fast unless I close everything, not sure if it's the RAM or the CPU (E5300 dual core and 3GB of RAM Win 7). With other applications open simutrans takes up 48-50% of the dual core (i.e 100% of its core), not sure about the memory yet, but I suspect the CPU. With no other applications it goes to 35-40%. I fear that by the time we reach 1825 (when convoy numbers should start delining rather than growing), it will stop working altogether on my PC.


Also, quite strangely, it seems that in April, all the pax companies' profits soared by 100-200%. No explanation for this, it seems that transported pax numbers increased by a similar margin.

[jamespetts]

It is the CPU that is the main performance bottleneck for Simutrans. 3Gb of RAM is plenty - that's what the server has, and it uses less than a third of it. Hopefully, when the passenger and mail levels are better balanced, there will not be a need for anything like this number of convoys, and the game should be more playable.

Looking on the internet briefly, it seems that your CPU does not score very well in comparisons with other CPUs, which might be part of the problem.

[asaphxiix]

thanks james - I guess I'll just play as long as I can...

should we use the RC to connect to the game?

[ӔO]

I was barely playing with an E6400 in the previous game at later stages with thousands of convoys, while a Q6600 handles this game just fine.

You should be fine if you score 900 points or better on this chart: http://www.cpubenchmark.net/singleThread.html

[asaphxiix]

I have 1062... But encountering some difficulties still.

Maybe it's time to switch to one of those Qs....

Is it true the new RC has multithreading capabilities?

[ӔO]

I don't think the multi-threaded parts matter in multiplayer. There was one part with it handling map rotations with multi-thread, but not much else.


Since the game currently boils down to single threaded performance, a Celeron G530 or Pentium G840 with 4GB of RAM should be more than adequate. If you really wanted to, AMD A10-5800K, Intel i3-3225 or i5-3570k with 8GB of RAM would be the overkill solution.

[jamespetts]

You should use the latest main release, not the release candidate, to connect to the game, as the client version must be the same as the server version, or else desyncs will occur. I have yet to look into the multi-threading capabilities of the later versions (I am not sure whether they are enabled in the RC), but they apply only to a limited number of things, such as graphics, and things that do not need to be synchronised with the server (as it is very difficult properly to synchronise multi-threaded code, and even if one does manage to synchronise it, one loses much of the speed advantage of multi-threading in the first place).

[ӔO]

I just looked in to patch up my lines, and we have somewhere around 11,000 vehicles running around.

[AP]

Yeah, there's just too much traffic generally (mail especially!)

[ӔO]

You and I will have to work out some sort of system when rail comes about, because there is a lot of overlap.

[asaphxiix]

I think sticking to the 'no waiting in city center' rule should work for all of us

[AP]

I've been omitting waits in townsfrom my routes generally, once other players start serving those same towns. The trouble is I forget the waits are in the schedules until there's a queue. I think it must be slightly incumbent on someone joining a town which is already served to ensure the 2nd service doesn't mess up the first one, or at least flag up a request for the first one to e.g. be edited to omit the wait. Editing the urban streets to remove the infernal city-block-grid is also rather essential to avoid gridlock.

Re Rail, yes, that should be quite fun. Most of my turnpike network has been (rather obviously) designed for re-use as rail routes, I'm not planning on serving your territory too densely - only to get to the other side, or as needed to interchange really (e.g. the town with the ship canal whose name I forgot).

[asaphxiix]

actually, I think that if spacing is done right, even for two busy lines of two companies, it should be ok to run them in a town with intersecting and all, unless very extremely busy, I think. With good spacing you can avoid congestion completely, but it's not easy to fix the spacing, especially with lines so long and so many convoys and waiting for load stops.

[AP]

The problem is that the spacing must be set (or fixed) at the termini, to do it anywhere mid-route causes huge backlogs and delays goods en-route, which is catastrophic for profit.

Unfortunately most termini are in cities. So only by resorting to private roads can one have vehicles waiting around in a town without clogging it up for other players.

When a city isn't used by other players, using the city streets for waiting is fine, until another player choses to serve that town, when things have to be adapted (carefully!).

In honesty, it's mainly an issue because of the volumes of goods/traffic we have in the map at the moment, once that setting gets fixed, for future game it'll be less of an issue.

[asaphxiix]

Of course if you're alone in the city you can do as you please But even alone, at a certain volume, it gets tough to carry so much and not get clogged. I've found a number of ways to cope, that also help to share the routes and cities:

1. setting tight schedules that are just right to avoid clog altogether:
Evenly spread through the line, and clogging onto wait-for-load stop (terminus) = increase frequency;
Non-even spread (gaps), and clogging in mid-route behind city cars and slopes = decrease.
Even spread, no clogging = just right

I also have a formula of:
<06:24 hours / actual Travel Time = Arrivals per Month per Convoy> X <number of Convoys in a Line> = <Number of scheduled Departures>, but I've found the right number to be above that by 30-50% sometimes, so could be I got it wrong somehow. Trial and error.

Also, like you said, fixing wait on mid-route is very problematic, since you have to add another wait time, as only one convoy can wait for one departure slot in a line at a given time, no matter the direction, and mid route you have two convoys in the station. So you can do it, but you'll have to double the frequency I think (or use two stations), assuming it is your only wait stop on the line. This was somewhat against my intuition (I got it wrong for quite a while), but makes sense in retrospective

There's a part I'm still unsure of, as to whether having more than one wait stop in a line causes the schedule to deviate from your planning. I've been getting the impression that it does, so I'm keeping it just one waiting stop terminus in a line, but I don't really understand why yet. If the frequency is right, I can't think of a problem one wait stop should pose, and it's actually working, at least with rather short lines.

2. building the wait-for-load termini stops (or even mid route, provided what was stated earlier) outside the city, or in the city outskirts with access to all lines, as far away as needed of course.

3. head to head stop junctions, where convoys share the station but not the route (adjacent but don't meet).

So yeah, I think by sticking to these guidelines, two companies can serve busy lines for mail and pax in cities and outside them, you don't even need private roads for that IMO (till a certain point, but we're not there yet). Some of this also can also apply to sharing rail tracks and can help it work at a later stage, if one desires. Although the proportion between the pax and mail volumes and the speed we can carry them in this game is not very realistic, it does make for a nice challenge I think. It's nice to see those yellow dots go, so close and orderly.

[AP]

Are you scheduling waits at 400% (i.e. strict?) or 100%?

[asaphxiix]

yes, always. Optimally, if you get the spacing just right, you won't lose any cargo from the strict schdule, since you will be making full usage of your buses per month (in a regular interval), and waiting time will decrease. Even below optimum, it's still more harm than good to let them go early when full, I think.

[AP]

It's still more harm than good to let them go early when full, I think.

Glad I'm not the only one who was coming around to this way of thinking! Timetables (effectively) are the way forward!

[ӔO]

It also helps to take a peak into other player's lines to see where their lines run and terminate, so that you don't overlap on a terminus.

---

It also helps to make lines that don't loop back into themselves so that they will jam.

[asaphxiix]

It also helps to make lines that don't loop back into themselves so that they will jam.

I wonder if it's a game issue - since it's somewhat recursive behaviour... they get stuck there in a vicious circle, never able to get out.

[ӔO]

^ It has to do with route calculations and vehicles taking the path of "least resistance".
Going up and down slopes with a turn in the middle weighs less favourably than 3 turns on a flat.
Vehicles will try and go as straight as possible and at a turn or slope, will prefer turns.

There are also some other factors that I don't fully understand, but it's advisable to avoid stops in a "U" shaped layout with stops at the tips. 50:50 chance the vehicle will take the route you don't want it to, which can lead to a jam.

[ӔO]

Is it just me, or does the server not send over the save file after the first 1.3MB?

[asaphxiix]

what do you mean?

it's working as usual for me, I think

[ӔO]

hmm, strange, well hopefully it is working now.

---

Seems like there is some issue with downloading at a decent speed from the server. The data trickles, even though ping is well below 150ms.

[AP]

Am having trouble getting onto the server tonight, and when I do (and it takes 10 minutes of trying and failing), it only runs for 3 or 4 minutes, saves, then freezes, never to get going again. Not sure what's happening...

[ӔO]

for me, it looks like I get around 10~50kb/s download rate for the file.

since the save file is around 80~100mb, this takes a significant amount of time to download.

After loading, it is very smooth however, now that I'm back on my i5 system.