The International Simutrans Forum

Community => Game Servers => Topic started by: jamespetts on May 16, 2020, 01:17:19 AM

Title: Bridgewater-Brunel game no. 3
Post by: jamespetts on May 16, 2020, 01:17:19 AM
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 development forum (https://forum.simutrans.com/index.php/board,53.0.html). Thank you.

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

Here is a screenshot of the map:

(http://bridgewater-brunel.me.uk/screenshots/bb3-initial.png)

This map provides two large land-masses separated by a large sea with mostly uninhabited islands in the middle. The map has many industries and small towns, and a few large towns in various places. There is a mix of lush lowlands with many towns and rugged highlands with a much sparser population. Towns tend to be built on lower areas near rivers or the coast, and industries tend to be built in or near towns, so transport opportunities will initially be focussed on the areas of denser population.

As players' transport empires expand, players will be able to link distant areas by sea and, for inland regions (especially the large  land mass to the west, much of which is inaccessible by sea), canals. Road transport in the early years is likely to require improvements to be made to the existing bridleways to allow stagecoaches and carts, but the island nature of this land and the slowness of road transport in the early years will require water based transport for many purposes.

When railways come to be invented, new transport possibilities will emerge, although the long sea crossing will still need to be undertaken by boat. Players may find themselves competing to establish the most profitable ports and routes across the central sea for passengers, mail and cargo: shipping lines linking the large towns on both sides of the map, especially if those towns be linked to neighbouring towns by good land transport, are likely to be lucrative.

Come the 20th century and the invention of the aeroplane and motor car and players may have to rethink transport strategies that had been dominant for over a century. Will new fast road networks make railways unprofitable, or will rail operators be able to stay competitive as roads become congested? Will aircraft take over from ships, or will air travel be affordable only by a wealthy few? We only have about 200 years to wait before we find out. In the meantime, let the transport lead industrial revolution commence!



Details

Dimensions (tiles): 8192x2560
Dimensions (km):  1,024x320
Starting date: January 1750
Towns: 274
Large towns: 18
Starting population: 468,816
Starting industries: 3,429

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
Edit: Added (above) some new tips for new players regarding waterways and stagecoaches.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on May 28, 2020, 03:57:21 PM
James, could you perhaps manually link, and maybe also build them if needed, some fishing waters to the fisheries? There are quite alot on the server that cannot be served.

Edit:
Server resettet O.o
Here are coordinates on some of the ones I found, but there are probably more:

(5791,1729)
(6060,2266)
(6397,1333)
(5946,2224)
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on May 28, 2020, 10:11:23 PM
Fisheries fixed, except for the one in excessively shallow water, which has been closed by order of the Board of Trade.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on May 28, 2020, 10:24:47 PM
Fisheries fixed, except for the one in excessively shallow water, which has been closed by order of the Board of Trade.

Thanks! Poor guys in that closed fishery, they where true optimists...
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on May 29, 2020, 01:42:22 AM
I noticed further "Crazy fishing port"s, that cannot reach catch any fishes, most of them on the Western continent
(1670, 2076)
(313, 1976)
(15, 1922)
(2540, 2372)
(2368, 2437)
(971, 2113)
(7826, 1909)

A few of them can be fixed with a short canal but most of them can not.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on May 29, 2020, 08:14:57 AM
The server seems down, and is also mismatched.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on May 29, 2020, 11:11:16 AM
This is a typical symptom when the nightly could not be built and in fact, I could not build the latest master.

Edit: latest working commit is e977162, aka one commit before line-dialogue-improvement was merged in.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on May 29, 2020, 11:55:05 AM
line-dialogue-improvement
It looks like a mix with james' experimental branch, unlike the name.
I have little knowledge of Linux. I have successfully built it on windows.
Regarding mismatch, I think it is a new parameter of the vehicle added by James.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on May 29, 2020, 12:52:52 PM
Sorry, I was not about to blame anyone. Just wanted to point out which commit was meant as the commit hash is rather hidden in some git viewers, whilst the comment is not.

Anyways, I am currently retrying using the bundled makefile, maybe something changed so my CMakeLists is not correct anymore.

The issue is with headless aka COLOR_DEPTH=0 build
Quote
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: build/default/gui/components/gui_convoiinfo.o: in function `gui_convoiinfo_t::draw(scr_coord)':
gui_convoiinfo.cc:(.text+0x1a3): undefined reference to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: gui_convoiinfo.cc:(.text+0x265): undefined reference to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: gui_convoiinfo.cc:(.text+0x7a7): undefined reference to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: build/default/gui/curiositylist_stats_t.o: in function `curiositylist_stats_t::draw(scr_coord)':
curiositylist_stats_t.cc:(.text+0x1585): undefined reference to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: build/default/gui/schedule_list.o: in function `schedule_list_gui_t::display(scr_coord)':
schedule_list.cc:(.text+0x1886): undefined reference to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: build/default/gui/schedule_list.o:schedule_list.cc:(.text+0x1c30): more undefined references to `display_color_img_with_tooltip(unsigned int, short, short, signed char, int, int, char const*, signed char)' follow
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on May 29, 2020, 01:32:47 PM
There was a problem with command line server compilation which I have now fixed - I have now restarted the server with this new version, and it should be running very soon (if it is not already).
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on May 30, 2020, 11:32:08 AM
I have noticed that some of the posts here were placed in the wrong topic, for the old Bridgewater-Brunel saved game, so I have moved them to this topic. I think that I have either connected or deleted the affected fishing ports now.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on May 30, 2020, 01:16:21 PM
Seems to be much better now.

May I ask you to check (2368, 2437), (1670,2076), (580,1244) and (259,2244) again?

It seems like you had deleted the most suitable Fishery (on Lake greeninghill) in the first case, might have mised to link industries in the second case and entirely missed the remaining two.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on June 06, 2020, 12:13:59 PM
Hi,
due to the recent bug on the server, everyone is loosing lots of lots of money. I grabbed a save from it right now, which appear to be 5 months after the nightly update, and I would ask James if he could reinstate that save instead of letting the exisitng run its course. My company is in the minus already, and the timing of this is just really bad  :-|

The save is in the link I provided in this bugreport: https://forum.simutrans.com/index.php/topic,19979.0.html (https://forum.simutrans.com/index.php/topic,19979.0.html)
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 06, 2020, 12:21:56 PM
Hi,
due to the recent bug on the server, everyone is loosing lots of lots of money. I grabbed a save from it right now, which appear to be 5 months after the nightly update, and I would ask James if he could reinstate that save instead of letting the exisitng run its course. My company is in the minus already, and the timing of this is just really bad  :-|

The save is in the link I provided in this bugreport: https://forum.simutrans.com/index.php/topic,19979.0.html (https://forum.simutrans.com/index.php/topic,19979.0.html)
I second this. Revenue for most players is near zero, mine is negative (before maintenance etc.) due to refunds paid out to passengers who can't reach their destinations.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on June 06, 2020, 01:18:51 PM
I'd prefer the nightly backup, if you store those. Otherwise Ves save.
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 06, 2020, 05:20:48 PM
There's something weird going on with stagecoach routes scheduling, skipping stops etc. I only have one line so I can't interrogate it but I ntoed others chatting about it too, they may be able to shed more light on it.

What I'm seeing is timed waits being ignored totally, and vehicles going from stop 1 to stop 12 on a schedule ignoring the stops and waypoints in between. I'm also seeing weight limit errors being reported when the roads seem fine.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on June 06, 2020, 05:51:40 PM
See above?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on June 07, 2020, 12:21:14 AM
My apologies for the difficulty; I will look into reinstating one of the saves once we have confirmation to-morrow that the bug is entirely fixed.

I should note that the backups are not nightly, but rotating hourly (but only rotating if anything changes) with an archive of about 6.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on June 07, 2020, 11:13:27 AM
I see that players have managed to restore themselves to profitability and all those who were previously solvent remain solvent, so I shall omit reverting the saved game on this occasion. Apologies again for the difficulties related to yesterday's bug.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on June 07, 2020, 12:39:16 PM
Oh well, two years of hard earned acount balance gone, not including the loss of profit :/
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 09, 2020, 03:11:52 PM
Server is down it seems?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on June 09, 2020, 05:35:37 PM
It seems to have been down transiently earlier this afternoon but has restored itself before I was able to investigate.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 10, 2020, 12:39:52 AM
AP, for the Southern Mail line, you seem to be using a 'wait for time' order of once every ~6 hours combined with a 'maximum wait time' order of ~1.5 hours. The good thing about this is that your horses will 'only' wait at stops for a maximum of ~1.5 hours rather than the full ~6. Luckily. since the subsequent convoys cannot wait for more than ~1.5 hours, they do not wait at all, although this is probably not what you intended. Please, as I have suggested, remove all waiting orders within cities and instead wait at terminals (composed of many adjacent stops and a choose sign) just outside the cities on the two ends of your route. On my end at Bickcaster, I have already built a terminal which you are welcome to use. This will ensure that you do not disrupt other players' routes.
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 10, 2020, 07:31:56 AM
Freddy - The use of giant out-of-town terminals is rather out of character with the c18th setting of the game. I think it's fine as it is, if the lines' vehicles are well spaced out - ensured by wait orders at many of the stops - then any given vehicle is unlikely to ever need to use the wait order, since no vehicle will have previously called at any given stop for quite some time. The stop at Bickcaster has a wait time due to the adjacent depot, as is always a good idea so as to smooth the entry of new vehicles onto a line if required.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 10, 2020, 08:34:52 AM
I think it's fine as it is, if the lines' vehicles are well spaced out - ensured by wait orders at many of the stops - then any given vehicle is unlikely to ever need to use the wait order, since no vehicle will have previously called at any given stop for quite some time. The stop at Bickcaster has a wait time due to the adjacent depot, as is always a good idea so as to smooth the entry of new vehicles onto a line if required.
Even the best-case scenario when convoys are evenly spaced would not prevent a vehicle arriving from ~4:50:00 onwards to wait up to 1.5 hours until the start of the next month, delaying up to 3 of my twice-hourly coach services. In fact, this has already happened a few times, usually lasting about 1 hour, and so I have had to divert my route to avoid being stuck. I'm not sure how your system helps to spread out convoys either, since it makes the first one wait but allows the subsequent ones to catch up and follow closely behind it
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 10, 2020, 08:48:27 AM
Freddie- I%u2019m offline now (working) but that line doesn%u2019t have a max wait (It%u2019s unlimited). Only a spacing time. So if two vehicles arrive at once for some reason (e.g. a local problem), they should depart correctly spaced. The timing stops are all through the route however.

I%u2019ve tweaked the times to account for more vehicles now present, balancing is clearly trial and error.

The only caveat is the bug causing scheduling to go awry, which I can%u2019t get my head around. It%u2019s a nuisance.

I doubt the company will remain solvent much longer so I wouldn%u2019t worry unduly, the game%u2019s pretty unplayable right now.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 10, 2020, 09:21:37 AM
Freddie- I%u2019m offline now (working) but that line doesn%u2019t have a max wait (It%u2019s unlimited). Only a spacing time. So if two vehicles arrive at once for some reason (e.g. a local problem), they should depart correctly spaced. The timing stops are all through the route however.

I%u2019ve tweaked the times to account for more vehicles now present, balancing is clearly trial and error.

The only caveat is the bug causing scheduling to go awry, which I can%u2019t get my head around. It%u2019s a nuisance.

I doubt the company will remain solvent much longer so I wouldn%u2019t worry unduly, the game%u2019s pretty unplayable right now.
The line is set up completely differently to what you're saying, either by mistake or because of the bug. On my end, there is clearly a maximum wait time of 1:36:00, and a fixed wait for time order set for 6:24:00 (i.e. 0:00:00) once a month, though this is effectively negated by the maximum wait time. I believe the only way to set up a relative spacing system in simutrans-extended is to use a minimum load of 100%, but even that has a high potential to block other lines.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 17, 2020, 11:27:35 PM
After I acquired player 11 (AP's company), everyone's profits, including my own, rose dramatically. Does anyone know the cause of this? I did make some changes to the mail lines that reduced their throughput, but they were not very profitable to begin with, and this doesn't explain the 10s of thousands in increased profits for players all over the map.
Edit: there was a massive spike in global passenger numbers in 1786, but I don't know what caused that either.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on June 17, 2020, 11:48:42 PM
After I acquired player 11 (AP's company), everyone's profits, including my own, rose dramatically. Does anyone know the cause of this? I did make some changes to the mail lines that reduced their throughput, but they were not very profitable to begin with, and this doesn't explain the 10s of thousands in increased profits for players all over the map.

Profits do not increase on their own: if profits increase, it will be because something in the game is happening differently such that you are earning more in the way of profit. The most common thing that increases profit is transporting more. You can check the amount being transported in the finance window graphs.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 17, 2020, 11:53:19 PM
Profits do not increase on their own: if profits increase, it will be because something in the game is happening differently such that you are earning more in the way of profit. The most common thing that increases profit is transporting more. You can check the amount being transported in the finance window graphs.
You might have posted this right after my edit: there was a global increase in total passengers from 29,000,000 in 1785 to 36,000,000 in 1786.
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 18, 2020, 05:40:38 AM
After I acquired player 11 (AP's company), everyone's profits, including my own, rose dramatically. Does anyone know the cause of this? I did make some changes to the mail lines that reduced their throughput, but they were not very profitable to begin with, and this doesn't explain the 10s of thousands in increased profits for players all over the map.

Interesting! 🤨



I trust you saw the incomplete mail line to the east- I didn’t have the funds to build the short length of road required to finish it.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 18, 2020, 06:16:22 AM
I trust you saw the incomplete mail line to the east- I didn’t have the funds to build the short length of road required to finish it.
Hmm, I didn't notice that. I was more concerned that there were private road signs only allowing the Timo Trawling company, causing the mail coaches to be rerouted over 300km to reach their destinations. Hopefully that was a bug and not a genius trolling attempt. In any case, you'll be pleased to know that the Southern Mail line coaches now enjoy the Bickcaster terminal as well as the new Bewchester Megaterminal ;p
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 18, 2020, 06:33:26 AM
There were private road signs on the roads I actually built. None on the roads which were public rights of way obviously. But they were set to admit my own coaches of course. My economics were so fragile I didn’t want competing routes using my roads through the mountains (since they cost so much of my capital to build, and since it would have screwed up trying to figure out how to optimise them).
Title: Re: Bridgewater-Brunel game no. 3
Post by: AP on June 20, 2020, 07:25:10 PM
Did  you guys ever figure out why taking over my company increased everyones profits?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on June 21, 2020, 12:00:39 AM
Did  you guys ever figure out why taking over my company increased everyones profits?
I think that was a coincidence; the global number of passengers (ie people attempting to make trips) increased drastically, although I still don't know why.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 03, 2020, 07:28:55 AM
Hi guys,
I'm away from home and have no means to connect to the server for the next couple of weeks.
If my company gets unlocked, would you please mind not cheating until I get back?  ;D (and also please not be claimed by another player!  :o)

Thank you all, and have a very good summer!
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 03, 2020, 08:35:19 AM
Hi guys,
I'm away from home and have no means to connect to the server for the next couple of weeks.
If my company gets unlocked, would you please mind not cheating until I get back?  ;D (and also please not be claimed by another player!  :o)

Thank you all, and have a very good summer!
Oh dear... your railway is completely jammed! If it does get unlocked, do we have permission to unclog the railway to allow the free-flow of goods?
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 03, 2020, 10:02:41 AM
Boggers, thought I had cleared it!
Yes, of course, that would be very helpful! Perhaps one of you even could get my pw and clear it (and any future deadlocks) until I get back?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 04, 2020, 08:03:51 AM
Boggers, thought I had cleared it!
Yes, of course, that would be very helpful! Perhaps one of you even could get my pw and clear it (and any future deadlocks) until I get back?
I will volunteer to do it if you think I'm trustworthy enough!
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 04, 2020, 08:12:00 AM
Thank you!   :D

Well, you will just have to play by your conscience  ;)

If you got any questions, or if anyone else wants to discuss something about it, type here as I can see this all the time!

Thank you
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 07, 2020, 06:42:27 PM
Freddy, did you get my pm?  :)
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 07, 2020, 11:50:26 PM
Freddy, did you get my pm?  :)
Yes, I fixed the jam a while ago. I also made a few minor changes around winerworth and Lulington to better accomodate railways. I did all the terraforming with my company and only used yours to replace a couple of ways. If I remember correctly the total cost for your company was something like 2000c.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 09, 2020, 02:32:02 AM
I have just fixed a serious problem with your rail schedule - it was set to mirror, so trains would loop around the entire line to access the same platform in reverse. This probably caused the jam in the first place. i manually added the return trip using the opposite platforms.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 09, 2020, 07:02:27 AM
Thank you, Freddy!
Btw, what year is it now? Is passenger railway a thing yet?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 09, 2020, 07:23:23 AM
Thank you, Freddy!
Btw, what year is it now? Is passenger railway a thing yet?
The year is 1810, and yes, passenger railways are emerging. There are currently three networks shown in these maps:
(https://i.imgur.com/78TrQf1.png)

(https://i.imgur.com/7xKHm1w.png)

(https://i.imgur.com/OdAsmzy.png)
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 09, 2020, 07:11:35 PM
What's going on with the server?
There have been a lot of desynchs today, a few crashes and it seems to be unreachable at the moment.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on July 11, 2020, 09:50:18 AM
I think the server crashed when I upgraded the bridge with cobblestone road.
(Unless someone else did something that caused the crash or another problem happened by chance. 2 other people were connected)

EDIT:
May have crashed again (´・ω・`)
This time I just saw the depot, so I think it's another cause.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on July 11, 2020, 10:00:03 AM
I think one of the causes of dysync is the routing anomaly I've reported several times so far.
After disconnecting from the server, I found a strange traffic jam on offline state, so when I checked the schedule I found a lot of unusual [<<] inserted and the schedule was broken.
I immediately connected to the server hoping to fix it, and it was fine.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on July 14, 2020, 03:54:46 PM
As you can see on the bridgewater server, colliery and Ironworks are closing down one after another, the industry prefers to close, but nothing new or upgrades happen. Ironworks at bridgewater server left only the last one, which will also be closed in the near future. That is why I have withdrawn from those industries. I am afraid that industries that have passed their retired dates will be shut down in this way. The next big industrial decline could be in 1840.


EDIT:
Oh, my pig... The final ironwork was closed and many lost their jobs.
(https://i.imgur.com/xbw3nw7.png)
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 16, 2020, 05:56:42 PM
Ťoday I cannot connect to the server.
It's either not responding at all or I get the "not enough bytes transfered" error after a few seconds of loading.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 16, 2020, 11:02:59 PM
I may have just crashed the server :(. some kind of array out-of-bounds error while buying vehicles at the rail depot.
Title: Re: Bridgewater-Brunel game no. 3
Post by: ceeac on July 17, 2020, 08:10:16 AM
some kind of array out-of-bounds error while buying vehicles at the rail depot.

Should be fixed by PR #213 (https://github.com/jamespetts/simutrans-extended/pull/213).
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 18, 2020, 06:43:13 AM
Freahk, there is quite a significant jam on your railway near Mount Greeninghill:
edit: there is also a big jam at olderminster, where I would like you to use the new outer tracks.
(https://i.imgur.com/OQfXnl3.png)
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 18, 2020, 02:30:54 PM
Well I had no time to fix it this morning.
Drive by sight, the not-working method*

*Except for tracks without any intersections**

**More preciesely, intersections are okay, as long as these are perpendicular in ordinal directions and there is no terminus station involved
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 20, 2020, 07:00:32 PM
Im back now, thank you for keeping track of my company :)

So, what did I miss? :D
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 21, 2020, 02:06:53 PM
Management in trouble

It's the year 1825.
Most of the active companies are running horse hauled passenger railway networks. The first steam engine that has an odvantage over horses just became available. Some companies are planning to run these, whilst others do still prefer horses for their much better braking capabilities.
In any case, all companies are expanding. All companies? No! Prominster Shipping & Coaches is in trouble.
They had been short of money since a very expensive investment just before the depression. The rivermetro was a money printing machine for two months, but then the dpresion turned that 5m investment into the biggest fail-investment in history so far. Prices had expanded by more than 3m above the expected cost due to over-restrictive road replacement rules, so it took 2m alone to get some roads upgraded into bridges.

The company recovered from this, now maintaining a fairly large railway network, now running into troubles again.
The management simply missed to order a new datacenter from the future to manage the company.

Due to this, the management resigned from the company.
For emergency cases, Far East Railways' manager Freddyhayward is managing the company. To date, it is unclear if the original management or a new management will continue operation of that company.


It was nice to play with you most of the times, but I suspect I have to leave the server already. My i7 6700HQ with its 16GB of DDR3-1866 memory seems to be too slow to keep up since yesterday. Sunday was the last day where I was able to play pretty fluently.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ves on July 21, 2020, 05:50:42 PM
Im sorry to read that, it was very nice to have you in there!

But, my gosh, this is just some coincidence... Because I too have decided to leave the server game. :o Not because of the lagging like Freahk, but because my company have suffered severely from the competition when I was away, even though Freddy was managing it. This in it self is not a problem, as I truly believe it can be set right without too much effort, however I severely lack the time to do so. I too will give the keys to my company, the "Ves Transport Agency" to whoever who wants a great challenge in recovering a company.

I have reset the password to 1234

Thank you all for the time spent in there, it is a really fun place to be!


Freahk, this is just a strange thought: I came back to the game on monday, this is the day you say it started to trouble again. Could it be that you and I cannot be connected at the same time? If so, hang on to the server a few more days, we could do some experiments if you want to.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on July 21, 2020, 06:08:16 PM
My i7 6700HQ with its 16GB of DDR3-1866 memory seems to be too slow to keep up since yesterday. Sunday was the last day where I was able to play pretty fluently.
I don't think the specifications of the computer are related to the cause of this. I haven't played much these days, but even in my case the server can be responsive or very bad.
It is often said that players in Japan have network compatibility with each other, but I'm not sure if that is the case.
I sometimes get disconnected frequently, but I don't even know if it was my own operation.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 21, 2020, 06:42:27 PM
In my case I am quite sure it is the hardware, not the network.
I had the exact same symptoms a few weeks ago on my PC, so I started playing on my (much faster) laptop.
It worked ell there until yesterday.

Desyncs are a different thing. Even now I can stay connected for many hours, I just cannot practically build anything. The response times are just muc htoo long, it can be as much as 15 minutes, which is because the game on my laptop is running 15 minutes behind the game on the server.
Such huge delays are not a network thing.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on July 26, 2020, 09:12:28 PM
I have almost lost my motivation now. So I leave the server once. After a while the password will be unlocked.

The original purpose of my play was to confront the railroad by bus. Well that is the distant future of the 20th century. I wanted the concept of labor costs to be independent, as I started a dedicated thread before.
Without it, I thought it would be difficult to balance buses and railroads, and recombination system, these games and the economy.
In addition, the reason for the cost is difficult to understand, which means that it is easier for the player to understand.
After all, I felt it in the play of the previous era. For example, ship personnel, carriage personnel, drover, postboy, and why that cost is incurred.
When making a new pakset, the cost determination method becomes clear.

Regardless of that, old times, big maps, playstyle differences, competition, historical reenactment, it's been a good experience for me and has given me a lot of inspiration.
A lot of UI ideas have come up, but they haven't been worked on yet. I bring it back to Japan.

Also we ranran haven't used the overtaking feature at all so far, so I was able to find many problems this time.

Some play style differences are interesting.
One, the occupation of the land by the marker, such bad behavior of the manner is rarely seen in Japan. And it severely interferes with the marker function. Even in Japan, markers are used as a means of communication between players. As you can see in the other thread's discussion, simutrans's chat functionality is poor. Often there will be a dedicated area for communication between specific players. This creates a place where strange signs line up.
Returning to the reservation of the land by the marker, at least in Japan it is common to do that with add-ons such as fences, trees and promenade. This also has some balance issues regarding land reservations and costs, but at least it does not interfere with the original function of the marker. In addition, it is not possible to reserve land that is not leveled, so there will be no unnecessary obstruction work such as obstructing the construction of a bridge. If you do, you will pay the additional costs in advance. And there are few abnormalities in appearance. There is just a vacant land add-on under the viaduct.
Also, since this was my first time to participate in a pakset network game that reproduces a long history, I had never seen the act of making a reservation for a distant future.

Thank you for running the server and giving me this opportunity. See you next life. (´・ω・`)

EDIT:
Don't worry too much. I'm not leaving because something went wrong on the server.

@Huitsi - I was aware of the demands of moving the road, but the frequent dysyncs couldn't handle it. And I was out on the weekend. I'm sorry.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on July 26, 2020, 10:36:36 PM
I have almost lost my motivation now. So I leave the server once. After a while the password will be unlocked.

This is sad to hear :(. I hope the accumulation of matters brought up by other players including myself did not cause this.
Despite the frustrating problems with road convoys in simutrans-extended, you led the most successful transport company until the steam age, and I'm sure it could have remained so with continued management. You also permanently reshaped the global road network, bringing towns closer together.
You have also brought up legitimate balance issues that I hope, given enough time, will be addressed.
I hope we see you in the future.
Title: Re: Bridgewater-Brunel game no. 3
Post by: prissi on July 27, 2020, 02:33:50 AM
Standard removes lot of stupid chat messages upon saving and reloading, so only the player relevant messages remains. This has led to a much more useful ingame chat. You should aks makie on the current experience.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on July 27, 2020, 07:48:40 PM
It seems that several people have left this server at the same time.

The first thing to say is that it's a game and if a game stops being fun or real life is more important, then leaving is the right thing to do. And if you can't run the game, then there's little alternative.

Secondly, you could all have just disappeared without explanation. That's fine and Sim-Ex has procedures in place to deal with that (bankruptcy, password expiry, and takeovers). But you have left with an explanation and succession plans, which is courteous. Thank you!

I would like to say that these departures might make room for new players like me, but actually I suspect my participation will be brief as Freahk's experience suggests the game will soon be unplayable for me too.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 28, 2020, 01:31:31 AM
This town decided to build a new road bridge - at whatever the cost!
The bridge did even cut train routes along that line.
Title: Re: Bridgewater-Brunel game no. 3
Post by: DrSuperGood on July 28, 2020, 05:51:10 AM
I wanted the concept of labor costs to be independent, as I started a dedicated thread before.
As far as I am aware that has always been an intended feature. Just due to lack of development it is not a high priority feature.

The feature is required for correct operation of multi-unit trains since they can have cab units connected back to back with only a single driver at the forward end of the entire train.
This town decided to build a new road bridge - at whatever the cost!
The bridge did even cut train routes along that line.
That needs a bug report...
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 28, 2020, 10:33:56 AM
That needs a bug report...
I do only report bugs that I am able to reproduce, otherwise I'll be told to provide a reproduction case, which I am not able to provide in this case anyway.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on July 30, 2020, 01:33:36 AM
There has been some discussion here and in the Discussion thread about the problems of using chat and markers. The Simutrans chat system was probably state-of-the-art at one time and I'm grateful to everyone who created it (prissi?), but it does have weak points. A couple of days ago I asked Leartin (server admin) whether they could add a Bridgewater-Brunel channel, and Freahk independently had the same idea yesterday. Great minds think alike!  :D

Several players have already found it, but I thought it was useful to raise it here, so that everyone is aware of this innovation.

For those who haven't used it before, Discord is a live chat system that was specifically designed for use in multi-player games. I haven't used it for multiplayer, but I've used it for other purposes (e.g. K-pop and language learning) and it's one of the best bits of software I've ever used. The advantages for us:
The disadvantages:
IMHO that makes Discord a good replacement for in-game chat, but not for the forum. The particular setup of my system means that I can spare the CPU cycles, and so can Freahk, but I think that's the biggest issue and I worry that it makes B-B even more socially exclusionary.

For those who wish to try it out, you can join the Simutrans server using this link: https://discord.gg/fpXY772 (https://discord.gg/fpXY772) .
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on July 30, 2020, 12:36:00 PM
James, could you please adjus the max diversion tiles number to a (much) larger number?
Once it was possible to temporarily cheat-cut routes, it was not too much of an issue, but now it is.
With the current number, it is virtually impossible to build cut-and-cover railway Lines, which was and is rather common practice in the real-world (sub-surface tube lines for example)

Further, the discussed bridge replacement/upgrade issue in cities could at least partly be solved by this.

This would be the simplest and best temporary solution I can think of until there is a better way to modify existing PROW ways without cutting these.
Title: Re: Bridgewater-Brunel game no. 3
Post by: VOLVO on July 31, 2020, 07:55:42 AM
Since after the update of today, the server keep crashing and rolling back, it has happened 3 times in 2 hours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on August 04, 2020, 04:44:10 PM
Have there been any changes to simuconf?
A few days ago, global passenger numbers suddenly doubled.

I am now in the situation that I'd need to increase capacities of the majority of my lines in order to handle this. Especially oversea lines seem to be affected.
I am somehow unsure if I should do those major adjustments to my lines.
If this increase was intended and will remain, I should definitely do so. Otherwise, it's not worth the effort.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Junna on August 04, 2020, 11:42:14 PM
Have there been any changes to simuconf?
A few days ago, global passenger numbers suddenly doubled.

I am now in the situation that I'd need to increase capacities of the majority of my lines in order to handle this. Especially oversea lines seem to be affected.
I am somehow unsure if I should do those major adjustments to my lines.
If this increase was intended and will remain, I should definitely do so. Otherwise, it's not worth the effort.

Maybe the price on the route was changed? This can easily double or triple passenger numbers if the old was "low" and now is "very low" depending on population demographics.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on August 05, 2020, 12:47:18 AM
This is entirely unrelated.
No matter if you serve them or not, the global Passenger demand will always be more-or-less constant. Obviously not exactly constant but slowly growing as cities grow and with some random variation.
Doubled pasenger numbers cannot be caused by those natural effects.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on August 13, 2020, 07:09:21 AM
(https://cdn.discordapp.com/attachments/737992455361658891/743363976401911839/unknown.png)
Sorry, but I can't. My "favourite" feature is doing it's job quite well again, which seems to be to forbid improvements.

Edit: And here is an image showing how well that feature prevents players from building huge detours.
(https://cdn.discordapp.com/attachments/737992455361658891/743374278782877716/unknown.png)
Note that this road is PROW, but I chose one that was unused anyway, so I'm not obstructive to anyone (not even privatecars)
In principle, that could be done to any other road as well.

So again, please increase the max diversion tiles. It will help people to build reasonable diversions and doesn't make any difference in case of obstructive people building ridiculus detours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 14, 2020, 06:31:59 PM
To answer the question - the only change in the last few months that has been made to simuconf.tab has been to reduce the framerate from 30 to 15.
Title: Re: Bridgewater-Brunel game no. 3
Post by: SuperTimo on August 15, 2020, 11:02:36 AM
Hi James, are you able to unlock companies? I am not sure how but my company, Great North Western Railway, won't accept the password I had previously. So I am locked out of it.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 15, 2020, 11:08:02 AM
Hi James, are you able to unlock companies? I am not sure how but my company, Great North Western Railway, won't accept the password I had previously. So I am locked out of it.

Unlocked.
Title: Re: Bridgewater-Brunel game no. 3
Post by: SuperTimo on August 15, 2020, 11:08:29 AM
Thanks James!
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on August 18, 2020, 08:06:36 PM
For the benefit of others: you won't be able to connect using the Windows executable currently posted on Bridgewater-Brunel.

I guess this will be resolved when the B-B server recompiles tomorrow morning. I'm just miffed because tonight was my first chance to play after a few days away!
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 18, 2020, 10:47:07 PM
You should be able to force connect: try typing net:bridgewater-brunel.me.uk into the load game dialogue.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on August 21, 2020, 08:03:59 AM
I cannot login into my company anymore. It seems like the password has changed.
Could you please reset the password of Prominster shipping & Coaches?

As the listing server is down, could you in the meantime disable announcements?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on August 21, 2020, 08:09:42 AM
As the listing server is down, could you in the meantime disable announcements?
To clarify for others, it seems that failed attempts to contact the listing server are the cause of the no-pause-freezes we have been experiencing.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 21, 2020, 09:48:33 AM
Thank you for checking that. I have now modified the server's simuconf.tab so as to disable the announcements. This will affect the server on the next restart.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on August 21, 2020, 10:20:46 AM
Thank you for checking that. I have now modified the server's simuconf.tab so as to disable the announcements. This will affect the server on the next restart.
Thanks, can you please also reset Freahk's password (Prominster Shipping & Coaches)?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 21, 2020, 11:02:43 AM
Thanks, can you please also reset Freahk's password (Prominster Shipping & Coaches)?

Unlocked.

I am not sure how it happened that Freakh's password no longer worked - this might point to a very complex bug in which passwords somehow become corrupted, but I am afraid that I know nothing of the password code as I did not write it and have not, to my recollection, modified it.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 29, 2020, 11:12:16 AM
As some regular users may know, there are currently problems on the server which I am in the process of investigating.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 29, 2020, 02:06:54 PM
The server is now running again.

The problem appears to have been related to me setting the pakset settings to override the saved game settings. For reasons which I have yet to be able to trace, setting this seems to have caused the maximum number of alternative destinations for passengers (but, oddly, not the minimum number) to be set to an unreasonably high level. This is what caused the performance issues witnessed by those attempting to play yesterday.

These incorrect data seem to have been generated on the server. Unfortunately, I have not been able to reproduce this, so I cannot find the ultimate cause. Fortunately, unsetting the option for the pakset simuconf.tab to override the saved game settings reversed this problem, and, as the correct number of alternative destinations is calculated monthly, the incorrect number has now been replaced with the correct number, and performance has returned to normal.

My apologies for the difficulties: people should be able to connect now as previously.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on August 29, 2020, 02:42:15 PM
I notice that regions are now active on bridgewater-brunel. was this intentional?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on August 29, 2020, 02:45:07 PM
I notice that regions are now active on bridgewater-brunel. was this intentional?

It was, I think, an inevitable consequence of overriding the save settings with pakset settings in order to enable the new just in time mode 4.
Title: Re: Bridgewater-Brunel game no. 3
Post by: VOLVO on September 06, 2020, 01:22:48 PM
The server suddenly changed game revision? Seems weird
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 06, 2020, 01:32:12 PM
The server suddenly changed game revision? Seems weird

This was intentional: I am testing a possible fix to the losses of synchronisation. Please download the latest version to join.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 08, 2020, 03:02:43 PM
The server has been down for over 5 hours now.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 08, 2020, 04:11:28 PM
The server appears to have been running Simutrans-Extended since 0604h this morning as normal, but it was running with 100% CPU load and not responding, suggesting that it has become stuck in an infinite loop somewhere. I have now restarted the server.

If anyone can find a reproduction case for this behaviour, please let me know in a separate bug report thread in the Simutrans-Extended development forum. Thank you.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 08, 2020, 04:16:55 PM
The server appears to have been running Simutrans-Extended since 0604h this morning as normal, but it was running with 100% CPU load and not responding, suggesting that it has become stuck in an infinite loop somewhere. I have now restarted the server.

If anyone can find a reproduction case for this behaviour, please let me know in a separate bug report thread in the Simutrans-Extended development forum. Thank you.
Freahk and I were connected to it when it 'froze' (without pausing), and our clients were running at about 400% CPU before we manually closed them.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 08, 2020, 04:22:03 PM
Freahk and I were connected to it when it 'froze' (without pausing), and our clients were running at about 400% CPU before we manually closed them.

Interesting - let us see what happens when the server restarts.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 12, 2020, 11:07:36 AM
The server is now instantly crashing on connection causing the clients to desync.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 12, 2020, 11:11:42 AM
The server is now instantly crashing on connection causing the clients to desync.

I have noticed this. I have been unable to reproduce this offline, however, either loading the game in single player mode or loading it with my local testing client set to act as the server.

However, when I did connect, my client's log file showed the following:

Code: [Select]
ERROR: karte_t::step():   delta_t (10198) out of bounds!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: karte_t::sync_step():   delta_t too large: 32913
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: void convoi_t::laden():   Journey time (2) is zero or less
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: void convoi_t::laden():   Journey time (0) is zero or less
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: void convoi_t::laden():   Journey time (4) is zero or less
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: void convoi_t::laden():   Trying to load at halt Pondton Sainte-Chapelle when not at a halt
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
Message: bool haltestelle_t::fetch_goods():   A convoy's arrival time is not in the database
Message: uint32 haltestelle_t::get_service_frequency(halthandle_t destination, uint8 category) const:   Service frequency not in the database: calculating
ERROR: karte_t::step():   delta_t (10198) out of bounds!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: karte_t::sync_step():   delta_t too large: 33047
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: karte_t::step():   delta_t (10198) out of bounds!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
ERROR: karte_t::sync_step():   delta_t too large: 33186
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com

which looks suspicious. However, I am not familiar with the code relating to delta_t, so I do not know the significance of the error message that it is out of bounds.
Edit: This pattern seems to have been repeated with more delta_t errors in my local log file.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 12, 2020, 11:40:54 AM
Are you able to have the server rename its logs upon closing/crashing so that they are not immediately overwritten upon restarting?
edit: spelling
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on September 12, 2020, 11:45:56 AM
From the code,
Code: [Select]
const sint32 delta_t = (sint32)(ticks-last_step_ticks);delta_t is simply the time difference in ticks (aka milliseconds) in between this (sync_)step and the previous one.
Any value above 10000, aka 10s is considered implausible, will generate the warnings you see and set the number to 10s

It's not neccessarily an actual overflow, but might be caused by one. I'll need to reproduce this offline to see what's going on in detail.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 12, 2020, 12:01:07 PM
Freddy - I cannot think of any way of doing that at present, and, in any event, storing every single log file would soon fill the server's HDD space.

Freahk - I have transferred your post from the pakset forum, as I believe that you replied to the wrong thread. I have not been able to reproduce any crashes offline, and I do not know whether this is related to delta_t; quite why delta_t would be exceeding 10s, I am not sure, but I am also not convinced that the code from Standard for dealing with this is well suited to this situation.

Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on September 12, 2020, 12:03:11 PM
In extended, it seems that the // avoid overflow here ... part of the standard code is commented out. I don't know if there is any special reason for that...
Also, standard uses uint32, but extended uses sint32.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 12, 2020, 12:11:46 PM
Freddy - I cannot think of any way of doing that at present, and, in any event, storing every single log file would soon fill the server's HDD space.
You could run
Code: [Select]
mv simu.log old.log on startup so that it would only store the previous log. This could be inspected whenever a suspected crash occurs.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 12, 2020, 12:44:52 PM
In extended, it seems that the // avoid overflow here ... part of the standard code is commented out. I don't know if there is any special reason for that...
Also, standard uses uint32, but extended uses sint32.

The overflow code is commented out as Extended uses 64-bit values for storing ticks to avoid any overflowing.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 12, 2020, 02:40:14 PM
Can I check whether this problem has recurred this afternoon?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 12, 2020, 02:58:49 PM
Can I check whether this problem has recurred this afternoon?
It occurred several more times after my report, but has since stopped.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 20, 2020, 05:21:53 AM
You could run
Code: [Select]
mv simu.log old.log on startup so that it would only store the previous log. This could be inspected whenever a suspected crash occurs.
Have you considered this, James? I think it would be useful at very little cost.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on September 20, 2020, 10:04:36 AM
A quick note for those not on Discord: today's update has a bug (https://forum.simutrans.com/index.php/topic,20298.msg191216.html#msg191216) in the logging. So I guess it's best to run the client without logging (don't use the - log parameter) and expect frequent server crashes. But if you're reading this you probably know more than me about it.  :D
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on September 20, 2020, 10:06:50 AM
A quick note for those not on Discord: today's update has a bug in the logging. So I guess it's best to run the client without logging (don't use the - log parameter) and expect frequent server crashes. But if you're reading this you probably know more than me about it. 
'fortunately', the server will tend to crash before the client. But again, apologies for causing the issue...
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on September 20, 2020, 11:04:09 AM
I have now restarted the server with Freddy's patch applied.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on October 16, 2020, 11:02:22 AM
Bridgewater-Brunel crashes every time it tries to enter 1916 (crash confirmed by checking the server log). If you join and the date is December 1915, it might be best to wait and observe before changing anything.

Here are things I have noticed about the crash from the client log file (most of which are probably irrelevant):
(1) It was the start of the year.
(2) This new_month() message about industry appears every time:
(https://cdn.discordapp.com/attachments/756877359176613922/766526156450299954/Object_error_messages.png)
(3) The other messages in that particular log do not appear every time. (7325,28,1) is a cattle farm field in Caledonia. According to the Towns chat, the farm was upgraded at that month start, but on other attempts at starting the new month, other industries are closed/upgraded/connected.
(4) That industry message always seems to be followed by many
Code: [Select]
uint32 haltestelle_t::get_service_frequency(halthandle_t destination, uint8 category) const:    Unknown frequency messages. For example, the first time there were 142,496(!) lines of such messages.
(5) Then there were a mere 377 lines of Unknown arrival time messages.
(6) One time when I unpaused the client, I got a crash in private_car_t::~private_car_t.
(7) The total size of the Simutrans-Extended process now exceeds 10GiB.

All these logs were gathered using the Windows 10 64-bit executable from Bridgewater-Brunel.
I observed this on two different VMs (one with 10GiB and one with 16GiB of RAM).
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on October 16, 2020, 02:50:56 PM
I believe I have fixed the issue here: https://github.com/jamespetts/simutrans-extended/pull/293
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on October 16, 2020, 04:33:55 PM
I believe I have fixed the issue here: https://github.com/jamespetts/simutrans-extended/pull/293

Thank you, Freddy!

I tested Freddy's branch on Windows. In single-player mode, a Bridgewater-Brunel savegame passed into 1916 without difficulty and continued running smoothly for 1 hour 45 mins of in-game time.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on October 16, 2020, 05:01:40 PM
Thank you very much for the fix - now incorporated.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on November 19, 2020, 02:32:27 PM
Just now the game reached the beginning of October or November 1942. As usual, the game became unresponsive as it processed the new month. After 9 minutes, it was still unchanged. I believe this was a server problem as there was nothing untoward in the client logs and the client was not using CPU or memory.

The last entries in the server log were these:

Code: [Select]
Warning: karte_t::interactive: server lagging by 140304
Message: network_command_t::rdwr: write packet_id=9, client_id=0
Message: packet_t::send: sent 201 bytes to socket[6]; id=9, size=201
Warning: karte_t::interactive: server lagging by 140260
Message: network_command_t::rdwr: write packet_id=9, client_id=0
Message: packet_t::send: sent 201 bytes to socket[6]; id=9, size=201
Warning: karte_t::interactive: server lagging by 140218
Message: network_command_t::rdwr: write packet_id=9, client_id=0
Message: packet_t::send: sent 201 bytes to socket[6]; id=9, size=201
Warning: obj_t::~obj_t(): couldn't remove 0x15a492870 from 6130,1982,6
Warning: obj_t::~obj_t(): removed 0x15a492870 from 6130,1982,5, but it should have been on 6130,1982,6
Warning: obj_t::~obj_t(): couldn't remove 0x15a492840 from 6130,1980,6
Warning: obj_t::~obj_t(): removed 0x15a492840 from 6130,1980,5, but it should have been on 6130,1980,6
Warning: obj_t::~obj_t(): couldn't remove 0x15a4927b0 from 6130,1981,6
Warning: obj_t::~obj_t(): removed 0x15a4927b0 from 6130,1981,5, but it should have been on 6130,1981,6
Warning: obj_t::~obj_t(): couldn't remove 0x15a4d51c0 from 6668,588,4
Warning: obj_t::~obj_t(): removed 0x15a4d51c0 from 6668,588,3, but it should have been on 6668,588,4
Warning: obj_t::~obj_t(): couldn't remove 0x120198e00 from 6158,2100,4
Warning: obj_t::~obj_t(): removed 0x120198e00 from 6158,2100,3, but it should have been on 6158,2100,4
Warning: obj_t::~obj_t(): couldn't remove 0x120198920 from 6159,2100,4
Warning: obj_t::~obj_t(): removed 0x120198920 from 6159,2100,3, but it should have been on 6159,2100,4
Warning: obj_t::~obj_t(): couldn't remove 0x120197b40 from 6161,2099,5
Warning: obj_t::~obj_t(): removed 0x120197b40 from 6161,2099,3, but it should have been on 6161,2099,5
Warning: obj_t::~obj_t(): couldn't remove 0x1201d8570 from 617,990,5
Warning: obj_t::~obj_t(): removed 0x1201d8570 from 617,990,4, but it should have been on 617,990,5
Warning: obj_t::~obj_t(): couldn't remove 0x1201d8210 from 617,991,5
Warning: obj_t::~obj_t(): removed 0x1201d8210 from 617,991,4, but it should have been on 617,991,5
Warning: obj_t::~obj_t(): couldn't remove 0x1201dae40 from 493,1059,7
Warning: obj_t::~obj_t(): removed 0x1201dae40 from 493,1059,6, but it should have been on 493,1059,7
Warning: obj_t::~obj_t(): couldn't remove 0x1201f7130 from 433,740,6
Warning: obj_t::~obj_t(): removed 0x1201f7130 from 433,740,5, but it should have been on 433,740,6
Warning: obj_t::~obj_t(): couldn't remove 0x1571b3d60 from 2047,2511,7
Warning: obj_t::~obj_t(): removed 0x1571b3d60 from 2047,2511,6, but it should have been on 2047,2511,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571b3d00 from 2047,2512,7
Warning: obj_t::~obj_t(): removed 0x1571b3d00 from 2047,2512,6, but it should have been on 2047,2512,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571b3cd0 from 2048,2511,7
Warning: obj_t::~obj_t(): removed 0x1571b3cd0 from 2048,2511,6, but it should have been on 2048,2511,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571b6eb0 from 1910,2473,7
Warning: obj_t::~obj_t(): removed 0x1571b6eb0 from 1910,2473,6, but it should have been on 1910,2473,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571b6e50 from 1911,2472,7
Warning: obj_t::~obj_t(): removed 0x1571b6e50 from 1911,2472,6, but it should have been on 1911,2472,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571b6e20 from 1910,2472,7
Warning: obj_t::~obj_t(): removed 0x1571b6e20 from 1910,2472,6, but it should have been on 1910,2472,7
Warning: obj_t::~obj_t(): couldn't remove 0x1571f01a0 from 813,2231,4
Warning: obj_t::~obj_t(): removed 0x1571f01a0 from 813,2231,3, but it should have been on 813,2231,4
Warning: obj_t::~obj_t(): couldn't remove 0x1571f0140 from 813,2232,4
Warning: obj_t::~obj_t(): removed 0x1571f0140 from 813,2232,3, but it should have been on 813,2232,4
Warning: obj_t::~obj_t(): couldn't remove 0x3bcbe5e0 from 7321,1687,2
Warning: obj_t::~obj_t(): removed 0x3bcbe5e0 from 7321,1687,1, but it should have been on 7321,1687,2
Warning: obj_t::~obj_t(): couldn't remove 0x3bcdb8d0 from 205,2483,3
Warning: obj_t::~obj_t(): removed 0x3bcdb8d0 from 205,2483,2, but it should have been on 205,2483,3
Warning: obj_t::~obj_t(): couldn't remove 0x3bcdb480 from 203,2468,3
Warning: obj_t::~obj_t(): removed 0x3bcdb480 from 203,2468,2, but it should have been on 203,2468,3
Warning: obj_t::~obj_t(): couldn't remove 0x3bcdb180 from 200,2492,3
Warning: obj_t::~obj_t(): removed 0x3bcdb180 from 200,2492,2, but it should have been on 200,2492,3
Warning: obj_t::~obj_t(): couldn't remove 0x3bcdadf0 from 199,2492,3
Warning: obj_t::~obj_t(): removed 0x3bcdadf0 from 199,2492,2, but it should have been on 199,2492,3
Warning: obj_t::~obj_t(): couldn't remove 0x3bcda760 from 199,2471,2
Warning: obj_t::~obj_t(): removed 0x3bcda760 from 199,2471,0, but it should have been on 199,2471,2
Warning: obj_t::~obj_t(): couldn't remove 0x3bcda6d0 from 199,2474,2
Warning: obj_t::~obj_t(): removed 0x3bcda6d0 from 199,2474,1, but it should have been on 199,2474,2
Warning: obj_t::~obj_t(): couldn't remove 0x3bcda640 from 199,2473,2
Warning: obj_t::~obj_t(): removed 0x3bcda640 from 199,2473,1, but it should have been on 199,2473,2
Warning: obj_t::~obj_t(): couldn't remove 0x3bcda490 from 199,2476,2
Warning: obj_t::~obj_t(): removed 0x3bcda490 from 199,2476,1, but it should have been on 199,2476,2
Warning: obj_t::~obj_t(): couldn't remove 0x3bcda460 from 199,2475,2
Warning: obj_t::~obj_t(): removed 0x3bcda460 from 199,2475,1, but it should have been on 199,2475,2
Warning: obj_t::~obj_t(): couldn't remove 0x15ccce830 from 6562,2436,8
Warning: obj_t::~obj_t(): removed 0x15ccce830 from 6562,2436,7, but it should have been on 6562,2436,8
Warning: obj_t::~obj_t(): couldn't remove 0xe4428170 from 1655,2144,4
Warning: obj_t::~obj_t(): removed 0xe4428170 from 1655,2144,3, but it should have been on 1655,2144,4
Warning: obj_t::~obj_t(): couldn't remove 0xe4428110 from 1643,2150,5
Warning: obj_t::~obj_t(): removed 0xe4428110 from 1643,2150,4, but it should have been on 1643,2150,5
Warning: obj_t::~obj_t(): couldn't remove 0xe44280b0 from 1644,2150,5
Warning: obj_t::~obj_t(): removed 0xe44280b0 from 1644,2150,4, but it should have been on 1644,2150,5
Warning: obj_t::~obj_t(): couldn't remove 0xe4428080 from 1645,2150,5
Warning: obj_t::~obj_t(): removed 0xe4428080 from 1645,2150,4, but it should have been on 1645,2150,5
Warning: obj_t::~obj_t(): couldn't remove 0xe4428050 from 1646,2150,5
Warning: obj_t::~obj_t(): removed 0xe4428050 from 1646,2150,4, but it should have been on 1646,2150,5
Warning: obj_t::~obj_t(): couldn't remove 0x14cc1f400 from 6209,42,6
Warning: obj_t::~obj_t(): removed 0x14cc1f400 from 6209,42,5, but it should have been on 6209,42,6
Warning: obj_t::~obj_t(): couldn't remove 0x14cc1f1f0 from 6207,42,6
Warning: obj_t::~obj_t(): removed 0x14cc1f1f0 from 6207,42,5, but it should have been on 6207,42,6
Warning: obj_t::~obj_t(): couldn't remove 0x14cc1f160 from 6205,42,6
Warning: obj_t::~obj_t(): removed 0x14cc1f160 from 6205,42,5, but it should have been on 6205,42,6
Warning: obj_t::~obj_t(): couldn't remove 0x14cc1f130 from 6204,42,6
Warning: obj_t::~obj_t(): removed 0x14cc1f130 from 6204,42,5, but it should have been on 6204,42,6
Warning: obj_t::~obj_t(): couldn't remove 0x14cc1f100 from 6206,42,6
Warning: obj_t::~obj_t(): removed 0x14cc1f100 from 6206,42,5, but it should have been on 6206,42,6
Warning: obj_t::~obj_t(): couldn't remove 0x14cc23650 from 6297,86,5
Warning: obj_t::~obj_t(): removed 0x14cc23650 from 6297,86,4, but it should have been on 6297,86,5
Warning: obj_t::~obj_t(): couldn't remove 0x14cc37510 from 6021,2061,3
Warning: obj_t::~obj_t(): removed 0x14cc37510 from 6021,2061,2, but it should have been on 6021,2061,3
Warning: obj_t::~obj_t(): couldn't remove 0x14cc69490 from 6875,1942,3
Warning: obj_t::~obj_t(): removed 0x14cc69490 from 6875,1942,2, but it should have been on 6875,1942,3
Warning: obj_t::~obj_t(): couldn't remove 0x14cc69280 from 6878,1977,5
Warning: obj_t::~obj_t(): removed 0x14cc69280 from 6878,1977,4, but it should have been on 6878,1977,5
Warning: obj_t::~obj_t(): couldn't remove 0x14cc691f0 from 6878,1967,5
Warning: obj_t::~obj_t(): removed 0x14cc691f0 from 6878,1967,4, but it should have been on 6878,1967,5
Warning: obj_t::~obj_t(): couldn't remove 0x14cc69100 from 6878,1962,4
Warning: obj_t::~obj_t(): removed 0x14cc69100 from 6878,1962,3, but it should have been on 6878,1962,4
Warning: obj_t::~obj_t(): couldn't remove 0x14cc690a0 from 6878,1972,5
Warning: obj_t::~obj_t(): removed 0x14cc690a0 from 6878,1972,4, but it should have been on 6878,1972,5
Warning: obj_t::~obj_t(): couldn't remove 0x14cc684d0 from 6871,1972,4
Warning: obj_t::~obj_t(): removed 0x14cc684d0 from 6871,1972,3, but it should have been on 6871,1972,4
Warning: obj_t::~obj_t(): couldn't remove 0x14cc67810 from 6853,1981,4
Warning: obj_t::~obj_t(): removed 0x14cc67810 from 6853,1981,3, but it should have been on 6853,1981,4
Warning: obj_t::~obj_t(): couldn't remove 0x15a8a1dd0 from 7059,1402,4
Warning: obj_t::~obj_t(): removed 0x15a8a1dd0 from 7059,1402,3, but it should have been on 7059,1402,4
Warning: obj_t::~obj_t(): couldn't remove 0x15a8a1da0 from 7058,1403,4
Warning: obj_t::~obj_t(): removed 0x15a8a1da0 from 7058,1403,3, but it should have been on 7058,1403,4
Warning: obj_t::~obj_t(): couldn't remove 0x15a8a1d70 from 7058,1402,4
Warning: obj_t::~obj_t(): removed 0x15a8a1d70 from 7058,1402,3, but it should have been on 7058,1402,4
Warning: obj_t::~obj_t(): couldn't remove 0x15a9064c0 from 7119,1293,5
Warning: obj_t::~obj_t(): removed 0x15a9064c0 from 7119,1293,4, but it should have been on 7119,1293,5
Warning: obj_t::~obj_t(): couldn't remove 0x15a906490 from 7119,1294,5
Warning: obj_t::~obj_t(): removed 0x15a906490 from 7119,1294,4, but it should have been on 7119,1294,5
Warning: obj_t::~obj_t(): couldn't remove 0x15a9103b0 from 7330,1288,2
Warning: obj_t::~obj_t(): removed 0x15a9103b0 from 7330,1288,1, but it should have been on 7330,1288,2
Warning: obj_t::~obj_t(): couldn't remove 0x119c2d7d0 from 6894,1797,6
Warning: obj_t::~obj_t(): removed 0x119c2d7d0 from 6894,1797,5, but it should have been on 6894,1797,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c2cc60 from 6894,1798,6
Warning: obj_t::~obj_t(): removed 0x119c2cc60 from 6894,1798,5, but it should have been on 6894,1798,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c2beb0 from 6894,1799,6
Warning: obj_t::~obj_t(): removed 0x119c2beb0 from 6894,1799,5, but it should have been on 6894,1799,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c2b790 from 6894,1800,6
Warning: obj_t::~obj_t(): removed 0x119c2b790 from 6894,1800,5, but it should have been on 6894,1800,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c2aef0 from 6894,1801,6
Warning: obj_t::~obj_t(): removed 0x119c2aef0 from 6894,1801,5, but it should have been on 6894,1801,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c2ac20 from 6894,1802,6
Warning: obj_t::~obj_t(): removed 0x119c2ac20 from 6894,1802,5, but it should have been on 6894,1802,6
Warning: obj_t::~obj_t(): couldn't remove 0x119c3eef0 from 6812,1984,5
Warning: obj_t::~obj_t(): removed 0x119c3eef0 from 6812,1984,4, but it should have been on 6812,1984,5
Warning: obj_t::~obj_t(): couldn't remove 0x119c4a1d0 from 1058,1021,4
Warning: obj_t::~obj_t(): removed 0x119c4a1d0 from 1058,1021,3, but it should have been on 1058,1021,4
Warning: obj_t::~obj_t(): couldn't remove 0x119c4a170 from 1058,1020,4
Warning: obj_t::~obj_t(): removed 0x119c4a170 from 1058,1020,3, but it should have been on 1058,1020,4
Warning: obj_t::~obj_t(): couldn't remove 0x119c4a110 from 1059,1020,4
Warning: obj_t::~obj_t(): removed 0x119c4a110 from 1059,1020,3, but it should have been on 1059,1020,4
Warning: obj_t::~obj_t(): couldn't remove 0x119c9f750 from 6988,2193,5
Warning: obj_t::~obj_t(): removed 0x119c9f750 from 6988,2193,4, but it should have been on 6988,2193,5
Warning: obj_t::~obj_t(): couldn't remove 0x119753890 from 7340,2534,2
Warning: obj_t::~obj_t(): removed 0x119753890 from 7340,2534,1, but it should have been on 7340,2534,2
Warning: obj_t::~obj_t(): couldn't remove 0x119753860 from 7341,2532,2
Warning: obj_t::~obj_t(): removed 0x119753860 from 7341,2532,1, but it should have been on 7341,2532,2
Warning: obj_t::~obj_t(): couldn't remove 0x119753830 from 7340,2532,2
Warning: obj_t::~obj_t(): removed 0x119753830 from 7340,2532,1, but it should have been on 7340,2532,2
Warning: obj_t::~obj_t(): couldn't remove 0x119753800 from 7340,2533,2
Warning: obj_t::~obj_t(): removed 0x119753800 from 7340,2533,1, but it should have been on 7340,2533,2
Warning: obj_t::~obj_t(): couldn't remove 0x1197582f0 from 7292,2372,4
Warning: obj_t::~obj_t(): removed 0x1197582f0 from 7292,2372,3, but it should have been on 7292,2372,4
Warning: obj_t::~obj_t(): couldn't remove 0x119778d90 from 6416,594,4
Warning: obj_t::~obj_t(): removed 0x119778d90 from 6416,594,3, but it should have been on 6416,594,4
Warning: obj_t::~obj_t(): couldn't remove 0x119777500 from 6430,588,4
Warning: obj_t::~obj_t(): removed 0x119777500 from 6430,588,3, but it should have been on 6430,588,4
Warning: obj_t::~obj_t(): couldn't remove 0x119777410 from 6427,588,3
Warning: obj_t::~obj_t(): removed 0x119777410 from 6427,588,2, but it should have been on 6427,588,3
Warning: obj_t::~obj_t(): couldn't remove 0x119789300 from 6338,553,3
Warning: obj_t::~obj_t(): removed 0x119789300 from 6338,553,2, but it should have been on 6338,553,3
Warning: obj_t::~obj_t(): couldn't remove 0xe7fe5e90 from 7867,1920,5
Warning: obj_t::~obj_t(): removed 0xe7fe5e90 from 7867,1920,4, but it should have been on 7867,1920,5
Warning: obj_t::~obj_t(): couldn't remove 0xe7fe5e60 from 7867,1921,5
Warning: obj_t::~obj_t(): removed 0xe7fe5e60 from 7867,1921,4, but it should have been on 7867,1921,5
Warning: obj_t::~obj_t(): couldn't remove 0xe803a7a0 from 5584,1538,2
Warning: obj_t::~obj_t(): removed 0xe803a7a0 from 5584,1538,1, but it should have been on 5584,1538,2
Warning: obj_t::~obj_t(): couldn't remove 0xe80415b0 from 5878,1663,2
Warning: obj_t::~obj_t(): removed 0xe80415b0 from 5878,1663,1, but it should have been on 5878,1663,2
Warning: obj_t::~obj_t(): couldn't remove 0xe8041490 from 5805,1763,2
Warning: obj_t::~obj_t(): removed 0xe8041490 from 5805,1763,1, but it should have been on 5805,1763,2
Warning: obj_t::~obj_t(): couldn't remove 0xe80411c0 from 5805,1762,2
Warning: obj_t::~obj_t(): removed 0xe80411c0 from 5805,1762,1, but it should have been on 5805,1762,2
Warning: obj_t::~obj_t(): couldn't remove 0xe8041040 from 5805,1761,2
Warning: obj_t::~obj_t(): removed 0xe8041040 from 5805,1761,1, but it should have been on 5805,1761,2
Warning: obj_t::~obj_t(): couldn't remove 0xe8040fb0 from 5806,1761,2
Warning: obj_t::~obj_t(): removed 0xe8040fb0 from 5806,1761,1, but it should have been on 5806,1761,2
Warning: obj_t::~obj_t(): couldn't remove 0xe803f960 from 5770,1654,2
Warning: obj_t::~obj_t(): removed 0xe803f960 from 5770,1654,1, but it should have been on 5770,1654,2
Warning: obj_t::~obj_t(): couldn't remove 0xe803f000 from 5780,1656,2
Warning: obj_t::~obj_t(): removed 0xe803f000 from 5780,1656,1, but it should have been on 5780,1656,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f6c5220 from 5661,1602,2
Warning: obj_t::~obj_t(): removed 0x9f6c5220 from 5661,1602,1, but it should have been on 5661,1602,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f6c5160 from 5660,1603,2
Warning: obj_t::~obj_t(): removed 0x9f6c5160 from 5660,1603,1, but it should have been on 5660,1603,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f6c0f60 from 5646,1623,2
Warning: obj_t::~obj_t(): removed 0x9f6c0f60 from 5646,1623,1, but it should have been on 5646,1623,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f6f51b0 from 7026,2101,4
Warning: obj_t::~obj_t(): removed 0x9f6f51b0 from 7026,2101,3, but it should have been on 7026,2101,4
Warning: obj_t::~obj_t(): couldn't remove 0x9f6f5180 from 7026,2100,4
Warning: obj_t::~obj_t(): removed 0x9f6f5180 from 7026,2100,3, but it should have been on 7026,2100,4
Warning: obj_t::~obj_t(): couldn't remove 0x9f710b90 from 7073,1513,2
Warning: obj_t::~obj_t(): removed 0x9f710b90 from 7073,1513,1, but it should have been on 7073,1513,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f7108f0 from 7073,1514,2
Warning: obj_t::~obj_t(): removed 0x9f7108f0 from 7073,1514,1, but it should have been on 7073,1514,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f70f0f0 from 7068,1533,2
Warning: obj_t::~obj_t(): removed 0x9f70f0f0 from 7068,1533,1, but it should have been on 7068,1533,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f70f0c0 from 7068,1532,2
Warning: obj_t::~obj_t(): removed 0x9f70f0c0 from 7068,1532,1, but it should have been on 7068,1532,2
Warning: obj_t::~obj_t(): couldn't remove 0x9f732900 from 282,2069,6
Warning: obj_t::~obj_t(): removed 0x9f732900 from 282,2069,5, but it should have been on 282,2069,6
Warning: obj_t::~obj_t(): couldn't remove 0x9f7328d0 from 283,2069,6
Warning: obj_t::~obj_t(): removed 0x9f7328d0 from 283,2069,5, but it should have been on 283,2069,6
Warning: obj_t::~obj_t(): couldn't remove 0x9f732870 from 282,2070,6
Warning: obj_t::~obj_t(): removed 0x9f732870 from 282,2070,5, but it should have been on 282,2070,6
Warning: obj_t::~obj_t(): couldn't remove 0x9f732840 from 284,2069,6
Warning: obj_t::~obj_t(): removed 0x9f732840 from 284,2069,5, but it should have been on 284,2069,6
Warning: obj_t::~obj_t(): couldn't remove 0x14b147f90 from 2544,1910,2
Warning: obj_t::~obj_t(): removed 0x14b147f90 from 2544,1910,1, but it should have been on 2544,1910,2
Warning: obj_t::~obj_t(): couldn't remove 0x14b165dd0 from 8026,2376,3
Warning: obj_t::~obj_t(): removed 0x14b165dd0 from 8026,2376,2, but it should have been on 8026,2376,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b165d70 from 8026,2383,3
Warning: obj_t::~obj_t(): removed 0x14b165d70 from 8026,2383,2, but it should have been on 8026,2383,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b165ce0 from 8026,2373,3
Warning: obj_t::~obj_t(): removed 0x14b165ce0 from 8026,2373,2, but it should have been on 8026,2373,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b165c50 from 8026,2375,3
Warning: obj_t::~obj_t(): removed 0x14b165c50 from 8026,2375,2, but it should have been on 8026,2375,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b165980 from 8026,2374,3
Warning: obj_t::~obj_t(): removed 0x14b165980 from 8026,2374,2, but it should have been on 8026,2374,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b16f890 from 8022,2357,2
Warning: obj_t::~obj_t(): removed 0x14b16f890 from 8022,2357,1, but it should have been on 8022,2357,2
Warning: obj_t::~obj_t(): couldn't remove 0x14b16f740 from 8023,2356,2
Warning: obj_t::~obj_t(): removed 0x14b16f740 from 8023,2356,1, but it should have been on 8023,2356,2
Warning: obj_t::~obj_t(): couldn't remove 0x14b16f6b0 from 8023,2355,2
Warning: obj_t::~obj_t(): removed 0x14b16f6b0 from 8023,2355,1, but it should have been on 8023,2355,2
Warning: obj_t::~obj_t(): couldn't remove 0x14b16f080 from 8027,2348,4
Warning: obj_t::~obj_t(): removed 0x14b16f080 from 8027,2348,3, but it should have been on 8027,2348,4
Warning: obj_t::~obj_t(): couldn't remove 0x14b16a7c0 from 8050,2375,3
Warning: obj_t::~obj_t(): removed 0x14b16a7c0 from 8050,2375,2, but it should have been on 8050,2375,3
Warning: obj_t::~obj_t(): couldn't remove 0x14b16a730 from 8051,2375,3
Warning: obj_t::~obj_t(): removed 0x14b16a730 from 8051,2375,2, but it should have been on 8051,2375,3
Warning: obj_t::~obj_t(): couldn't remove 0x1425a7ca0 from 7378,2187,4
Warning: obj_t::~obj_t(): removed 0x1425a7ca0 from 7378,2187,2, but it should have been on 7378,2187,4
Warning: obj_t::~obj_t(): couldn't remove 0x1425a7ac0 from 7378,2188,4
Warning: obj_t::~obj_t(): removed 0x1425a7ac0 from 7378,2188,2, but it should have been on 7378,2188,4
Warning: obj_t::~obj_t(): couldn't remove 0x1425a7820 from 7378,2189,4
Warning: obj_t::~obj_t(): removed 0x1425a7820 from 7378,2189,2, but it should have been on 7378,2189,4
Warning: obj_t::~obj_t(): couldn't remove 0x14cf58e90 from 7373,2193,3
Warning: obj_t::~obj_t(): removed 0x14cf58e90 from 7373,2193,2, but it should have been on 7373,2193,3
Warning: obj_t::~obj_t(): couldn't remove 0x1425b3d40 from 7327,2250,2
Warning: obj_t::~obj_t(): removed 0x1425b3d40 from 7327,2250,1, but it should have been on 7327,2250,2
Warning: obj_t::~obj_t(): couldn't remove 0x1425ae9d0 from 7328,2254,3
Warning: obj_t::~obj_t(): removed 0x1425ae9d0 from 7328,2254,2, but it should have been on 7328,2254,3
Warning: obj_t::~obj_t(): couldn't remove 0x1425ae760 from 7329,2254,3
Warning: obj_t::~obj_t(): removed 0x1425ae760 from 7329,2254,2, but it should have been on 7329,2254,3
Warning: obj_t::~obj_t(): couldn't remove 0x1a41c410 from 7365,1667,2
Warning: obj_t::~obj_t(): removed 0x1a41c410 from 7365,1667,1, but it should have been on 7365,1667,2
Warning: obj_t::~obj_t(): couldn't remove 0x1a41bb40 from 7340,1701,2
Warning: obj_t::~obj_t(): removed 0x1a41bb40 from 7340,1701,1, but it should have been on 7340,1701,2
Warning: obj_t::~obj_t(): couldn't remove 0x1a41b9f0 from 7340,1700,2
Warning: obj_t::~obj_t(): removed 0x1a41b9f0 from 7340,1700,1, but it should have been on 7340,1700,2
Warning: obj_t::~obj_t(): couldn't remove 0x1a41ac70 from 7374,1670,2
Warning: obj_t::~obj_t(): removed 0x1a41ac70 from 7374,1670,1, but it should have been on 7374,1670,2
Warning: obj_t::~obj_t(): couldn't remove 0x1a41ac40 from 7370,1671,1
Warning: obj_t::~obj_t(): removed 0x1a41ac40 from 7370,1671,0, but it should have been on 7370,1671,1
Warning: obj_t::~obj_t(): couldn't remove 0x1a41aa90 from 7380,1674,2
Warning: obj_t::~obj_t(): removed 0x1a41aa90 from 7380,1674,1, but it should have been on 7380,1674,2
Warning: obj_t::~obj_t(): couldn't remove 0x142644920 from 7390,1698,3
Warning: obj_t::~obj_t(): removed 0x142644920 from 7390,1698,2, but it should have been on 7390,1698,3
Warning: obj_t::~obj_t(): couldn't remove 0x1a466ba0 from 2368,2535,5
Warning: obj_t::~obj_t(): removed 0x1a466ba0 from 2368,2535,4, but it should have been on 2368,2535,5
Warning: obj_t::~obj_t(): couldn't remove 0x1a466b40 from 2369,2535,5
Warning: obj_t::~obj_t(): removed 0x1a466b40 from 2369,2535,4, but it should have been on 2369,2535,5
Warning: obj_t::~obj_t(): couldn't remove 0x1a466b10 from 2367,2534,5
Warning: obj_t::~obj_t(): removed 0x1a466b10 from 2367,2534,4, but it should have been on 2367,2534,5
Warning: obj_t::~obj_t(): couldn't remove 0x1a466a20 from 2366,2533,5
Warning: obj_t::~obj_t(): removed 0x1a466a20 from 2366,2533,4, but it should have been on 2366,2533,5
Warning: obj_t::~obj_t(): couldn't remove 0x1a488bf0 from 6056,1336,6
Warning: obj_t::~obj_t(): removed 0x1a488bf0 from 6056,1336,5, but it should have been on 6056,1336,6
Warning: obj_t::~obj_t(): couldn't remove 0x1a4b3c50 from 7173,1853,7
Warning: obj_t::~obj_t(): removed 0x1a4b3c50 from 7173,1853,6, but it should have been on 7173,1853,7
Warning: obj_t::~obj_t(): couldn't remove 0x10eeef230 from 7482,2408,8
Warning: obj_t::~obj_t(): removed 0x10eeef230 from 7482,2408,7, but it should have been on 7482,2408,8
Warning: obj_t::~obj_t(): couldn't remove 0x10eefda90 from 6378,295,5
Warning: obj_t::~obj_t(): removed 0x10eefda90 from 6378,295,4, but it should have been on 6378,295,5
Warning: obj_t::~obj_t(): couldn't remove 0x10eefbed0 from 6377,291,4
Warning: obj_t::~obj_t(): removed 0x10eefbed0 from 6377,291,3, but it should have been on 6377,291,4
Warning: obj_t::~obj_t(): couldn't remove 0x10eefbdb0 from 6379,291,4
Warning: obj_t::~obj_t(): removed 0x10eefbdb0 from 6379,291,3, but it should have been on 6379,291,4
Warning: obj_t::~obj_t(): couldn't remove 0x10eefbb70 from 6378,291,4
Warning: obj_t::~obj_t(): removed 0x10eefbb70 from 6378,291,3, but it should have been on 6378,291,4
Warning: obj_t::~obj_t(): couldn't remove 0x10eef8180 from 6368,272,3
Warning: obj_t::~obj_t(): removed 0x10eef8180 from 6368,272,2, but it should have been on 6368,272,3
Warning: obj_t::~obj_t(): couldn't remove 0x10eef8150 from 6368,271,3
Warning: obj_t::~obj_t(): removed 0x10eef8150 from 6368,271,2, but it should have been on 6368,271,3
Warning: obj_t::~obj_t(): couldn't remove 0x10ef1a6a0 from 587,759,3
Warning: obj_t::~obj_t(): removed 0x10ef1a6a0 from 587,759,2, but it should have been on 587,759,3
Warning: obj_t::~obj_t(): couldn't remove 0x10ef1a1c0 from 587,758,3
Warning: obj_t::~obj_t(): removed 0x10ef1a1c0 from 587,758,2, but it should have been on 587,758,3
Warning: obj_t::~obj_t(): couldn't remove 0x10ef18e40 from 585,699,1
Warning: obj_t::~obj_t(): removed 0x10ef18e40 from 585,699,0, but it should have been on 585,699,1
Warning: obj_t::~obj_t(): couldn't remove 0x10ef17c70 from 607,706,1
Warning: obj_t::~obj_t(): removed 0x10ef17c70 from 607,706,0, but it should have been on 607,706,1
Warning: obj_t::~obj_t(): couldn't remove 0x10ef177c0 from 601,718,2
Warning: obj_t::~obj_t(): removed 0x10ef177c0 from 601,718,1, but it should have been on 601,718,2
Warning: obj_t::~obj_t(): couldn't remove 0x10ef16dd0 from 597,724,3
Warning: obj_t::~obj_t(): removed 0x10ef16dd0 from 597,724,2, but it should have been on 597,724,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c030a0 from 7170,1957,7
Warning: obj_t::~obj_t(): removed 0x159c030a0 from 7170,1957,6, but it should have been on 7170,1957,7
Warning: obj_t::~obj_t(): couldn't remove 0x159c1ded0 from 5613,1761,4
Warning: obj_t::~obj_t(): removed 0x159c1ded0 from 5613,1761,3, but it should have been on 5613,1761,4
Warning: obj_t::~obj_t(): couldn't remove 0x159c27fd0 from 5621,1607,2
Warning: obj_t::~obj_t(): removed 0x159c27fd0 from 5621,1607,1, but it should have been on 5621,1607,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c27e20 from 5620,1607,2
Warning: obj_t::~obj_t(): removed 0x159c27e20 from 5620,1607,1, but it should have been on 5620,1607,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c27dc0 from 5617,1608,2
Warning: obj_t::~obj_t(): removed 0x159c27dc0 from 5617,1608,1, but it should have been on 5617,1608,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c3a570 from 5639,1602,2
Warning: obj_t::~obj_t(): removed 0x159c3a570 from 5639,1602,1, but it should have been on 5639,1602,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c3a480 from 5638,1602,2
Warning: obj_t::~obj_t(): removed 0x159c3a480 from 5638,1602,1, but it should have been on 5638,1602,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c3a210 from 5637,1603,2
Warning: obj_t::~obj_t(): removed 0x159c3a210 from 5637,1603,1, but it should have been on 5637,1603,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c3a150 from 5637,1602,2
Warning: obj_t::~obj_t(): removed 0x159c3a150 from 5637,1602,1, but it should have been on 5637,1602,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c7d600 from 7163,2341,3
Warning: obj_t::~obj_t(): removed 0x159c7d600 from 7163,2341,1, but it should have been on 7163,2341,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c7d5d0 from 7175,2349,3
Warning: obj_t::~obj_t(): removed 0x159c7d5d0 from 7175,2349,2, but it should have been on 7175,2349,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c7d5a0 from 7174,2349,3
Warning: obj_t::~obj_t(): removed 0x159c7d5a0 from 7174,2349,2, but it should have been on 7174,2349,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c7d1e0 from 7270,2313,3
Warning: obj_t::~obj_t(): removed 0x159c7d1e0 from 7270,2313,2, but it should have been on 7270,2313,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c7c580 from 7268,2321,3
Warning: obj_t::~obj_t(): removed 0x159c7c580 from 7268,2321,2, but it should have been on 7268,2321,3
Warning: obj_t::~obj_t(): couldn't remove 0x159c7b6e0 from 7264,2319,2
Warning: obj_t::~obj_t(): removed 0x159c7b6e0 from 7264,2319,1, but it should have been on 7264,2319,2
Warning: obj_t::~obj_t(): couldn't remove 0x159c7a810 from 7251,2335,1
Warning: obj_t::~obj_t(): removed 0x159c7a810 from 7251,2335,0, but it should have been on 7251,2335,1
Warning: obj_t::~obj_t(): couldn't remove 0xdefad480 from 7628,2541,7
Warning: obj_t::~obj_t(): removed 0xdefad480 from 7628,2541,6, but it should have been on 7628,2541,7
Warning: obj_t::~obj_t(): couldn't remove 0xdefad390 from 7628,2542,7
Warning: obj_t::~obj_t(): removed 0xdefad390 from 7628,2542,6, but it should have been on 7628,2542,7
Warning: obj_t::~obj_t(): couldn't remove 0xdefad2a0 from 7628,2540,7
Warning: obj_t::~obj_t(): removed 0xdefad2a0 from 7628,2540,6, but it should have been on 7628,2540,7
Warning: obj_t::~obj_t(): couldn't remove 0x156ae71b0 from 7574,2494,8
Warning: obj_t::~obj_t(): removed 0x156ae71b0 from 7574,2494,7, but it should have been on 7574,2494,8
Warning: obj_t::~obj_t(): couldn't remove 0x156ae70c0 from 7575,2494,8
Warning: obj_t::~obj_t(): removed 0x156ae70c0 from 7575,2494,7, but it should have been on 7575,2494,8
Warning: obj_t::~obj_t(): couldn't remove 0x156b11720 from 5950,2197,4
Warning: obj_t::~obj_t(): removed 0x156b11720 from 5950,2197,3, but it should have been on 5950,2197,4
Warning: obj_t::~obj_t(): couldn't remove 0x156b11120 from 5951,2200,5
Warning: obj_t::~obj_t(): removed 0x156b11120 from 5951,2200,4, but it should have been on 5951,2200,5
Warning: obj_t::~obj_t(): couldn't remove 0x156b10e20 from 5951,2197,4
Warning: obj_t::~obj_t(): removed 0x156b10e20 from 5951,2197,3, but it should have been on 5951,2197,4
Warning: obj_t::~obj_t(): couldn't remove 0x156b10bb0 from 5952,2200,5
Warning: obj_t::~obj_t(): removed 0x156b10bb0 from 5952,2200,4, but it should have been on 5952,2200,5
Warning: obj_t::~obj_t(): couldn't remove 0x156b10af0 from 5952,2197,4
Warning: obj_t::~obj_t(): removed 0x156b10af0 from 5952,2197,3, but it should have been on 5952,2197,4
Warning: obj_t::~obj_t(): couldn't remove 0x156b10820 from 5953,2213,4
Warning: obj_t::~obj_t(): removed 0x156b10820 from 5953,2213,3, but it should have been on 5953,2213,4
Warning: obj_t::~obj_t(): couldn't remove 0x156b106d0 from 5953,2200,5
Warning: obj_t::~obj_t(): removed 0x156b106d0 from 5953,2200,4, but it should have been on 5953,2200,5
Warning: obj_t::~obj_t(): couldn't remove 0x14a4e4410 from 5616,1511,3
Warning: obj_t::~obj_t(): removed 0x14a4e4410 from 5616,1511,2, but it should have been on 5616,1511,3
Warning: obj_t::~obj_t(): couldn't remove 0x14a4e3960 from 5618,1502,3
Warning: obj_t::~obj_t(): removed 0x14a4e3960 from 5618,1502,2, but it should have been on 5618,1502,3
Warning: obj_t::~obj_t(): couldn't remove 0x14a4e3720 from 5618,1501,3
Warning: obj_t::~obj_t(): removed 0x14a4e3720 from 5618,1501,2, but it should have been on 5618,1501,3
Warning: obj_t::~obj_t(): couldn't remove 0x14a4e35d0 from 5619,1500,3
Warning: obj_t::~obj_t(): removed 0x14a4e35d0 from 5619,1500,2, but it should have been on 5619,1500,3
Warning: obj_t::~obj_t(): couldn't remove 0xd43c1e10 from 5800,1919,6
Warning: obj_t::~obj_t(): removed 0xd43c1e10 from 5800,1919,5, but it should have been on 5800,1919,6
Warning: obj_t::~obj_t(): couldn't remove 0xd43c0be0 from 5756,1897,8
Warning: obj_t::~obj_t(): removed 0xd43c0be0 from 5756,1897,6, but it should have been on 5756,1897,8
Warning: obj_t::~obj_t(): couldn't remove 0xd43c03d0 from 5761,1885,7
Warning: obj_t::~obj_t(): removed 0xd43c03d0 from 5761,1885,6, but it should have been on 5761,1885,7
Warning: obj_t::~obj_t(): couldn't remove 0xd43c0310 from 5763,1885,7
Warning: obj_t::~obj_t(): removed 0xd43c0310 from 5763,1885,6, but it should have been on 5763,1885,7
Warning: obj_t::~obj_t(): couldn't remove 0xd43c02e0 from 5760,1885,7
Warning: obj_t::~obj_t(): removed 0xd43c02e0 from 5760,1885,6, but it should have been on 5760,1885,7
Warning: obj_t::~obj_t(): couldn't remove 0xd43c0250 from 5762,1885,7
Warning: obj_t::~obj_t(): removed 0xd43c0250 from 5762,1885,6, but it should have been on 5762,1885,7
Warning: obj_t::~obj_t(): couldn't remove 0xd43fc290 from 7461,1965,7
Warning: obj_t::~obj_t(): removed 0xd43fc290 from 7461,1965,6, but it should have been on 7461,1965,7
Warning: obj_t::~obj_t(): couldn't remove 0xd43f66b0 from 7466,1964,7
Warning: obj_t::~obj_t(): removed 0xd43f66b0 from 7466,1964,6, but it should have been on 7466,1964,7
Warning: obj_t::~obj_t(): couldn't remove 0x14c6d9610 from 933,1090,7
Warning: obj_t::~obj_t(): removed 0x14c6d9610 from 933,1090,6, but it should have been on 933,1090,7
Warning: obj_t::~obj_t(): couldn't remove 0x14c6d3460 from 986,1063,6
Warning: obj_t::~obj_t(): removed 0x14c6d3460 from 986,1063,5, but it should have been on 986,1063,6
Warning: obj_t::~obj_t(): couldn't remove 0x14c6d3340 from 985,1063,6
Warning: obj_t::~obj_t(): removed 0x14c6d3340 from 985,1063,5, but it should have been on 985,1063,6
Warning: obj_t::~obj_t(): couldn't remove 0x14c6d3070 from 985,1064,6
Warning: obj_t::~obj_t(): removed 0x14c6d3070 from 985,1064,5, but it should have been on 985,1064,6
Warning: obj_t::~obj_t(): couldn't remove 0x14c6d2fe0 from 984,1068,7
Warning: obj_t::~obj_t(): removed 0x14c6d2fe0 from 984,1068,6, but it should have been on 984,1068,7
Warning: obj_t::~obj_t(): couldn't remove 0x318ae410 from 6171,1607,3
Warning: obj_t::~obj_t(): removed 0x318ae410 from 6171,1607,2, but it should have been on 6171,1607,3
Warning: obj_t::~obj_t(): couldn't remove 0x318ae320 from 6170,1607,3
Warning: obj_t::~obj_t(): removed 0x318ae320 from 6170,1607,2, but it should have been on 6170,1607,3
Warning: obj_t::~obj_t(): couldn't remove 0x318ad4e0 from 6136,1594,3
Warning: obj_t::~obj_t(): removed 0x318ad4e0 from 6136,1594,2, but it should have been on 6136,1594,3
Warning: obj_t::~obj_t(): couldn't remove 0x318ab9b0 from 6130,1614,3
Warning: obj_t::~obj_t(): removed 0x318ab9b0 from 6130,1614,2, but it should have been on 6130,1614,3
Warning: obj_t::~obj_t(): couldn't remove 0x318b2100 from 6120,1784,6
Warning: obj_t::~obj_t(): removed 0x318b2100 from 6120,1784,5, but it should have been on 6120,1784,6
Warning: obj_t::~obj_t(): couldn't remove 0x318c3380 from 6130,1364,7
Warning: obj_t::~obj_t(): removed 0x318c3380 from 6130,1364,6, but it should have been on 6130,1364,7
Warning: obj_t::~obj_t(): couldn't remove 0x318c3350 from 6130,1365,7
Warning: obj_t::~obj_t(): removed 0x318c3350 from 6130,1365,6, but it should have been on 6130,1365,7
Warning: obj_t::~obj_t(): couldn't remove 0x318e2dd0 from 6580,53,5
Warning: obj_t::~obj_t(): removed 0x318e2dd0 from 6580,53,4, but it should have been on 6580,53,5
Warning: obj_t::~obj_t(): couldn't remove 0x1357f02b0 from 1477,1602,5
Warning: obj_t::~obj_t(): removed 0x1357f02b0 from 1477,1602,4, but it should have been on 1477,1602,5
Warning: obj_t::~obj_t(): couldn't remove 0x15188e660 from 2125,1523,2
Warning: obj_t::~obj_t(): removed 0x15188e660 from 2125,1523,1, but it should have been on 2125,1523,2
Warning: obj_t::~obj_t(): couldn't remove 0x1518c2c40 from 9,995,7
Warning: obj_t::~obj_t(): removed 0x1518c2c40 from 9,995,6, but it should have been on 9,995,7
Warning: obj_t::~obj_t(): couldn't remove 0x1518c2c10 from 9,996,7
Warning: obj_t::~obj_t(): removed 0x1518c2c10 from 9,996,6, but it should have been on 9,996,7
Warning: obj_t::~obj_t(): couldn't remove 0x8b8bd9a0 from 31,1860,4
Warning: obj_t::~obj_t(): removed 0x8b8bd9a0 from 31,1860,3, but it should have been on 31,1860,4
Warning: obj_t::~obj_t(): couldn't remove 0x8b8bb9f0 from 42,1865,6
Warning: obj_t::~obj_t(): removed 0x8b8bb9f0 from 42,1865,5, but it should have been on 42,1865,6
Warning: obj_t::~obj_t(): couldn't remove 0x39b5c6d0 from 6378,1405,4
Warning: obj_t::~obj_t(): removed 0x39b5c6d0 from 6378,1405,3, but it should have been on 6378,1405,4
Warning: obj_t::~obj_t(): couldn't remove 0x39b5c400 from 6380,1404,4
Warning: obj_t::~obj_t(): removed 0x39b5c400 from 6380,1404,2, but it should have been on 6380,1404,4
Warning: obj_t::~obj_t(): couldn't remove 0x39b5bdd0 from 6379,1403,4
Warning: obj_t::~obj_t(): removed 0x39b5bdd0 from 6379,1403,2, but it should have been on 6379,1403,4

I haven't been able to study these tiles yet, as my VM timed out. I was in the process of lowering land when the month change happened.

EDIT: The next message in the server log after the above was:

Code: [Select]
Message: karte_t::new_month(): Industry density proportion of 10000 being overriden with a value of 10000
So maybe the pause could have been related to planting a factory too.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on November 19, 2020, 09:38:57 PM
From offline testing, this was caused by hundreds of industries closing between October - November 1942.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on November 22, 2020, 10:05:28 AM
An error in the most recent patch has caused about half the companies on the server to go into administration. The server will have to be rolled back to an earlier save and this patch (https://github.com/jamespetts/simutrans-extended/pull/304) will have to be applied. I have a save from earlier today, and I believe Matthew has even more recent saves.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on November 22, 2020, 12:01:31 PM
Thank you for finding and fixing this problem. Now restarting the server with your patch applied and rolled back to March 1944, before any players were in administration.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on November 22, 2020, 12:42:59 PM
Recent saves are here (https://drive.google.com/drive/folders/1Ebv0JiKVcjE7-lZMCMgblA3WE2xcpas-?usp=sharing).

Times in the filenames are in EST (GMT-5)
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on November 22, 2020, 12:49:12 PM
I believe that the server has now been restarted with a reverted saved game version - please let me know if this process has not been effective.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 03, 2020, 06:17:58 AM
It appears that the Bridgewater-Brunel game server has not updated to the latest nightly build (#1b3a304).

If you use Nightly Updater, you may want to hold off updating and/or save your old executable (#8afbbce).

EDIT: I have tried to build yesterday's version (#8afbbce) for Windows and it is available here (https://drive.google.com/file/d/1AUnCJ5KThQuopz6SdfiOwVHe-AoVEuav/view?usp=sharing). It has been been tested online and appears to work, but YMMV. Also, it's a GDI build (so it won't have that annoying mouse cursor offset, but it also won't be able to play more than one sound at a time or handle non-Latin characters)
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 03, 2020, 01:45:34 PM
I am not sure quite why there was a delay in restarting, but it has now restarted with the correct version.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 05, 2020, 11:47:46 AM
The server is currently undergoing an upgrade - although the game may appear to be available, the server may restart at any time and consequently changes will not be saved until further notice later to-day.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 05, 2020, 01:08:48 PM
The upgrade has now been completed and the server is running again: apologies for the inconvenience.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 05, 2020, 01:12:23 PM
The upgrade has now been completed and the server is running again: apologies for the inconvenience.
May I ask what the upgrade involved?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 05, 2020, 01:15:54 PM
May I ask what the upgrade involved?

It was an upgrade of the Linux distribution version on the server, which was out of date. One of the motivations was to allow installation of the latest libzstd-dev package for moving towards integrating this improved compression algorithm, once I have managed to get this to compile properly on the server and for cross-compile builds.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 05, 2020, 03:33:22 PM
The upgrade has now been completed and the server is running again: apologies for the inconvenience.

Thank you for the upgrade. Also thank you to Isaac, Vladki, and others who maintain the Extended infrastructure.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Vladki on December 05, 2020, 04:05:07 PM
What distro & version are you running?
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 06, 2020, 09:49:27 AM
The server and its clients have been frequently crashing because of my signal routing patch. Could you please revert it?
edit: pull request that reverts it here: https://github.com/jamespetts/simutrans-extended/pull/309
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 06, 2020, 12:18:02 PM
I have now merged Freddy's pull request - thank you for that.

I am in the process of running a further upgrade on the server, from Ubuntu 18.04 to Ubuntu 20.04 to get easy access to the latest development libraries for compiling.

After the next save, changes may be lost until further notice.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 06, 2020, 04:44:16 PM
The server has now been upgraded to 20.04 and is running normally again.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 07, 2020, 07:10:11 AM
The server game has not properly updated to the latest version again, could you please update it manually?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 07, 2020, 11:08:45 AM
The server game has not properly updated to the latest version again, could you please update it manually?

What appears to be happening is that the Simutrans-Extended instance on the server is failing to shut down when commanded to do so, so, while the new code is compiled, the old code is still running. I do not understand why this has now started to happen. I will try to restart manually, but, given the need to ensure that the game be saved, this is extremely time consuming.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 10, 2020, 04:02:03 PM
What appears to be happening is that the Simutrans-Extended instance on the server is failing to shut down when commanded to do so, so, while the new code is compiled, the old code is still running. I do not understand why this has now started to happen. I will try to restart manually, but, given the need to ensure that the game be saved, this is extremely time consuming.

The server instance has not restarted for three days now. Full marks for stability, Bridgewater-Brunel! And thank you to Freddy, James, Prissi, Turfit, and everyone who has made the server so stable. This is a nice problem to have, but it is a problem. The Nightly Updater has become useless, because the paksets and binaries at bridgewater-brunel.me.uk/downloads/ are not necessarily what the server is running. And the server log is now 1.8GB, which is effectively unusable.

I speculate that this is related to general 'server lag'. This is not a concept I totally understand (since it seems that clients and server can both lag at the same time), but I take to mean the server has unimplemented actions waiting in a queue.  Last week I noticed that the 'Minister of Transport' message, which should run at 0559 London time, did not appear until after 0600 (0601 IIRC). That suggests the server has unfinished business when the restart script runs at 0600.

Looking at the restart script (https://forum.simutrans.com/index.php/topic,20245.msg190378.html#msg190378), it appears that it uses simple kill, which I believe tells Simutrans-Extended to exit gracefully (in contrast to kill -9). As of August 2020, it also had startstopgracetime=5, so the server only had five seconds to stop and start. The server should stop and start faster than the clients, because it doesn't have to (un)load graphical objects, but it would not be surprising if (un)load times were longer than five seconds, especially if it's got to complete a backlog of queued actions beforehand. So as a first step, perhaps it would be sensible to increase startstopgracetime dramatically, to 120, 180 or 300 seconds?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 10, 2020, 06:12:07 PM
Thank you for the suggestions. At this stage, the strategy is to move towards implementing the improved compression algorithm as soon as reasonably possible, which may well reduce the lag enough to eliminate this problem. If it does not do so, more significant consideration can be given to other means of dealing with it then.

Thank you for analysing this carefully, however.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 16, 2020, 08:10:06 AM
The server has now been offline for over two hours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 17, 2020, 09:34:23 AM
The server has now been offline for over two hours.
This happened for 5:30 hours before working again. Now, the exact same problem has occurred after today's restart. In both cases, the log shows that the server freezes just before entering karte_t::load.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 17, 2020, 08:15:02 PM
That is very odd. Yesterday, what appeared to be happening was that the server was failing to load the saved game. I made some slight changes to the code with the intention of diagnosing the problem, and the problem went away after I ran the nightly script and refreshed the build. I am not sure what the problem was to-day: I was too busy to deal with this before now, and I see that the server is back online again.

The problem yesterday appeared to be related to the following part of the code:

Code: [Select]
if(!file.rd_open(name)) {

if(  file.get_version_int()==0  ||  file.get_version_int()>loadsave_t::int_version(SAVEGAME_VER_NR, NULL).version  ) {
dbg->warning("karte_t::load()", translator::translate("WRONGSAVE") );
dbg->warning("karte_t::load()", "Version is %u (Ex %u)", loadsave_t::int_version(SAVEGAME_VER_NR, NULL).version, loadsave_t::int_version(SAVEGAME_VER_NR, NULL).extended_version);
create_win( new news_img("WRONGSAVE"), w_info, magic_none );
}

I was getting the translated error message from WRONGSAVE in the command line on the server. I added debugging information to try to get it to be more specific, but, as noted above, the problem went away after recompiling. I do not know whether or not to-day's problem was related.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 18, 2020, 06:31:42 AM
The same exact problem is happening again today - the log always ends just before entering karte_t::load. Can you please manually restart the server again?
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on December 18, 2020, 09:10:11 AM
As previously reported, there is an issue where the save version cannot be read correctly. The version will be blank. (It is saved correctly just because it cannot be read. If you use an old client, you can check that the version information is recorded in the save data created by the current client)
I think that is the cause.
One of the possible problems seems to be the incorrect version. (Or the part related to this is incorrect)
Code: [Select]
#define SIM_SAVE_MINOR      7
#define SIM_SERVER_MINOR    7
But I have no idea what this version should be.
For example, current nightly build can't recognize the saved game version recorded by itself, but the it will read recorded version if you change it. But I couldn't find the number to read its own saved game.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 18, 2020, 12:40:47 PM
The server is currently not running. I have very limited time to-day, but the problem with the server starting appears to be not quite the same as it has been previously. A backtrace output gives the following:

Code: [Select]

Warning: sound_desc_t::get_sound_id():  sound "konakaboom-black-five.wav" not found
Warning: sound_desc_t::get_sound_id():  sound "felix-blume-old-factory.wav" not found
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'GOOD-bulk'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-LBSCR-4Wheel-composite-sub-fitted'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-gwr-4100'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-GWR-517Tank-AutoFitted'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-LBSCR-4Wheel-Brake-front-sub-fitted'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-LBSCR-4Wheel-Brake-rear-sub-fitted'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-LBSCR-4Wheel-Second-sub-fitted'
Warning: obj_reader_t::resolve_xrefs(): cannot resolve 'VHCL-LBSCR-4Wheel-First-sub-fitted'
Message: warn_missing_objects:  Object MonorailGround not found, feature disabled
Message: simu_main():   Reading menu configuration ...
Warning: tool_t::read_menu():   toolbar[11][5]: replaced way-builder(id=14) with default param=cityroad by cityroad builder(id=36)
Message: simu_main():   Reading private car ownership configuration ...
Message: register_desc():       Notice: obj Button already defined
Message: register_desc():       Notice: obj Roundbutton already defined
Message: register_desc():       Notice: obj Editfield already defined
Message: register_desc():       Notice: obj Listbox already defined
Message: register_desc():       Notice: obj Back already defined
Message: skinverwaltung_t::register_desc():     Extra object Titlebar added.
Message: skinverwaltung_t::register_desc():     Extra object GadgetBack added.
Message: register_desc():       Notice: obj Checkbutton already defined
Message: register_desc():       Notice: obj Posbutton already defined
Message: register_desc():       Notice: obj Scrollbar already defined
Message: register_desc():       Notice: obj Gadget already defined
Message: register_desc():       Notice: obj Divider already defined
[New Thread 0x7ffff762e700 (LWP 647892)]

Thread 2 "simutrans-exten" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff762e700 (LWP 647892)]
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383
383     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) backtrace
#0  __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383
#1  0x00007ffff7f6a754 in ZSTD_decompressStream () from /usr/lib/x86_64-linux-gnu/libzstd.so.1
#2  0x00005555556cf6b1 in ?? ()
#3  0x0000000100000000 in ?? ()
#4  0x4a1833deb9388600 in ?? ()
#5  0x0000000000100000 in ?? ()
#6  0x0000555555c19020 in ?? ()
#7  0x0000000000100000 in ?? ()
#8  0x0000000000000000 in ?? ()
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 18, 2020, 09:57:48 PM
Oddly, the problem now appears to have changed:

Code: [Select]
Incompatible saved game.

Cannot load file.

Warning: karte_t::load():       Version is 120007 (Ex 0)
ERROR: loadsave_t():    failed reading with error 1
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
Warning: nwc_routesearch_t::reset:      all static variables are reset
Message: nwc_auth_player_t::init_player_lock_server:    new = 32767
Message: karte_t::create_rivers():      There aren't any water tiles!

Message: simmain():     Creating cities ...
Message: karte_t::init():       Creating factories ...
Distributing 1 tourist attractions ...
Message: karte_t::init():       Preparing startup ...
Message: network_command_t::rdwr:       write packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr:      rdwr id=8 client=0 plnr=255 pos=koord3d invalid tool_id=8224 defpar=16384,Now 0 clients connected. init=1 flags=0
Message: simu_main():   modal_dialogue( new welt_gui_t(&env_t::default_settings), magic_welt_gui_t, welt, never_quit );
ERROR: modal_dialogue:  called without a display driver => nothing will be shown!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
Title: Re: Bridgewater-Brunel game no. 3
Post by: Ranran on December 18, 2020, 11:16:18 PM
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/54290198039d2ce8f2011bcad4a74b44804acf9a
I found what seems to be a merge error in network_file_transfer.cc. Near the 160th line. I hope you can see if this has any effect.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 19, 2020, 12:12:45 AM
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/54290198039d2ce8f2011bcad4a74b44804acf9a
I found what seems to be a merge error in network_file_transfer.cc. Near the 160th line. I hope you can see if this has any effect.

Thank you for this - now incorporated.

I have been spending some time trying to deal with this problem - it is still unclear what the cause is; latest investigations seem to suggest that what was happening at least at one point was that, when the server was restarting automatically, without the "-load [savegame]" in the command line, it was failing with a segfault, whereas, when I gave the "-load server13353-network.sve" command explicitly, it would work. I have therefore managed to get the server running again by adding "-load ../server13353-network.sve" to the script - I am not sure whether this will work over the long term, but I should be grateful if people could report the result.

Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 19, 2020, 12:33:23 AM
I have been spending some time trying to deal with this problem - it is still unclear what the cause is; latest investigations seem to suggest that what was happening at least at one point was that, when the server was restarting automatically, without the "-load [savegame]" in the command line, it was failing with a segfault, whereas, when I gave the "-load server13353-network.sve" command explicitly, it would work. I have therefore managed to get the server running again by adding "-load ../server13353-network.sve" to the script - I am not sure whether this will work over the long term, but I should be grateful if people could report the result.
Though I can't recall any specific cases, I vaguely remember having segfaults in the past when trying to start servers without specifying -load [savegame], and that adding -load [savegame] fixed them.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on December 20, 2020, 11:32:01 AM
After a fairly good run for several hours after today's reset, an improvement on previous days, the server has now been down for nearly 2.5 hours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 20, 2020, 11:43:51 AM
The Simutrans-Extended instance was running on the server, but was unresponsive for reasons unknown. Now restarted.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 28, 2020, 11:09:13 AM
Bridgewater-Brunel has not run since the nightly restart
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 28, 2020, 11:21:27 AM
Bridgewater-Brunel has not run since the nightly restart

It seems to have entered a frozen state - I have now restarted it.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 28, 2020, 02:34:17 PM
It seems to have entered a frozen state - I have now restarted it.

Thank you for fixing this, James!  :thumbsup:
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on December 28, 2020, 07:39:42 PM
Sorry to sound like a stuck record, but the server has frozen again for the last 3 hours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on December 28, 2020, 09:36:34 PM
I have restarted it again.

There seems to be a persistent problem causing the server to get stuck in an infinite loop on occasions. It is not a thread deadlock, as there is high CPU usage. The trouble is that it is very difficult to think of any way of reproducing this. If anyone can find a reproduction case for an infinite loop/freeze, please post it in the bug reports forum. Thank you.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on January 01, 2021, 03:07:09 AM
The server has now been down for over 8 hours. I wonder if you could add a script that automatically restarts the server if the log file has not updated for 2 hours, for instance?
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on January 01, 2021, 11:23:18 AM
The server has now been down for over 8 hours. I wonder if you could add a script that automatically restarts the server if the log file has not updated for 2 hours, for instance?

I have now restarted the server. The freezes do need to be identified and fixed: the suggested script is not a permanent solution. The process can only be terminated with the kill -9 command in this state. In any event, terminating the server if the log has not been updated in 2 hours will not be sensible, since this stat will occur if nobody has played on the server for the last 2 hours.
Title: Re: Bridgewater-Brunel game no. 3
Post by: Vladki on January 16, 2021, 03:53:36 PM
I have tried to connect to B-B, but after (long) loading the game it said that the save is incompatible, and dropped me to demo.sve. And probably crashed the server...

I run self compiled binary because the nightlies have too fresh libraries for debian. But I have no problem connecting to S-S which is on ubuntu 20.04. I suspect the libzstd to be the culprit?
Debian: libzstd1:amd64 1.3.8+dfsg-3 Ubuntu: libzstd1:amd64 1.4.4+dfsg-3
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on January 16, 2021, 03:57:18 PM
If you are self compiling, make sure that you enable zstd otherwise you will not be able to connect.
Title: Re: Bridgewater-Brunel game no. 3
Post by: zook2 on February 11, 2021, 06:05:46 AM
After decades of lying dormant, the venerable Rolls Royce factory in Maltbere openend its gates for business again in February 2009. Production of the legendary British limousines commenced - a milestone in British industry development. But with great regret we announce that, after only five months of low-level production, the factory has closed again - this time forever, we're afraid. The Class I listed historic buildings have already beeen torn down, to make room for hovels.

Only thirty Rolls Royce cars of the much anticipated 2009 model were ever made. There are no more car makers in the UK now.

Of course the last production car will be donated to Her Majesty Queen Elizabeth II. Buckingham Palace announced that Her Majesty is greatly pleased to "finally dump the Toyota".
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on April 02, 2021, 02:25:04 PM
I notice that we are now quite far into the future (2041, I believe). What are people's views on when it would be optimal to bring the current game to a close and start afresh?
Title: Re: Bridgewater-Brunel game no. 3
Post by: Freahk on April 02, 2021, 05:16:07 PM
Ohhh noooo!
In my opinion, opposing to stephenson-siemens game, there's still very much that can be done on the current bridgewater map offering fun for at least another 50-100 years.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on April 02, 2021, 08:04:24 PM
Ohhh noooo!
In my opinion, opposing to stephenson-siemens game, there's still very much that can be done on the current bridgewater map offering fun for at least another 50-100 years.

Interesting! I shall be interested to know others' views on the topic.
Title: Re: Bridgewater-Brunel game no. 3
Post by: freddyhayward on April 03, 2021, 02:52:09 AM
There are only three remaining active players: Freahk, zook, and myself. We clearly still enjoy it and there is more to do, but I would welcome restarting the game if it rekindles interest for former and new players.
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on April 03, 2021, 11:22:29 AM
There are only three remaining active players: Freahk, zook, and myself. We clearly still enjoy it and there is more to do, but I would welcome restarting the game if it rekindles interest for former and new players.

I should be interested to know why those who have retired have done so; is it purely for personal reasons, or does it have anything to do with the state of the game itself, and, if so, what?
Title: Re: Bridgewater-Brunel game no. 3
Post by: Matthew on April 03, 2021, 12:28:59 PM
I should be interested to know why those who have retired have done so; is it purely for personal reasons, or does it have anything to do with the state of the game itself, and, if so, what?

I explained (https://discord.com/channels/379629070670888973/737992455361658891/813459197680549929) my reasons on the Discord channel:

Quote
Earlier in this channel I said that I would probably retire from managing Central Trains, Cambrian Trains etc. when B-B reached the present day. I have brought that forward to now and I am going on hiatus (as explained here: https://forum.simutrans.com/index.php/topic,20807.new.html#new), though I will still have notifications for this channel turned on.
The company is available for takeover and I have attempted to remove the password. @Zook as you are the newest player I would like you to have right of first refusal on the company. If nobody wants it, I would be happy to log on again to Withdraw all the profitable vehicles in the hope of making the company go bankrupt as quickly as possible (it has 'only' £300MM in the bank, so I guess it's not totally impossible).(edited)
By the way, this does not mean that I am in a hurry to start the next B-B game. I intend to spend some time thinking about things other than trains and if (more likely, when) I come back from hiatus I hope to make some contributions to improve the next round. I hope you all have a long and enjoyable 21st century! 

I would be unlikely to join a new game at the moment as I am currently preoccupied with other interests (ancient DNA and the new rugby league season). So if others are happily playing that suits me too.  8)
Title: Re: Bridgewater-Brunel game no. 3
Post by: jamespetts on April 03, 2021, 12:59:02 PM
Thank you - that is helpful. Ancient DNA is an intriguing topic - do enjoy your researches in that field! No doubt Simutrans will still be here whenever you feel like returning.