Author Topic: Bridgewater-Brunel game no. 3 (Read 17648 times)

Junna · « **Reply #70 on:** August 04, 2020, 11:42:14 PM »

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

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.

Sirius · « **Reply #71 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.

Sirius · « **Reply #72 on:** August 13, 2020, 07:09:21 AM »

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.

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.

jamespetts · « **Reply #73 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.

SuperTimo · « **Reply #74 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.

jamespetts · « **Reply #75 on:** August 15, 2020, 11:08:02 AM »

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

Unlocked.

SuperTimo · « **Reply #76 on:** August 15, 2020, 11:08:29 AM »

Thanks James!

Matthew · « **Reply #77 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!

jamespetts · « **Reply #78 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.

Sirius · « **Reply #79 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?

freddyhayward · « **Reply #80 on:** August 21, 2020, 08:09:42 AM »

Quote from: Freahk on August 21, 2020, 08:03:59 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.

jamespetts · « **Reply #81 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.

freddyhayward · « **Reply #82 on:** August 21, 2020, 10:20:46 AM »

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

Thanks, can you please also reset Freahk's password (Prominster Shipping & Coaches)?

jamespetts · « **Reply #83 on:** August 21, 2020, 11:02:43 AM »

Quote from: freddyhayward on August 21, 2020, 10:20:46 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.

jamespetts · « **Reply #84 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.

jamespetts · « **Reply #85 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.

freddyhayward · « **Reply #86 on:** August 29, 2020, 02:42:15 PM »

I notice that regions are now active on bridgewater-brunel. was this intentional?

jamespetts · « **Reply #87 on:** August 29, 2020, 02:45:07 PM »

Quote from: freddyhayward on August 29, 2020, 02:42:15 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.

VOLVO · « **Reply #88 on:** September 06, 2020, 01:22:48 PM »

The server suddenly changed game revision? Seems weird

jamespetts · « **Reply #89 on:** September 06, 2020, 01:32:12 PM »

Quote from: VOLVO on September 06, 2020, 01:22:48 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.

freddyhayward · « **Reply #90 on:** September 08, 2020, 03:02:43 PM »

The server has been down for over 5 hours now.

jamespetts · « **Reply #91 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.

freddyhayward · « **Reply #92 on:** September 08, 2020, 04:16:55 PM »

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

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.

jamespetts · « **Reply #93 on:** September 08, 2020, 04:22:03 PM »

Quote from: freddyhayward on September 08, 2020, 04:16:55 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.

freddyhayward · « **Reply #94 on:** September 12, 2020, 11:07:36 AM »

The server is now instantly crashing on connection causing the clients to desync.

jamespetts · « **Reply #95 on:** September 12, 2020, 11:11:42 AM »

Quote from: freddyhayward on September 12, 2020, 11:07:36 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.

freddyhayward · « **Reply #96 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

Sirius · « **Reply #97 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.

jamespetts · « **Reply #98 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.

Ranran · « **Reply #99 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.

freddyhayward · « **Reply #100 on:** September 12, 2020, 12:11:46 PM »

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

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.

jamespetts · « **Reply #101 on:** September 12, 2020, 12:44:52 PM »

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

The overflow code is commented out as Extended uses 64-bit values for storing ticks to avoid any overflowing.

jamespetts · « **Reply #102 on:** September 12, 2020, 02:40:14 PM »

Can I check whether this problem has recurred this afternoon?

freddyhayward · « **Reply #103 on:** September 12, 2020, 02:58:49 PM »

Quote from: jamespetts on September 12, 2020, 02:40:14 PM

Can I check whether this problem has recurred this afternoon?

It occurred several more times after my report, but has since stopped.

freddyhayward · « **Reply #104 on:** September 20, 2020, 05:21:53 AM »

Quote from: freddyhayward on September 12, 2020, 12:11:46 PM

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.