The International Simutrans Forum

This game has now ended. An archive of the game at its final state (in-game date September 2022, real life date October 2022) can be found here (http://bridgewater-brunel.me.uk/saves/bb4-end-sep-2022.sve). Below the following line break is the archived message.

---

The Bridgewater-Brunel  (http://www.bridgewater-brunel.me.uk/)server is now running its fourth long-term game, started in June 2021.

Here is a screenshot of the map:

(http://bridgewater-brunel.me.uk/screenshots/bb4-start.png)

This map has two main landmasses: one to the east and one to the west, the easterly landmass being the largest of the two. There are also some larger inhabited islands in the north and south-west. The landscape has been generated with the "hilly landscape" setting, which I find gives more realistic contours than the default setting, and after some slight modifications to the map generation algorithm, which have recently been incorporated into the nightly builds.

This is the first Bridgewater-Brunel game to provide full support for regions, so towns have region appropriate names and the industry mix is region linked.

This map is slightly smaller than the previous map from game no. 3 (May 2020) (7500 x 2100 vs. 8192 x 2560; 212 starting towns vs 274 starting towns), but experience with the previous map suggested that a slightly smaller map is likely to be preferable.

---

Details

Dimensions (tiles) 7500 x 2100
Dimensions (km): 937.5 x 262.5
Starting date: January 1750
Towns: 212
Starting population: 885,520
Starting industries: 2,051

Please see here (http://bridgewater-brunel.me.uk/guidance.html) for rules and guidance for playing on this server. Please see here (http://bridgewater-brunel.me.uk/company-names.html) for guidance on how to choose a realistic, era-appropriate company name. Although doing so is not strictly compulsory, it is strongly encouraged.

Tips and notes for those new to playing Simutrans-Extended online

• To join the game, just select the Bridgewater-Brunel server from the network games dialogue in the game (press the "n" key).
• In case of a problem with the listing server, join the game either by typing bridgewater-brunel.me.uk into the network game dialogue, or type net:bridgewater-brunel.me.uk into the load game dialogue.
• Remember to set a password: do this by going to the "players" dialogue and clicking the green box. If you do not do this, other players will be able to play your company and even lock you out
• Do not use the same password for this as you use for anything else. The password encryption is not strong.
• The game will be paused when no players are connected.
• Bridges over public rights of way, including navigable rivers, need to be at least two tiles high.
• The "Board of Trade" (later "Ministry of Transport" and later still "Department for Transport") player is the in-game government. It is run by the server administrator
• Most towns will be connected by bridleways at the start of the game. These cannot be passed by wheeled vehicles. Roads can be upgraded at a lower cost than building a new road.
• It is not possible to delete public rights of way, but it is possible to divert them slightly. To do this, build the diversion before deleting the old way. The diverted route will become a public right of way itself even if you paid to build it.
• Anyone whose company is unused after 10 years will have their password automatically reset.
• Anyone whose company has never built anything will have their password automatically reset after 2 years.
• Anyone who wishes to leave the game or would like to abandon her/his transport company and start again, one can set one's company to allow being taken over. Once the company has been taken over, it will be permissible to start a new company even if you have had one before the takeover (but having multiple companies at once is not permitted).
• Please report any bugs with the game or pakset or balance issues on the appropriate boards (one thread per bug, please), not in this thread.
• As the game develops, it will become more demanding on computational resources. Slower computers might not be able to keep up. The symptom of a client computer not being able to keep up is a large and increasing time lag between doing something (e.g. deleting a tree) and this action occurring in-world. Disabling water animations can reduce the computational load, as does viewing the map at a higher zoom level (i.e. more zoomed in).
• Stagecoaches require two pairs of horses to travel at a sensible speed
• Players will not be able to rename towns and industries, as this is not appropriate for a multi-player game
• Canals and rivers are important in the early game: see here for a video tutorial on the subject:

Notes for players familiar with previous Simutrans-Extended online games

• The "observer" role has been reinstated: the default player is now password protected. Players wishing to start a company should select a company other than the default player.
• The map is less rough and has more realistic contours than game no. 3.
• The road network starts more comprehensively than in games before the last May 2020 (no. 3) game, and all the roads are public rights of way. Towns, industries and attractions on the same land-mass are mostly connected by road.
• Those who have not played in some time might notice some significant performance improvements, as there has been substantial work in this area since the start of the previous (no. 3) game in May 2020.
• Industries are now partly restricted by region (some industries can only be built in some regions), so some much longer industry chains will be needed in the early game where resources that cannot be produced in the region in question are required
• Industries are now much more widely linked than in previous saved games owing to a bug fixed in early 2020 and further improvements in later 2020. This should make freight transport significantly more viable from the beginning of the game
• The private car generation and routing algorithm has changed significantly in 2021; it should now work properly from the outset. This will not be obvious until the 20th century, but congestion should start to accumulate in towns from the early 20th century onwards, but be more tractable than it was in game no. 3 owing to a more accurate measurements system.
• There are now significant private road tolls, so there may be cases (especially after the invention of the motor car) when it is commercially viable to build a road just for private vehicles (player vehicles from other companies will also pay tolls)
• This map is slightly smaller than Bridgewater Brunel game no. 3, which may make things easier for those whose ability to play is resource constrained, and also mean that a higher proportion of the map will be connected at an early stage
• The computational load of private car route finding has been deliberately reduced by splitting the map into multiple separate islands separated by bodies of water

I have now twice seen what appear to be "pre-pack administrations (https://en.wikipedia.org/wiki/Pre-packaged_insolvency)". A player's company falls into administration. Within seconds a new company is started and takes over the old company. Assuming that both companies are controlled by the same player, the result is that they have an unlimited supply of capital. Maybe I have misunderstood, but this looks like a breach of rule 2.

EDIT: It might be worth cutting and posting the B-B rules & guidance to the top post, so that we are all reminded of them?

You can still ask a friend to take the company over, run it into bankruptcy again, so you can take it over "for free" again.
Totally conforms to the rules, still seems very cheated to me...
Currently, in my opinion takeovers are broken by design. It shouldn't be possible to generate freee money that way.

I guess a simple solution to this is adding the start money to the takeover cost.

The long term solution to this is adding the long planned debt feature, starting companies with 0 free capital, and requiring them to borrow in order to spend.

Until that change can be effected, however, I will ask players not to engage in this practice, as it does amount to an exploit. I have made a statement to this effect in the in-game chat and I will modify the written rules to make this clear.

I will not take action against those who have done this in the past because there may have been some lack of clarity as to the scope and extent of the rule prohibiting playing multiple companies.

Quote from: Freahk on June 05, 2021, 10:30:56 PM
You can still ask a friend to take the company over, run it into bankruptcy again, so you can take it over "for free" again.
Totally conforms to the rules, still seems very cheated to me...

I am not a lawyer, but I think in common law countries it's generally understood that two people working together to do something because it would break the rules if one of them did it, is generally even worse. Perhaps it's different in civil law countries?

Maybe B-B needs an explicit rule about conspiracies (https://en.wikipedia.org/wiki/Conspiracy_(criminal)#Statutory_offence)? Something like "Two or more players may not work together to do something that would be against the rules if one them did it on their own"?

The fewer rules we have the better, but it seems that players will exploit any loophole available to them. Or maybe I'm just blind to the ways in which I am bending and breaking the rules.

QuoteCurrently, in my opinion takeovers are broken by design. It shouldn't be possible to generate free money that way.

I guess a simple solution to this is adding the start money to the takeover cost.

I can see from Discord that you've been trying to find an in-game solution to this problem. Thank you for trying to improve the code to resolve this issue.

Quote from: jamespetts on June 06, 2021, 11:08:49 AM
Until that change can be effected, however, I will ask players not to engage in this practice, as it does amount to an exploit. I have made a statement to this effect in the in-game chat and I will modify the written rules to make this clear.

Thank you.

QuoteI will not take action against those who have done this in the past because there may have been some lack of clarity as to the scope and extent of the rule prohibiting playing multiple companies.

Yes, I agree it's best to move on. However, I think it would be merciful to tell Huitsi to start a new company. When I raised this issue, he immediately put his (second) company into administration. I think he should be encouraged to make a new (third) company so that he can take over his second company. Making him rebuilding all his stops and lines seems petty. It means he gets another 250,000¢. Spending it all using the raise/lower tools would need about fifty clicks, which might be less onerous. Maybe he could landscape something pretty like a White Horse (https://en.wikipedia.org/wiki/Category:White_horses_in_England) or a Lion Rock (https://en.wikipedia.org/wiki/Lion_Rock) for everyone to admire? Or just let it go.

Anyway, onto happier things!

Quote from: jamespetts on June 05, 2021, 02:46:53 PMThis map is slightly smaller than the previous map from game no. 3 (May 2020) (7500 x 2100 vs. 8192 x 2560; 212 starting towns vs 274 starting towns), but experience with the previous map suggested that a slightly smaller map is likely to be preferable.

This map is slightly smaller than Bridgewater Brunel game no. 3, which may make things easier for those whose ability to play is resource constrained, and also mean that a higher proportion of the map will be connected at an early stage.
The computational load of private car route finding has been deliberately reduced by splitting the map into multiple separate islands separated by bodies of water

Many thanks for taking several steps to make this game playable on weaker PCs. I am hopeful that my new PC will be able to stand the strain, but the more people can play, the better.

QuoteThe "observer" role has been reinstated: the default player is now password protected. Players wishing to start a company should select a company other than the default player.

Phew! I accidentally built things using the Default player on several occasions in the last game, so this is a good way to idiot-proof it.

Quote from: Matthew on June 06, 2021, 07:43:21 PMTwo or more players may not work together to do something that would be against the rules if one them did it on their own

I don't think so tbh.
Furthermore, this doesn't work quite well logically.
It implies that nobody is allowed to work together with anymore, because running multiple companies on its own is against the rules if one player does this on  own.

It appears Bridgewater-Brunel is not restarting each day as it should.

The client (downloaded using the Nightly Updater) is #8b9d4c6, which GitHub confirms is the latest build.
The server listing and log report #bad0022, which is the build from 29 June.
The server log still records my attempts to join on 30 June, which suggests it has missed two restarts.

Stephenson-Siemens has updated to #8b9d4c6, so it's a B-B specific problem.

Quote from: Matthew on July 02, 2021, 06:05:31 AM
It appears Bridgewater-Brunel is not restarting each day as it should.

The client (downloaded using the Nightly Updater) is #8b9d4c6, which GitHub confirms is the latest build.
The server listing and log report #bad0022, which is the build from 29 June.
The server log still records my attempts to join on 30 June, which suggests it has missed two restarts.

Stephenson-Siemens has updated to #8b9d4c6, so it's a B-B specific problem.

To clarify for all readers, this means bridgewater-brunel is not starting at all and remains offline.

I have incorporated Ranran's latest pull request and restarted the server - it appears to be running now. Apologies for the downtime.

Quote from: jamespetts on July 03, 2021, 01:00:14 PM
I have incorporated Ranran's latest pull request and restarted the server - it appears to be running now. Apologies for the downtime.

It still appears to be offline and shows no sign of having restarted at all.

Quote from: freddyhayward on July 03, 2021, 01:42:33 PM
It still appears to be offline and shows no sign of having restarted at all.

My apologies: I had misread the date on the status command on the server: it appears to have been stuck since the 30th of June. I am not sure how it got stuck, but I have killed and restarted it now, so it should be back online shortly.

It's up! Thank you James.

Thank you also to Freddy for fixing the OOS.

B-B froze or crashed at ~1900 BST last night and has not restarted.

The last thing in the server log is someone in Germany (Freahk?) joining. Nothing else looks particularly odd in that log.

Hmm - this seems to have the same symptoms as last time: the game being entirely unresponsive, including to shutdown commands, with low (but not zero) CPU utilisation. That looks as though it may be a thread deadlock, which sort of error is unfortunately extremely difficult to track down. I will be updating with the latest pull requests from Freddy and Ranran and then restarting manually very shortly.

The server has now been restarted with the latest version. Apologies for the downtime.

The same has happened again.

Quote from: freddyhayward on July 12, 2021, 05:26:11 AM
The same has happened again.

It is the same symptom in that the server has frozen and is not being picked up in the restart script.

But the last announce was at 0603 BST and the last entries in the server log are this:

Warning: nwc_chat_t::rdwr: rdwr message=Download from https://bridgewater-brunel.me.uk/download/nightly. This is an automated message. plnr=1 clientname=Admin destination=(null)
Warning: __ChatLog__: adminmsg,Download from https://bridgewater-brunel.me.uk/download/nightly. This is an automated message.
Warning: nwc_chat_t::execute: server, client id: 0
Warning: nwc_chat_t::execute: attempt to send message as locked company by client 0, redirecting to PLAYER_UNOWNED
Message: network_command_t::rdwr: write packet_id=3, client_id=0
Warning: nwc_chat_t::rdwr: rdwr message=Download from https://bridgewater-brunel.me.uk/download/nightly. This is an automated message. plnr=15 clientname=Server#0 destination=(null)
Warning: nwc_chat_t::add_message:
Warning: __ChatLog__: chat,0,0.0.0.0,Server#0,15,,Download from https://bridgewater-brunel.me.uk/download/nightly. This is an automated message.
Warning: network_receive_data: connection [6] already closed
Message: socket_list_t::remove_client: remove client socket[6]
Warning: zstd_file_rdwr_stream_t::zstd_file_rdwr_stream_t: Cannot set workers: Unsupported parameter
Message: simu_main(): World finished ...

That strongly suggests that the freeze happened immediately after the scheduled restart. It may be a coincidence, but perhaps worth noting as a point in the diagnosis.

Would there be any point in trying to get core dumps from the server, given that the executable doesn't have debug symbols? (By "debug symbols" I mean function names in the backtrace; if that is the wrong term please correct me.)

Quote from: Matthew on July 12, 2021, 07:15:59 AMWould there be any point in trying to get core dumps from the server, given that the executable doesn't have debug symbols? (By "debug symbols" I mean function names in the backtrace; if that is the wrong term please correct me.)

Yes, debug symbols is the correct term.

Might be worth a try to get a core dump from the server. Anyways keep in mind that an optimised build will opt-out many things in the code, so debugging it might not offer informations you'd expect.

If the debug symbols are not included in the binary, you can still generate the debug symbols and load it from an external source.
To do so, you'll have to re-compile the binary from source using the exact same compiler options as before except from adding the debug informations (-g flag in gcc)
Then, you can extract the debug informations from that build and load it in gdb.
See this SO for more information https://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target

Apologies for the downtime: I am restarting the server now with the latest fixes from Ranran.

We seem to be getting quite frequent freezes, which have the symptoms of a thread deadlock. I wonder whether these might be related to this (https://forum.simutrans.com/index.php/topic,20994.0.html) reported bug?
Edit: Now running again.

B-B has been down since approximately 0700 GMT today. I couldn't see any obvious explanation for this in the server log.

Quote from: Matthew on August 25, 2021, 08:10:20 PM
B-B has been down since approximately 0700 GMT today. I couldn't see any obvious explanation for this in the server log.

Thank you for letting me know: this appears to be the freezing issue again, which appears to have occurred less lately. I have now restarted this.

I would be grateful if other players could pay attention to Choose Signs when planning road routes. They do not work in a particularly intuitive way and in my experience cities will jam unless players actively consider them.

Road Choose Signs will direct convoys to the next available halt tile (if any) at the convoy's next scheduled destination. As far as I know, Choose Signs have no awareness of which stop they are near..

Here (see screenshot) is an example of how this can cause a jam. Several convoys from the line "*- Zenlyn Rocks" are going to the single-tile stop "Zenlyn Tavern" (not shown on the screenshot below, but some distance to the north) from the southeast. The routefinder has automatically routed them past the Choose Sign in front of the multi-tile stop "Zenlyn King George Street" (at the top right of the screenshot). When the first "*- Zenlyn Rocks" convoy reaches the Choose Sign, it is allocated to Zenlyn Tavern's one and only tile. When the next "*- Zenlyn Rocks" reaches the Choose Sign, there are no more tiles available at Zenlyn Tavern, so it will wait there - blocking the entrance to Zenlyn King George Street:

(https://i.imgur.com/yjpoxmm.jpg)

There were ~30 convoys stuck in this queue. I unjammed them by temporarily deleting the Choose Sign, but although those convoys could quickly pass through King George Stop (thanks to the Choose Sign!), they were now stuck behind the slow-moving "*- Zenlyn Rocks" convoy, as shown in this screenshot

(https://i.imgur.com/gmceefE.jpg)

There are several ways around this problem:

• We could have an unwritten rule not to use Choose Signs. But this means using single-tile stops, which means convoys will queue up behind one another anyway.
• We can use waypoints to avoid routes that encounter Choose Signs. In the screenshot above, I show an alternative route for "*- Zenlyn Rocks", using a single waypoint, that would have avoided this jam.
• If the best route for a road convoy involves encountering a Choose Sign, we can schedule it to stop at the stop that the Choose Sign is intended for. It will make the convoy's journey slower, but it's still much, much faster than waiting for hours in front of the Choose Sign, or waiting behind convoys that can only use a single tile because the Choose Sign has been demolished.
• We can probably all think of solutions to this issue by coding new features, but I'm conscious that it's easier to suggest new features than to code, test & debug them.

I realize it's an easy thing to forget and I have done so myself. I also realize that in this case I am the incumbent operator and you could argue I have an unfair advantage by controlling the locations of existing Choose Signs, but I am open to discussions about moving Choose Signs, etc. Hopefully we can find outcomes that work for everybody.

Probably, we have to have an End of Choose sign for road traffic as well as railway's one. It is a pakset issue, not Simutrans itself.

As with rails the end of choose will not help. A second choose sign should help. Put it just before the next stop (even if it is single tile) for the line which should not choose. In such a case the first one will be ignored. (At least for trains, not sure if this logic is active for cars.)

Server is down since eight-something this morning.

Quote from: zook2 on September 29, 2021, 11:15:49 AM
Server is down since eight-something this morning.

My apologies: I did not get an e-mail notification about this message for some reason. I have now restarted the server, which seems to have become stuck in the manner in which this has occurred before (0% CPU load, failing to reset except when killed on the command line). I suspect that the problem is a thread deadlock somewhere.

Bridgewater-Brunel is down again, presumably the usual freeze.

Now restarted.

Quote from: jamespetts on October 21, 2021, 08:37:43 PM
Now restarted.

Thank you, that was super quick!  :thumbsup:

B-B is down. It last announced just before the nightly update, so the cause is probably a failed build. I note that the nightly Linux executable at http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/simutrans-extended (http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/simutrans-extended) has not been updated (http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/), and that an odd /downloads/nightly//linux-X64 file (a malformed directory??) has appeared. The Windows executables have not updated either.

The underlying bug has been reported here (https://forum.simutrans.com/index.php/topic,21121.msg197574.html#msg197574).

My apologies for the downtime: I have now incorporated Ceeac's fixes and the server should be back up with to-morrow's nightly build.

That is such a fast response. Thank you for taking time to fix this, James!

B-B and stephenson are both down :O

The problem appears to be pakset related. I am just about to start an all day meeting - I will have to look at this later. I wonder whether the problem is some error with Rollmaterial's latest addition? I am not sure why, as it compiles without difficulty on my local computer.

I have no idea.
On my machine it builds and runs just fine.

It compiles here fine as well.

The log messages suggest there is some problem with trains not being able to find their goods. I compared the goods.pak from B-B with the one that I pak'ed myself in a hex editor and it did not find any differences between the two. I tried to compare trains.pak but the editor repeatedly froze with a generic error message, probably because the file is too large.

I have no idea what could cause this. Maybe disk corruption? Seems unlikely but I don't know what else.

The only files that have changed, according to git are br-303.dat as well as the related images, so if it compiled just fine yesterday, the issue must be in there.
The dat seems to be fine but the Railcars directory seems supicious.

The problem appears to have been a capital/lower case clash, which would not cause problems on Windows, but does cause problems on Linux as the image files are not where they need to be. I have now fixed this, I believe.

The server is now online again.

Thank you!  :thumbsup:

Quote from: Matthew on October 25, 2021, 08:08:55 PM
B-B is down. It last announced just before the nightly update, so the cause is probably a failed build. I note that the nightly Linux executable at http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/simutrans-extended (http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/simutrans-extended) has not been updated (http://bridgewater-brunel.me.uk/downloads/nightly/linux-x64/), and that an odd /downloads/nightly//linux-X64 file (a malformed directory??) has appeared. The Windows executables have not updated either.

The underlying bug has been reported here (https://forum.simutrans.com/index.php/topic,21121.msg197574.html#msg197574).

I think that this may have occurred again, or something related. The server has been down for a few days, and there the "linux-X64" file is still present and updated, and seems to be very similar to but slightly different from bridgewater-brunel.me.uk/downloads/nightly/linux-x64/makeobj-extended. Maybe the file which is supposed to be going to downloads/nightly/linux-x64/makeobj-extended is instead going to downloads/nightly/linux-X64?

Quote from: Dessard on December 04, 2021, 08:33:06 PM
I think that this may have occurred again, or something related. The server has been down for a few days, and there the "linux-X64" file is still present and updated, and seems to be very similar to but slightly different from bridgewater-brunel.me.uk/downloads/nightly/linux-x64/makeobj-extended. Maybe the file which is supposed to be going to downloads/nightly/linux-x64/makeobj-extended is instead going to downloads/nightly/linux-X64?

Welcome to the forums!

Apologies that this is down: I think that the reason is the known and occasional (but extremely hard to find and fix) suspected thread deadlock issue, as the symptoms on the server are entirely consistent with this.

I have now restarted the game on the server, so hopefully this should be working again now. I was hoping to look at some other things this week-end, too, including some of the very helpful patches that a few people have submitted, but I ran out of time in the end; I hope to review these soon.

In the meantime, happy transport network designing!

Thanks!

Server appears to be offline now.

Also, it is expected behaviour for the client's game to freeze for some time when the month change? For me, every time the game goes to the next month, it freezes for a bit, if I'm lucky it'll recover but with some weird side-effects such as everything going fast-forward for a minute or so, or the game automatically saving then disconnecting and reconnecting to the server, but if I'm unlucky it'll just crash to desktop.

Quote from: dannyliux on January 03, 2022, 10:18:52 AM
Server appears to be offline now.

Also, it is expected behaviour for the client's game to freeze for some time when the month change? For me, every time the game goes to the next month, it freezes for a bit, if I'm lucky it'll recover but with some weird side-effects such as everything going fast-forward for a minute or so, or the game automatically saving then disconnecting and reconnecting to the server, but if I'm unlucky it'll just crash to desktop.

Thank you for the report. My hosting provider's control panel access is currently down, so I am unable to retrieve my login password to log in to reset the server (I am currently staying away from home, so do not have my own record of it). I will check back later in the day to see if I can login then.

As to your question, the long time taken at the end of a month I believe is industry related. I am not entirely sure why this now takes such a long time; I will have to investigate this at some point.

I have now been able to login and restart Simutrans-Extended on the server, so this should be back up again in a few minutes.

Thank you, it's indeed back online now.

Quote from: jamespetts on January 03, 2022, 10:48:00 AM
As to your question, the long time taken at the end of a month I believe is industry related. I am not entirely sure why this now takes such a long time; I will have to investigate this at some point.

I remember this happened when the game wanted to spawn new industry (chain) but couldn't find a suitable place to build it.

Also autosave could cause that.

The server has been offline for 2.5 hours since the last restart. I also recently experienced a server crash that reset quite a bit of progress, though I can't recall any details that could help identify the issue.

Apologies - this appears to be the known intermittent thread deadlock bug rather than any crash. I have now restarted the server.

I did notice that the server appeared to be crashing at the end of December 1878 recently, but, when I loaded the saved game locally, I could not reproduce the crash. I then tried to load the game in the debugger on the server, and this then worked without crashing, so I have been unable to reproduce the problem.

Quote from: freddyhayward on January 12, 2022, 08:40:01 AMI did notice that the server appeared to be crashing at the end of December 1878 recently, but, when I loaded the saved game locally, I could not reproduce the crash. I then tried to load the game in the debugger on the server, and this then worked without crashing, so I have been unable to reproduce the problem.

This is not too surprising, as the intermittent deadlocks would likely need very specific timing of events to occur, some of which may be from clients.  I recommend compiling the live server with the -g flag and making sure it is setup to capture core dumps so that when this inevitably happens again, the process can be killed with kill -3 and the core dump analyzed.  If the server is powerful enough, it may be necessary to run the active server from a build without the optimizations (-Og flag).

Server is currently down owing to a compile issue. Apologies for any inconvenience.

Server up again.

Just a note to everyone playing, there appears to be some problems with the trams, they display negative speed and don't move at all, see the GIF below:

https://gfycat.com/afraidjubilantleafbird

I was not able to reproduce this in single player, neither new game nor old saved games appear to suffer from this, so I didn't file a bug report.

This is currently offline owing to a bug causing the game to crash on loading the saved game. The save is confirmed working with older versions, so the data should be safe. Apologies for the disruption.

Edit: Now running again.

This might not have been entirely fixed. Now whenever I try to join the server, it will load in the map and then immediately display 'Lost synchronisation with server'.

Quote from: dannyliux on February 03, 2022, 10:59:18 AM
This might not have been entirely fixed. Now whenever I try to join the server, it will load in the map and then immediately display 'Lost synchronisation with server'.

Can I check whether you have the latest nightly build?

I have also been having difficulties for a few weeks now. If I join from the terminal using -net, then I instantly desync like dannyliux. If I join using the in-game GUI, then I get a segmentation fault.

I haven't bug reported it because I haven't yet ruled out problems at my end or debugged the crash. I am using a self-compiled build (due to the libpng bug (https://forum.simutrans.com/index.php/topic,20491.msg192375.html#msg192375)), but the commit hash matches with the B-B server.

Quote from: jamespetts on February 03, 2022, 11:02:37 AM
Can I check whether you have the latest nightly build?

I believe so, yes. I use the Java updater everytime before I start playing. Currently on build 14.17 #6a9ac0a, just checked, problem still there.

I have found and fixed a bug which I believe is responsible for this - this should be incorporated into to-morrow's nightly build. My apologies for the trouble.

Thanks for the work, can confirm it is working again.

Quote from: dannyliux on February 04, 2022, 10:05:53 AM
Thanks for the work, can confirm it is working again.

Excellent!

Quote from: jamespetts on February 03, 2022, 07:01:35 PM
I have found and fixed a bug which I believe is responsible for this - this should be incorporated into to-morrow's nightly build. My apologies for the trouble.

Thank you, this has fixed the problem here too!

Bridgewater-Brunel has stopped. I guess it's the usual freeze bug.

Reset just now.

Thank you, James!

The server appears offline right now.

Reset: my apologies.

It's offline again.

The usual suspected thread deadlock issue - now in the process of being restarted.

Is it just me or is the server down again? It seems to have been down since yesterday.

Quote from: passengerpigeon on March 24, 2022, 12:07:54 PM
Is it just me or is the server down again? It seems to have been down since yesterday.

The Listserver confirms (http://list.extended.simutrans.org:8080/list?detail=bridgewater-brunel.me.uk:13353#bridgewater-brunel.me.uk:13353) that it's been down since yesterday.

Suited me since I was busy with work yesterday. ;D I can barely keep up with all the industry changes.

Quote from: Matthew on March 24, 2022, 12:12:09 PMSuited me since I was busy with work yesterday.

Me too, can you keep the server crashed until monday?  ;D

I should note that the announce function of Simutrans-Extended appears to have stopped working with the latest updates, which merged in some changes from Standard. However, I have verified that the Bridgewater-Brunel game is still running.

To join the game, go to the load game dialogue, and type net:bridgewater-brunel.me.uk. This will bypass the compatibility checks, so make sure that you have the latest version of the pakset and executable before doing this.

https://github.com/jamespetts/simutrans-extended/commit/c23b545ee9f23ab658910386036a015ba24bd4d3
This commit does not match the description and content, and I believe that unnecessary code was mixed in from the standard corresponding commit.
Perhaps r10123 was already merged and I tried to merge again and only got the excluded code.
Please check the pull request #529.

Excellent, thank you. I have now merged this and it has fixed the problem. I have run a manual update on the game server, so players will need to download the latest version again this afternoon in order to play.

B-B is feeling poorly and is having a rest.  ::'(  If you are able to give it a fresh start at some point, James, that would be lovely. I have uploaded a save from 0559 BST today (https://drive.google.com/file/d/19qojl8Z20DoOiAKDs2C-W2DI2jl9MfEi/view?usp=sharing) if you don't have anything more recent.

Bridgewater-Brunel is down. I am able to load a B-B savegame into today's build of the Linux client, so I guess it's just the usual mystery bug.

Warning to players: I get a reproducible client crash if you view the area west of Godwithers with the road direction overlay (toggled with the colon key :   ) switched on. A bug report will be up shortly, but I suggest being careful with that area and overlay for the time being.

B-B is down. It went down exactly at the time of today's scheduled restart, but the client definitely runs and the server was built, so it seems to be just a coincidence.

Could you restart it please, James?

This has now been restarted.

Thank you!

The server has gone down again. Could you please restart it, James?

Now restarted - apologies for the downtime.

I have so many Simutrans saves that I literally filled my /home drive (I corrupted my settings.xml because there was no space to save it  :-[ ) with Simutrans saves, so I have uploaded a pile of BB4 saves here (https://drive.google.com/drive/folders/1iX8Gj5Ml_IGvhQIzSve8PC_6WPkVNycU?usp=sharing), if anyone is interested in seeing how the world developed or using the savegames for tests.

James, could you please reset Bridgewater-Brunel? Thank you.

My apologies: now restarted.

Bridgewater-Brunel has crashed again.

Quote from: Matthew on July 10, 2022, 07:45:08 PMBridgewater-Brunel has crashed again.

Thank you for letting me know - now reset.

Quote from: jamespetts on July 10, 2022, 07:48:26 PMThank you for letting me know - now reset.

Thank for resetting it. Unfortunately, it seems to have promptly frozen again. I joined and it still hadn't unpaused half an hour later (no desync).

Now restarted again - apologies for the trouble.

BB is down again

BB seems to be down again

Now restarted.

We got a B-B Serial killer.
Mat reported it's dead again

Now restarted again. Apologies for not having replied to this sooner: it has been to hot to work on Simutrans in the last few days. I have been hiding in my air-conditioned shed with my model railway instead.

The server is up but seems to be consistently crashing at 5:41 ingame time, which is just a few real life seconds after joining the server.

B-B is down. Since the in-game date is May 2022, I guess that the server has gone on strike in solidarity with the rail unions. Good server! ;)

QuoteThe server is up but seems to be consistently crashing at 5:41 ingame time, which is just a few real life seconds after joining the server.

Hmm, I might have time to look into that this week if it's still happening.

This game is now at an end. A new game starting in 1750 will be commenced on the Bridgewater-Brunel server shortly. The archived saved game (in-game date September 2022, real life date October 2022) is available here (http://bridgewater-brunel.me.uk/saves/bb4-end-sep-2022.sve).