Topic: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1

[AP]

Indeed, I see that now that I've looked in to it.  In early years the freight cars are much slower (30 km/h until 1835, then 40 km/h until 1855) and the capacity is very low... so we're stuck using ships for quite some time for freight.  It's really not until 1885 that anything viable comes along.

I think the canal cost issue is the problem here. We should favour rail over canal for inland freight, except we have a vast number of inland ship canals which ought not to have happened.

I'm intending to try a coal route on my inter-island rail route if passenger traffic proves insufficient, not sure how it will turn out though.

[Sarlock]

Remember that we started in 1750... not a lot of freight trains running around at that point.  It wasn't until the mid 1800's that you saw much freight travelling by rail - canals were still in heavy use because it was by far the more efficient mode of transport for freight.  Actually, even today freight by water is a much cheaper method, as long as the freight isn't time sensitive.  The Great Lakes/St. Lawrence River is still a very busy shipping route for freight.

I tried a freight line in offline play and I wouldn't bother at this point... you can barely break even on operational costs with the available equipment in 1830, let alone cover your infrastructure cost.  Even a 64-long train can only carry a couple hundred cargo... whereas a ship can carry 1575.  At a fraction of the cost.  You don't get much financial bonus for quick delivery of freight, unlike for passengers.

[AP]

Thanks for the heads up. Suspect it's a balancing issue - most of the early railways went for the freight traffic routes, not passenger traffic, so they ought to make money. Although granted many were also industry-to-port types of routes.

[Sarlock]

Probably... the early cargo cars can only hold 4-6 of each cargo type, so even with 50+ cars, you can only hold 200-300 cargo.  Which wouldn't be too bad if you could fill a line up with hundreds of trains to move the cargo, but at over $50/km (using enough locomotives to move it at a decent acceleration/top speed), they are extremely pricey as compared to a ship at $1.80/km.  Top speed for 1835 cars is only 40 km/h as well.

In 1855 there are new rail cargo cars that can hold 8 units of cargo, but even that is quite small and hard to make a profit with.  I suspect ship based cargo routes will be the norm until at least 1885.

[VOLVO]

I think the running costs for the ships are unrealistic. Just think of the salary for that many people working for such a long time/hard work, the food/water to supply them?
They should be more expensive to run than the trains as far as I concern. So do the maintenance costs for canals.

Also, the de-synchronise problem is getting out of hand..

[jamespetts]

Thank you for all your feedback. When I rebalance the pakset, I shall explicitly make reference to the number of crew required for a ship in setting the ship's fixed costs, which should greatly increase its cost over that of a railway freight train, requiring a total crew of three people (driver, fireman and guard). Maintenance costs for canals should be relatively modest as they would not need much more than dredging, but their construction cost needs to be increased.

As to the desyncs, TurfIt thinks that he has spotted a possible cause for desyncs and we are working on a solution. Sorry that people are having difficulties.

[Sarlock]

Thanks, James.  For what it's worth, it seems to always be a checklist mismatch with the rand= and traffic= being out of synch.  It is happening a lot now, probably 10+ times per game month.  I used to just get one in the first ~15 game minutes in each new month.

The server is growing laggier as we add more things, but it is still running considerably faster than it was a few weeks ago before the fixes.

[ӔO]

I think we might break 10,000 ships at this rate, but at least they are only two pieces that replace a lot of 8 piece ships.

2 steamers can replace 1 brig
3 to 4 steamers can replace 1 east indianman.

[Sarlock]

And by 1830-1835 we will convert a vast majority of our pax/mail system to rail which should help a lot.  Just have to get to 1830-1835

[AP]

When I rebalance the pakset, I shall explicitly make reference to the number of crew required for a ship in setting the ship's fixed costs, which should greatly increase its cost over that of a railway freight train, requiring a total crew of three people (driver, fireman and guard). Maintenance costs for canals should be relatively modest as they would not need much more than dredging, but their construction cost needs to be increased.

Sounds very good. Not sure how dredging was done before modern ships were available? I suspect it was rather labour intensive (as with digging a railway cutting before steam shovels).

Just have to get to 1830-1835

Tempus fugit 

[Sarlock]

