The International Simutrans Forum

Community => Game Servers => Topic started by: jamespetts on June 05, 2021, 02:46:53 PM

Title: Bridgewater-Brunel game no. 4
Post by: jamespetts on June 05, 2021, 02:46:53 PM
Please do not post bug reports in this thread - please post bug reports in their own thread (i.e., strictly one thread per reported bug) in the Simutrans-Extended bug reports subforum (https://forum.simutrans.com/index.php/board,152.0.html). Thank you.

The Bridgewater-Brunel  (http://www.bridgewater-brunel.me.uk/) server is now running its third 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
Notes for players familiar with previous Simutrans-Extended online games
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on June 05, 2021, 09:52:46 PM
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?
Title: Re: Bridgewater-Brunel game no. 4
Post by: 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...
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on June 05, 2021, 10:58:05 PM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: 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.

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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on June 06, 2021, 07:43:21 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.

Quote
Currently, 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.

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.

Quote
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.

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!

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.

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.

Quote
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.

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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Freahk on June 06, 2021, 10:31:38 PM
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
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: freddyhayward on July 03, 2021, 10:26:49 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: freddyhayward on July 03, 2021, 01:42:33 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on July 03, 2021, 02:18:43 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on July 03, 2021, 02:22:08 PM
It's up! Thank you James.

Thank you also to Freddy for fixing the OOS.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on July 08, 2021, 10:41:06 AM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on July 10, 2021, 10:16:04 AM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on July 10, 2021, 12:02:40 PM
The server has now been restarted with the latest version. Apologies for the downtime.
Title: Re: Bridgewater-Brunel game no. 4
Post by: freddyhayward on July 12, 2021, 05:26:11 AM
The same has happened again.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on July 12, 2021, 07:15:59 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:

Code: [Select]
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.)
Title: Re: Bridgewater-Brunel game no. 4
Post by: Freahk on July 12, 2021, 10:39:26 AM
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.)
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
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on July 16, 2021, 06:37:43 PM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: 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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: jamespetts on August 26, 2021, 08:10:28 AM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Matthew on August 29, 2021, 07:43:02 PM
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:

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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: Phystam on September 08, 2021, 02:33:39 AM
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.
Title: Re: Bridgewater-Brunel game no. 4
Post by: prissi on September 08, 2021, 02:49:28 AM
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.)