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

[asaphxiix]

so my new 3570K is arrived and installed!

I can now run two instances of the game in its peak (13000 convoys) at once, at fast forward, with other programs running as well!

However, when I tried pushing the line, I started a game of 3500X4000, 900 cities, 30 big cities, 90 clusters, 3600 median pop - -this was a few minutes ago, but it's still stuck on Initializing Map... CPU is working hard (27% of the quad core), but no progress in the progress bar. Slightly disappointing, but still I'm happy

edit: after a long while the map loaded! It would freeze for some minutes at first, but now seems to run well! I suppose it would have been faster had I used 'no trees'.

[jamespetts]

Congratulations on your new purchase!

Generating a new map can take a very long time, even on a fast computer. However, that is a task that is done only once per (hopefully) very long game, so this is not too much of an issue. (As it happens, it is generating cities that takes most of the time, not the trees, and you probably have too many cities on that map, although it depends to some extent on your distance per tile setting. You might also want to set "assume_everywhere_connected_by_road" to on if you have 900 cities, or else the game will not perform well once private cars become popular. The significance of trees is the map size, and hence the amount of time that it takes to transfer an online game over the internet).

[asaphxiix]

thanks james It was just a test to push the new machine to its limits, I'm not really playing it, but I'll keep this advice at hand when I wish to start a new mega-game (perhaps with the new US map of 5120x3276 size!)

[jamespetts]

The best advice when you want to start a new mega-game is: make very sure before you start generating that you have the right settings, then generate it whilst having lunch'.

[jamespetts]

I have restarted the server with the latest backup version of the saved game from November 1861 and the latest release, Simutrans-Experimental 10.19. I have fixed a few bugs in this version, but I am not sure whether this fixes the bugs that were causing saved game corruption which brought down the server last week. Nonetheless, a number of the reported issues that were causing problems, including excessively low revenues and convoys not replacing properly are fixed.

I have also unlocked players 1, 11 and 12, who are available for playing. Unfortunately, there is not yet a system for resetting their treasuries, so new players will just have to make do with starting with a relatively large amount of money - which might help in competing with the AEO behemoth.

Happy playing, everybody!

[jamespetts]

The server is now back online with the latest 10.20 version, which should deal with the save game corruption that has caused stoppages recently. Apologies to everyone who has had difficulties connecting, and happy playing!

[asaphxiix]

wow james - i was following that stack overflow thread today, knowing you will make it. I dunno much about coding, but it seems that nut was real tough! thank you so much for the hard work.

happy playing everyone!

[jamespetts]

Thank you!

Incidentally, still one open slot left as "player 13"...

[ӔO]

that was a speedy job with the stack overflow, for sure. Well done.

I think I still need to somehow clear that pileup, because it feels like the server slows down or desyncs when they reroute.

[jamespetts]

Slowing down might cause desyncing if the server slows down more than the client. A very large number of them seem to have gone away in the last few minutes, but huge numbers of passengers arrive all the time on ships.

[ӔO]

I do plan to add platforms at ingleminster for NLT and tortoise.

It will probably be as large as London waterloo station at that point.

[jamespetts]

After the most recent issue, the server is now running again with version 10.21. Thank you all for your patience.

[asaphxiix]

Seems to be down again :/

[jamespetts]

Working on it...

Edit: I think that I might have fixed this, but haven't had chance to test it fully or deploy the new version. The fix is on my 10.x branch, however.

[jamespetts]

I have restarted the server with 10.22 and the most recent working backup - hopefully the saved game corruption will not occur now. Apologies for the difficulties, and thank you everyone for your patience.

[ӔO]

cheers james.

excellent work on the somewhat whack-a-mole nature of these overflow/corruption bugs

[jamespetts]

Hope that I have fixed it this time!

[asaphxiix]

sorry, I logged in using 10.20 by mistake, must have caused a crash!

edit: save game is corrupt, this happened after entering with 10.22 and someone joined, then crashed.

[jamespetts]

Hmm. Your original attempt to join with 10.20 was probably not to blame. I suspect that this is the original problem not fully solved. Apologies for the difficulties.

[ӔO]

I would suggest those using sailing ships to transport pax to switch to steam ships.

You can replace 40 to 57 sailing ships with one great eastern.
The comfort the great eastern provides over sailing ships also makes them extremely profitable.