My client is crashing every time I connect to the server... I assume by the lack of months moving forward on the game that everyone else is having the same problem.

[jamespetts]

The crash is caused by a bug which I have now fixed on the 11.x branch - apologies for the difficulties. I will post again once the fixed version is released.

[AP]

My client is crashing every time I connect to the server... I assume by the lack of months moving forward on the game that everyone else is having the same problem.

Indeed.

Thanks James for fixing, will wait for that.

Happy easter everyone.

[jamespetts]

TurfIt has also produced some fixes which I will merge into the 11.x branch and deploy when I have a chance, probably to-morrow when I get home from my Easter break.

[jamespetts]

The server has now been restarted with version 11.25, incorporating TurfIt's fixes as well as a fix for the bug that caused it to crash previously. Apologies for the delay - do let me know whether these fixes help.

[Sarlock]

Wonderful!  Thank you James (and TurfIt!).  And my wife was happy to have me around all weekend... I was worried that the server would come back up and we were going to hit the rail age just as the Easter weekend hit and I was going to be holed up in front of the computer half the weekend laying tracks instead of attending to the numerous chores around the house and yard.   

EDIT Still getting several of these per month:  (mismatch on rand/traffic)

Code: [Select]

Warning: NWC_CHECK: time difference to server 0
Warning: karte_t::interactive: sync_step=63812  server=[rand=3874953405 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16749 traffic=73532899] client=[rand=3874953405 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16749 traffic=73532899]
Message: network_command_t::rdwr: read packet_id=9, client_id=0
Warning: network_check_activity(): received cmd id=9 nwc_check_t from socket[488]
Warning: NWC_CHECK: time difference to server 0
Warning: karte_t::interactive: sync_step=63816  server=[rand=889777117 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16749 traffic=73532925] client=[rand=999474437 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16749 traffic=73532921]
Warning: karte_t::interactive: disconnecting due to checklist mismatch
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset

[VOLVO]

Thanks for bringing the server back on.

I have a problem:
Some ships got stuck with "no route" for no apparent reason.
They will skip a few waypoints which will make the route-finding system out of range.
But when I redirected it to the nearest waypoint, it automatically skip the waypoints again.

Still trying if there's anyway to get the ship moving again.

[AP]

I had the same thing (only on one ship so far...) and ended up adding extra waypoints, which seemed to cure it.

[jamespetts]

Volvo - can you give any detailed instructions to reproduce this reliably (preferably in a specific thread)?

[Sarlock]

Volvo, I had a few occur too.  I believe it has to do with the additional code for ship wayfinding that eliminates choices that are farther than it assumes it can wayfind.  I had about 20 ships impacted by this and just had to add additional waypoints to the schedule and send them on their way manually and the problem was fixed.  All of the schedules in question were fairly distant, so I guess the program assumed they were beyond wayfinding distance, though they worked fine before the change.  Didn't take long.

[VOLVO]

Volvo - can you give any detailed instructions to reproduce this reliably (preferably in a specific thread)?

I have difficulty staying connect right now, I have set some more way point for a few ships at my last connection. Will see how it turns out.

Volvo, I had a few occur too.  I believe it has to do with the additional code for ship wayfinding that eliminates choices that are farther than it assumes it can wayfind.  I had about 20 ships impacted by this and just had to add additional waypoints to the schedule and send them on their way manually and the problem was fixed.  All of the schedules in question were fairly distant, so I guess the program assumed they were beyond wayfinding distance, though they worked fine before the change.  Didn't take long.

Do they skip waypoints before this version too?

[jamespetts]

This depends on what you mean by "skipping" waypoints. In Experimental, a convoy will always compute the full route from one stop to the next, and not simply stop at the next waypoint (this is important for railway signalling to work properly). What it will do is calculate the route from the current location to the next entry on the schedule, and, if the next entry is a waypoint, calculate the route on from that point to the next entry and so on until it reaches either a stop or the same place as it started. Waypoints are thus still effective, but, unless the waypoint is a reversing waypoint (marked with an [R]), which are treated differently, and which do not apply to ships, the next destination shown in a convoy's schedule will not actually be a waypoint, but a stop.

[ӔO]

only 3 of my lines were affected, which I fixed by adding waypoints within 500 tiles.