[jamespetts]

I have restarted with the latest version, 10.23. Hopefully the issue has now been vanquished! Thank you all for your patience.

[Junna]

I would suggest those using sailing ships to transport pax to switch to steam ships.

You can replace 40 to 57 sailing ships with one great eastern.
The comfort the great eastern provides over sailing ships also makes them extremely profitable.

But that running cost! Insurmountable! Isn't it the one that is like 89?

[ӔO]

it's not that bad, actually. The comfort more than makes up for the running costs. You only need it to be about 25% full to be profitable too.

Pretty decent compared to 9x clyde steamers to do the same job as a single great eastern.

If you can run 4x clyde steamers, then you might as well switch to a single great eastern.


I think the recent, rather frequent, disconnects are caused by the pax at lindley lines rerouting. some 200,000+ pax change their destination occasionally.

[waerth]

Note: There is a bug in the 0.8.4 release, fixed in the forthcoming 0.9.0 release, which means that pakset mismatches between server and client are erroneously detected. This prevents connexion to the server in the normal way. To workaround this problem, go to the load game dialogue, and enter:

Code Select Expand


net:bridgewater-brunel.me.uk


The server game will then load as usual.

Edit: Might I remind people of the importance of setting a password? Go to the "players" dialogue and click the little green box: there, you can set a password and also change the name of your company, the latter of which is also a good idea.

Unfortunately the : net:bridgewater-brunel.me.uk did not work, I get: server did not respond. If I go to the normal server address I get the PAK mismatch message.

W

[jamespetts]

The "server did not respond" message usually means that somebody else is trying to join the game at the same time. If you see this message, wait about two minutes and try again.

[asaphxiix]

seems to be a problem now as the game often hangs and crashes, and the server restarts and reverts also, but not by much thankfully. It was very stable throughout the day.

edit: the game came back from the freeze after a while and seemed to be connected still with the small icon, but not actually connected as no operations could be made. Then, trying to rejoin, it just hangs. After a while I can join, seems there was no reversion.

[jamespetts]

Hmm - are there any particular common factors that tend to lead to this issue being experienced? I connected to observe a little earlier, and did not notice any particular trouble.

[dustNbone]

I noticed the same sort of behavior at least twice, a very long (minutes) stop in the game, which then carried on as normal.  Other than one time I thought I caused it by switching to underground mode, I'm pretty sure I wasn't doing that the second time (though I suppose someone else may have been).  Aside from that and occasional lag (again probably the result of another players construction/vehicle management) things seem to be working well considering how much is going on with the map.  I seem to sit around 60% use of one core (AMD Athlon X4 @ 3.0ghz) when things are rolling along normally.  Thanks for all your recent work, James.

Dustin

[asaphxiix]

something with aeolus replacing his vehicles... He mentioned this in the chat, I see it's happened again now - frozen and lose sync, and when the game comes back I see 'replacing of aeo vehicles complete', seen it before as well. Doesn't seem to be a critical issue, though, I only saw a reversion happening once I think.

[ӔO]

I'm not sure. I tried reproducing the crash locally by replacing on top of replacing in progress and it doesn't seem to crash or hang.

Might be some server side problems?

It seems to hang at a specific time and date.

which is nov. 42:20ish

[jamespetts]

The vehicles that AEO is replacing - are they ships or trains?

The reference to a specific date and time - is this a recurrent failure in that the game will fail at that time, revert to an earlier save, and fail again when it reaches that time?

[ӔO]

The replacing was with trains, so it shouldn't have stalled, unlike ship path finding that is cpu intensive.
The only other thing I was doing at the time was removing some ship lines that were eating money.

http://dl.dropbox.com/u/17111233/stalling.sve

[jamespetts]

Are you referring to a slowdown that eventually concludes successfully or a crash/revert?

[ӔO]

yes, the slowdown that eventually concludes successfully.

It happens occasionally.

---

pretty sure the cause is the backlog on lindley lines due to a stuck vehicle.

The pax rerouting seems to cause significant CPU usage, which lags the server.

[wlindley]

Somehow my trains, which appear to be properly scheduled with proper signals, get deadlocked regularly.  Any idea why this happens?  I left everything just this way.  Looks like bankruptcy looms for Lindley Lines.