AP's lines are severely affected
Asaph's lines are somewhat affected.
Island Hopper only has one line affected, but it is a pax/mail line, so this can cause severe backlogs.

I might need to set behind_server to 25~35 with the amount of desyncs I am experiencing.

[Sarlock]

The desynchs you are getting are checklist mismatches between client and server, not time differentials, so setting the delay higher won't help.  There is something in the code that is causing these mismatches and it has increased significantly in frequency over the past few weeks.  It is consistently in the rand/traffic numbers.  If it was just the desynchs and we could immediately reconnect, it wouldn't be too bad, but with a 1-2+ minute download/connection time and multiplied over several players, it is very difficult to get much accomplished.

I constructed most of my lines with a 500-600 tile maximum distance between waypoints so I was only affected in a minor fashion (fortunately).

[wlindley]

In months of trying, I have never been able to connect.  "Transferring Map" takes about 2 minutes (at up to 7Mbit/sec!) and then "Loading Map" takes another 90 seconds, after which I get an instant "Lost Synchronization."  And this is on a 4-core i5 processor.  How is this usable? 

[VOLVO]

In months of trying, I have never been able to connect.  "Transferring Map" takes about 2 minutes (at up to 7Mbit/sec!) and then "Loading Map" takes another 90 seconds, after which I get an instant "Lost Synchronization."  And this is on a 4-core i5 processor.  How is this usable? 

Being too fast can lead to desync too.

That said, is it possible to save the game when mismatches detected instead of kicking the clients out?
I also think a bit more tolerating to minor mismatch can help too?

[jamespetts]

The system relating to network synchronisation is the same as in Standard - I do not have the necessary (very deep) skills to write the fundamental network code. However, tolerating mismatches is not an option: the client and server would be running games in which totally different things were happening.

W. Lindley - do you still have the problem? What specification computer are you using? Are you able to run it at a reasonable speed locally?

[VOLVO]

This depends on what you mean by "skipping" waypoints. In Experimental, a convoy will always compute the full route from one stop to the next, and not simply stop at the next waypoint (this is important for railway signalling to work properly). What it will do is calculate the route from the current location to the next entry on the schedule, and, if the next entry is a waypoint, calculate the route on from that point to the next entry and so on until it reaches either a stop or the same place as it started. Waypoints are thus still effective, but, unless the waypoint is a reversing waypoint (marked with an [R]), which are treated differently, and which do not apply to ships, the next destination shown in a convoy's schedule will not actually be a waypoint, but a stop.

After a few observations it's definitely the reduced route finding tiles causing the problems, so it's not a bug or anything like that.

[TurfIt]

In months of trying, I have never been able to connect.

IIRC you're using Linux? There's a bug in Experimental rendering it unusable with anything but MSVC compiled executables. Online you'll desync immediately, offline you'll get massive 20+ second freezes.

[jamespetts]

IIRC you're using Linux? There's a bug in Experimental rendering it unusable with anything but MSVC compiled executables. Online you'll desync immediately, offline you'll get massive 20+ second freezes.

Hmm - I was not aware of this. Thank you for letting me know. The server itself runs Linux, albeit the build without graphics. Do you have any idea when this bug was introduced and whether it is still present on the way-improvements branch?

It is odd that a Windows client should be able to stay in sync with a Linux server better than a Linux client.

[TurfIt]

It's the get_2d() issue which you said you'd reverted on the server. A Linux/OSX/MinGW client will desync immediately unless the client is compiled with the reversion.

[jamespetts]

I thought that your patches, which I had applied for the 11.25 build, included a patch reverting this change? I have not edited the code specifically for the server: the server is always built from the master branch from which all release builds are compiled.

[jamespetts]

It seems that I had omitted to apply all of TurfIt's patches, and the get_2d() issue had not been fixed. I have now pushed a new version, 11.26 (now running on the server), which does apply this patch. I should be grateful for feedback as to how this performs. Thank you everyone for your patience.

[wlindley]

Ta-da! 11.26 connects and works perfectly! Woohoo!

[Sarlock]

Still getting frequent desynchs.  Almost unplayable except for those of us who are stubborn enough to keep reconnecting every few minutes.