The International Simutrans Forum

Community => Game Servers => Topic started by: jamespetts on January 26, 2014, 01:35:08 AM

Title: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 01:35:08 AM
Edit: This has now been archived to make way for testing for development versions of the next release of Simutrans-Experimental.

This is a very large online game running Simutrans-Experimental and Pak128.Britain-Ex.

Start year: 1750
Map size: 7000 x 2000
Towns: 395
Meters per tile: 125
When no clients connected: Server will pause
Heightmap by: Sarlock
Image

(http://www.bridgewater-brunel.me.uk/screenshots/bb-3-start.png)

Version of Experimental (currently): Simutrans 112.3 Experimental 11.35
Last updated: 30th of June 2014

Version of pakset (currently): Pak128.Britain-Ex 0.9.1
Last updated: 26th of January 2014

Notes:
Happy playing!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 26, 2014, 04:40:38 AM
I'd like to see how other players gain capital in the early game. :)

I think I needed a minimum of $10,000,000 setting up an unprofitable pax/mail rail line in a local 0.9.0 game.


oh, and default player is unlocked. Is this intended?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 26, 2014, 08:13:09 AM
Wow, new pakset, new Experimental release, new server... you were busy today, James!

Now to carefully consider the design of my initial network...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 11:12:48 AM
oh, and default player is unlocked. Is this intended?

Yes, it is: we no longer need an "observer", since any player can join, observe and chat without being associated with any company, so having the default player free allows an extra player slot.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 26, 2014, 04:13:50 PM
Some of my sailing ships are having issues finding a route between the two main islands.  Unsure if that's a case of user-error or something to do with e.g. the large size of the map.

I also had to spend quite a lot trying to fix an issue with the freight stop coverage being different than the passenger radius (which is what shows when using the V key overlay), so may well quickly go bankrupt, but hey.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 05:38:20 PM
The ship routing issue is due to a limitation in the routefinding system, and is not a bug per se: this can be solved by using waypoints.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 26, 2014, 07:47:49 PM
Indeed, on some of my really long voyages I have to install multiple waypoints to get the ships to find a route.  I'm not sure where the limit lies, it seems to depend on whether it's a straight run of open water or needs to navigate around islands and such.  I typically install a waypoint in any distance over about 1000 tiles (125 km).  I've noticed the same in offline games, it's just a limitation of the engine... we are playing with a map that's 7,000 tiles wide.

I do like how the game engine puts the rivers down the pre-made river valleys.  It's not perfect in every location but in many cases the rivers drop down exactly where they would have in the relief map that I used.  The clustering of cities down the rivers and shorelines is nice, too.

Industrial demand is low, but as you say, it's realistic and I'm okay with it.  Profits are slow to accumulate in this era no matter what you do.  The downside that I find in playing 1750 games is that there is a very long stale period of several decades where ship traffic is the only feasible method of profit-making.  Building canals of any size beyond limited runs will bankrupt you quickly.  The monthly maintenance charge is the thing you need to keep an eye on the most.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 08:06:59 PM
Industrial demand is low, but as you say, it's realistic and I'm okay with it.  Profits are slow to accumulate in this era no matter what you do.  The downside that I find in playing 1750 games is that there is a very long stale period of several decades where ship traffic is the only feasible method of profit-making.  Building canals of any size beyond limited runs will bankrupt you quickly.  The monthly maintenance charge is the thing you need to keep an eye on the most.

Thank you for the feedback - are canals too expensive on monthly maintenance, do you think? In reality, extensive canal networks were built up, but these were heavily used for multiple types of traffics, and some lesser used canals went out of business.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 26, 2014, 10:47:41 PM
I think that's the trick... a lot of canals were multi-purpose and I'm sure in many cases were a public/private partnership.  In order to make them more useful on longer runs you'd have to reduce the operating cost.  For the most part, unless you're lucky, most canals are single purpose only and so opportunity for sufficient profits to offset the operating cost is limited.

Let me continue to play for a few game years and I'll have a better sense of things.

EDIT: Another thing is that some industries are just not going to be profitable at the current low demand levels.  Orchard-->Pub is limited to about 20 units maximum delivery due to the low demand of the pub.  Hard to make a line profitable when you can only carry 20 max units.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 26, 2014, 10:51:39 PM
the narrow canal + narrow barge is one of the cheaper to operate and maintain.

For me, the main profits are coming from transporting over sea.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 26, 2014, 11:09:58 PM
Something weird going on with my ships - they have "wait for 100% cargo" orders yet are sailing the seven seas empty (costing money!)

The low industrial output from e.g. coal mines and quarries means filling a sailing ship's hold is a slow process indeed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 11:13:29 PM
AP - are you sure that you do not have maximum wait for load set?

Sarlock - thank you for your feedback. (For reference, incidentally, almost all of the early canals were actually entirely private and profit-making enterprises, although many of them turned out not to be very profitable).

Can anyone suggest a degree by which the canal maintenance ought to be reduced; or is it too early to tell given that they might be more profitable when tasked with supplying multiple industries? (Or are there not enough industries? I tried to generate slightly more industries than there were towns). Remember, you can allow other players access rights to your canals and make profit by charging them tolls.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 26, 2014, 11:31:38 PM
From my experience, operating a large network of large canal/medium river is not cost effective for the amount of traffic that goes over it.

short canals to feed sea fairing ships is a good way to balance costs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 26, 2014, 11:43:57 PM
I think part of the problem is that while there are a lot of industries on the map as a whole they are so utterly spread out due to the sheer size of the map.  400 industries on a 7000x2000 map ends up with a still very low density level (even if they are concentrated on the shorelines).  Most industry connections are at least 500 tiles apart, and most are thousands.  This makes the use of long-distance shipping the primary key to making profits.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 26, 2014, 11:52:20 PM
I see. I am interested to work out what in the abstract a sensible industry density should be. How many per town do people think sensible?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 26, 2014, 11:56:44 PM
I ran the server game locally and by 1758 there were some 700 industries.

The long distance shipping is highly profitable, but you need to make sure your ships can get there (with waypoints).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 27, 2014, 05:24:33 AM
Indeed, lots of factories popping up as the game goes on... probably be fine in 5-10 years.  I think the biggest issue is that most industry chains are very distant; they don't usually link to industries just down the shoreline.  On the flip side, once your boat makes that 80 hour trip across the map loaded with cargo, the profits are nice.  You just have to have the capital to survive a year without income from those lines.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 27, 2014, 10:15:01 AM
In terms of industry density, I would expect a town of 2000 people to have 6 or 7 different small industries or 3 or 4 larger ones. Otherwise a lot of people are sitting idle. Multiply up for larger towns. EDIT: Industries say how many employees they have (and where they live). Cannot industries spawn around towns until all the population is employed?

Also industries should be moderately close to the towns, the people who work there, which means linking towns with canals makes it likely the canals will serve multiple industries. If the industries spawn miles apart then you need a lot of canal to connect them all. (Farms are different, of course). Having heavy industry or mines in the hills without a town adjacent is just implausible.

AP - are you sure that you do not have maximum wait for load set?

I am sure. However it seems to be behaving itself now, unsure why it wasnt before... one to watch for?


EDIT

Terrain editing in game seems sluggish, suggest players be very careful with it. I managed to turn a £2k click into a £30k click... :-(
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 27, 2014, 10:46:51 AM
for me, the server side crashes in march and reverts to febuary.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 27, 2014, 11:31:14 AM
Ditto. Annoyingly it reverts to after I made my costly mistake with the terrain editor  :-[ .
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 27, 2014, 12:06:02 PM
I do have this save from just before.

https://dl.dropboxusercontent.com/u/17111233/client3-network.sve
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 27, 2014, 03:19:42 PM
Crashes in the first few moments in to March.  Continues to run fine on solo, however...

EDIT: Crashes at 13:00 in March.  I had a look around and I can't see anything abnormal about this time point but clearly something is snagging the server up.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 27, 2014, 04:03:19 PM
To what extent are players 'testing' their routes in solo savegames before building them in the server? I seem to have spent a lot of cash getting routes that work.


once your boat makes that 80 hour trip across the map loaded with cargo, the profits are nice.  You just have to have the capital to survive a year without income from those lines.

In testing I have seen £60,000+ profit from a ship on arrival at one end of the map!

Can anyone with access to the numbers provide a formula for estimating the running cost of a ship though, so we know how much capital to retain?

e.g. a journey of 5000 tiles will take n hours and cost x in maintenance? Presumably its a multiple of the vehicle speed. With journey lengths as described by Sarlock, it would be useful to know how much capital we need to keep handy (per ship)...


Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 27, 2014, 04:53:01 PM
Here's what I am using to base things on:

For the most part you can break even with 20-50 units of cargo on a long haul ship, so operating cost doesn't even factor in to things for my purposes.  It might cost 2-3,000 or so to cross the entire map, so the cost is pretty negligible.  You can get a good 10-20,000 in revenue for even 100-200 units of cargo, so the profits are easy to attain in that respect.  The key is having enough cash to last that long.  It takes 5 real life seconds to travel a single tile at 15 km/h which is about ~30 seconds in game time.  So to travel 8,000 tiles = 1,000 km (1,800 in operating cost at 1.8 per km), it will take over 60 game hours to make that journey, which is nearly a year long.  If your infrastructure to facilitate this trip (stations, depots, etc) costs, say, 1,000/month to maintain, you need 12,000 in cash reserves in order to survive the first year until the first boat arrives to deliver its cargo.  Add to this the fact that you will probably need 20-30 convoys in transit in order to have a steady income stream and feed the industry supply/demand requirements and you require a further 50,000 on hand in order to continue building ships to send to sea.  So consider having at least 60,000 in cash set to the side in order to support this kind of long distance arrangement.  This example highlights how important it is to keep your standing infrastructure monthly cost in mind while building networks -- your boats have to bring in enough revenue to not only offset their operating cost but also offset the high monthly maintenance charges.

Of course, this is only if this is your only route.  What I do is mix some long distance, profitable routes, with some short distance lower profit routes.  The shorter routes aren't as profitable but they bring in steady cash flow in order to offset the losses from establishing your longer routes.  Once the longer routes start delivering their cargo, the profits come in nicely.  I'm looking at some very tidy profits coming in the summer in the current game, assuming the crash can be resolved.

EDIT: To address your other point, yes, I have done some simulations of trial routes in solo save games, especially with these recent crashes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 27, 2014, 05:34:48 PM
Thanks Sarlock.

The "20-30 cargoes in transit" part is interesting. In offline simulation (same map) a colliary-coal merchant route across the entire 6000 tile map is stable with around 6 ships. There are actually very few such routes on the map available given the size and number of players, the seven seas will be very empty indeed. Having 30 long distance vessels in action would mean monopolising the few such routes available, at the expense of other players.

As I said earlier, I think the map is very light on industry, all other things considered.

Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 27, 2014, 06:35:33 PM
cow farm - dairy should be easily profitable too.

wooden planks - builder yard are probably the most profitable
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 27, 2014, 06:56:35 PM
game is effectively down it seems - see here (http://forum.simutrans.com/index.php?topic=13208.new#new) for report
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 27, 2014, 10:26:28 PM
Apologies for the problem: this has proved to be an extremely elusive error. I could not reproduce it locally or on the server when I restarted it manually from the command line. It now seems to be running again (although I am not sure why the viewport is centred on the middle of the ocean rather than near the small island with the sign with the server's name on it as before - very curious).

Thank you all for your reports, and happy playing!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 27, 2014, 11:15:27 PM
Thanks for looking in to it... seems fine now, no clue as to why it decided to hiccup at that same spot every time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 28, 2014, 02:47:32 AM
the server seems to be doing the endless loop again for the beginning of june.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 28, 2014, 03:28:36 AM
Indeed; another endless loop.  I wonder what's causing it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 28, 2014, 10:43:56 AM
I have managed to get a backtrace on Linux for this:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000469a78 in dingliste_t::check_season (this=0x7e65e50, month=21017) at dataobj/dingliste.cc:1424
1424                            if (!d->check_season(month)) {

Still not sure what is causing it, though.

Edit: I suspect that the previous server game did not show this because it did not have any trees, whereas I have given this one a smattering of trees for visual effect (the "check season" suggests that the issue is caused when trees are changed from their spring to summer graphics).

Edit 2: Cannot reproduce on a local server.

Edit 3: Can reproduce on a local server in 64-bit, albeit it crashes at a slightly different point: an access violation is generated in line 317 of grund.cc:

Code: [Select]
/**
    * true if tunnelboden (hence true also for tunnel mouths)
    * check for visibility in is_visible()
    */
    inline bool ist_tunnel() const {
        return ( (get_typ()==tunnelboden) );
    }

This is called from line 491 of void gebaeude_t::calc_bild(), which is in turn called from line 159 of gebaeude.h:

Code: [Select]
bool check_season(const long /*month*/) { calc_bild(); return true; }

itself called from line 1417 of dingliste.cc:

Code: [Select]
if (!d->check_season(month)) {

Edit 4: The "pos" of the gebaeude_t object on which this function is called seems to be registered as 0,0, which does not seem to be right.

Edit 5: On further investigation, the offending building seems to be the town hall of Norley Wood.

Edit 6: I have tried to reproduce this with the 112.5-merge branch to see whether any of this has been resolved in any event in the later code, but other bugs prevent a command line server running at all in that version at present.

I do not have time to continue working on this straight away: it is clear that this bug will recur at every season boundary until it is fixed. It relates to code with which I have had no dealings so far, being dingliste, and is something quite a long way beyond my comprehension (especially as to why it should occur in this map but not the previous map: the earlier tree explanation postulated does not fit with what is later discovered about the error occurring in a town hall, and, in any event, I recall that AEO had planted some trees in the previous game).

I should be very grateful for any assistance in relation to understanding what might be happening here. I think that Neroden did some work on the dingliste code a while ago, but I do not know whether this is responsible. Without some assistance, I fear that it may take many months of intensive work for me to understand, let alone fix, this problem.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 28, 2014, 03:25:38 PM
Interesting... and puzzling.  Thank you for putting all that time in to discovering what the source of the problem is.  Is it just Norley Wood's town hall, I wonder?  Should remove the town and see what happens: whether it doesn't crash or the crash occurs at another point.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on January 28, 2014, 04:29:47 PM
Could it be that the threaded season change is to blame for this? Or is the server compiled explicitely without threads?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on January 28, 2014, 04:43:21 PM
I don't believe the threaded season change has ever hit trunk - atleast for standard. I still have threading of sync_step() in progress, and was going to look at threading step() after...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 29, 2014, 01:47:52 AM
Of course this begs the question as to why the game didn't crash in the first four season changes and only now in 1751.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 29, 2014, 09:52:11 PM
Thank you all for your feedback on this. The threaded season code has not made it into Experimental, and in any event the server has only a single core, so is compiled as a single threaded application, so it cannot be this. I will try what Sarlock recommends to attempt to narrow the trouble.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 30, 2014, 01:37:56 AM
So I ran the game locally until 1805, and even in this 1/4 minimap image, you can sorta see how the cities really grow without any player help.
(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans/simscr95_zps6a610653.png)

And by 1805 there were 1159 industries with a global population of 2,829,234
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 30, 2014, 06:51:14 AM
Wow... look at that megalopolis on the long inlet on the north end of the eastern island.  It practically covers the entire northern coast.  I'm serving about half of the island with a break-even passenger/mail network with the intention of big profits in 25-50 years due to population growth.  Looks like it'll pay off.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 30, 2014, 10:18:49 AM
I do find myself wondering if the map is a bit too crowded. Because of all the sea, and the settlements-like-water setting , there are a lot of settlements very close together. I could see it becoming a very urban map later on.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 30, 2014, 10:23:11 AM
There is plenty of shallow water for land reclamation in certain areas, which is probably cheaper than demolishing through built up cities.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 30, 2014, 03:25:21 PM
The edge islands themselves are massive.  Once land transport becomes feasible there is a lot of potential for vast rail networks to service the western and eastern islands.  Both islands have a lot of cities locked up in their interiors.

All of the eastern islands are connected by shallow water, as are all of the western ones.

Given that land transport isn't really available in any usable form for another 50-100 years, we're stuck with sea transport either way.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 30, 2014, 04:17:08 PM
What is it that constrains passenger journeys now, is it journey time? Would there be any passenger demand for the months-long voyage between islands?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 30, 2014, 04:25:15 PM
Hard to say, but I don't think there is going to be much demand for those voyages at this point in time.

In another test game, pax hardly wanted to use the 27km/h train. With 80km/h max trains, I finally saw 12 carriage trains that were full. Both were not profitable, btw. Probably needed a larger network for more frequency and more demand.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 30, 2014, 05:09:47 PM
I've set up a network of about 40 cities connected by ships and it's barely covering the operating costs (it may even be losing money when maintenance costs are factored in - my freight operations are likely subsidizing my passenger network).  All of the feeder lines are money losing and it's just the main trunk lines that produce moderate profits.  The ships between the hubs are running with 50-100 passengers per trip on average - enough for a small profit but nothing substantial.  The vast majority of prospective passengers decide that the journey time is too slow to want to bother.

In past games, as soon as steam ships appear passenger counts rise significantly.  The additional speed brings a lot of new customers online.  In other past games I've also been successful with inter-island transport - but you need to connect enough cities on either end to be able to produce enough passengers for the journey.  I don't have any long distance inter-island ship lines yet so I can't say if this will work in this game.  My longest passenger journey is about 6 game hours (~800 tiles=100km) distant and passengers are happy to take this (with no refunds).

It's interesting to note that while the passenger depots of the era are only 3 tiles in radius, passengers are willing to walk from much further out to reach the station, so effective coverage of the dockyards is sufficient to serve the bulk of the citizens in each city.

Another thing I'd like to share: You have a cargo ship that arrives at a dock full of cargo and loads it up, 225t and it's full.  But now it waits for 2 hours for the transfer time.  If you jump to the next location in the schedule, the ship will happily disembark and move on to its next destination with the holds nicely full of cargo without having to wait for the 2 hours to load.  It seems the cargo loading/unloading process is cosmetic only and the actual transfer is done immediately upon arrival.  Good way to save 2 hours, especially in the vital first few months when you want your first profits to roll in.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 30, 2014, 05:31:29 PM
btw, it is historically realistic that freight is the profitable side of business, as railway lines mainly sprouted up to carry coal from mines to factories and cities as their main source of power.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 30, 2014, 05:41:31 PM
The problem we have with sea travel and historical realism though is the inability of ships to carry different cargo.

Historically there were "triangles of trade" where a ship would carry 3 very different cargoes in a triangular route, or even just a different cargo 'out' than 'back'. I.e. fully loaded 100% of the time .In Simutrans there are very few opportunities for this*, so when ships and vehicles are created and priced based on realistic data, they will inevitably make less money as a consequence. Because we have to "pick a freight type".


*Coal/Stone/Clay works (all being bulk good). Much later, logs/steel works (both long goods). Maybe fish/dairy (cooled goods). Piece goods may work but the quantities are small.

In theory you could do coal in both directions on a route (ColliaryA to MerchantB and Colliary B to MerchantA) but normally the suppliers are linked to the local consumers, so that ends up not working profitably.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 30, 2014, 06:33:41 PM
A great point, AP.  I've had the same thought.  pak.Britain isn't too bad as there isn't that many freight types, but pak128 is particularly bad in that there are too few opportunities for freight backhauls due to the restriction to certain goods types.  Keeping the number of freight types low is important in this respect.

I haven't given it much thought yet, but with such a large map there must be opportunity for significant backhauls.  That's my next area of focus.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 30, 2014, 07:06:32 PM
I'm making good money now with land transport on this map using stage coaches with a stop in every town. It really is possible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 30, 2014, 07:28:10 PM
I haven't given it much thought yet, but with such a large map there must be opportunity for significant backhauls.  That's my next area of focus.

Fewer than you'd think between the two main archipelagos:

Bulk goods: I could only find two bulk goods wanting to go west to east (stone) which I am using to balance the coal going east to west. No potteries on the eastern island, so clay isn't required there.[Edit: and no demand for woodchips due to brewery issue]

Chilled goods: fish/meat/milk?  In 1750 it would seem implausible if we can start shipping that stuff too far... assume the speedbonus would make it uneconomic??

Piece goods: Beer / vegetables / furniture / clothes (can't find a textile mill though) . Only in small quantities.

Long goods: only timber in play at the moment.

As I wrote before, there may be a lot of industries, but given the size of the map, there actually aren't that many.

I'm making good money now with land transport on this map using stage coaches with a stop in every town. It really is possible.
How - the server game isn't fixed yet??
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 30, 2014, 07:39:56 PM
Wrought iron is long goods. It's not particularly profitable, but it is not the worst either.

Milk and Planks are the most profitable.

In fact, I am half tempted to rename my company "Sea Cow" and pick up more milk chains.



oh, and if anyone is wondering, I won't be doing any pax until rail comes about.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 30, 2014, 07:42:53 PM
locally...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 30, 2014, 08:05:45 PM
Returning for a moment to the bug, deleting Norley Wood does not help: the error merely manifests in a different building. Investigating further...

Edit: Reverting Neroden's changes to dingliste.cc have no effect: exactly the same error occurs.

Edit 2: Using Pak128.Britain-Ex 0.9.0 instead of 0.9.1 makes no difference.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 30, 2014, 09:13:29 PM
Milk and Planks are the most profitable. In fact, I am half tempted to rename my company "Sea Cow" and pick up more milk chains

 ;D

Scanning the islands, there are numerous rather absurd 'opportunities' for long distance milk shipping routes. Indeed the industries are sufficiently-non-interlinked that I could run milk ships full both ways selling milk from east island to the dairies on the west island and vice versa. Presumably the consumers are very discerning and the milk is UHT... :o

Being 1750, dairies are one of the few industries we have a lot of! (and they keep spawning...)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 31, 2014, 12:08:26 AM
After several hours of testing, I can confirm that the crashing on the May/June month boundary does not occur with the previous saved game in 2029. This is, I have to say, very mysterious indeed, and I am struggling to understand what the current saved game has that the previous one does not that might cause this.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 31, 2014, 12:46:59 AM
And why it didn't crash in the first year of the game and only in the second... and why it runs just fine locally.  If I had any coding knowledge at all, I'd be right in there helping.  Thanks for spending/wasting all of your time on this issue  :D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 31, 2014, 02:30:36 AM
is it the same under both 32bit and 64bit operation?


---
actually the game run locally on 64bit crashes in the same exact place as the server does.


---
yeah, so the when I setup a local server and client, both using 32bit, the game went into June just fine, while a 64bit client crashed as soon as June started.

Also, there is something odd about the forest on the server side, but it doesn't seem to affect the client side.

---

64bit client crashed again in July when joining a game that has already progressed beyond the point where it would have normally crashed in June.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 31, 2014, 09:56:43 AM
Thank you both very much for your input, and especially AEO for the testing. May I inquire - what is odd about the forest on the server side?

Edit: Bizarrely, I have now managed to connect with my debug build and neither it nor the server have crashed. It is now June 2:01.

Edit 2: To confirm, the server is now back up. However, I seem to have noticed a pattern. The ability to connect and remain connected appears to occur after connecting to the troubled game and then disconnecting again before getting to the point where it crashes. Last night, while testing with a local server, I accidentally connected to the Bridgewater-Brunel server for a very short time, but disconnected before reaching the month end. I seem to remember something similar happening before the bug mysteriously disappeared last time. That suggests some issue with the save/load code (which might also explain why the viewport has ended up in the middle of the sea on loading rather than next to the island with the name of the server on it. Quite where this problem is, however, is a mystery to me as yet.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 31, 2014, 11:36:44 AM
Thanks James! So we have a work-around. Should we as a precaution leave and reconnect at the very end of Feb, May, Aug, and Nov?

Sadly, I don't seem to be able to change my company's name.

Also I wonder, should I build my roads over existing roads (and have them only open to players I give access to, who'll pay toll), or make new roads?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 31, 2014, 11:51:20 AM
Particularly, the forest is not rendered the same between server and client.
Left: 32 bit client
Middle: 64bit client
Right: 32 bit server
(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans/3waytest_zps65aa50ff.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 31, 2014, 01:23:00 PM
Also I wonder, should I build my roads over existing roads (and have them only open to players I give access to, who'll pay toll), or make new roads?

If you are turnpiking an existing right of way I suggest you would have to give access to all players.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 31, 2014, 01:24:38 PM
If you are turnpiking an existing right of way I suggest you would have to give access to all players.
Fair enough, I won't mind, of course, except sometimes people leave the game etc.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on January 31, 2014, 01:27:53 PM
Particularly, the forest is not rendered the same between server and client.

The positions of individual trees on a tile are not saved; Reduces the size of the save file. This will result in a different look between client/server, or even just saving/loading a game locally. The number of trees on a tile, and their ages is important for client/server sync, and so is saved.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 31, 2014, 01:30:10 PM
The positions of individual trees on a tile are not saved; Reduces the size of the save file. This will result in a different look between client/server, or even just saving/loading a game locally. The number of trees on a tile, and their ages is important for client/server sync, and so is saved.
ah, gotcha. It does look like the server has rows of trees with blank tiles inbetween, where as the clients have all tiles filled, but that explains it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on January 31, 2014, 01:37:53 PM
It keeps crashing at the start of Aug 1751. Is there any point us persisting at the moment?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 31, 2014, 01:39:34 PM
trying the workaround now.

Edit: Alas, to no avail
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on January 31, 2014, 02:57:51 PM
I think I reverted it to the beginning of July, if anyone wants to play.

interestingly, the 64bit client doesn't crash in August when connected to the server, nor locally.

---
Also, there is something odd about this new July... I don't recall connecting at the beginning of July, but the changes I've made are there.
https://dl.dropboxusercontent.com/u/17111233/client2-network_aug.sve
https://dl.dropboxusercontent.com/u/17111233/client1-network_new_july.sve
take a look at convoy (142)'s position between july-august and new july.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 31, 2014, 09:17:25 PM
Kept crashing at the end of September.  I quit the game at 6:23:50, just before it flipped to October, then rejoined and the game resumed at 0:00 October and seems to now be happily progressing in to October without crashing.  I'll try again at the end of October and see what happens (assuming I'm the only player online).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 31, 2014, 09:20:33 PM
End of October should not crash, as this is not a season boundary: the end of November may well crash, as this is the autumn/winter boundary. This is all very odd.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on January 31, 2014, 09:27:19 PM
aye, I had it at July as well. After a few joins it didn't crash. Perhaps it's an end-of-month issue.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 31, 2014, 09:35:20 PM
The saved game that I downloaded from the server at the end of September appears to be corrupted. The error occurs in loading the tiles. Loading of tiles comes shortly after loading towns, as is seen in this segment of code:

Code: [Select]
DBG_DEBUG("karte_t::laden", "init %i cities", settings.get_anzahl_staedte());
   stadt.clear();
   stadt.resize(settings.get_anzahl_staedte());
   for (int i = 0; i < settings.get_anzahl_staedte(); ++i) {
      stadt_t *s = new stadt_t(this, file);
      stadt.append( s, s->get_einwohner());
   }

   DBG_MESSAGE("karte_t::laden()","loading blocks");
   old_blockmanager_t::rdwr(this, file);

   DBG_MESSAGE("karte_t::laden()","loading tiles");
   for (int y = 0; y < get_size().y; y++) {
      for (int x = 0; x < get_size().x; x++) {
         plan[x+y*cached_grid_size.x].rdwr(this, file, koord(x,y) );
      }
      if(file->is_eof()) {
         dbg->fatal("karte_t::laden()","Savegame file mangled (too short)!");
      }
      ls.set_progress( y/2 );
   }

Edit: The same result obtains in the 32-bit version.

Edit 2: It seems that it is a month thing rather than a season thing after all, as it crashed on the October/November boundary, which does not involve a season change.

Edit 3: It seems that this issue is not confined to the command line server: a normal client with graphics running as a server will also fail in the same way, and will, interestingly, give dialogue box warnings about heap corruption just before crashing, too.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 31, 2014, 10:53:52 PM
Quote
Edit: It seems that it is a month thing rather than a season thing after all, as it crashed on the October/November boundary, which does not involve a season change.

So it seems.  At least we know we can advance it a month by jumping off the server just a moment before the month ends.

EDIT: I  jumped off at 6:23:50 in October and then rejoined.  The server didn't crash but when I rejoined it was now October 0:00... but everything that was done before the end of October was still there: new construction, new ships, ship positions and on the finances it still had all of October's revenue and profits listed as current month.  But new we get to enjoy the month of October all over again...
The fact that it won't crash when the clients drop off is an interesting point.  Quitting just before the month-end will not make the server recognize that I've lost connection yet, I assume, so it will still advance the clock and not pause until it detects that I am gone.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 31, 2014, 11:17:03 PM
I think what happens is that it crashes shortly after the season change. If you manage to get it to run a load/save cycle after the season change but before it crashes, it does not crash.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 12:03:48 AM
Can anyone explain why I have 7 passengers at 6724,1182 wanting to travel the entire width of the map, and yet if I link (in offline testing) the two islands' stagecoach networks with a ferry, nobody uses it??
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 01, 2014, 12:21:42 AM
That will be the distance ranges: some passengers wanting to travel long distances are willing to travel a very long time, whereas all passengers wanting to travel a shorter distance always have a lower journey time tolerance. This system will be abolished entirely in the next major release.

Edit: Returning to the bug issue: I have managed to set it up reliably to reproduce the bug without running a server/client arrangement: running the x64 debug build on the current 11.x branch with the saved game from just on the May/June border, loading the game and running it produces no crash; but loading it once again causes it reliably to crash at about 0:27 in June in line 317 of grund.h.

Interestingly, running this game with the 112.5-merge branch, I get a different crash in the same place, one relating to citycars, which seems to be similar to the occasional citycar crash that I had had before and had seemed random. It is not immediately clear whether the two are connected, but I do get rather a lot of heap corruption warnings running it on the 112.5-merge branch after a month boundary on any recent saved game from the server.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 12:49:40 AM
Who is controlling the blue player "Siren/Atlach-Nacha". They seem to be raking in the profit, and I'm not entirely clear how...

Looking at the lines, they all have a "wait for 20% load" order on the supplier, which is lower than I'd expect. Is this somehow advantageous??
The lines are also in several instances quite short.
Many of the docks are also mostly one-tile in spite of the lines using ships that ask for 3-tile docks, so the infrastructure maintenance is low.

I would have thought short lines with mostly empty ships would lead to low profits... would be interested to understand what the trick is here!

Also, the lines use no waypoints at sea, which is odd given the trouble I've had without them.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 01, 2014, 12:58:50 AM
It's the long-haul milk lines which generate excessive profit, I'm not sure if this is realistic, or requires urgent balancing...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 01:03:17 AM
But I have a couple of those too, and I'm not seeing "excessive profits". That's what puzzles me.

If anything, I'm having the opposite problems; long-haul lines mean you only intermittently receive income, you have many 'dry' months.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 01, 2014, 01:08:03 AM
yes, but if notice his milk line 43 had 960 units hauled last month, which made a spike of a profit of 143000.

There is also an anomaly with revnue, I've seen it in the previous game too, and now if you look at my line 47 you'll see a great spike of 8000 for a stage coach line some months ago, that shouldn't be... If it happens again I'll report it in a bug thread. So could be the case here with the milk, the profit does seem excessive even for a long haul milk line. Maybe it has to do with the detrimental stop near the coal mine on that line.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 01, 2014, 01:56:14 AM
It's AEO... I run some of my lines down near 20% as well, depending on what I am hauling.  Milk is very profitable but so are other commodities as well.  The key is to have enough routes/lines so that you can even out the intermittent revenue you get from any single line.  My profits are becoming rather significant now too.  I should be over 100k per month within a year.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 01, 2014, 01:57:56 AM
still, it's strange that he would get 143000 from transporting 960 units in one month on any distance.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 01, 2014, 02:51:49 AM
Not really, those long distance routes are very profitable, it just takes a long time to complete the journey.  I have several routes that will pay 50-100k per delivery of 450 units per arrival (milk, clothes), I'm just still 6+ months away from realizing those profits on a regular rotation (most long distance routes arrive every 2-3 months).  Some of these routes take an entire game year to complete their first journey, plus another 1-2 months to fill the first ship up to capacity.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 01, 2014, 05:34:50 AM
usually those milk lines pull in 15k~25k, but 145k!?

wow...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 01, 2014, 09:13:53 AM
some new towns were built with a bridleway connecting them. However the latter cannot be upgraded by players - might I request they be upgraded?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 12:06:54 PM
yes, but if notice his milk line 43 had 960 units hauled last month, which made a spike of a profit of 143000.
I know you could stockpile the milk so move a lot all at once (on a big ship).

However, some of the cattle farms seem to be producing vastly more units than others, and more than they say they would. Mine are producing up to 2-300 units per month, the one on Blue's line 43 has been producing up to 580 units/month (according to the farm's graph, and contrary to what the farm's info page says). I know from the industry list there should be slight variety but nothing as high as 580 (highest is 426).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 01, 2014, 12:24:00 PM
I am not sure, but I think factories with frequent service receive upgrades more easily.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 01, 2014, 12:25:42 PM
at any rate, I do think those cargo shipping revenues need balancing, don't you agree? or is it quite realistic?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 01, 2014, 12:26:44 PM
oh, yeah, definitely.

Even with one cargo hold, they are super profitable.
It's mainly because the sea is free to traverse.

---

The dogger seems to be a good ship to balance against for all early ships.

$0.62/km for 8 live fish ($0.37)
It's not super profitable, but does rake in $1000 or so for a round trip that costs roughly $450
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 12:37:08 PM
I am not sure, but I think factories with frequent service receive upgrades more easily.

Can anyone confirm this - that productivity of an industry relates to number of convoys per month somehow? I would have thought that having a single ship waiting for 100% load, or a large warehouse at the adjacent cargo stop, would have been just as good.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 01, 2014, 01:04:42 PM
I am not ignoring your balancing comments, incidentally, which are very useful, but I am concentrating on trying to fix the crash bug for the time being. I have now been able to reproduce this issue on a 32-bit local build using the May/June 1751 month boundary (when loaded twice). This enables me to run Dr. Memory, which produces the following output:

Code: [Select]
Dr. Memory version 1.6.1 build 2 built on Dec 14 2013 12:27:10
Dr. Memory results for pid 9832: "Simutrans-Experimental-debug.exe"
Application cmdline: "C:\Users\James\Documents\Development\Simutrans\simutrans-experimental-sources\simutrans\Simutrans-Experimental-debug.exe"
Recorded 99 suppression(s) from default C:\Program Files (x86)\Dr. Memory\bin\suppress-default.txt

Error #1: UNADDRESSABLE ACCESS: writing 0x098d0684-0x098d0688 4 byte(s)
# 0 stadtauto_t::set_list               [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\vehicle\simverkehr.h:178]
# 1 karte_t::new_month                  [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:3833]
# 2 karte_t::step                       [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:4144]
# 3 karte_t::interactive                [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:7327]
# 4 simu_main                           [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simmain.cc:1259]
# 5 sysmain                             [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys.cc:703]
# 6 WinMain                             [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys_w.cc:731]
Note: @0:02:18.237 in thread 11796
Note: refers to 8 bytes(s) beyond last valid byte in prior malloc
Note: prev lower malloc: 0x098d0638-0x098d067c here:
Note: # 0 replace_operator_new                               [d:\drmemory_package\common\alloc_replace.c:2421]
Note: # 1 grund_t::rdwr                                      [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\boden\grund.cc:264]
Note: # 2 boden_t::boden_t                                   [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\boden\boden.cc:23]
Note: # 3 planquadrat_t::rdwr                                [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simplan.cc:259]
Note: # 4 karte_t::load                                      [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:5715]
Note: # 5 karte_t::load                                      [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:5290]
Note: # 6 loadsave_frame_t::action                           [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\loadsave_frame.cc:77]
Note: # 7 savegame_frame_t::action_triggered                 [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\savegame_frame.cc:375]
Note: # 8 gui_action_creator_t::call_listeners               [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_action_creator.h:36]
Note: # 9 gui_table_t::infowin_event                         [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_table.cc:147]
Note: #10 gui_scrollpane_t::infowin_event                    [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_scrollpane.cc:112]
Note: #11 gui_container_t::infowin_event                     [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\gui_container.cc:183]
Note: instruction: mov    %ecx -> 0x5c(%eax)

Edit: Running the game again without loading twice, the only useful Dr. Memory output is the below, which is also a crash. Other outputs suggest minor leaks present in code unchanged from Standard that have been present for a long time. There does not seem to be any output actually trapping a double free despite me having commented out the code for using freelist with citycars.

Code: [Select]
Error #1: UNADDRESSABLE ACCESS: writing 0x0ab96db4-0x0ab96db8 4 byte(s)
# 0 stadtauto_t::set_list               [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\vehicle\simverkehr.h:178]
# 1 karte_t::new_month                  [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:3833]
# 2 karte_t::step                       [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:4144]
# 3 karte_t::interactive                [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:7327]
# 4 simu_main                           [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simmain.cc:1259]
# 5 sysmain                             [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys.cc:703]
# 6 WinMain                             [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys_w.cc:731]
Note: @0:02:23.361 in thread 1876
Note: refers to 4 bytes(s) beyond last valid byte in prior malloc
Note: prev lower malloc: 0x0ab96da0-0x0ab96db0 here:
Note: # 0 replace_operator_new_array                             [d:\drmemory_package\common\alloc_replace.c:2450]
Note: # 1 minivec_tpl<gebaeude_t *>::resize                      [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\tpl\minivec_tpl.h:43]
Note: # 2 minivec_tpl<gebaeude_t *>::append                      [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\tpl\minivec_tpl.h:70]
Note: # 3 minivec_tpl<gebaeude_t *>::append_unique               [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\tpl\minivec_tpl.h:79]
Note: # 4 gebaeude_t::check_road_tiles                           [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\dings\gebaeude.cc:249]
Note: # 5 karte_t::load                                          [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:6132]
Note: # 6 karte_t::load                                          [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:5290]
Note: # 7 loadsave_frame_t::action                               [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\loadsave_frame.cc:77]
Note: # 8 savegame_frame_t::action_triggered                     [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\savegame_frame.cc:375]
Note: # 9 gui_action_creator_t::call_listeners                   [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_action_creator.h:36]
Note: #10 gui_table_t::infowin_event                             [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_table.cc:147]
Note: #11 gui_scrollpane_t::infowin_event                        [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\gui\components\gui_scrollpane.cc:112]
Note: instruction: mov    %ecx -> 0x5c(%eax)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 01, 2014, 02:53:27 PM
could it possibly be linked to the larger map sizes?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 03:01:44 PM
I am not ignoring your balancing comments, incidentally, which are very useful, but I am concentrating on trying to fix the crash bug for the time being.

Entirely reasonable, was assuming as much :) . Unfortunately it's well outside my expertise to help with.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 01, 2014, 04:16:05 PM
could it possibly be linked to the larger map sizes?

It is conceivable, but that is very hard to test.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 01, 2014, 06:04:24 PM
Server is down?

Edit: back now. Might have been my internet...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 02, 2014, 02:27:16 AM
Over 1,000 convoys and counting... many of which are long haul shipping routes.

Really enjoying this, even with the added maintenance of manually skipping the months ahead.  I'm done with major expansions now, I'll leave the rest for other players (as much as I am fighting the urge to continue to expand).  I should be generating more than enough profits for future projects.  I want to build a canal on the eastern island soon.

I am keeping a running list of bugs/issues that I will share after I research a few of them.


(http://www.ssgholdings.ca/simutrans/images/many-boats.jpg)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 02, 2014, 06:10:22 AM
I would save up.
Terra-forming, cutting through cities and laying down rail in 1827 costs an amazing amount of money.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 09:45:05 AM
I'm done with major expansions now, I'll leave the rest for other players.  I should be generating more than enough profits for future projects.

Same here. :) I may pick up a few short routes because the income peaks/troughs are still troubling me (it's because I'm not actually operating very many ships/lines: compare the companies' asset values).

I can't get my monthly income up to match Pacific Transport / Siren/Atlach-Nacha, in spite of trying (not enough lucrative industries left to connect), so I suspect those two will be ahead come 1840* by a substantial margin (compound interest etc).

Will be interested to see how the newer players build up their capital.

(*I'm assuming rail in 1827 is as unprofitable as before... until the faster locos arrive)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 02, 2014, 10:36:05 AM
Did you steal my textiles routes for Gorchester on purpose?  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 10:39:24 AM
Maybe... all those crates were sitting there undelivered, and I was running a piece goods ship over to the other island anyway, from the furniture factory next door ;)

Although it might have happened anyway as I had connected at least one other textile mill/ clothes shop into my 'piece-goods' route already. Most of my routes have many stops so industry cross-linking can sort itself out...
 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 02, 2014, 10:41:57 AM
Actually, AP, you definitely grow faster than I do.
My S/AN is 3rd place in growth.

Probably has something to do with infrastructure maintenance and your two-way milk routes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 10:45:18 AM
Actually, AP, you definitely grow faster than I do.
My S/AN is 3rd place in growth.

Probably has something to do with infrastructure maintenance and your two-way milk routes.
That's changed since I fast-forwarded a local save last night then  ??? . Make sure you compare year on year not month on month - as I say, my income is very uneven due to having fewer ships, some months are very lean  :-[ .

Most of my routes were two way (esp. the bulk routes) from the beginning, it definitely helps, I was pleased with that, at least.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 02, 2014, 10:47:46 AM
I've been supplying the wool to the textile mill and shipping out the clothing.  There are some weird bugs happening with freight, the textiles sat seized up for many months after a bunch of successful deliveries - I couldn't figure out what was going on and am trying different experiments to figure it out.  It's related to the in transit and storage limits, it creates really odd pulses of activity and long pauses which drives down your overall production to around 50%.

Now my boats are sitting idle as for some reason the game has decided that you should get 100% of the cargo and not my ships... which is weird and not overly sporting of you  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 02, 2014, 11:47:02 AM
you wait, my pax endeavor will outgrow you all! evil grin.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 02, 2014, 11:59:00 AM
asaph, you can use my mail docks for a west side pax expansion.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 03:49:33 PM
Now my boats are sitting idle as for some reason the game has decided that you should get 100% of the cargo and not my ships... which is weird and not overly sporting of you  ;)

That is odd. I expected it to pick up any surplus, not steal everything.  ??? Wonder why its done that?

Am running around today pretty busy, but will see if I can look at fixing it later tonight/tomorrow. Now I've built roads to the clothes shop I suppose I'll have to find another textile mill to pay for them instead.


you wait, my pax endeavor will outgrow you all! evil grin.

I tried in offline testing, but couldn't get passengers to make much of a profit.  :-[ I think it was because everything is so slow, so nobody travels far.  I hope you have more luck (am watching with interest!)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 02, 2014, 04:01:49 PM
I think that I have now found and fixed the bug causing instability: like many of these bugs, it was fixed by a single line of code, but tracking it down has taken a long time. What was happening was that, when a game was loaded, the city cars in the "unassigned" list (that is, not associated with a particular town) were deleted, but were not removed from that list, so that, when at the end of the month the list was checked to make sure that there were not too many city cars, memory locations that had already been deleted would be deleted again causing memory corruption and instability. My tests so far have shown the game to be stable with the fix applied.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 04:08:09 PM
Fingers crossed, and many thanks James for the effort.  :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 02, 2014, 04:34:14 PM
Hmm - further testing shows that some heap corruption is still present in some cases, but it is not clear how often that this will occur or what effect that it might have on the server game.

I should also note that the error that I fixed was capable of causing desyncs as well as heap corruption.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 02, 2014, 04:44:32 PM
splendid news!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 02, 2014, 06:04:25 PM
Wonderful!  Thank you for putting all those hours of frustrating bug hunting in to finding and squashing this one... hopefully it does the trick :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 02, 2014, 08:35:34 PM
That is odd. I expected it to pick up any surplus, not steal everything.  ??? Wonder why its done that?

Am running around today pretty busy, but will see if I can look at fixing it later tonight/tomorrow. Now I've built roads to the clothes shop I suppose I'll have to find another textile mill to pay for them instead.

Well I fixed it, but the server looks to have crashed and reverted at the end of May, so it was lost. If it can't be recovered, will try again tomorrow.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 02, 2014, 10:09:25 PM
Server restarted with version 11.18. Error in the initial message concerning the pakset vesrion corrected (it had erroneously given the version as 0.9.0). A new note added concerning allowing access to other players if public roads and rivers are upgraded.

I hope that this version works rather better - sorry for the troubles before.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on February 05, 2014, 10:38:47 AM
Ah.. people are making a large sum of profit while I already managed to bankrupt a company..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 05, 2014, 11:11:33 AM
Ah.. people are making a large sum of profit while I already managed to bankrupt a company..

Don't worry about that - learn from your mistakes and have another go! That is what real life businesspeople do, after all...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 05, 2014, 06:32:12 PM
How much of a resource drain are city cars?  There must be thousands on the map... some cities have 50+ city cars all circling around.  A quick guess puts it at an average of 20 cars per city x 400 cities = 8,000 city cars.  It actually could be significantly more than this, 8,000 is probably a conservative estimate.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on February 05, 2014, 07:21:07 PM
Don't worry about that - learn from your mistakes and have another go! That is what real life businesspeople do, after all...

Though, how often was a railway company's entire infrastructure lost when the company went belly-up? I'm guessing it wasn't too frequent, except those times when the company was taken over by a competitor and the competing route was closed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 05, 2014, 08:01:38 PM
Ah.. people are making a large sum of profit while I already managed to bankrupt a company..

I bankrupted my first one with 24h of starting.  ;D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 05, 2014, 08:25:14 PM
Though, how often was a railway company's entire infrastructure lost when the company went belly-up? I'm guessing it wasn't too frequent, except those times when the company was taken over by a competitor and the competing route was closed.

IRL, some questionable companies would set up another company to fund a line. When the line was built, these companies would mysteriously go belly up and be bought at a nice discount by the parent railway company.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 05, 2014, 08:37:42 PM
Though, how often was a railway company's entire infrastructure lost when the company went belly-up? I'm guessing it wasn't too frequent, except those times when the company was taken over by a competitor and the competing route was closed.

I do eventually plan to have a more sophisticated system of dealing with assets of insolvent companies.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 05, 2014, 09:07:59 PM
Anyone know what's up with the server game??? I just had several lines lose all their stops and waypoints for no reason, dozens of vehicles teleporting to depot. My lines 124 and 126 definitely affected. I just compared with a savegame from yesterday, the lines were definitely ok before.

Have logged off for fear of doing more damage!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 05, 2014, 09:18:39 PM
I had that happen a few game years ago... all of my non-line convoys lost their stops and went to depot.  Only my lines remained intact.  It may have been related to adding access for other players, it happened around the same time.  I had this happen a month or two ago during a local game as well, I wasn't able to find out why it occurred.

It was a massive undertaking to reschedule everything.  My sympathies.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on February 05, 2014, 09:19:59 PM
Anyone know what's up with the server game??? I just had several lines lose all their stops and waypoints for no reason, dozens of vehicles teleporting to depot. My lines 124 and 126 definitely affected. I just compared with a savegame from yesterday, the lines were definitely ok before.

Have logged off for fear of doing more damage!

It seems to happen when I play around the access button.. Sorry.
But the thing is that you seems to be using only one of my stops,
but other routes are affected too, so that's likely to be a bug.

I do eventually plan to have a more sophisticated system of dealing with assets of insolvent companies.
What about the infrastructure being take over by the government(even though it's bankrupt...)
and others have to pay a fee to use the belly-up infrastructure?

Also a company take-over system sound fun too.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 05, 2014, 09:27:11 PM
But the thing is that you seems to be using only one of my stops,
Which stop?? I wasn't aware I was using any stops other than my own.  Is it a stop that has been built on a tile I previously used as a waypoint?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on February 05, 2014, 09:30:42 PM
Which stop?? I wasn't aware I was using any stops other than my own.  Is it a stop that has been built on a tile I previously used as a waypoint?
Berryington Promenade Street dock
Your (110) Timber to west seems to be using my stop..
It might be.. But when I first built the stop there is no other route serving the stop (the station property)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 06, 2014, 06:54:06 PM
What is the server load like now?  I am starting to get more disconnects/desynchs from the game and it is becoming less responsive to new construction (sometimes it's a 5 second wait between doing something and seeing it happen).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 06, 2014, 08:02:05 PM
I can still get 25x in fast forward, although that is a long cry from 400x in 1752.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 06, 2014, 08:49:10 PM
Berryington Promenade Street dock
Your (110) Timber to west seems to be using my stop..
It might be.. But when I first built the stop there is no other route serving the stop (the station property)

Yes, it's right by the river mouth, I had a waypoint on that tile.

Am also having the slight lag issues...


Am I the only one who thinks this whole canals-for-passenger-traffic thing is getting a bit silly?  :o
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 06, 2014, 09:40:37 PM
The CPU load is currently 36.7%, so it is doubtful that the CPU load is causing the issue. Lag is likely to be caused when the server runs more quickly than the client, or there are network latency issues; if the client runs faster than the server, this will result in a desync, and although the code is meant to keep the client going no faster than the server, this may not happen when the server is under very severe strain.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 07, 2014, 04:57:08 AM
I can still get 25x on my local copy as well.

It may be related to our relative distance in the world, given that I am half a world away from the server.  I imagine that as the map gains in complexity there will be more and more data sent between client and server which may impact on desynch issues.  How much of a drain do you figure private cars are?  There are thousands on the map... and I'd imagine that that data has to be sent on a regular basis from server to client.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 07, 2014, 10:27:37 PM
The amount of data sent, except when saving and loading, is actually quite limited: for any given saved game (run in online mode), the game is essentially deterministic (the random seed is shared, so even things based on random number generation will be the same between client and server). Most of the data sent are regular check packets to ensure that the client and server remain in sync, and, of course, any commands or chat messages sent by any player have to be propagated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 07, 2014, 11:50:49 PM
Ah, interesting.  I didn't realize that it was built in that fashion.  So the movement of city cars is generated locally but kept synchronized with other players by using the same random number seed.  Good to know.

Many of my desynchs seem to happen while I am constructing new projects.  I build something, wait 5+ seconds for a response of the build from the server and then build the next thing.  If I queue up several projects in a row before I receive confirmation of the first one, I almost always desynch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 07, 2014, 11:55:43 PM
Ahh, that sort of desync could well be caused by latency - I think that you need to wait for one command to complete before executing the next.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 08, 2014, 12:12:34 AM
I do.  If I don't it's a guaranteed desynch.  :)

Ping time to server is 150ms... not huge, I wouldn't think it would cause desynchs, especially if the amount of data transferred is small.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 08, 2014, 03:58:42 PM
Could it be a PC speed issue? My PC isn't the newest... which didn't give me concern until now but the map is quickly getting filled with activity, I wonder if it will be an issue going forward.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 08, 2014, 04:05:28 PM
If your computer is too slow, you will lag behind the server, and so get increasing latency the longer that you are connected.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 08, 2014, 05:33:01 PM
My computer can easily handle the map... and still accelerates to near 30x in offline play.  It seems far more likely to desynch when I'm building things, setting schedules, etc.  If I am just passively watching the game, it does desynch now and then but not nearly as often.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 08, 2014, 06:54:00 PM
Interaction desyncs seem more common than passive desyncs generally - I believe that this is the case in Standard, too.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 01:06:28 AM
I connected just to take a look, my client timing is being jerked all over the place by erratic time check packets from the server. I highly doubt I would be able to maintain connection if anyone else was online performing any commands; My client is frequently hundreds of ms ahead of the server. I've never seen this before - log example:
Code: [Select]
Message: NWC_CHECK: time difference to server 5
Warning: karte_t::interactive: sync_step=576768  server=[rand=1903003556 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971487] client=[rand=1903003556 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971487]
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[468]
Message: NWC_CHECK: time difference to server -1075
Warning: karte_t::interactive: sync_step=576775  server=[rand=3362342101 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971486] client=[rand=3362342101 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971486]
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[468]
Message: NWC_CHECK: time difference to server 218
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[468]
Message: NWC_CHECK: time difference to server 414
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[468]
Message: NWC_CHECK: time difference to server 628
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[468]
Message: NWC_CHECK: time difference to server 840
Warning: karte_t::interactive: sync_step=576780  server=[rand=42489301 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971485] client=[rand=42489301 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971485]
Warning: karte_t::interactive: sync_step=576785  server=[rand=734433582 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971482] client=[rand=734433582 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971482]
Warning: karte_t::interactive: sync_step=576790  server=[rand=2510892483 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971481] client=[rand=2510892483 halt=1 line=1 cnvy=1025 ind_dns_prop=3816 act_ind_dens=6928 traffic=1971481] 
The karte_t::interactive message should always immediately follow the NWC_CHECK: message.
And the sync_step= value should be spaced based on the servers server_frames_between_checks and frames_per_second setting. There should never be timing checks 5 syncs apart, and never a consistent 5 like that.
I also note the erroneous NWC_CHECKS are always spaced ~200ms apart.
I have verified with Wireshark that my client is indeed receiving these NWC_CHECK messages inappropriately. And in ~200ms spaced bursts.
A local test server runs things just fine. No timing anomalies seen by clients.

Can you check the packets being sent by the server? confirm these bursts of NWC_CHECKs.
Can you provide the simuconf.tab from the server? with the default settings, I can't duplicate locally.
I really have no clue what could be causing this.



There's also some other errors showing in the client log for the game:
Code: [Select]
Message: hashtable_tpl::put: Duplicate hash!
Message: hashtable_tpl::put: Duplicate hash!
Message: hashtable_tpl::put: Duplicate hash!
<snip thousands and thousands of these>

ERROR: haltestelle_t::starte_mit_route(): route cannot contain us as first transfer stop => recalc route!
For help with this error or to file a bug report please see the Simutrans forum:
http://forum.simutrans.com
<and hundreds of these>

Warning: sint64 convoi_t::calc_revenue: Average speed (23) for (null) exceeded maximum speed (977488149); falling back to overall average
Warning: sint64 convoi_t::calc_revenue: Average speed (23) for (null) exceeded maximum speed (977488149); falling back to overall average
Warning: sint64 convoi_t::calc_revenue: Average speed (23) for (null) exceeded maximum speed (977488149); falling back to overall average
<and just a few of these>
not likely relevant to the sync issue, but still errors.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 01:22:49 AM
Thank you very much for this analysis: this is most useful. Here (http://www.bridgewater-brunel.me.uk/downloads/simuconf.tab) is a link to the base simuconf.tab - do you need the pakset simuconf.tab, too? It is unaltered from the default for Pak128.Britian-Ex.

How do I go about checking the packets being sent by the server?

As to the client errors/warnings, the duplicate hashes, are, if I recall correctly, not necessarily erroneous, as I do recall writing some code which would put values into a hashtable in the expectation that there might be a duplicate. The calc_revenue problems I have found somewhat intractable, which is why we have the workaround of the overall average (in some cases, this might be related to integer overflows). The middle of these errors is not one with which I am familiar, and it is not immediately obvious whether this is an indication of the programme not acting correctly.

In any event, thank you again for testing this - this is much appreciated. I should be most interested in any comments on the simuconf.tab file and how to check the packets.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 02:12:19 AM
I just repeated the test locally with your server config. No timing issues encountered, as expected since the values aren't that far off default.

Why change server_frames_ahead? The default should be fine, or even reduced. You're adding an extra 170ms latency to every client, even if they don't need it. If clients are ending up with 'execute in past' desyncs, they should adjust additional_client_frames_behind instead. That way clients with good connections aren't penalized.

server_frames_between_checks = 256 is the default, but IMHO way too long. At 12 fps that's 21s between checks, a client could run way ahead in that time... I would drop that to 24-48 frames. A time check packet is a mere 98 bytes, times the number of connected clients, even once second, is still a bandwidth pittance.

I presume you changed server_frames_per_step to reduce CPU load? A setting of 5 and 12 fps is equivalent to 2.4 simloops. Offline the simloops target is 5.0. 2.4 isn't horrible, but things would be more responsive if you put frames_per_step back to 3 or 4. At the cost of extra CPU load of course.

For checking packets, try Wireshark or Tshark, or even good 'ole tcpdump would do.

Also, if any other players could post their logs  ( simu.log after running 'simutrans-experimental -debug 3 -log' ), that could confirm it's not just me seeing this. I can't 100% rule out something with my internet connection, although I had a steady 111-113ms ping to the server the whole time during my test.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 05:41:51 AM
the command to use tcpdump would be 'tcpdump -i eth0 -w filename.cap' (you can also use filters to reduce the size of the file)

I also experience lag, though only sometimes, intermittently and it passes. I have quite a strong i5 and lots of RAM, and a stable wired connection with 77 ms to the server.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 11:26:39 AM
I just repeated the test locally with your server config. No timing issues encountered, as expected since the values aren't that far off default.

Hmm - very curious. I don't suppose that it could have anything to do with the client being multi-threaded and the server single threaded, could it?

Quote
Why change server_frames_ahead? The default should be fine, or even reduced. You're adding an extra 170ms latency to every client, even if they don't need it. If clients are ending up with 'execute in past' desyncs, they should adjust additional_client_frames_behind instead. That way clients with good connections aren't penalized.

I had adjusted this some time ago, having found that clients were disconnecting often with the previous setting. Do you notice an unacceptable degree of latency? I could try to adjust this downwards if you think that it would help.

Quote
server_frames_between_checks = 256 is the default, but IMHO way too long. At 12 fps that's 21s between checks, a client could run way ahead in that time... I would drop that to 24-48 frames. A time check packet is a mere 98 bytes, times the number of connected clients, even once second, is still a bandwidth pittance.

Ahh, interesting - would increasing this value be likely to reduce desyncs due to the client running ahead?

Quote
I presume you changed server_frames_per_step to reduce CPU load? A setting of 5 and 12 fps is equivalent to 2.4 simloops. Offline the simloops target is 5.0. 2.4 isn't horrible, but things would be more responsive if you put frames_per_step back to 3 or 4. At the cost of extra CPU load of course.

This was indeed to reduce CPU load: the current game is in the fairly early stages, and the load is not too intense. I found that a well developed game in the 20th century on a map of this size could have really very high CPU usage that could cause desyncs due to the server running behind the client (presumably) and unresponsiveness without this setting being lowered. That being said, there have been one or two changes to make the code more efficient since then, but I do not know whether that will be enough to allow a higher setting of this value.

Quote
For checking packets, try Wireshark or Tshark, or even good 'ole tcpdump would do.

Hmm - I am not familiar with these tools: do I need to restart the executable and attach one of these to the process somehow, as with gdb, or are they independent packet sniffers of some sort?

Thank you very much for your investigations here - most helpful.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 09, 2014, 12:53:25 PM
Something seems very off with the city growth, we have vast urban sprawl with little or no urban transport. Either that or the cities started off far too close together for the growth settings.

By the time we get to rail, there are going to be no corridors left between towns.

Am also concerned that exclusively-passenger-services via canal seems to be profitable. Canals were mainly built for freight.

--

On an unrelated matter. The maintenance costs on the tool buttons in brackets e.g. Bridleway (1.6), what time base is that over? And how many of those units in a game-month? E.g. if I build a bridleway 10 tiles long, I should be able to calculate monthly maintenance ahead of time somehow and relate it to operating profit.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 01:15:13 PM
The high rate of city growth is a known issue: the maximum rate should be set to be a percentage of the total size. In Standard, and much earlier versions of Experimental, town growth would not occur without player transport. In more recent versions of Experimental, passengers can get to their destinations by walking alone, and this prompts town growth, whose rate is too high (the current system was not designed for a very long game). I tried to adjust this downwards for the pakset release in simuconf.tab, but evidently did not adjust it enough. Town growth will be looked at for the next major release.

As to the profitability of canal services, there were indeed passenger services by canal, so this should not automatically be unprofitable. However, the construction and maintenance costs of the ship canals necessary to support the Thames sailing barges currently used on the canals should be such that using those canals only or mainly for passengers should not be profitable. I should note that the pakset is not balanced yet.

As to the maintenance costs, these are monthly.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 05:22:48 PM

Hmm - I am not familiar with these tools: do I need to restart the executable and attach one of these to the process somehow, as with gdb, or are they independent packet sniffers of some sort?


This is a separate process, you run alongside the game executable (as it transmits and receives packets:)

the command to use tcpdump would be 'tcpdump -i eth0 -w filename.cap' (you can also use filters to reduce the size of the file)

where filename.cap is a file you can then open on your computer using wireshark (which I believe is free), and allows you to analyze the packets transmitted or received by the server during the running of tcpdump.

"eth0" might be replaced with the interface name through which the default route goes. route -n show show all the routes, then use the interface name stated in the route of 0.0.0.0 (that's the default route).

I think it can only be run under root. Of course I'll gladly help doing this, but I'll need the root password for that (you can always change it later :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 05:44:35 PM
Hmm - very curious. I don't suppose that it could have anything to do with the client being multi-threaded and the server single threaded, could it?
Unlikely. Unless there's been extra multithreading code added to Experimental over that in Standard which is not yet multithreading any of the simulation related stuff. Experimental appears to still be missing the multithreaded drawing that was added to Standard last year, would be a big help to those running higher resolutions and with multi core processors - frees up a lot of CPU time to spend on the simulation instead of drawing...


I had adjusted this some time ago, having found that clients were disconnecting often with the previous setting. Do you notice an unacceptable degree of latency? I could try to adjust this downwards if you think that it would help.
I do find the latency on this server more noticeable than others, bordering the annoying actually. From what I can tell, the server has a solid internet connection. I'm at the mercy of the usually unstable trans-atlantic links, and still am getting a rock steady 112 +/- 1ms ping. Hence if clients are discoing, they need to fix their connection and/or adjust their client settings for more margin (assuming of course we find/fix this timing anomaly I've found - nobody experiencing this will stay connected long when others are online and building things). Changing the server settings needlessly penalizes those with good connections.



Ahh, interesting - would increasing this value be likely to reduce desyncs due to the client running ahead?
Decreasing would be an idea. I thought we'd discussed this before... yes we did - see  Simutrans-Experimental - Pak128.Britain-Ex 0.8.4 server perfomance  (http://forum.simutrans.com/index.php?topic=11079.0).


This was indeed to reduce CPU load: the current game is in the fairly early stages, and the load is not too intense.
I'd be tempted to put it back to the default 4, atleast once past the crazy boat era in the game. IIRC that was the peak CPU usage during the last game. Would help the responsiveness getting the simloops back up a bit. Ideally this setting and all the others would be dynamically adjusted - another item on the long term todo list - and as usual if somebody else were to get there first...  ;)


Hmm - I am not familiar with these tools: do I need to restart the executable and attach one of these to the process somehow, as with gdb, or are they independent packet sniffers of some sort?
asaphxiix has provided good info. If you have GUI access to your server, Wireshark might be the easiest for you to use. Ideally you'd do the capture when you're the only client connected, and your client is idle (not sending commands). Otherwise filter the capture to just the traffic to a single client. Even better capture the server sent packets, client received packets, and client log all at once.

First though, I'd like to see a log from anybody else showing the NWC_CHECKs - especially the 5 frame progression that should not be there. Mine run normally for minutes, then receives a burst of NWC_CHECKs, then back to normal for a while. Every burst throws my client timing way off, and if anybody else is online doing commands - disconnect.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 05:46:07 PM
how can this log be found?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 05:47:56 PM
Run your client with '-debug 3 -log' command line args.
simu.log will be created which is the log.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 05:57:26 PM
plenty of those. the time difference initially grows up to 8000, then I think the pause ends, and there are a bunch of

Warning: karte_t::interactive:   sync_step=1359430

and then the NWC_CHECK starts slowly to decrease to zero, going negative, reaching -354 even, and then back to up to 8000, and dwindles in that range. so it's quite unstable, but this could be normal and seems to react positively to the sync_steps.

Log: http://www.filedropper.com/simu-copy
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 06:01:03 PM
See my log in post #137. I'm looking for somebody else experiencing a burst of NWC_CHECK messages in a row, and then followed by the interactive messages with sync_step= counting up by 5. Or any other anomalies. Each NWC_CHECK should be immediately followed by an interactive message with sync_step counting up by 256 (for the current server settings).

EDIT: you edited to post your log while I was posting. It does indeed contain the problem I'm seeing. Now for James to obtain the server side of things...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 06:08:12 PM
Yes I have those too I believe. You can see also in the file I posted last message.

Message: NWC_CHECK:   time difference to server 7476
Warning: karte_t::interactive:   sync_step=1365615  server=[rand=1827315087 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351262] client=[rand=1827315087 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351262]
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[480]
Message: NWC_CHECK:   time difference to server 7582
Warning: karte_t::interactive:   sync_step=1365620  server=[rand=3168147781 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351261] client=[rand=3168147781 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351261]
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[480]
Message: NWC_CHECK:   time difference to server 7790
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[480]
Message: NWC_CHECK:   time difference to server 7917
Warning: karte_t::interactive:   sync_step=1365625  server=[rand=2912924728 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351263] client=[rand=2912924728 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351263]
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[480]
Message: NWC_CHECK:   time difference to server 8116
Warning: karte_t::interactive:   sync_step=1365630  server=[rand=1175234442 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351263] client=[rand=1175234442 halt=1 line=1 cnvy=2049 ind_dns_prop=3816 act_ind_dens=7022 traffic=2351263]
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[480]
Message: NWC_CHECK:   time difference to server 8237
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[480]
Message: NWC_CHECK:   time difference to server 8449

not sure what you mean by the sync_step counting up to 256, but this seems just like your messages.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 06:14:06 PM
See my log in post #137. I'm looking for somebody else experiencing a burst of NWC_CHECK messages in a row, and then followed by the interactive messages with sync_step= counting up by 5. Or any other anomalies. Each NWC_CHECK should be immediately followed by an interactive message with sync_step counting up by 256 (for the current server settings).

EDIT: you edited to post your log while I was posting. It does indeed contain the problem I'm seeing. Now for James to obtain the server side of things...

Is it server logs that you are after, or tcpdump statistics? I have command line access to the server, but there is no GUI installed. Should I simply upload the raw output from the command posted above? If so, for how long should I leave tcpdump running?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 09, 2014, 06:15:00 PM
By the time we get to rail, there are going to be no corridors left between towns.

Am also concerned that exclusively-passenger-services via canal seems to be profitable. Canals were mainly built for freight.

Passenger canals aren't really making money right now.  They are making a small profit, if there is enough population density in its catchment area, but when offset against the maintenance cost of the canals it's probably a money loser still.  My monthly maintenance cost is 200,000/month, which is a huge cost, mostly to support my canal infrastructure.  There is no way my canal passenger services are earning 1,000,000+ in revenue to offset their part of that.

The main reason I have set up extensive passenger canal networks is to get ready for rail, since now I already have nicely laid out right-of-ways through the cities (which by then will be well within the urban area-assuming the game isn't reset by then) and serve as a break-even (if I am lucky) way to aggregate passengers to my profitable long-distance connector lines.  A quick guess puts my passenger/mail service revenue at about 5 million/year-probably about 3 million in profits.  The long-distance lines is where the big profits are, but you need to have lots of feeder connections to build up sufficient demand.

I am very surprised that no one on the western islands has set up any significant passenger networks.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 06:25:21 PM
Is it server logs that you are after, or tcpdump statistics? I have command line access to the server, but there is no GUI installed. Should I simply upload the raw output from the command posted above? If so, for how long should I leave tcpdump running?
Packet capture is what I want to see, the server sides logs are not sufficiently detailed - why the heck aren't the logs entries timestamped???
If no gui, you're obviously stuck with command line, try posting the raw tcpdump. I can filter locally. Running for a few minutes should be fine.
WARNING: the capture may contain passwords. Don't be entering any while doing this to play it safe.

And ideally run Wireshark locally on your client at the same time, and post that along with the client simu.log.
WARNING: if capturing on a windows client, windows is very very very very very chatty. Definitely filter to only the comms with the server. Otherwise there'll be all sorts of who knows what you probably don't want posted...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 07:05:26 PM
I have produced a brief capture here (http://bridgewater-brunel.me.uk/misc/tcpdump.cap). Is this sufficient?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 07:21:56 PM
This is the output file created with the -w option? It should be the raw packets, not just this semi decoded print.
Might be usable, but there's so much junk in here, and it's not the correct format for the tools to filter. A nice pcap format file would be nice which is what the -w should give???
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 07:36:59 PM
Ahh, I had trouble with the -w option. I had the error:

Code: [Select]
tcpdump: filename.cap: Permission denied

The error was the same whatever file name that I specified.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 07:38:55 PM
was it run from root? perhaps try to another folder, where there are write permissions.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 09, 2014, 07:40:42 PM
It was indeed run from root, and I tried a known good folder (the same as I used without the -w option where it worked without difficulty).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 09, 2014, 08:47:21 PM
that's quite strange. what version and distro is running?

Googling, I see some stuff about a process called AppArmor, i'm guessing you don't have that but better to make sure.

the best lead seems to be trying to create (touch) the file you are writing to and setting full permissions for everyone (chmod 777 filename) on it.

Also try the -Z option?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 09, 2014, 08:53:27 PM
-p option could be tried too, but I'd expect a different error if setting promiscuous failed. We don't need a promiscuous capture for this.

EDIT:
OK, this capture does indeed appear to show the server sending NWC_CHECKs ~200ms apart. Without the full packet data from the -w file, I can't be certain, but there's definitely bursts of packets being sent that match the timing signature of bursts received by my client.

Not sure where to go from here. Any chance you can try copying your whole simutrans server install to somebody else's server somewhere? Running the same binary elsewhere would point the finger to simutrans or your host/OS environment...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 10, 2014, 12:07:39 AM
To answer the question - I am using Ubuntu 13.04. Apologies for not having been able to respond more quickly - I have been working on the forge cost feature and latterly making dinner and pudding, taking photographs of the pudding, and uploading said photographs to Flickr (http://www.flickr.com/photos/14730981@N08/).

Perhaps it is time for a distribution upgrade?

Turfit - thank you very much for your analysis. When you ran the server, did you use a Linux or Windows version, command line or graphical, 32- or 64-bit? If other than a Linux command line 64-bit version, I wonder whether the variance in behaviour somehow arises there. If you have a 64-bit Linux environment, I could copy the whole server install (save that I will remove the admin password from simuconf.tab) to a .tar for you?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 10, 2014, 12:20:06 AM
Looks more like a cake or something than what I'd call pudding. But then you do have weird names for things over that side of the pond.  ;D

I just ran the graphical x86 windows program compiled by you as the server on an old laptop. I don't have 64 bit linux environment at the moment, but it's easy enough to create one...  a .tgz would be fine.
I'd also still really recommend 32 bit for Simutrans. It really is not designed for 64. But then it's not really designed for MSVC either, doesn't really matter until you're pushing the performance limits, but then maps on this server tend to!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 10, 2014, 01:20:59 AM
Ahh, we use "pudding" as a general word for what I believe that you call "dessert", although this particular pudding is a close relation of a sponge cake (the distinction being that it is steamed rather than baked, and served hot in a bowl with custard or similar rather than cold on a plate on its own).

As to using 64-bit: I do that because the server is a Linux 64 bit server, and the 32 bit version of the application has been found to be unstable on Linux (but not Windows) running a 64-bit architecture. Also, some of the very largest maps are now coming close to the practical limit of memory available to 32 bit applications.

The server files are here (http://bridgewater-brunel.me.uk/misc/Server%20mirror.7z) [Edit: now deleted]. That is an enormous file, however: over 800Mb at the maximum possible compression ratio that I could obtain. Please let me know when you have downloaded it so that I can delete it. I have omitted the folder, which is on the server, for the old Pak128.Britain-Ex 0.9.0, and I have also omitted the log files and custom script setups for starting/stopping the game.

I hope that this is sufficient. I should be very interested in your findings. Thank you again for taking an interest in this.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 10, 2014, 01:19:02 PM
I have the file. Might be a couple days before I can look into it. I see you included source, presume this is the source you compiled from for the current running server? And simutrans/simutrans-experimental-11.18 is the executable? With .17, 16, 15, etc the previous builds?

EDIT:
Did you mean Ubuntu server 12.04.4 LTS?  or 13.04?   12.04.04 LTS is latest long term, and 13.10 latest otherwise...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 10, 2014, 08:40:12 PM
I did mean 13.04. The next release of Ubuntu is an LTS, is it not? I was planning on skipping 13.10 and waiting for 14.04.

The source code included is indeed from the current executable version, and the executable actually run is the one simply named "simutrans-experimental", which is a build of 11.18. The source code should be the same as on my Github "master" branch.
Title: Re: Sim City (2013)
Post by: sdog on February 10, 2014, 11:02:00 PM
James, could you ask one of the players on Bridgewater-Brunel to briefly describe a particularily good game on Simutrans. With a focus on those aspects you consider most interesting. As the interest in Carl's project shows, a lot of people are very interested in the complexity that airses from a compact set of rules. The historical development, and how it reflects real transport development could be very interesting as well.

However a large number of people interested are passive, and not joining the server, thus it happens a bit out ouf the view of a wider audience. A compact summary might lead to further interest, and present also to non players what the serious aspects of simutrans are. (That might also help someone who has to provide a good reason for playing such a game.)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 11, 2014, 12:06:27 AM
OK. Fired up Ubuntu server 64bit 13.04, started the server, connected a windows 32 bit client, and the timing went wonky immediately. Now to find the culprit...

EDIT: was able to duplicate with Standard, but only by making the CPU beg for mercy with the OP test game - pegs at 100%. So, despite your experimental save only consuming ~25% CPU, it's behaving overloaded. I suspect Experimental is doing too much in step(), and hence not calling ::interactive regularly enough. What the OP game does to Standard is massively overload the passenger generation/pathfinding, and hence end up spending most of its time in step().

So, I believe this tracks right back to the fundamental architecture of the program, and therefore could very well be unfixable. That said, I'll try looking into the behaviour of ::interactive when it's not being called regularly, and see if something can be done there. Otherwise, try to shorten up the time Experimental is spending in step()!


Also, when I compiled the Experimental server without DEBUG=3, the client discod immediately on the first checklist check with a mismatch. Both rand= and traffic= were different. I don't know how your windows x86 binary I was using for the client is compiled, but it shouldn't matter. Debug, non-debug, optimized, non-opt, all combinations thereof, shouldn't matter. Client should still stay connected to server, so you've got some other thing going on too...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 11, 2014, 11:37:45 PM
Sdog - as you will see, I have merged your request with the server thread so that people can see your request directly. Players in this server game: if anyone feels inclined to produce a write-up as Sdog requests, this might be very interesting. Thank you for suggesting this.

TurfIt - thank you very much for investigating this: it is much appreciated. You are correct in deducing that there is indeed more work being done in passenger generation and pathfinding in Experimental than Standard. I do not know a great deal about the details of the way in which karte_t::interactive() works and how it fits in with the networking and timing: I have never really delved into such low-level parts of the programme. May I ask - is this the same thing as calling INT_CHECK(), or is this something else? If so, where is and is not safe to call INT_CHECK? Perhaps adding more calls to INT_CHECK() will help. If this is not the same thing, I should be very grateful if you could explain the difference.

As to a checklist desync when the server is not running with DEBUG defined, that is odd, as whether DEBUG is defined makes no difference in Windows, and synchronisation is maintained although the server is an optimised build with the debug symbols stripped. The definition of DEBUG causing desyncs would tend to suggest an assert with a side effect, but this cannot be so, since it does not make a difference in Windows: I must say, I am quite stumped as to why this might occur in Linux but not Windows.

Thank you again for all of your investigations - they are much appreciated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 12, 2014, 03:01:05 AM
INT_CHECK is only applicable to offline games. Online, the interrupts are disabled as the execution on the server and all clients must be done in lock step. I think I see a couple things that can be done to improve the situation, but I'm out of time tonight to even describe them...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 12, 2014, 04:09:45 AM
The best part about the online game is that you can see what other players do to be successful.

I wouldn't have known of the high speed corner exploit if it were not for the first game.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 12, 2014, 07:21:14 PM
What is the high speed corner exploit??
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: sdog on February 12, 2014, 08:08:31 PM
Sdog - as you will see, I have merged your request with the server thread so that people can see your request directly. Players in this server game: if anyone feels inclined to produce a write-up as Sdog requests, this might be very interesting. Thank you for suggesting this.

Thank you James.

And thanks in advance to whomever would  write such a history of a game.

To clarify it a bit: I should post it to the blog, in its full length. Then write a synopsis to post on social media, linking to the blog.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 12, 2014, 09:39:30 PM
The best part about the online game is that you can see what other players do to be successful.

I wouldn't have known of the high speed corner exploit if it were not for the first game.

This reminds me that I need to fix this for the next major release.

TurfIt - thank you for the clarification. I shall be interested to know your thoughts when you have time to record them. Your input is much appreciated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 13, 2014, 03:43:43 AM
I did try out some changes to client timing. So far so good, but I need to think on possible undesirable implications on the one change, and need to tame down the adjustments a bit as they're currently a bit aggressive. Timing after the initial join is all over the place, but it seems the cause is server side. After 30secs or so I settles right down and runs quite nicely.

I also joined with my modified client to your server, and things were still pretty good, except every now and then your server seems to go to sleep... My client has to slam on the brakes to avoid overrunning, then your server takes off like a Bugatti Veyron leaving my poor client pedaling like mad trying to catch back up. I don't get such extreme pauses running the server locally...

Also, feel free to split all this timing discussion off to a development forum. Leave this thread for gameplay discussion would be good IMHO.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 13, 2014, 04:25:50 AM
Thanks TurfIt.  This parallels much my own experience: When I first connect it's very laggy until it settles down after a bit.  The same occurs when I am already online and another player joins the game.  It also happens at month-end boundaries as well - for the first few minutes after a new month it's very unresponsive.  I'm most likely to get disconnects during these times if I am doing any construction/building.  I try to save my building to the 3: and 5: hour marks, the connection seems the most responsive and I am least likely to get booted.

If I am just idling, I can stay connected for hours.  It's the building process that kicks me off frequently.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 13, 2014, 10:15:42 AM
Hmm - I was in the process of splitting the topic when I realised that there were some posts that simultaneously dealt with both game play and the client/server timing issue.

I am very grateful to TurfIt for looking into this - it is very much appreciated. I am not sure why the server goes to sleep sometimes - perhaps it has something to do with running on a virtual server which is also running a web server that hosts the downloads?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 15, 2014, 04:37:30 PM
I've had several more instances of lines having some or all stops disappearing. It's becoming quite tiresome I'm afraid. My profitability was £2M/yr in 1757, now averaging barely 20% of that because of key stops being deleted from lines' schedules.

In many cases a line with 2 stops and 30 waypoints, just the first "100% load" stop is deleted, so the ships sail about empty (costing a fortune). Its always entry 1. in the list in that case. It happened to all of my most profitable lines. ::'(

I wonder, if entry 1. got deleted enough, it would presumably result in empty line-schedules??

What really puzzles me is how the other high-earning players arent having the same trouble?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 15, 2014, 05:51:26 PM
Interesting.  I haven't run in to this issue, all of my lines are still operating flawlessly.  I had my road vehicles wiped a couple of times, as discussed earlier, but thusfar (fingers crossed) my shipping lines have remained intact.

If it happened to me I might very well quit playing as I have almost 900 ships in motion and over 200 shipping lines.  :o  (trying to re-establish everything while fighting frequent server disconnects would probably be close to impossible)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 15, 2014, 06:07:37 PM
The trouble is it's not easy to spot, because the ships keep sailing merrily.

The only clue is stations with "no service". There is a filter for that in lists (called "no connections") which I am now keeping a very close eye on indeed. Of course, it won't pick up if a stop is deleted but another service also calls there...

Server is down right now, I still have a fair few services to fix. If it recurs I may, as you say, give up. I've tried putting a "sacrificial" waypoint as entry 1. in each of my lines' schedules, may help?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 15, 2014, 11:11:42 PM
what works for me is all convoys set to a line, rather than lineless schedules.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 16, 2014, 07:57:00 AM
what works for me is all convoys set to a line, rather than lineless schedules.
I do that always. It's impossible to manage all the vehicles otherwise. Hence the vulernability to this *issue*
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 16, 2014, 06:36:27 PM
Just thinking ahead, many canals are in use by multiple players, in line with reality. If the canal owner player decides they want to remove a canal (e.g. to build a railway on the alignment), that will affect other players lines, and deprive them of revenue. I believe in reality since canals were "common carriers" they were not allowed to simply "close".

It would seem bad if a player comes back to game to find all his ships are reporting errors because vital infrastructure has been deleted...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 16, 2014, 06:44:50 PM
a nice solution could be that if you use another player's canal and you want to be protected from sudden closure, you'd sign a contract with them :)

but I think this is not practical until we can transfer funds manually, if only to pay compensation for a breach of contract :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 16, 2014, 06:55:46 PM
Most canals and railways had "in perpetuity" clauses built into the enabling acts of parliament. Canals were called the "eternal navigations".
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on February 16, 2014, 07:31:01 PM
yeah, and then, it's not that easy IRL to destroy a canal and restore the ground as it were, is it. I do think there's a long term plan to enable "abandoning" infrastructure rather than removing/restoring it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 16, 2014, 08:48:24 PM
That is an interesting idea, but I have no idea how this can practically be incorporated into the game without causing more problems than it solves.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 19, 2014, 05:11:27 PM
AP, why did you attach canals at Dartinghall and Dartington with my canals that don't work with sea fairing ships?

That peninsula does not even require a canal that bisects it, since going through there does not result in a shortcut for ships.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 19, 2014, 07:22:33 PM
I assumed your canal was built with ship canal! Narrowboat canal is more expensive to maintain than ship canal in this version so nobody is using it. You should upgrade to save the maintenance.

I built the other half because it looked like it would be slightly shorter. Oh well.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 19, 2014, 08:02:29 PM
the barge canal is overly expensive, but the narrow boat is half the cost to maintain over ship canal.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 19, 2014, 09:54:07 PM
Oh i see. oh well.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 20, 2014, 11:53:01 PM
Server now upgraded to 11.19, which should, in time, reduce the number of private cars to a more sensible level and overcome a number of the other bugs reported recently.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 21, 2014, 12:00:29 AM
My attempt to rejoin with the new version caused a fatal error in simutrans,;the map loads and i can interact with it, but the clock does not start ticking, then it crashes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 21, 2014, 12:19:35 AM
Might I suggest trying with the 64-bit version? I think that the memory requirements are a bit too much for the 32-bit version at present owing to the large number of private cars. That number will diminish with time with this new version, and might well reduce the memory consumption.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 21, 2014, 12:40:05 AM
64-bit client works, but is constantly stuttering while connected.

---

the stuttering can be reproduced locally by fast forwarding.
Typically does 11 to 12x, but dips down to 2x every 5 to 10 seconds.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 21, 2014, 12:51:34 AM
I suspect that the performance troubles (and memory use) are caused by the very large number of private cars. The numbers should slowly dwindle until a new, lower, sustainable level is reached as the new code in 11.19 gradually takes effect.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 12:57:55 AM
32 bit crashes for me too.  64 bit is working fine thusfar.

The stuttering/pausing makes it a bit difficult, but if it'll clear up after a while we can live with it.

Game is taking up 1.7GB in memory.

Could it also be related to the more complex pathfinding?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 21, 2014, 01:01:54 AM
Could it also be related to the more complex pathfinding?

Yes, that is also possible. The situation will need to be reviewed after about one game year to see what the position is then.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 01:18:25 AM
By how much has the server load % been impacted?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 21, 2014, 01:48:55 AM
is there a way to check how many private cars there are?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 21, 2014, 01:55:31 AM
There is no means of tracking the number of private cars currently outstanding in a game. The current server load is 54.3% CPU and 43.4% RAM (out of 3Gb).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 02:08:44 AM
Hmmm, I am getting very frequent desynchs... I can connect but I will desynch usually within 60 seconds, sometimes right away after connecting... and especially if I try to do something like build.

I am getting the heavy stuttering on local play as well, runs at 12-13x but then freezes up for a few seconds every couple of minutes of game time, then bursts back to 12-13x again.

EDIT: It usually happens during the stutters - the clock freezes, then jerks ahead, freezes and then I desynch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 21, 2014, 11:09:35 AM
Hmm - I wonder whether this is the game not being able to cope with the increased routing depth. Are others also experiencing this? If this is so, I will have to put the old routing depth back (but, be warned, one problem that I encountered was that, when access rights were withdrawn from players whose ships docked at the ports of the other players who were withdrawing the rights, the ships would often end up being sent to the depot because the jump between one stop and the next became too much after the removed stop was taken out).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 21, 2014, 03:10:40 PM
I fast forwarded a local copy to 1780 and the stuttering persists, but not as frequently. I feel that it is about half as frequent.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on February 21, 2014, 03:17:14 PM
I have been unable as yet to connect without an instant desynch.  Quadcore i5 @ 2.6GHz, Linux 64-bit, on 18Mbps connection.  This map is seriously un-responsive when played locally.  =sigh=
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 03:39:52 PM
Indeed, James, we've been facing that problem all along and have learned to live with it.  The best solution I can suggest is to have shipyards all over the place so that if this happens your ship isn't pushed too far off their scheduled route.

I tried a few more times to connect last night and couldn't stay connected for more than a few seconds (sometimes an instant desynch).  I managed to place two stations after about 10-15 connection attempts.  I think I also built a ship but wasn't able to get so far as put holds on it.

The clock is really jittery, shooting ahead, stopping, shooting ahead again.  I assume that is occurring on the server side as well which is causing the desynchs.  We'd need a mechanism to keep the clocks more in synch so that this doesn't happen.

EDIT: I think what's happening is that when you perform a function in the game and your client is waiting for confirmation of the action from the server and it enters one of its frequent multi-second pauses, the client signals a desynch because it hasn't received anything from the server.  At least, that's how it feels.  When I am lucky enough to not desynch immediately on connection, as soon as I perform any action it will likely desynch because it will hit one of the pauses and time out.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 21, 2014, 06:49:42 PM
Also, a
Indeed, James, we've been facing that problem all along and have learned to live with it.  The best solution I can suggest is to have shipyards all over the place so that if this happens your ship isn't pushed too far off their scheduled route.

Also, lots of waypoints, so it has a chance of making it if a (formerly shared) stop is removed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 21, 2014, 07:04:58 PM
^
If you keep your waypoints within 1200 tiles, it seems like there is less chance of the stop being deleted.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 21, 2014, 07:14:29 PM
^
Is that 1200 total or 1200x and 1200y ?(i.e. how are diagonals dealt with?)



Might I suggest trying with the 64-bit version? I think that the memory requirements are a bit too much for the 32-bit version at present owing to the large number of private cars. That number will diminish with time with this new version, and might well reduce the memory consumption.

Am on a 32bit operating system, so I believe that means this isn't possible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 07:19:46 PM
I am keeping my waypoints 600-800 average.  It's more work putting your schedules together but then you run no risk of failures.  I don't think I've had any shipping routes fail in that regard.  The only problem I had was when one of my docks was accidentally blocked by someone else, but other than that keeping below 1000 distance for waypoints has worked well for me.

I will also put my waypoints closer to together in areas that have more complex pathfinding (ie: open ocean vs. around islands).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 21, 2014, 07:50:46 PM
^
Is that 1200 total or 1200x and 1200y ?(i.e. how are diagonals dealt with?)



Am on a 32bit operating system, so I believe that means this isn't possible.

1200 total.

If the route is dead straight, you can even go up to 1500.

The more bends there are, the shorter this number is.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 21, 2014, 08:01:34 PM
Understood, thanks. :D

I still can't join the server game, assume from the above everyone else is having similar issues...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 21, 2014, 08:23:44 PM
Yup, after about 10 attempts today, the best I could do was about 5 minutes and no actions, just watching.  If I try to do anything it's almost a guaranteed desynch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 22, 2014, 01:19:02 AM
I am sorry for the difficulties: it seems that the game cannot cope with the restriction being lifted on the routing algorithm. I will work on releasing a revised version with the old limit reinstated soon. Thank you all for your patience.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 22, 2014, 01:29:07 AM
You might want to try pulling in r7000 from Standard... CHG: use faster route search for ships (jump-point search)  (https://github.com/aburch/simutrans/commit/943f75a0565f05e58904bd4a976974685b442339)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 22, 2014, 01:35:27 AM
Ahh, thank you. That is already merged in for the next major release, I think, so it is probably easier to leave it there than try to backport it manually to the 11.x branch; but Experimental users will get the benefit of this in due course.

Out of interest, how much of a difference does it make?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 22, 2014, 09:42:23 AM
I am sorry for the difficulties: it seems that the game cannot cope with the restriction being lifted on the routing algorithm. I will work on releasing a revised version with the old limit reinstated soon. Thank you all for your patience.

No worries James, these things happen, it's all in the name of progress after all :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 22, 2014, 03:48:20 PM
Testing the 112.5-merge branch as against the current 11.x branch for performance with the server game in April 1779, in a non-optimised debug build, I get 0.34x speed in fast forward mode on the 112.5-merge branch and 0.22x on the 11.x branch. On the 112.5-merge branch, once the game has loaded, it is a little sluggish, but performance is just about acceptable. On the 11.x branch, the game is quite unresponsive, with a delay of about two seconds between action and response for something such as clicking on a building tile.

Note that these are both unoptimised debug builds, and optimised release builds will perform much more quickly: however, the relative difference between the two gives some idea of the difference in performance of the current code and the code on the 112.5-merge branch, both as a result of the improved ship routing algorithm and Bernd Gabriel's recent work to improve performance.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 22, 2014, 05:27:39 PM
Just return the routing maximum back to what we had before, we had learned to live with it by putting in multiple waypoints.  Certainly helps the performance.  It will matter increasingly as the game moves on and we double, triple and beyond the number of convoys already in motion.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 22, 2014, 05:38:32 PM
Yes, that is the plan: I have already reverted the change on the 11.x branch. I am seeing whether I can fix another bug or two in the next release while I am working on the 11.x branch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 23, 2014, 12:48:49 AM
Server now upgraded to 11.20, with the routing depth limits reinstated, which has solved the performance problem as far as I can tell from my brief tests.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 23, 2014, 02:02:23 AM
Is it just me, or does it seem like the ships that reach the end of their schedule will attempt to go to 1 instead of reversing route?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 23, 2014, 02:53:43 AM
Woah... something really nasty is going on with my ships.  They're all failing on route and being sent to depot.  I tried intercepting a few and they're picking really odd points on their schedules, leaving the dock and selecting a point in the schedule several points ahead and then failing to find a route and going to depot.  When I try to open their schedule and send them to their next waypoint on the list, then close the schedule, the ship still wants to go to its original selection and fails again... I can't seem to override it.  Thus, all of my convoys are going to depot and there's nothing I can do to stop it  :-[

Ack!  This is a complete disaster!

EDIT  I think I've figured out.  Waypoint distances are super small now, almost everything is failing unless your waypoints are less than 300 tiles apart, it seems.  Every single one of my lines/convoys is failing and going to depot...

EDIT 2  I figured out why I couldn't change schedule.  With the 5-10 second lag, you have to select a schedule change, close the schedule and then wait for 5-10 seconds before you start the convoy or it will revert back to its previous setting.  Very slow.  Can only do this in a depot, I can't do this to a convoy once it fails to find a route.  Have to wait for the ships to fail in pathfinding, then revert to depot, then send them out again.  I hope... going to take hours.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 23, 2014, 03:19:48 AM
probably best to build several docks for the long distance ships so that they can route through a shipping lane that is known to work.

I am sure the lag will go away once all the ships stop trying to go to depot.

I remember the lag being quite bad when the replacer was used en-mass, so this lag is probably due to the same reason.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 23, 2014, 04:11:31 AM
I've been frantically trying to get all of my convoys back on track but it seems that the waypoint spread on routes is much smaller than it was previously and even routes that were closer together and didn't require waypoints are now failing as well.  Add to that desynchs every 5-10 minutes and it has been a frustrating exercise  :P.  Without adding dozens of new waypoints to every single line, pretty much all of my convoys will fail and go to depot.  Seems to need waypoints that are less than 300+/- tiles apart... which would require 20+ waypoints for a trip across the map, 40-50 or more for a round-trip.

Is it possible to return the value to what it was previously and revert the save game?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 23, 2014, 09:22:39 AM
I logged into the game out of morbid curiosity - the seas are almost totally empty.  :o

Is it possible to return the value to what it was previously and revert the save game?

I agree. Its hours of pain to try and get all the ships back on route manually.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 24, 2014, 11:42:56 PM
Apologies everyone for the trouble with this. I have now been able to track down the bugs causing these difficulties and have fixed them on the 11.x branch. Before I deploy the release, I should be interested in people's views on what is best to do. I have some saved games locally from April 1779 that I could set onto the server, thus reverting some of the difficulties recently with the ships, or, if anyone has a later version before the difficulties, I could use that (and, in the process, manually increase the maximum number of routing steps slightly to see whether that helps a little with reducing the number of waypoints needed for ships). Alternatively, I could leave the game as it is if people have managed to make it work satisfactorily in the current condition and do not want to lose any progress.

Please let me know - thank you.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 25, 2014, 04:42:39 AM
I've been able to salvage my passenger and mail network and have it running fine currently but all of my freight lines are all suspended currently.  It's pretty easy to send all those ships back out in to the network again once the waypoint distances work again and within a year have everything back to normal, so I'd be okay with either option you choose.  Losing a couple years of profits isn't likely to hurt anyone in this early stage of the game.  It was a nice chance to see what my passenger/mail network made just by itself (6 million/year, which surprised me!).

No apologies necessary, I think we're all aware that this is primarily for testing purposes... I am happy to be one of the test subjects.  :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 25, 2014, 07:55:34 AM
I'm not worried about the profits either.

Do we think the lag issue should also be resolved? If so, redeploying the ships on existing routes shouldn't take too long.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 25, 2014, 11:57:41 AM
Splendid, thank you both for your feedback. In that case, when I get a chance later, I will update to 11.21 and leave the current saved game intact. Apologies again for the difficulties.

As to the lag, although I cannot be sure, because the bug that I found over the week-end was one which made the pathfinding for vehicles much less efficient, fixing it could well fix ongoing lag issues.

Also, I am planning to make a further change before I release 11.21 which should make things easier for users of ships: I plan to disable the automatic sending to depot of convoys on open water with no route. The idea of the automatic sending to depot of such convoys was to avoid convoys with no route (for example, as a result of the withdrawal of access rights) blocking other convoys in a multi-player game when the player whose convoys were in a "no route" state might not be online for real time hours or days. With ships on open water, this is not an issue, since, on open water, ships do not block other ships. (Things will be different on canals and rivers from the next major version, which is why I am confining this to ships on open water; aircraft, whilst they do not block other aircraft, should also return to the hangar, as it makes no sense for aircraft to be suspended indefinitely in mid-air).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 25, 2014, 05:59:26 PM
yes, I don't mind having to resend out ship, as long as most of them work fine with their current schedules.

It's pretty easy to find the convoys in depot if you use the convoy list with filter enabled.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 26, 2014, 01:32:53 AM
Thank you all for your feedback. Now updated with 11.21. Please let me know how this works out for people - sorry for the problems.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 26, 2014, 03:37:10 AM
Looks like the previous routes are working fine.

I added many nav markers anyways, since this makes it more like a shipping lane and because it is easier to find the waypoints.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 26, 2014, 10:02:15 PM
Server is down? Not been able to connect since 7pm ish (GMT)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 26, 2014, 11:16:31 PM
looks okay from here.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 26, 2014, 11:17:27 PM
Hmm - I am able to get in. Perhaps other people have been connecting when you tried?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 26, 2014, 11:21:58 PM
AP, make sure to install the latest 11.21.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 26, 2014, 11:58:54 PM
I am on 11.21. I'm back on now. It just kept giving "no response from server". Odd.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 27, 2014, 12:08:59 AM
Curious.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 27, 2014, 12:33:09 AM
Sometimes you get that if someone else just logged on.  With the large file size now, it takes a good 5 minutes or more for someone to log in to the game, during which time no one else can log in until the new player is all set up and connected.

Working fine for me, I put over 1,000 ships in motion today and they seem to be doing what they're supposed to do.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 27, 2014, 12:46:12 AM
Sarlock, is ship 2261 going in circles outside of Monkington from a previous test?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 27, 2014, 01:07:04 AM
Oh, haha, yes, that was a test from a few days ago that I forgot to remove.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 27, 2014, 01:38:11 AM
I thought so, lol.

It sure is pretty easy to lose things or forget about projects on a large map.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 27, 2014, 08:00:55 AM
Tried about 10 times tonight to connect and couldn't stay connected for longer than a minute or so at the longest.  Most were instant desynchs within 5 seconds of the clock starting to run after loading.

Is the long delay between map loading/transferring and the clock ticking a data transfer period?  It takes around 5 minutes or more between when the transfer completes and the clock starts to move.

The clock is rather "jerky" in that it freezes up for a few seconds, then bursts ahead again.  It does this in offline play as well though not quite as pronounced (fast forward jumps between 7x and 13x, back and forth).  It may be related to there being over 3,000 convoys in motion and the amount of calculation required.  I suspect that it is this that is causing the frequent desynchs.  It was fine earlier but that was because over 1,000 of the 3,000 convoys were in depot.  After we sent them all back out the game because quite lagged again and the desynchs returned.

I haven't played a large map in Standard so I can't compare, to tell if this is unique to Experimental online play.

Is anyone else experiencing frequent desynchs?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 27, 2014, 10:12:53 AM
it is a bit jerky now, but i only noticed it after seeing a few ships get stuck.

i can stay connected for a while, but i also have a much faster connection 1mb/s, so it takes less than 30s to load the game.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 27, 2014, 10:49:01 AM
Thank you for noticing this. It is difficult to know exactly what is causing the difficulties, but it does seem that they are at least correlated with the increase in computational load caused by the existence of a large number of convoys, particularly ships, which are more demanding on route-finding.

TurfIt had some interesting ideas about this earlier in the thread, but nothing seems to have come of that, unfortunately.

Incidentally, the time to load the game is a combination of the time to transfer the data (but that is the time during which there is a "transferring data..." progress bar) and the time for the server to re-load the game (which will be slower for the server than the client because the server is single-threaded). This should not by itself by responsible for desyncs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 27, 2014, 03:24:50 PM
Ah, that explains the long delay after the game loads.  My connection is quite fast as well, I typically reach speeds of 2-4 MB/s for most downloads.  The server download only takes 20-30 seconds to occur, then the long wait while the server loads, then the desynch happens within seconds of the game starting.  Given that I seem to be getting the worst of it, it must have to do with my 150ms lag time to the server (due to geographic distance).

I've thought about setting up a parallel copy of the game but at a much closer location to test if that is my issue.  Are you running this server locally (in your home) or do you have it set up on a remote server?  I haven't set up a game server before but I imagine it isn't too complicated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 27, 2014, 08:25:12 PM
What is working for me...

1st connection is almost always instant desync when the game progresses
After switching to another player, 2nd connection will work for some 30mins (so far)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on February 27, 2014, 08:32:25 PM
TurfIt had some interesting ideas about this earlier in the thread, but nothing seems to have come of that, unfortunately.
Patience  8)
I got distracted by the Mac thing... but I've gone far enough there for now. Back to experimenting with the client timing. I don't want to introduce any other bad side effects like the current algorithm does when the server gets overloaded.

Also, the bulk of the 'loading' time is actually waiting on the server to destroy the map. Specifically destroying the halts takes a ludicrously long time in Experimental vs Standard. Something you should really look at fixing as it's taking 10x longer to join than it should...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 27, 2014, 11:06:39 PM
Thank you - and apologies for being a tad hasty. These things take time, I know.

Thank you very much for pointing out the issue with destroying halts - I had not noticed that difference before. I will look into it and see whether any routines in the destructor can be skipped when destroying the world entirely.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 28, 2014, 02:40:35 AM
"Having discovered the invention of the plateway, the owner of Associated Shipping decided to survey a new route, which might one day prove useful."

Or put another way, engineering takes ages, and noting the appearance of several sections of strategic plateway on the map, AP decided to make a start sooner rather than later. Ferries and horse drawn trains may follow shortly :-)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 28, 2014, 02:50:20 AM
oh yeah, I just wanted to make sure I didn't need to make an awkward climb to get to Monkington from the north.

My intention is to have two mainlines. Furbury-Saltlow through the eastern coast and Norley-Binlock through the canal.

Other than those two, I am not really interested on the west island.

(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans/simscr03_zps0b49018e.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 28, 2014, 03:39:36 AM
Interesting how blind chance made Monkington the largest city on the map and was also placed in a very strategic location at the centre of a large area of cities.

I plan to build a similar system on the eastern island (assuming I can connect for more than 5 seconds at a time), connecting the large urban centres in the south with the north.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 28, 2014, 04:29:49 AM
I took a look, but that is very ambitious.

I would suggest watching out for the maintenance costs of such a long line.

and also, if pax use is desired, I would suggest more passing loops.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 28, 2014, 08:00:45 AM
oh yeah, I just wanted to make sure I didn't need to make an awkward climb to get to Monkington from the north.
Safeguarding the route; the same reason I figured I had to start building my route soon -  several of the islands are really hilly with just one viable short route along the edge. Hills are such a pain (roll on twin-slope simutrans!)

There are a couple of spots where I'd appreciate it if roads could slightly be realigned, have put up signs. (2200,1060)(1984,1017)(3996,478), but no immediate hurry to do so.

Am hoping I can run it as a single track main line, but I've allowed enough space to double it, because my experience with single track and intensive service has been mixed thus far. But it would keep the maintenance down, since I'll need 7 short(!) tunnels too. I now need to figure out the passing loop spacing and where I aim for at each end.
Interesting how blind chance made Monkington the largest city on the map and was also placed in a very strategic location at the centre of a large area of cities.
Was it chance or did the city cluster setting have an effect? I was thinking I'd aim for Monkington and if you are making it the key node of your network, that makes even more sense. Anyone drawn up plans for the east island yet? ;)

Edit: typo.
 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on February 28, 2014, 11:31:51 AM
Safeguarding the route; the same reason I figured I had to start building my route soon -  several of the islands are really hilly with just one viable short route along the edge. Hills are such a pain (roll on twin-slope simutrans!)

There are a couple of spots where I'd appreciate it if roads could slightly be realigned, have put up signs. (2200,1060)(1984,1017)(3996,478), but no immediate hurry to do so.

Am hoping I can run it as a single track main line, but I've allowed enough space to double it, because my experience with single track and intensive service has been mixed thus far. Bit it would keep the maintenance down, since I'll need 7 short(!) tunnels too. I now need to figure out the passing loop spacing and where I aim for at each end. Was it chance or did the city cluster setting have an effect? I was thinking I'd for Monkington there and if you are making it the key node of your network, that makes even more sense. Anyone drawn up plans for the east island yet? ;)
(NAF&C) [is going to be renamed..]
May I have the franchise on building and operating local service in this area?
(It will mostly be running underground)
And you can operate the intercity service in it.
Also I might (if i have the money rolled in..) extend the eastern mainline to radshot metropolitan area.
(http://i218.photobucket.com/albums/cc155/kmb_68x/fq5lvbco2_zps6f5d82c9.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on February 28, 2014, 10:14:07 PM
@Volvo
I don't mind.

@AP
1984 to 2200, wouldn't it be easier if you go through the south side of the Barnbridge?
Then you wouldn't need to cross the roads there or go through the mountain.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 28, 2014, 10:47:00 PM
I haven't given the east island a great deal of thought on exactly how to lay things out yet, but I have laid a general concept many years ago with canals and am quite content to continue to serve the cities' pax/mail needs through canals for a while longer... at least until better trains arrive.  The cites have grown a lot and many have amalgamated into huge urban areas.

A general concept below, conceptual routes in white, existing hub cities in red, probably remain the same once I advance to rail.  Eventually connect the two networks, but that's a lot of open ground to cover in between on the east side.

This is, of course, predicated on the fact that I will be able to connect for more than 5 seconds at a time.

(http://www.ssgholdings.ca/simutrans/images/network_plan.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 28, 2014, 11:13:28 PM
Gosh, you are all planning ahead - it is the 1820s before passenger rail transport over distances becomes viable!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on February 28, 2014, 11:47:13 PM
There's rather little else to do in this era, once one's canal / overseas trading empire is up and running. Possibly explains why the British kept invading places all the time...

James - what is the game setting for maximum interchanges in a journey, for both passengers and freight? I recall the default used to be 7. I'm assuming I have to use undersea tunnels to link the two islands right from the start, because if I have 6 ferries and 7 train journeys, it will exceed the maximum setting and nobody will travel.

@AP
1984 to 2200, wouldn't it be easier if you go through the south side of the Barnbridge?
Then you wouldn't need to cross the roads there or go through the mountain.
By preference I try to use the existing terrain in a realistic fashion rather than just reclaim the ocean. There's enough space to get both a road and railway through along the coastline, am happy to build road bridges.

I mocked up the entire route offline, about a week ago, but since then that road had appeared  ??? It was that in fact that persuaded me I had to build the route now, 4 decades earlier than ideal, but whilst it was still mostly unobstructed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on February 28, 2014, 11:59:46 PM
max_transfers is set to 13 currently. Is that sufficient?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 01, 2014, 12:06:36 AM

I mocked up the entire route offline, about a week ago, but since then that road had appeared  ??? It was that in fact that persuaded me I had to build the route now, 4 decades earlier than ideal, but whilst it was still mostly unobstructed.

okay, gotcha.

I'll fix up those roads when I can log in for a while.

I tried earlier, but I was instantly desynched.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 01, 2014, 12:10:36 AM
13 should be more than plenty.  I can't imagine connections beyond 9-10 at most, even cross-map.  Especially once travel times increase.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 01, 2014, 12:41:39 AM
Having properly checked the map, I think 5 ferries and 6 trains is the more likely option in that case, not 6&7*, so 10 interchanges end to end using ferries. max_transfers=15 might allow more flexibility in terms of feeder routes at each end? If it can be handled computationally. I presume extra interchanges don't by themselves introduce a penalty, it remains all about speed & comfort? But I'm still unsure if ferries or tunnels are the way to go...

*island at 1366,1025 is tiny so hardy worth building a railway on.

I prefer the tunnel option for simplicity sake, one railway right through but I'm aware the maintenance might be punishingly high.

Route Data (approx)

No 1 Tunnel =   30 tiles
No 2 Tunnel = 100 tiles
No 3 Tunnel =   20 tiles  -  @AEO: hence why going through the mountain doesn't concern me unduly
No 4 Tunnel = 800 tiles
No 5 Tunnel = 170 tiles
No 6 Tunnel = 300 tiles  (200x, 100y) - not sure if there is a maintenance reduction for diagonal ways?
No 7 Tunnel = 250 tiles
___________________+
                     1,670 tiles of tunnel  (at $2750/tile, $tbc/mth)
Route length: 3,954 tiles (Latitude)
Ergo route is 42% underground

Stone Tunnel 1670 tiles long = $4.5M to build,  but how much to maintain???
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 01, 2014, 01:05:57 AM
Ahh, remember that the cost shown on the toolstrip is per kilometre, not per tile.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 01, 2014, 03:01:36 AM
okay I touched the roads up so you can remove those markers.


FYI, there is a ship off the coast of Dule that is stuck.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 01, 2014, 10:27:09 AM
The thing is that cross-atlantic (let's say..) trains is really a bit crazy, a bit like what the victorians proposed..
I think the two main island realistically should be coneected by either ships or planes..
But then, you got the money to do so.. oh well.. ;D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 01, 2014, 11:06:15 AM
@AEO - Thanks :)   I wonder about a bridge at 2167,1048 also, but i can't remove the level crossing now (it's on your tile of road).
@James - oh yes, always forget that one.

The English Channel tunnel construction was stopped only by politics, not engineering. Serious proposals were put forward several times from 1857, the first had an intermediate ventilation shaft on the varne sandbank. But the military were opposed to it.

They actually started building it in 1882, they said they could have built it in 10 years. http://sussexhistoryforum.co.uk/index.php?topic=841.0 (http://sussexhistoryforum.co.uk/index.php?topic=841.0)

Also, don't forget this one: when the water is shallow enough many things are possible :) (http://upload.wikimedia.org/wikipedia/commons/a/a5/Train_on_Overseas_Railroad_Long_Key_Viaduct.jpg)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 01, 2014, 11:57:30 AM
(I was going to post a new topic for this, but since it's being discussed here, I thought it better not to clutter up the dev board!)

The clock is rather "jerky" in that it freezes up for a few seconds, then bursts ahead again.  It does this in offline play as well though not quite as pronounced (fast forward jumps between 7x and 13x, back and forth).  It may be related to there being over 3,000 convoys in motion and the amount of calculation required.  I suspect that it is this that is causing the frequent desynchs.  It was fine earlier but that was because over 1,000 of the 3,000 convoys were in depot.  After we sent them all back out the game because quite lagged again and the desynchs returned.

Quote from: James Petts
It is difficult to know exactly what is causing the difficulties, but it does seem that they are at least correlated with the increase in computational load caused by the existence of a large number of convoys, particularly ships, which are more demanding on route-finding.

I've been using 11.9 for a while, and in testing 11.21 the most noticeable difference is this "jerkiness". The most recent savegame (https://dl.dropboxusercontent.com/u/61716/BalkansFeb2014.rar) for the Balkans map (http://forum.simutrans.com/index.php?topic=9467.msg132418#msg132418), which features no ships, bears this out -- in 11.9, on my machine, fastforward fluctuates between the high 30s and the low 50s, spending almost all its time between 40x and 49x. In 11.21 (and 11.20) the variation is much more stark, from 10x-40x ish. (Your numbers will vary depending on CPU, obviously). This effect is most obvious when following a convoy whilst fastforwarding. It suggests that the issue is not merely the volume of computational load but also the way in which it is being managed.

This is partly an aesthetic issue - when following convoys, it's nice to see them moving smoothly rather than "jerkily". But the jerkiness means that overall performance is lower, so it is a genuine issue, I think. Perhaps it's simply a necessary consequence of recent code changes, but it might be worth looking into.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 01, 2014, 12:16:06 PM
Carl - thank you for the feedback: that is useful. Do you actually mean 11.9, or are you referring to 11.19? 11.9 is really rather old now, dating from August last year.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 01, 2014, 12:26:05 PM
I'm afraid I do mean 11.9 -- this is a dual effect of my (a) not playing Simutrans much in late 2013 and (b) erring on the side of conservatism when faced with a new version.

I appreciate that an 11.9 vs. 11.21 comparison is not very useful, so I apologise for this. If it helps, 11.15 is also much less "jerky" than 11.21 when loading the same map. 11.17, however, is comparable to the latest version - so whatever had this effect seems may have taken hold between 11.15 and 11.17.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 01, 2014, 01:06:32 PM
Ahh, thank you for narrowing it down. I will look into the differences between those versions and consider whether anything can be done.

Edit: Hmm - there is nothing obvious that impacts on performance critical code between those two versions.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 01, 2014, 05:17:10 PM
The "jerkiness" came with release version 11.19.  Before that, when fast forwarding, you got a fairly consistent rate of speed increase, but after 11.19 it bounced between two fairly constant numbers (in the online game, I get 8x and 15x).  It also introduced the same effect in the server game, at normal speed, the clock bursts ahead, then slows, bursts ahead again, etc.  There must be some significant computational load that happened with 11.19.

EDIT It seems to occur every 4-6 game seconds in the server game at normal speed, just by watching the clock tick.

EDIT 2 For whatever reason, I've been able to connect longer today than I have in days.  Has anything changed or am I just lucky today?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 02, 2014, 01:17:07 AM
I have not changed anything on the server. It is odd that Carl and Sarlock report a different point at which the performance issue arose. Is it still present in 11.21? I thought that this had been eliminated when the wayfinding bug was fixed.

Incidentally, testing on the way-improvements branch, which is closely based on the 112.5-merge branch, which forms the basis for the next major release, shows much more reliable connexions than testing with the 11.x branch using a saved game from 1779: the 11.x branch will engender a desync very shortly after connexion, whereas the way-improvements branch will allow the client to stay connected for as long as I tested, which was over an hour.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 02:52:01 AM
This may very well be the source of the issue: having over 3,000 ships all way-finding at the same time.  Perhaps the jerkiness was introduced earlier but we only started to notice it once we reached a certain amount of convoys in motion.

We'll see if the merge to 112.5 resolves this (once the conversion is complete).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 02, 2014, 10:47:42 AM
I have not changed anything on the server. It is odd that Carl and Sarlock report a different point at which the performance issue arose. Is it still present in 11.21? I thought that this had been eliminated when the wayfinding bug was fixed.

The degree of certainty in Sarlock's assertion makes me suspect that I would have reached the same conclusion had I tested for longer ;) I'll take another look later.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 06:21:40 PM
Unfortunately I have a very vague understanding of the way the network interface is coded, but it seems to me that there should be a way to resolve the frequent desynch issue.  I just had another one occur right when there was a seasonal update to the area that I was working in.  Given that there is a fair amount of CPU load now, for both server and client, how does the system ensure that both systems are in alignment with their clocks?  If one CPU is computing faster than the other, how does it realign itself?  Is there a mechanism for the client to speed up or slow down to keep in time with the server?

Without knowing the details, I imagine that a desynch occurs when the clocks reach a certain spread apart... or are there other factors involved?

If there's a way to significantly speed up the map destruction process, it would help a lot... the worst part of desynchs is that you have to wait 5 minutes to reconnect again.  Not only is this a long time to wait but it also forces any other players in the game to wait that long as well before they can continue playing.  There has been periods where 2-3 players are all trying to play but we each get desynched and then you spend most of your time just waiting to play.  For now I am only logging in to the game when there is only myself playing - any additional players and I desynch far more frequently.

re: the "jerkiness"
Carl, you may be right in your determination of when it started.  We only noticed it in the server game recently but it may have occurred before and we just didn't have enough convoys in motion to see it.  Your GB map has a lot of convoys and would probably have highlighted the issue before we saw it.  There is some computational load that was added that seems to be dragging things down every time it does its calculation (every 4-6 seconds, it seems, in the server game).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 02, 2014, 06:42:16 PM
The way that it works is that the client and server produce the same result in parallel: information is sent from the server to the client whenever any other player performs a task to update the client's world, and from the client to the server whenever the local player performs a task. The simulation is broken down into steps, and it is imperative that the action is performed in precisely the same step on the server and every client, or else they will get out of sync and disconnect. The server frequently checks with the client whether it is in sync by checking whether a sample of important variables, most importantly the random number generator seed, is identical for the same step number on the client and server. If there is any difference, the server will kick the client. The server will also kick the client if the client runs ahead of the server (the client can safely run behind the server: it will just cause a delay between a player sending a command and it being executed).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 07:20:40 PM
Is there a mechanism for the client to speed up or slow down to keep in time with the server?
There is, unfortunately it does not handle the case where the server is overloaded very well. I've had a chance to continue working on improving things this weekend, but it'll likely still be a couple weeks before I'm happy with it. It's easy to have the client maintain time with the server, it's hard to do it in a way that doesn't make you seasick watching the vehicles!

There's also a bug in the existing algorithm that can result in the client falling farther and farther behind. I ended up over 30 seconds behind once within 5 mins of connecting. That would make it virtually impossible to build anything.

Finally, the server itself is much more erratic than I can duplicate with a local server. I suspect due to its VPS nature. Likely trying to run a heavily loaded server on a VPS is futile. And note, heavily loaded won't show up on any CPU utilization graph, the simutrans workload is too spiky.


Without knowing the details, I imagine that a desynch occurs when the clocks reach a certain spread apart... or are there other factors involved?
jamespetts answer is good. Although in the case of the client running ahead it disconnects itself rather than the server doing the kicking.
You can run the game with 'simutrans-experimental -debug 2 -log', and check the resulting simu.log file after a desync for the reason. Most common would be 'wanted to execute in past' meaning the client ran ahead, and 'checklist mismatch' meaning a game bug.
If you're running ahead, you should set additional_client_frames_behind to a higher number. Also while closely watching the timing lately, I've found things work much better if the sum of server_frames_ahead and additional_client_frames_behind is integral with server_frames_per_step. So for the current server settings, you want client settings of 4, 9, 14, etc. Also @jamespetts - server_frames_between_checks should also be integral with frames_per_step.


If there's a way to significantly speed up the map destruction process, it would help a lot... the worst part of desynchs is that you have to wait 5 minutes to reconnect
I see jamespetts made a change trying to help, but most of the delay is coming from the removing from halt lists section which is shared with Standard. I took a quick look and it looks safe to skip when destroying the world. @jamespetts - care to assess that section closer?  it's responsible for 48 of the 52 seconds the map currently spends unloading.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 02, 2014, 08:14:24 PM
TurfIt - thank you very much for your input. I have had another go at reducing the map unloading time based on your latest suggestion, which is now on the 11.x branch: I should be very interested in any comments on this.

I must confess to being slightly confused by what you mean by "server_frames_between_checks should also be integral with frames_per_step": perhaps I am just being dim, but I should be very grateful if you could elaborate. Thank you.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 08:21:05 PM
Evenly divisible by, or multiple thereof. The idea is to have the timing message sent always after a frame that includes a step().
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 02, 2014, 08:42:20 PM
Ahh, I see - I have now made some modifications to the simuconf.tab on the Github repository, which I hope will address these issues. However, I cannot find a separate setting for "frames_per_step", only a setting for "server_frames_per_step". Am I missing something?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 08:50:12 PM
Nope, just me missing a word. server_frames_per_step is the setting, which you'd changed from 4 to 5 on the server. Hence the default 256 for checks should be changed too.

For the unloading changes, as long as you assessed the impact of the skipping those calls, then it's fine. I'd taken a quick look and it seemed the entire haltlist was deleted later anyways, so no need to remove them one by one. But it needs to be examined in detail to make sure no remnants of the old map hang around when bypassing sections of the destructors.

EDIT: the frames_ahead and _behind should be multiples of the server_frames_per_step setting, not the frames_between_checks setting as you added to the text in github.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 09:17:48 PM
There's also a bug in the existing algorithm that can result in the client falling farther and farther behind. I ended up over 30 seconds behind once within 5 mins of connecting. That would make it virtually impossible to build anything.

Thanks TurfIt... experientially, I have encountered this issue a few times, where the delay between sending a build command and receiving it from the server was well over 10 seconds.  Usually, though, it's a 2-5 second delay.  Typically it's worse at the beginning of the month and starts to improve by 1:00:00.

Most likely times to desynch are during seasonal snow level changes, the beginning of a new month (almost guaranteed to desynch within the first 10:00 of the new month) and when another player is online.  I'm also more likely to desynch while building things/vehicles.

Hopefully this helps... I appreciate all of the work you two are doing on this.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 09:27:33 PM
That does sound very much like you're experiencing the 'execute in past' type desyncs. But do please check the log to confirm.
I'd suggest trying to set the additional_client_frames_behind = 4 or 9. Default is 0. This does add extra lag (333ms for 4), but that's better than disco city...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 09:36:20 PM
Code: [Select]
Warning: nwc_tool_t::rdwr: rdwr id=8 client=5 plnr=3 pos=6336,764,-8 wkzid=8218 defpar=a,6346,756,-8,3529,29,BrigAddMail init=1 flags=0
Warning: network_check_activity(): received cmd id=8 nwc_tool_t from socket[488]
Warning: network_world_command_t::execute: wanted to execute(8) in the past
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset

It's a long log for about a 5 minute connection with the server, but this seems to be the most important part.  I can send more if it's helpful.  Was building a new ship and then desynched.

When I first connected I was experiencing a 8-10 lag time between action and reply from server.  It improved to about 3-4 seconds around the time I disconnected.

EDIT: Currently at additional_client_frames_behind = 4, I'll try 9.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 09:46:27 PM
The log should also be showing 'NWC_CHECK: time difference to server:' messages. If the number is negative, you're running ahead. Based on your/the server settings, you should have had ~750ms margin. Meaning if you ever see the time difference less than -750 (more negative), you're at risk for a desync. You can run ahead without desyncing, it only matters if you or another player is performing a command at the instant you are ahead.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 10:08:37 PM
Hmmm, I can't find that message in the logs.

I get:

Code: [Select]
Warning: network_check_activity(): received cmd id=9 nwc_check_t from socket[488]

But no time difference messages.

Just tried again with additional_client_frames_behind = 9.  I was able to connect for about 1:00:00 of game time.

Desynched around 0:20:00 in to a new month.  I very consistently desynch around this time.

Code: [Select]
Warning: karte_t::interactive: sync_step=583936  server=[rand=826554337 halt=1025 line=1 cnvy=3541 ind_dns_prop=3816 act_ind_dens=10855 traffic=14774226] client=[rand=1220077208 halt=1025 line=1 cnvy=3541 ind_dns_prop=3816 act_ind_dens=10855 traffic=14774220]
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

Different message this time.  I was actually reading on the forums when it happened, so it wasn't anything that I was doing at the time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 02, 2014, 10:18:42 PM
I think you need a higher debug level to see that one. Try with '-debug 3'.
The checklist mismatch is a genuine game bug that James will have to track down. They can be a royal PITA to find...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 02, 2014, 10:22:25 PM
I think that at least one checklist mismatch bug from 11.x is fixed on the 112.5-merge branch (by Bernd Gabriel).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 02, 2014, 11:47:33 PM
It seems like the change to "additional_client_frames_behind = 9" has helped a lot.  I don't seem to be getting time mismatch desynchs anymore.

I had a checklist mismatch around 3:00:00 and another one just as the new month opened.  It seems consistent when the month opens that a checklist mismatch occurs.

Code: [Select]
Message: NWC_CHECK: time difference to server -1884

Was the lowest (most negative) time difference I could find.  It floats around a lot, sometimes positive up to 1000 or more, sometimes negative.  Doesn't go below -1000 very often.

Largest (most positive) was about 9000, most of the time it was between -500 and +1000.

Getting a ton of:

Code: [Select]
Message: hashtable_tpl::put: Duplicate hash!

Hundreds of them in a row.

All in all, however, it is much nicer to play with desynchs only happening every 3 game hours or so.  Fair bit of server lag but I can live with that just fine.  Thanks Turfit! :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 06, 2014, 02:41:46 AM
AP, can you remove those three houses at Monkington?

At Camberford, I think it would be better if you went through north side of city hall.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 06, 2014, 06:38:36 AM
Getting more desynchs again... could be because of the added convoys in the past few game years.  Most recent desynch was a time difference of -1900.  Can additional_client_frames_behind be increased beyond 9 (with the consequence of even more lag) to combat this?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 06, 2014, 07:52:23 AM
I'm finding it impossible to stay connected to the server for more than a few seconds at the moment. Which is odd because it held the connection for several hours whilst I build the inter-island railway.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 06, 2014, 03:34:54 PM
Yeah, I was fine two days ago, the connection issues started yesterday.  That said, it had been getting a bit slower over the past few days, so I think the server load is increasing again.  The time differences between server and client are fluctuating over a wider margin.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on March 07, 2014, 10:55:51 PM
yikes... two weeks away, someone took over!

I don't suppose I could have my company back?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 07, 2014, 10:59:51 PM
Ohh dear. Should I extend the time before a player is automatically unlocked? How many years was it that you were away?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on March 07, 2014, 11:02:31 PM
can't say really... it has been many years since I built anything (surely more than 10). But I would connect every now and then.

edit: looking in saved games, I definitely connected on 1779. But last thing built was 1764.

edit: the new owner doesn't seem to have created any new lines or stops. It's true though that I kind of lost interest in this game, but at least while there are available slots, I don't see why they should take over an existing company.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 08, 2014, 12:18:43 AM
I suppose that, if the player thought the company abandoned, he/she might have thought it more interesting or easier than starting afresh. I should be interested in any other views on the question of the time limit for unlocking players.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 08, 2014, 12:54:54 AM
I wouldn't mind it extended... going on vacation for 10 days next week and I might not be able to connect during that time (in fact, I highly doubt it - the hotel wireless likely won't be adequate).

The new player might have just been playing around, I haven't seen them do anything with that company and it might open up again in a few more days.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 08, 2014, 01:03:49 AM
What figures would people suggest for the time before a company is unlocked?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 08, 2014, 05:02:42 AM
I think 15 real life days would probably be ample... as to how many game years this translates to, it depends on how often people are on to advance the clock.  Right now we're advancing about ~1 year per day, so 15 game years... but in earlier years we were on more often (due to less disconnects) and we were close to 2 game years per real life day, which would be 30.  I think if you set it to 30 years, that would be sufficient - beyond that, it's highly unlikely anyone is interested in playing anymore.  Less than that and we run in to the issue that asaph had where his company was taken over after a period of inactivity.

I was going to ask if you'd be kind enough to log in to my company halfway through my vacation to just quickly build a tile to reset the timer, but if you set the timer to a larger amount then we wouldn't have to worry.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 08, 2014, 06:13:40 AM
At this rate, some places might turn into rail and road spaghetti, which does reflect real life, so it's all good.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 08, 2014, 08:08:53 AM
yikes... two weeks away, someone took over!

I don't suppose I could have my company back?
Are you the owner of Ex Insulus(?) Navigation Company?
It's 1784/11(look at the chat room lol) when someone took over your company and changing it to Fodus Inc and the colour.. He left almost immediately though.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 08, 2014, 10:59:11 AM
Asaph - would you like me to reset the password for that company?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: asaphxiix on March 08, 2014, 07:02:45 PM
I'd like that, yes, thank you James :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 08, 2014, 07:05:01 PM
At this rate, some places might turn into rail and road spaghetti, which does reflect real life, so it's all good.

Indeed, the rate of urban expansion is amazing.  It's not even 1800 yet.  Many of the eastern cities that I have been serving with passenger ship/canal routes have grown from 5,000 citizens to 25,000-30,000 citizens in just 40 years and have mostly all joined together in to one big urban stretch.  By 1850 they are going to be massive.

I am going to continue to serve these eastern cities with canal and ships and see how that performs, at least until after 1850 when better rail infrastructure comes available.  While a bit slower, canal ships have the advantage of not getting bogged down in road traffic.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 09, 2014, 01:35:06 AM
Fodus Inc. is now unlocked - apologies for the delay!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 09, 2014, 03:30:46 AM
Please try the attached patch. It appears to keep clients from falling way behind, and more smoothly adjusts the timing. Assuming neither server nor client is overloaded of course (which the actual server shows signs of at the moment - please check server log for 'server lagging by' messages after applying patch).

Also, applying mingw_sdl.diff would be nice so that it actually compiles the file rather than skipping it...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 09, 2014, 12:41:57 PM
Thank you very much for that - I have now applied this to the 11.x branch. I will update the server presently so that we can test how it now performs. That is most helpful.

As to the SDL compilation - I had set the preprocessor directives as they were to allow for optional SDL compilation in MSVS: I have modified it now so as not to interfere with compilation in MinGW.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 09, 2014, 01:59:27 PM
Now updated to 11.22, incorporating TurfIt's patch, increasing the speed of joining a new game (by reducing the time taken to unload the map) and fixing a few other bugs. I should be very grateful for any feedback on whether this makes things any better.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 09, 2014, 02:40:37 PM
the server certainly starts quicker after connecting with 11.22, but I have yet to test out connecting for a long duration.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 09, 2014, 04:12:11 PM
What figures would people suggest for the time before a company is unlocked?

I think it needs to be specified in "real life days" not in game years, if at all possible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 09, 2014, 06:41:58 PM
There is no mechanism for doing so, and it would be rather difficult to code such a thing. I have extended it to 180 months from 120 for now.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 09, 2014, 06:44:50 PM
Thank you, TurfIt!

Connection time has decreased from about 2-3 minutes to less than a minute... much nicer!

Just testing stability now... the server is starting to get really laggy from the sheer amount of activity on the map, so it's hard to gauge.

EDIT: It seems more responsive now (even with the lag).

EDIT 2: James, can we increase it some more?  180 months, at a max of 24 months/real life day, is 7.5 days before a player loses their company.  We can increase that to 360?  That gives a full half month, which is helpful for those of us about to leave to Hawaii for 10 days  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 09, 2014, 10:15:37 PM
Please try the attached patch. It appears to keep clients from falling way behind, and more smoothly adjusts the timing. Assuming neither server nor client is overloaded of course (which the actual server shows signs of at the moment - please check server log for 'server lagging by' messages after applying patch).

I am having a spot of bother merging this into the 112.5-merge branch, which is based on the latest Standard nightlies, as opposed to the 11.x branch, which is based on an older stable version of Simutrans-Standard. It seems that there are some significant architectural differences beyond changing the name of "umgebung_t" to "env_t". Any assistance in how this might best be merged into the latest version would be most welcome.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 09, 2014, 10:31:28 PM
Standard has for some bizarre reason split the interactive into several functions (each called once - what's the point...). But the code should still be the same (excepting the renaming), just moved around. I was planning to add it to standard once we see how well it works here.

And if you want a true spot of bother, try an execute in past desync on a server. Yup, my server desynced from itself! Something rather weird with that nwc_routesearch thingy...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on March 10, 2014, 12:11:30 PM
Standard server has never ever (to my knowledge) been hitting a performance issue, even on virtual servers. Although way search certainly (especially with many ships and large maps) may  take longer than on a fast client.

By the way, you patch may create performance issues by printing a warning each step if diff is negative. Make this better a dbg->message (or change the text, if this really occurs rarely.)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 10, 2014, 04:46:17 PM
Setting the additional frames behind server from 4 to 9 seems to help connection stability quite a bit.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on March 10, 2014, 05:44:16 PM
Since at least the start of the new game, all I can get is "Loading game... loading new map... [and then instantly] lost synchronization with server."  Most frustrating!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 10, 2014, 08:38:44 PM
W. Lindley - what version of the pakset are you using?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 10, 2014, 09:13:35 PM
Standard server has never ever (to my knowledge) been hitting a performance issue, even on virtual servers. Although way search certainly (especially with many ships and large maps) may  take longer than on a fast client.
Standard is certainly susceptible to the same client timing issues. Experimental just does a good job making them a problem... Large maps, 4000 ships, and the extra load compared with standard.


By the way, you patch may create performance issues by printing a warning each step if diff is negative. Make this better a dbg->message (or change the text, if this really occurs rarely.)
Which warning would be creating an issue?
Clients already print 2 warnings for every check command, and the 3rd relevant message containing the actual time diff was moved to a warning from a message to keep them together (also -debug 3 is all but useless with all the crap being spewed).
The added server lag message should be monitored IMHO. Otherwise servers run with no indication of overload. I doubt logging a single line every step would affect performance in any noticeable way. Ideally it'd occur never with a fast enough server for the game, but could be a message instead of warning (at risk of being buried though), or be changed to???
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on March 10, 2014, 10:33:05 PM
I just suggest to change the first dbg->warning in the patch to a dbg->message. There are two more debug level (5) which can print out timing informations on each frame. One might consider to change those client messages to those.

About the lagging warning for the server: I agree with you.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 10, 2014, 11:23:06 PM
Getting more and more of these as the server gets slowly loaded up more:

Code: [Select]
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 -1909
Message: network_command_t::rdwr: read packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr: rdwr id=8 client=2 plnr=3 pos=5686,519,-8 wkzid=8216 defpar=l,4325,743 init=1 flags=0
Warning: network_check_activity(): received cmd id=8 nwc_tool_t from socket[488]
Message: nwc_tool_t::pre_execute: append sync_step=456301 wkz=8216 init
Warning: network_world_command_t::execute: wanted to execute(8) in the past
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0

Can additional frames be set beyond 9?  Going from 4 to 9, would the next step be 14 or 16? (+5 or squares)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 11, 2014, 01:20:53 AM
You can set it to anything you want. Keeping total in multiple of 5 (for the specific other settings on this server, 6+4, 6+9, 6+14, etc.) helps the smoothness when running steady, but I just connected to take a look and wow, that is one horrid stutter. It's only running at 9-10 fps rather than the 12 set - server is not keeping up. So, there won't be much help keeping it to 5's.
Note you'd need to be 2 seconds behind, or 24 frames to have avoided that desync.


I just suggest to change the first dbg->warning in the patch to a dbg->message. There are two more debug level (5) which can print out timing informations on each frame. One might consider to change those client messages to those.
Maybe you've misread the patch? It's not printing every frame, but every time a NWC_CHECK message is received. And receipt of that message (and indeed every command from the server) already triggers 2 warning messages. Likely all the network messages should be changed from level 2 to 3?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 11, 2014, 01:39:37 AM
You can set it to anything you want. Keeping total in multiple of 5 (for the specific other settings on this server, 6+4, 6+9, 6+14, etc.) helps the smoothness when running steady, but I just connected to take a look and wow, that is one horrid stutter. It's only running at 9-10 fps rather than the 12 set - server is not keeping up. So, there won't be much help keeping it to 5's.

Note that I have reverted to 4 on your advice, so multiples of 4 would be better here. Would there be any benefit to de-reverting to 5 again?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 11, 2014, 01:54:53 AM
What did you revert? If you set server_frames_per_step back to 4, that would explain the current apparent server overload. I'd suggest keeping that 5, and even dropping fps to 10 until all those ships go away... Are you getting the 'server lagging by' warnings in the log?
If you set server_frames_ahead back to 4 from 6, then everyone should just add the 2 back onto their additional_client_frames_behind settings.
The need to keep (frames_ahead + frames_behind) % frames_per_step == 0 should go away after my next trial patch which spreads the step() load out across the frames...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 11, 2014, 10:23:37 PM
If anyone is wondering what crashed the server, it's because I raised land and a ship ran aground.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 11, 2014, 11:22:46 PM
I did indeed set the server_frames_per_step back to 4 - do you think that I should change it to 5 again?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 12, 2014, 12:15:13 AM
Is the server not horribly lagging? I thinks it needs all the help you can gives.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 14, 2014, 10:46:05 PM
Standard has for some bizarre reason split the interactive into several functions (each called once - what's the point...). But the code should still be the same (excepting the renaming), just moved around. I was planning to add it to standard once we see how well it works here.

Hmm - I have tried twice and given up trying to merge this myself with the latest code. The method void karte_t::process_network_commands(sint32 *ms_difference) does not have frame_timediff or time_to_next defined in scope, so, in order to merge this, I should have to understand the intention of the code, which is well beyond my capability at the present. I shall have to wait for it to be merged with Standard, I think, and incorporate the merged version from that in order to incorporate it into the 112.5-merge branch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 16, 2014, 03:46:24 AM
the server is quite laggy right now with nearly 4700 convoys running. I can't stay connected for more than 5mins at a time.

While running a local copy, my CPU and RAM are at its limits. 2.4Ghz going full tilt and more than 1500mb RAM usage.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 16, 2014, 11:57:06 AM
the server is quite laggy right now with nearly 4700 convoys running. I can't stay connected for more than 5mins at a time.

While running a local copy, my CPU and RAM are at its limits. 2.4Ghz going full tilt and more than 1500mb RAM usage.
It takes me around 17.8% of CPU, but 1.2 GB of memory is needed to run it offline.. Also, fast-forward is not possible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 16, 2014, 12:37:25 PM
Hmm - too many ships (caused by too much demand for intercontinental freight traffic) and too much city growth I suspect is responsible. These things will have to be tamed for future versions.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 16, 2014, 04:45:44 PM
I'm still able to get 6-8x fast forward on a local copy.  This is on a fast (4.4GHz) computer, however.

I've increased frames to 14 and this has helped a bit but I still can't remain online more than 10 minutes at most.  If there is anyone else on the server at the same time, disconnects are far more likely.  For the most part I am avoiding a login if someone else is already connected, and waiting for a time when no one is on.

I am gone for 10 days and won't be able to log in during this time (highly unlikely the hotel wireless will be stable enough to connect-if it even allows the port(s)).  We're only progressing at a rate of 1 year/day, so I should be fine while I am gone.

For the next map, I'd strongly suggest about half the size and more square.  It will probably require 5 times less convoys (or more) to connect the map together.  The 6000+ tile cross-map journeys require dozens of convoys to effectively service each line.  Significantly taming city growth will help as well.  Already there are huge areas that have become one big continuous urban zone.  When faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 16, 2014, 05:23:33 PM
  When faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.

I rather hope some of them will be travelling by rail ;-)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 16, 2014, 06:29:25 PM
I'm still able to get 6-8x fast forward on a local copy.  This is on a fast (4.4GHz) computer, however.

I've increased frames to 14 and this has helped a bit but I still can't remain online more than 10 minutes at most.  If there is anyone else on the server at the same time, disconnects are far more likely.  For the most part I am avoiding a login if someone else is already connected, and waiting for a time when no one is on.

I am gone for 10 days and won't be able to log in during this time (highly unlikely the hotel wireless will be stable enough to connect-if it even allows the port(s)).  We're only progressing at a rate of 1 year/day, so I should be fine while I am gone.

For the next map, I'd strongly suggest about half the size and more square.  It will probably require 5 times less convoys (or more) to connect the map together.  The 6000+ tile cross-map journeys require dozens of convoys to effectively service each line.  Significantly taming city growth will help as well.  Already there are huge areas that have become one big continuous urban zone.  When faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.

Reducing the size is a measure of last resort, I think. The next major release has a more efficient search algorithm for ships, which should help somewhat. It will be important to reduce the length of connexions between industries, as it is the humorously anachronistic intercontinental milk trade that is driving much of the ship activity that is causing such a slow-down. Certainly, reducing town growth will have an impact, too, especially as the number of industries is linked to the population size.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 17, 2014, 08:16:10 AM
as it is the humorously anachronistic intercontinental milk trade that is driving much of the ship activity that is causing such a slow-down. Certainly, reducing town growth will have an impact, too, especially as the number of industries is linked to the population size.

Agreed on both counts... and had a good laugh at your chosen wording for the absurd milk trade that is reaping 50% of the overall profits.  It is certainly excessive but also accounts for a relatively small percentage of cross-ocean traffic.  My cross-ocean routes currently include passengers, mail, milk, coal, grain, textiles, planks, beer, iron, hardware and wrought iron.  And of course milk earns more profits than the rest combined.  :)  Even with a more efficient ship routing system and slower population growth, the server might still be eventually bogged down as the years progress on such a map.  Reducing to 5000x2000 might make the game a lot more playable in later years.


Quote
I rather hope some of them will be travelling by rail

AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 17, 2014, 08:36:18 AM
Reducing the size closes of all possibility of very long routes; I should prefer just to have fewer towns. Indeed, the current map seems a little overcrowded of towns in some areas.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 17, 2014, 09:23:13 AM
AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)

You should be able to lower track in shallow water, so do all the lowering there.

---

Since true capacity is "capacity & speed", the later years requires fewer convoys than what is used now from speed alone.
Add to that motorization and pax convoys are further reduced.
The reduced travelling times counteracts the motorization to an extent, but since freight and mail are not affected by motorization, the net effect is fewer convoys being used.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 17, 2014, 06:39:41 PM
AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)
You should be able to lower track in shallow water, so do all the lowering there.
Correct. :D I did and it works. Just be careful not to cluster your gradients too close together or the locomotives will struggle. Looking forward to dual-heights :) .


Reducing the size closes of all possibility of very long routes; I should prefer just to have fewer towns. Indeed, the current map seems a little overcrowded of towns in some areas.

I think partly the trouble is that this is a water map. If it were a land map, for a map of this size there would a lot more space. So the same number of towns could be much further apart.

I still think we're substantially short of industry for the population. Most large towns have one shop... which is presumably because nobody has any money due to chronic unemployment!

And of course, the city growth factor... :o

Agreed on both counts... and had a good laugh at your chosen wording for the absurd milk trade that is reaping 50% of the overall profits.  It is certainly excessive but also accounts for a relatively small percentage of cross-ocean traffic.
Milk is the only one of my routes which reliably reports a profit, which is both because of this and because I used more small ships rather than few large ships when setting it up (reduces the peaks and troughs). Long routes and infrequent (but lucrative) arrivals seem to confuse the in-game accounting!

Milk routes only account for a handful of my ships also, there isn't the demand for any more.

I've found Bulk Goods to generate a reliable (and realistic) profit if you can make them work full both ways. The lack of industry is an issue here, because there are so few matching industry pairs (e.g. coal out, stone back). You can't haul the same cargo both ways unless you're very careful because of industry interlinking. The grain and wool bulk cargos seem to be more troublesome than coal/stone/clay.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 17, 2014, 07:01:17 PM
Quote
I think partly the trouble is that this is a water map. If it were a land map, for a map of this size there would a lot more space. So the same number of towns could be much further apart.

Absolutely agreed.  The vast majority of the centre of the map is just a few islands and water.  We could easily remove 2000 tiles from this area by moving the islands around a bit and shrinking the size of the large sections of open ocean.  It would still be the same map effectively, just a bit shorter across the middle.


Quote
I've found Bulk Goods to generate a reliable (and realistic) profit if you can make them work full both ways. The lack of industry is an issue here, because there are so few matching industry pairs (e.g. coal out, stone back). You can't haul the same cargo both ways unless you're very careful because of industry interlinking. The grain and wool bulk cargos seem to be more troublesome than coal/stone/clay

I ran a test with this map in a local version and I had set up large freight collection yards for the two main islands and ran a series of mixed-hold ships back and forth.  Then I had feeder connections deliver all material to and from these collection yards.  This made things considerably more efficient as ships were travelling both ways with a significant load, and since freight isn't that sensitive to delivery times, it worked fairly well.  For pax delivery, however, it was more effective to directly connect the destinations.


Quote
Since true capacity is "capacity & speed", the later years requires fewer convoys than what is used now from speed alone.
Add to that motorization and pax convoys are further reduced.

There is also the 2 hour loading time for the East Indiaman which slows things down considerably as well.  With faster loading times, less convoys are required.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 17, 2014, 07:56:23 PM
I suspect it will only get worse in the next century or so.. People will start doing railways and they are slow and unprofitable, which means more freight lines have to be connected to fund the railways. Slow moving trains doesn't help either. I would say the size of the map did exceed the limit of the program.

At the moment the server is keen to "instant synchronise"..
But less city(both number an growth) and industry will probably help, but it's still doubtfully enough.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 17, 2014, 11:01:55 PM
People will start doing railways and they are slow and unprofitable, which means more freight lines have to be connected to fund the railways

Are they still unprofitable?  :-[ I remember them being a total pain in the last online map, really difficult to make money, but was hoping that had been fixed.

As for slow, they are at least faster than sailing ships and post bikes  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 17, 2014, 11:16:24 PM
The issue raised about the number of towns and the size of the ocean is an interesting one. What really drives computational and memory load is transport infrastructure, and what, in turn, drives that are towns and industries. We could afford to have a larger map with larger land areas (and therefore the potential for longer journeys) if we had the same number of towns with much slower growth, and possibly even more industries, although care would have to be taken not to have too large an area of land based wilderness, which is not very realistic for the UK.

(Forgive the code box - this prevents a misinterpretation of my symbols as BBCode.
Code: [Select]
Perhaps, in a future map, have an equivalent of the Scottish highlands in the [i]middle[/i] of the map. In the following diagrams, take [L] to be lowlands, [H] to be highlands, [I] to be small islands and [S] to be sea. Something like this might work:

[L][L][L][H][H][H][L][L]

Or possibly

[L][H][H][H][L][L][L][L][L]

Or even

[L][L][L][H][H][L][L][L][L][/s][/i]
[code]
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 18, 2014, 12:49:07 AM
At the moment the server is keen to "instant synchronise"..
But less city(both number an growth) and industry will probably help, but it's still doubtfully enough.

go into the main config directory and open up simuconf.tab with notepad or a similar word editing program.
In simuconf.tab, change "additional_client_frames_behind" to 19, this should help reduce desync considerably.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 18, 2014, 02:20:20 AM
The computation problem at the moment is due to ships stacking at docks, and the 'hold' concept that was added to the pak. 35% of the CPU time is currently being spent loading convois, and 38% moving them around. The normal CPU hogs of vehicle pathfinding and pax/goods routing are at 20% and 3%.

Ships have the problem of infinite stacking which results in the loading calculations being performed on more convois than would fit into a station otherwise. This is exacerbated by the 'holds' that were added multiplying the number of vehicles to be checked greatly. A snapshot from yesterday shows 4610 convois comprised of 28520 vehicles, and 10% of them loading at any one time.

Stacking and/or 'holds' need to go if you want to run 4000+ ships around...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 18, 2014, 03:08:00 AM
A highlands style map would certainly be interesting.  We'd end up criss-crossing it with canals in short order and likely run in to the same situation as we have currently with thousands of convoys zipping around.  It might be lessened, however, if the map isn't as wide and the distance between most industry connections on the island isn't as great as those that we encounter in the current game.  The wider the map, the more convoys are required for each industry and pax/mail connection.

Interesting results, TurfIt: I didn't realize that each ship hold was treated as a separate vehicle.  That certainly adds significantly to the load on the system.  It could be worth considering making a distinct East Indiaman and brig for pax/mail transport (600 pax, 1000 mail/150 pax, 250 mail) to reduce the number of vehicles used for this purpose by a factor of 8.  I probably have 1500+ pax/mail convoys serving the eastern island and my stations are still filling up with demand so fast that I can barely keep up... and so I am faced with the tough choice between continuing to bog down the system with exponential convoy growth or leave it be and suffer the consequences of having hundreds of thousands of unhappy passengers.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 18, 2014, 04:46:59 AM
changing the max pieces from 8 to 4 also offers a theoretical 50% decrease.

The very small barges and horse carriages could also be combined into one convoy.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 18, 2014, 11:00:31 AM
The ultimate thing that will, on any map of any type, drive computational effort is transport infrastructure, and the thing that sustains that is urban population and industry. The size and style of the map determine play style: the density determines computational load.

TurfIt - thank you for the interesting analysis apropos the number of vehicles loading at any one time. I wonder whether there is a means of reducing the computational load in respect of vehicles which are loading for a very long time? Edit - and it would also be interesting to know which specific functions are the ones that are shown in your analyses to generate the most load.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 18, 2014, 11:09:11 AM
Are they still unprofitable?  :-[ I remember them being a total pain in the last online map, really difficult to make money, but was hoping that had been fixed.

As for slow, they are at least faster than sailing ships and post bikes  ;)
For a route with 50% or more tunnels, not a chance mate... (480quid for a km in maintenance...)
I will have to re-plan my network to see whether to continue the underground plan or use the overground strategy(but it's too hilly in the south).
I doubt even freight route will make profit (didn't try that though).
I've set up a local save file to test the profitability of the trains, even the overground part is struggling to make profit.
In the later days, electrification will probably help as EMUs are cheaper to run, but we shall see what will happen.
AEO's network is likely to be self-sustainable(just). (But will take ages to cover the actual building costs)


go into the main config directory and open up simuconf.tab with notepad or a similar word editing program.
In simuconf.tab, change "additional_client_frames_behind" to 19, this should help reduce desync considerably.
Thanks for the tips, now i can actually do something other than just staying connected..

The issue raised about the number of towns and the size of the ocean is an interesting one. What really drives computational and memory load is transport infrastructure, and what, in turn, drives that are towns and industries. We could afford to have a larger map with larger land areas (and therefore the potential for longer journeys) if we had the same number of towns with much slower growth, and possibly even more industries, although care would have to be taken not to have too large an area of land based wilderness, which is not very realistic for the UK.

(Forgive the code box - this prevents a misinterpretation of my symbols as BBCode.
Code: [Select]
Perhaps, in a future map, have an equivalent of the Scottish highlands in the [i]middle[/i] of the map. In the following diagrams, take [L] to be lowlands, [H] to be highlands, [I] to be small islands and [S] to be sea. Something like this might work:
...
[L][L][L][H][H][L][L][L][L][/s][/i]
[/quote]
It certainly will make this a lot more difficult to play with. But making it difficult to play with is probably the key point to lower the CPU load...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 18, 2014, 05:50:41 PM
I wonder how many more ships we can add to the map before the server completely seizes up...

We're almost at 6 million residents, and that growth happened in just 50 years.  There will likely be a population over 10 million by 1850, 15-20 million by 1900.  While trains may help in theory, with how TurfIt is reporting server load, adding 10-20+ vehicle trains may make the problem worse, given that most of the western size of the map isn't even served for pax/mail yet.  Some of the ships coming up in the next 50 years are single hold ships which will help tremendously in reducing this load.

James - can we consider making a quick addition to the pakset and create a single hold East Indiaman and brig for pax/mail?  Might want to do one for the Clipper too, since I plan to heavily upgrade to that in 1837.  I could probably convert at least 1000 (maybe even 1500) of my convoys over to this form, reducing vehicle count in the game by 8000-12000, which may have huge benefits.  Rather than releasing a whole new pakset version, we could just release that single .pak file and add it to our pakset folder and carry on playing.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 18, 2014, 07:27:26 PM
For a route with 50% or more tunnels, not a chance mate... (480quid for a km in maintenance...)
Well I thought that at first. But tunnel maintenance isn't hugely more than normal track mainenance, and a single track route is only half the maintenance of a double track route. I think it comes down to intensity of operation, how much demand there is. It needs a moderately intense service I think, hence ensuring I had large settlements at both ends.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 18, 2014, 11:41:59 PM
Making "quick updates" is actually not quick at all - every release involves a very great amount of overhead in preparation and ancillary work (especially as the next version of the pakset is already in progress, but is set up for half heights, which is only compatible with the next major release, which is not yet complete). The time would better be spent investigating a longer term solution to the issue of computational load taken by many multiple vehicle convoys waiting for a long time at stops, probably by altering the code rather than interfering with the pakset.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 18, 2014, 11:58:55 PM
True, for a full release.  But it could be as simple as releasing a .pak file and posting the link in here to download so we can put in to our pak folders.  Only people using the server game would need it to keep their pak folder compatible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 19, 2014, 12:14:09 AM
If I understand the problem correctly (I am waiting for TurfIt to reply to my edit to the earlier message enquiring as to what function that he found took the high amount of processing power to confirm the position), the solution might well be as simple as calling the loading function one in every X steps rather than every step for convoys which have more than Y ticks of loading to do before they may leave or one in every Z steps for a convoy which is waiting for a full load and is more than N percent away from achieving that load.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 19, 2014, 12:25:20 AM
We are at 4834 convoys now, but I reduced some excess holds on all lines, so maybe it balances out.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 19, 2014, 12:28:13 AM
I didn't time into halt->request_loading(self) called from convoi_t::laden() which is where all the CPU was going.  How are you handling the loading time? I presume when the convoi is waiting for its departure that it doesn't keep calling laden()... What are you doing with wait_lock? I notice upon game loading many convois with it being reset to the 60000 maximum, and from seemingly absurd values at times (3.5 hours). If the convois are loaded, and waiting to depart, and with the wait_lock set, they shouldn't be calling laden(). You need to look into if all the calls to laden() are legitimate, and if so, hopefully reduce the computation being done therein.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 19, 2014, 12:55:32 AM
Hmm - this is quite complicated. Would you be able to break down the timing a little more? That would be particularly helpful. What I am finding is that laden() is not called constantly, but is called near the end of the loading time, and progressively more often as the departure time nears. It also calls halt->request_loading(self), which, in turn, calls hat_gelhalten() on all convoys currently in the stop. Large chunks of hat_gelhalten() are skipped when the convoy has not moved since the last time that it was called, however. It would thus be extremely useful to know where all the time is being spent among these methods.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 19, 2014, 03:22:50 AM
server seems to have crashed or stalled

to add, the save game also seems to crash at around the 4h mark in April.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 19, 2014, 10:24:57 AM
Hmm - will have to investigate when I have more time. Thank you for the report.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 20, 2014, 08:53:38 PM
...the save game also seems to crash at around the 4h mark in April.

Hmm - I cannot get it to crash on my local debug copy in April, I am afraid, nor is it easy to deduce why the server came to a halt in what on the face of it seems like an infinite loop. I have restarted the server, and taken the opportunity to increase the server frames per second back to 5 to ease load (adjust your additional client frames behind to a multiple of 5 to get the best performance) and increased the months before an inactive player is unlocked to 360. Please let me know if anyone has any more insight into what caused this crash/freeze or whether anyone can reliably reproduce one.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 20, 2014, 11:56:47 PM
It would thus be extremely useful to know where all the time is being spent among these methods.

haltestelle_t::hole_ab() is the culprit. Within it, 50% is being spent on the get_halt() call in the inner loop, and 25% spent handling the binaryheap.

The excessive number of waypoints in the schedules is resulting in far more loops and get_halt() calls than normal. The preponderance of docks is also forcing the get_halt() calls into a search.  Waypoints need to be detected some other way than get_halt().is_bound() which is far too costly in that inner loop.

The binaryheap being created/destroyed for every vehicle on every convoi that's loading is another area for improvement. It would really make sense to load by convoi than by vehicle, especially with ship holds artificially inflating the vehicle count.

Beyond hole_ab(), throughout the loading process there appear to be sections of code that would be better executed when a convoi first arrives at a stop, or leaves it. The time wasted performing the same calculation over and over during the loading is minimal compared to the hole_ab() problem, but fix that and they'll be more significant. It appears the purpose of laden() was misunderstood at some point - there's even a comment in there expressing surprise it's executed more than once when a vehicle hasn't moved...

There also appears to be some shenanigans with wait_lock. Haven't really looked at it yet, but besides excessive values at times (3.5hrs), the loading routines appear to be triggering more often than they should.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 21, 2014, 12:43:56 AM
Thank you very much for your analysis - this is extremely helpful. I will look into this when I have some chance (currently working on calibrating passenger generation for the next major release).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 21, 2014, 04:42:53 AM
Thank you for bringing the server back up... hopefully we can find what is causing it to hang.

Amazingly, I can connect from this hotel.  It takes nearly 10 minutes to download the map, however, so I am only connecting when there are no other players present... I'd hate to hang things for 10 minutes while I connect!  Connection is surprisingly stable, I've been able to stay on for a good 5 minutes a couple of times.

I tried a mock game on local here and in 1835 I am able to get a decent underground rail network going that is able to cover its construction and monthly operating cost.  One significant limitation that AP will run in to is that underground signals aren't available until the 1860's, so you'll have to run a looped double track system under the oceans if you want to run more than one train at a time (or set up empty stations to break things up-but this slows things down).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 21, 2014, 06:02:32 AM
I unwittingly stuck some ships after raising some land.
There are a few off of Brickingport and Emwich.

The server does not seem to handle rerouting of ships elegantly when new land is blocking its original route.
But mysteriously, the ship reroutes just fine most of the time, while extremely rarely ships will run aground. Running aground obviously causes a crash.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 21, 2014, 01:58:05 PM
Thank you for bringing the server back up... hopefully we can find what is causing it to hang.

Amazingly, I can connect from this hotel.  It takes nearly 10 minutes to download the map, however, so I am only connecting when there are no other players present... I'd hate to hang things for 10 minutes while I connect!  Connection is surprisingly stable, I've been able to stay on for a good 5 minutes a couple of times.

I tried a mock game on local here and in 1835 I am able to get a decent underground rail network going that is able to cover its construction and monthly operating cost.  One significant limitation that AP will run in to is that underground signals aren't available until the 1860's, so you'll have to run a looped double track system under the oceans if you want to run more than one train at a time (or set up empty stations to break things up-but this slows things down).
Did you try to try to connect the interchange stations as well? As the line just couldn't barely cover the cost when I tried.
As for AP's problem.. It's something that I never think of, as I will have underground stations in the tunnel sections.
But that probably is the only option, as I really don't wanna see more causeways which kind of altered the landscape quite ridiculously.. :/
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Milko on March 21, 2014, 04:15:26 PM
Hello

In this server you use holds of ships, but I remember that there was a problem with the "length" of the ship with the hols added (http://forum.simutrans.com/index.php?topic=12462.msg123235#msg123235). I see none of you encountered the problem, then the problem is solved?

Giuseppe
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 21, 2014, 06:42:37 PM
Can't say I've noticed this issue... I seem to be able to fill all 7 holds on ships without an issue, even at single tile docks.

VOLVO, I've connected a bit but for the most part the passengers generated on my eastern island create a lot of west-bound traffic.  Almost every coastal city on the eastern island is well served with a criss-cross of canals and shipping routes - there is several million passengers and mail created every year on the eastern side, more then enough to feed profits to the cross-map tunnel network.  With a similar network established for the western cities, there will be a lot of demand for the inter-island rail route -- likely more than it can handle until technology improves.  I think the reason it's profitable is because our map has so many passengers/population.  By 1835ish, there could be 20 million people on the map (if the server survives).

For the eastern cities, I plan to serve all of the cities that I am currently connecting through an underground tunnel/subway system looping around under the entire island.  I will continue serving local inter-city routes with the canal system - I've tested this and found that ships offer a very effective option compared to busses - they do not need to wait for road traffic, travel nearly as fast (faster when road traffic is accounted for), and have a much higher capacity (and therefore need far less convoys in motion than with early road vehicles).  They have a slightly longer wait time at each station but the passengers don't seem to care... and some selections can carry both mail and pax.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 21, 2014, 08:53:20 PM
One significant limitation that AP will run in to is that underground signals aren't available until the 1860's, so you'll have to run a looped double track system under the oceans if you want to run more than one train at a time (or set up empty stations to break things up-but this slows things down).

I hadn't noticed that, but in offline testing I'm trying to figure out how much passenger demand there is (see other thread). There is less that i would have expected...may have to consider freight also.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 21, 2014, 11:45:09 PM
There are certainly lots of opportunity to add freight to the line.  When testing, did you connect my entire network to your hub at Applelock?  Consider that we are still a few decades away from this network and by then the cities will have grown even more... there seems to be plenty of demand for profitable travels.  And, frankly, with interest income on your big cash balance, even if it's not profitable at the start you will still be cash positive.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 22, 2014, 12:29:38 AM
Since most of the line is single track, you can use the American trick of making really long trains to avoid clogging up the lines.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 22, 2014, 07:15:47 AM
Exactly what I did.  I am running 36 vehicle trains, using 4 LMR "Patentees" to pull a 688 pax/1200 mail train.  There was no science behind this configuration, I'm sure it could be improved upon (nearly doubled in length, basically, to reach 64), but it is doing the trick.  Seems to be profitable enough, if you're running 75% full or more most of the time.

Running steam trains in a purely underground application is a little weird, but it works...  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 22, 2014, 09:18:04 AM
They did this on metropolitan railway didn't they..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 22, 2014, 09:41:54 AM
the metropolitan railway had a lot of ventilation holes and special steam engines until the advancement of electricity.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 22, 2014, 10:32:46 AM
Since most of the line is single track, you can use the American trick of making really long trains to avoid clogging up the lines.

That was the plan for later - start with 6 tile trains, keep lengthening the trains and passing loops (and adding more loops) rather than doubling the entire network. There are many precedents for single-track main lines (and Spain is even talking about single-track high speed rail).

I'd rather keep freight on the seaways tbh, since it doesn't have the same speedbonuses that passengers do.

How do TPOs work, i assume it must give a loading time advantage for mail? Do I just use one per train?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 22, 2014, 11:42:31 AM
TPO gives a payment bonus for long distance mail. Loading times remain unchanged.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 22, 2014, 03:10:22 PM
TPO gives a payment bonus for long distance mail. Loading times remain unchanged.
Do you use one per mail train, or do you get bigger bonuses the more you use?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 22, 2014, 03:16:54 PM
Adding more than one TPO makes no difference to the revenue.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 24, 2014, 08:39:43 AM
with a local save, I'm now down to 0.5x speed and the server also seems to be running a lot slower.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 24, 2014, 08:49:23 AM
with a local save, I'm now down to 0.5x speed and the server also seems to be running a lot slower.
No surprise when the number of vehicles has approached 5000...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Isaac.Eiland-Hall on March 24, 2014, 01:11:43 PM
Sorry for offtopic, but you two gave me a heart attack. Some weird server problems, and in my timezone, your two comments were made at 02:39:43 and 02:49:23, which I misread as the same timestamp and thought there must be some problem where all posts on the forum were sharing a timestamp, since the one message quotes the other........... :-/ lol
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 24, 2014, 07:31:53 PM
I can still manage about 3-4x on my laptop, but it's a fairly fast machine.

I ran a local copy and removed a lot of ships (down to about 2000) and was able to get it back up to about 10x.

Running a huge underground railway system in 1836/37 on a local save, construction costs are about $80 million so far (and $3 million/month maintenance), but making about $5 million/month in profits, so it's certainly feasible.  You just have to make certain you have enough pax/mail on each side to run your trains at least half full.  A full train running between the two big islands is earning about $500,000/trip.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 24, 2014, 11:30:53 PM
in 1820, there will be a steamship that can carry 200pax/500mail and has a loading time of 40min/48min.

Replacing all the current pax/mail ships with that should reduce the load.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 24, 2014, 11:52:23 PM
I shall be very interested in reports of how the magical ship of 1820 makes a difference to server performance...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 24, 2014, 11:54:48 PM
It will certainly help with my short-distance canal pax/mail routes (currently served by brigs) as this will reduce the number of vehicles per convoy from 8 to 2.  Higher operating costs, but higher capacity and slightly faster loading time should mitigate this.  Many of my medium-range inter-city routes will benefit as well.

Another 22 game years is a long time to wait, however... (mid to late April, likely)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 25, 2014, 12:35:59 AM
There is also a steam tug in 1816 that can replace all canal only freight service.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 25, 2014, 12:47:20 AM
Ran two simulations on a 2048x128 map, two cities on opposite sides, year 1820:
Same map, same line:

Case 1: 1000 Brigs, 5 passenger/2 mail holds: 8 vehicles total
Case 2: 1000 Wooden paddle ships, 1 mail hold: 2 vehicles total

Test A: No load % at stations.  Boats arrive, wait their required transfer time and head out again.  Most ships in motion.
Test B: 10% load at stations.  99% of boats at stations.

I couldn't notice a discernible difference in speed between the two vehicle types.  With Test A, I was getting around 50x fast forward speed for both cases.  With Test B, with most ships at dock, I was getting around 80-85x fast forward speed.  Clearly the wayfinding drags down performance significantly more than the loading algorithm.

My only means of testing speed was to use maximum possible fast forward speed (I set to 250x in settings).  It was getting about 180x before I started to add the ships to each map.  If there is a built-in better way of gauging performance, I could provide better figures.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 25, 2014, 12:50:05 AM
There is also a faster 18km/h Schooner around the same time as steam boats. Slightly slower loading times than Brig, but with the same capacity.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 25, 2014, 12:57:13 AM
Sarlock - thank you very much for that test. That is very interesting.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 25, 2014, 09:54:11 PM
Quick and dirty patch that cuts time spent loading by 25%, and overall 10% reduction in CPU usage for this game. The 'problems' identified above remain, this just skips loading a convoi if a convoi on the same line at the same stop index going the same way carrying the same freight type has already loaded in a particular step.


I couldn't notice a discernible difference in speed between the two vehicle types.  With Test A, I was getting around 50x fast forward speed for both cases.  With Test B, with most ships at dock, I was getting around 80-85x fast forward speed.  Clearly the wayfinding drags down performance significantly more than the loading algorithm.
I presume you didn't have 10000's of goods packets at the stations that were not loading onto the waiting convois? i.e. the goods were waiting for other convois. This is the situation in the online game killing performance.

Wayfinding is largely insignificant, on average. But is responsible for the long (1000+ ms) hiccups. Hopefully the new ship wayfinding eliminates those.
The slowdown you're seeing with most ships in motion is likely due to experimentals physics. I think I read they're being worked on.

EDIT: patch removed. Superseded below.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on March 25, 2014, 10:11:34 PM
When there was discussion of using the new physics in standard way back, I did some profiling, and the new physics did consume about 10x more time than the standard one (both are not correct anyway, the old is not and the new one isn't either, it is rather more differenciated, but that is not important.) The total time is not much, but it is called every frame, and hence accumulates quickly.

(Btw, wasn't it floating point? Then is should desync after some time if people start to compile with fastmath switches or use a non-intel CPU. Because slight arrival changes could end up in different loading times and hence change overcrowding etc.)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 25, 2014, 10:50:12 PM
The floating point is being handled by a float32e8 class which is using integers for everything. Solves the multiplayer portability problem, but yikes the CPU cost...
For this game, 90% of the sync_step() time is being spent in convoi_t::calc_acceleration() representing 38% of the overall CPU usage (pre my patch above. post it's 44%). A further 9% sync_step() time is actually moving the vehicles.
I'm quite happy with standard sticking with its current physics; Would rather spend the CPU on other more interesting things.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 25, 2014, 11:22:49 PM
Thank you very much for that - I have incorporated this and brief testing shows that it does indeed seem to make a difference. That is helpful. Any views on whether it is worthwhile pushing a new release even though this is the only change from 11.22 so far?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 26, 2014, 12:08:00 AM
Quote
I presume you didn't have 10000's of goods packets at the stations that were not loading onto the waiting convois? i.e. the goods were waiting for other convois. This is the situation in the online game killing performance.

That is correct, the stations were empty of waiting packets, since there were just two stations in the example and ample convois to transport them.

Thank you for the patch... James, it doesn't matter if it's released right away or waits until 11.23 has other components to add.  There isn't much going on in the server game for the next 20 years anyhow, until we reach the early train and steam age.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 26, 2014, 12:29:27 AM
I think it would be nice to see a performance improvement, as the game currently goes at half speed for me.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 26, 2014, 09:21:28 AM
That is correct, the stations were empty of waiting packets, since there were just two stations in the example and ample convois to transport them.

Thank you for the patch... James, it doesn't matter if it's released right away or waits until 11.23 has other components to add.  There isn't much going on in the server game for the next 20 years anyhow, until we reach the early train and steam age.
I think it's safe to say that starting from 1775/1800 is a bit more sensible than 1750..
80 yeas of absolutely no change in vehicles or whatsoever makes people knid of bored..
Thus the railway constructions..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 26, 2014, 09:58:02 AM
Thank you very much for that - I have incorporated this and brief testing shows that it does indeed seem to make a difference. That is helpful. Any views on whether it is worthwhile pushing a new release even though this is the only change from 11.22 so far?
It needs more work. A mixed cargo convoi could inhibit a latter single cargo convoi from loading until it leaves.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 26, 2014, 10:57:53 AM
Turfit - thank you for letting me know. Do let me know of any further developments.

Volvo - the pakset is intended to be started in 1750. If the game was better balanced, and I am working towards making it better balanced, the 18th and early centuries would be filled with the building and then upgrading of intricate canal networks, the generation of revenue from which would be slow enough that they would require careful planning over many game years to bring to fruition, but which, once built, would have the potential to bring in much profit. Also, once passenger generation is properly configured (the task on which I am working at present), there would be a market for stage coach operations, too.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 28, 2014, 03:32:10 PM
On the loading/CPU question -- given that convoys don't load at all until ten minutes before departure, are there any gains to be made in streamlining the CPU time given to those convoys which still have over 10 minutes to go until their departure? I added that clause telling convoys not to load if departure time minus current time > 10 mins, IIRC, but I've no idea if it's done in an optimal fashion.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 28, 2014, 06:33:38 PM
I think that something similar to this is what TurfIt's code is intended to do, if I understand it correctly.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on March 28, 2014, 07:02:25 PM
Aside from the unbearable lag (64bit crashes a lot for me and all), the slowness of this era is why I haven't had any interest in playing. It's just unbearable when it takes hours of real time to even set something up and you can't fast-forward as one would if playing singly.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 28, 2014, 08:59:42 PM
I can't even manage to hold a connection, it loads but then desynchs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 28, 2014, 09:04:11 PM
I can't even manage to hold a connection, it loads but then desynchs.
I think you need to change the
server_frames_ahead
additional_client_frames_behind
Those things in your config to a multiple of 5..

And you really do need to come back too, as your company is not sustaining yet again...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 28, 2014, 11:43:15 PM
AP, if you do manage to connect, there are two spots on the map that I would like you to open up to ships.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 29, 2014, 12:25:39 AM
I think that something similar to this is what TurfIt's code is intended to do, if I understand it correctly.
I read TurfIt's change as only applying when multiple convoys on the same line are loading at the same stop -- but I may have either misread or not seen the full extent of his changes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 29, 2014, 07:59:10 PM
Even at frames of 14, I can't seem to stay connected for more than a few seconds anymore.  I do note that the number of convoys is still growing, so people are still building... which probably isn't wise given the state of the game's speed.  Over 5200 now.

EDIT:  Increased it to 24, lasted about 2 minutes.  So laggy, however, it's almost impossible to do anything.  In offline play I can still accelerate the map to between 4-7x.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 29, 2014, 09:37:33 PM
On the loading/CPU question -- given that convoys don't load at all until ten minutes before departure, are there any gains to be made in streamlining the CPU time given to those convoys which still have over 10 minutes to go until their departure? I added that clause telling convoys not to load if departure time minus current time > 10 mins, IIRC, but I've no idea if it's done in an optimal fashion.
The clause is in entirely the wrong spot IMHO. If a convoi is not actively loading, it shouldn't even be in the loading state. Performance wise, it's only responsible for "wasting" 1% of the hole_ab() loops. At least in this online game; It has the potential for far worse. Also, unless I'm missing something I don't see how it does much. When the convoi first arrives at the halt, this clause is checking the go_on_ticks from the previous departure against the current time. Hence any goods waiting will load immediately.



What is current_loading_time supposed to be doing?
convoi_t::vorfahren() is trying to do something with it, but ends up doing nothing. "// The reversing time must not be cumulative with the loading time, as"
And convoi_t::calc_current_loading_time() appears to be trying to set a loading time based on how much freight is loaded, but is only called during the initial loading step after arrival. Hence any cargo loaded on subsequent steps take zero time.



EDIT:
Attached is new version of the patch. Should handle mixed cargo convois properly now. Much more effective trimming the wasted CPU cycles too!

EDIT2:
If you plan to continue this game using 11.x, I suggest you add Dwachs jump point search patch. I just tried it against this game and it cuts the average routefinding time by 25%, and the worst case time by 50%. Overall effect is a 5% CPU usage reduction.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on March 30, 2014, 08:19:03 AM
Even at frames of 14, I can't seem to stay connected for more than a few seconds anymore. 
I couldn't find a setting which let me stay connected for longer than that either. I don't have a recent offline save to test speed with.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 30, 2014, 09:21:48 AM
I couldn't find a setting which let me stay connected for longer than that either. I don't have a recent offline save to test speed with.
This is my settings :
server_frames_ahead = 5
additional_client_frames_behind = 20
server_frames_per_step = 5
server_frames_between_checks = 256

It's very laggy obviously, but I managed to stay connected for usually hours.
If there's anything to do with geological position, I'm in south devon.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 30, 2014, 04:21:38 PM
I think it might be geographic location too, since I too can stay connected for hours. (Van, BC)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 30, 2014, 06:11:56 PM
I'm in Vancouver, BC as well... but can't stay connected.  It's the time difference to server that causes almost all of the desynchs.

I wonder if the speed of your local computer has an impact.

EDIT: Thank you for your continued research in to performance issues, TurfIt, very appreciated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 30, 2014, 06:38:25 PM
TurfIt - thank you very much indeed for your work on this - it is greatly appreciated. I have now pushed this to the 11.x branch. I asked before whether it was worthwhile upgrading the released version of Simutrans-Experimental to incorporate these new updates; at the time, I think that TurfIt indicated that his patch was not ready, so I took no action. Do people think that this is now a good time, even though there are no other fixes/changes? TurfIt - is your latest patch ready to be deployed on the server and in a release version?

Sarlock/AEO - the speed of your local computer may well make a difference. May I ask each of you what hardware that you have?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 30, 2014, 06:54:36 PM
As long as you have a steady ping to the server, geographic location doesn't count for much. Farther away will result in a longer round trip time, but if consistent, you'll only notice it as some extra latency when you try to build things. If you have jitter you need to adjust the frames behind to compensate, but generally, except if you have a horrible ISP the frames behind is by default enough for the typical internet jitter. Note: there was a transatlantic fibre cut a few weeks ago (and not sure if fully fixed yet) that was causing issues for those of us on this side of the pond...

Automatically adjusting the client for internet jitter would require a complete rewrite of the main game loop. At least I can't think of anyway to do anything with the current routine.


This is my settings : server_frames_ahead = 5 additional_client_frames_behind = 20 server_frames_per_step = 5 server_frames_between_checks = 256
additional_client_frames_behind is the only setting you can adjust as a client. The rest are set by the server.


I wonder if the speed of your local computer has an impact.
It does. The server is running so slowly that those with faster computers can end up running way ahead. The server does broadcast messages about it's current position when it's lagging, but that's not enough when faced with very fast clients. The timing algorithm could be changed to better handle this, but frankly if you're running a server, make sure it can handle things. i.e. The server should be the fastest. For reference, based on my observations of the servers progress, I'd estimate it as approximately a Core2Duo @3.0 GHz. Slow your computer down to that and you're much more likely to stay connected. Otherwise set client frames behind to an absurdly high value and accept the latency.


TurfIt - is your latest patch ready to be deployed on the server and in a release version?
I don't know if my work is ever ready for release... but it's up to you. Obviously it would be best tested by more than just me first, but it doesn't seem Experimental has the nightly concept...
A testing release for use on this server might be an idea?  And don't forget the jump point search - it merges right in with no issues, and is quite effective.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on March 30, 2014, 07:01:37 PM
i5-3317U, 4GB RAM, which is ramping up to 2.4Ghz with the server game.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 30, 2014, 07:22:39 PM
TurfIt - thank you very much for your continued input. As for the jump point search - thank you for checking compatibility. I was initially thinking of leaving that until 12.x, as Bernd had already merged it, but given that you have confirmed that it merges cleanly, it might be worth adding to 11.x. Can you remind me in which commit that I can find this code?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 30, 2014, 07:30:53 PM
r7000.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 30, 2014, 08:00:01 PM
Done - on my local copy, with both changes, a saved game from the server runs about 3x faster in fast-forward mode than with the released 11.22.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 30, 2014, 08:04:13 PM

The 3x performance boost sounds lovely -- does everything else w.r.t. loading and convoy spacing still work as expected on the server map with the patch applied?

Also, unless I'm missing something I don't see how it does much. When the convoi first arrives at the halt, this clause is checking the go_on_ticks from the previous departure against the current time. Hence any goods waiting will load immediately.
This may be right - but in current versions it does seem to prevent convoys loading before <10 minutes to departure in the standard cases at least. I should say, however, that my knowledge of the code is next to nothing, and I would defer to anyone more knowledgeable who could recreate the same functionality with better performance!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 30, 2014, 09:35:09 PM
Server now restarted with 11.23 with TurfIt's improvements plus the jump point search. I should be grateful for any feedback on how this performs by comparison.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 30, 2014, 09:37:03 PM
A quick point of positive feedback on 11.23 -- it seems to eliminate the problems of inconsistency on performance that we discussed a few weeks ago (i.e. constantly jumping between speeds when fast forwarding).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 30, 2014, 09:40:26 PM
Ahh, splendid! You have TurfIt to thank for that.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on March 30, 2014, 09:47:53 PM
...

It does. The server is running so slowly that those with faster computers can end up running way ahead. The server does broadcast messages about it's current position when it's lagging, but that's not enough when faced with very fast clients. The timing algorithm could be changed to better handle this, but frankly if you're running a server, make sure it can handle things. i.e. The server should be the fastest. For reference, based on my observations of the servers progress, I'd estimate it as approximately a Core2Duo @3.0 GHz. Slow your computer down to that and you're much more likely to stay connected. Otherwise set client frames behind to an absurdly high value and accept the latency.

...
Just reconnected again after 11.23 upgrade. My computer is a 2.3GHz i3 notebook computer and still have a bit of jumping speed issue(Since my computer is slow), but it's a lot better than before.
So basically to achieve the best connection is for the client to have similar a performance as the server?

Thanks again for making the server smoother to play with once again.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Carl on March 30, 2014, 09:48:24 PM
Ahh, splendid! You have TurfIt to thank for that.
Indeed, many thanks TurfIt!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on March 30, 2014, 11:32:56 PM
So basically to achieve the best connection is for the client to have similar a performance as the server?
Yes and no. The problem is really the server being massively overloaded. The server is configured to run at a certain rate, and then tells clients to run at that rate. But if the server doesn't actually achieve that, and the clients do, bad things happen - desync. The timing changes I made before help in the case where the server/clients are partially overloaded, but once the server can't keep up at all, all bets are off.

I just connected to see how the server is doing with the new version - still not very good. @jamespetts - I'd suggest changing to 7 fps, and 4 frames per step. And that might still be too fast for it...

Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on March 31, 2014, 01:44:46 AM
Quote
i5-3317U, 4GB RAM, which is ramping up to 2.4Ghz with the server game
2.3GHz i3 notebook computer

Mine: i7-3770K @ 3.5GHz, 16 GB RAM

I suspect that's part of the reason I'm leading ahead of the server.

Update 11.23 has worked... I was able to stay connected for about an hour, which is the best I've been able to do in weeks.  Thanks, TurfIf and James!

Local play Fast Forward speed has jumped from 4-7x to about 7-14x, quite an improvement.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 01, 2014, 10:38:22 AM
I have a question on your man-made islands, how did you build those houses?

Also, since the speed up of the server, I now start to desync more than I used to
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 01, 2014, 10:51:47 AM
I just connected to see how the server is doing with the new version - still not very good. @jamespetts - I'd suggest changing to 7 fps, and 4 frames per step. And that might still be too fast for it...

Now done - I should be grateful if people could let me know whether this makes any difference.

Edit: CPU usage is currently reported at 73.9%.
Edit 2: Memory at 48.4% of 3Gb.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 01, 2014, 02:25:16 PM
Volvo, I built the islands on cities that had pent-up growth with no place to put it - the city quickly grows in to any new area of land that you provide it, as long as new area lies within the city's limits (Feathervale and Upford are prime examples).  There are only a few cities that have growth that doesn't have room to expand, but I'm sure we'll have more and more of them as the years advance (we're only 50 years in to this game!).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 01, 2014, 07:56:30 PM
Yeah, the city growth is too fast and those city sizes are what I would expect to see in 1920~1960

Paving roads at the city borders is the best way to get them to expand.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 03, 2014, 02:56:18 PM
A warm reminder for Mr. AP, your company is unlocked again.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 03, 2014, 07:18:28 PM
I'm rather lacking in free time this week (and weekend...) hence inattentiveness. Hopefully next week better...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 04, 2014, 04:37:44 PM
Um.. Some very strange and questionable construction costs there I see.
And to the one(I'm assuming only one) who've also done it to Merceyside Postal Service,
I made that company and planned to operate Mail service on multiple player's network,
so I looked through the finance sheet every year. And compare with yours...


(http://i218.photobucket.com/albums/cc155/kmb_68x/Untitled-1_zpsbc5abb60.png) (http://i218.photobucket.com/albums/cc155/kmb_68x/Untitled-1_zpsbc5abb60.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Qiw on April 04, 2014, 10:02:50 PM
I just started playing simutrans.. I had to take a look at your server and i gotta say its **** impressive :D I dont get how you guys made it so far!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 04, 2014, 10:10:08 PM
Welcome to the forums, and to Simutrans! May you have many hours of Simutransing fun.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Qiw on April 05, 2014, 11:06:20 AM
Welcome to the forums, and to Simutrans! May you have many hours of Simutransing fun.

Haha thanks a lot :D I feel like its quite difficult to make profits on a consistent basis... :D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 05, 2014, 11:17:22 AM
There is much to be said for observing and copying what successful players in the online game do. Good luck and happy playing!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 05, 2014, 11:35:00 AM
So he is still doing this. Construction costs in unlocked inactive player uh?
I would only assume it's the active player who never show up on this forum. :::)


(http://i218.photobucket.com/albums/cc155/kmb_68x/Untitled-1_zps38e02d0b.png)

Haha thanks a lot :D I feel like its quite difficult to make profits on a consistent basis... :D

I think it's because of the slow moving ships that's causing the problems..
Nearly all of my routes shows up red in the line management.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 05, 2014, 05:22:25 PM
Thank goodness for interest income or AP would be broke soon :)

Qiw: it will be more of a challenge to establish a profitable network at this point due to large sections of the map having heavy infrastructure in place.  I would avoid passenger/mail routes unless you are linking large urban areas together that are interlinked with feeder lines from nearby cities, otherwise you will not get the demand to have a profitable network set up.  Also be very conscious of monthly maintenance fees in early years, as the fixed price upkeep of stations, etc, will quickly break your company unless you have the profits to offset them.

There are plenty of industrial connections that are unlinked that can lead to some nice profits if built properly... especially in the south-west part of the map and to the central islands... both of which are largely untouched by players (north-west island is heavily built-up, as is most of the eastern island, which is where my company, Pacific Transport, is primarily operating).

As an aside, it took me about 10 game years to build up a profitable passenger/mail network.  Until that point, it was being subsidized by industrial hauling profits.  Now I derive about 2/3rds of my profits from mail/passengers.  I had to connect enough cities to generate enough traffic volume as well as wait for the cities to grow large enough to generate significant amounts.  After 50 years of growth, the cities I've connected on the eastern island represent nearly all of the top 50 cities on the map.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 05, 2014, 06:14:39 PM
Thank goodness for interest income or AP would be broke soon :)

Qiw: it will be more of a challenge to establish a profitable network at this point due to large sections of the map having heavy infrastructure in place.  I would avoid passenger/mail routes unless you are linking large urban areas together that are interlinked with feeder lines from nearby cities, otherwise you will not get the demand to have a profitable network set up.  Also be very conscious of monthly maintenance fees in early years, as the fixed price upkeep of stations, etc, will quickly break your company unless you have the profits to offset them.

There are plenty of industrial connections that are unlinked that can lead to some nice profits if built properly... especially in the south-west part of the map and to the central islands... both of which are largely untouched by players (north-west island is heavily built-up, as is most of the eastern island, which is where my company, Pacific Transport, is primarily operating).

As an aside, it took me about 10 game years to build up a profitable passenger/mail network.  Until that point, it was being subsidized by industrial hauling profits.  Now I derive about 2/3rds of my profits from mail/passengers.  I had to connect enough cities to generate enough traffic volume as well as wait for the cities to grow large enough to generate significant amounts.  After 50 years of growth, the cities I've connected on the eastern island represent nearly all of the top 50 cities on the map.
He probabaly will bankrupt faster than it's meant to because someone is using his money to build canals and raise lands..
I've locked the companies (Ex Insulis Co. is also having the same issue so I locked it as well) with a password.
The password is the company who's most likely used that money to build things.. (No capital letter, no space) (He apparently doesn't use this forum)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 06, 2014, 07:12:01 PM
This whole unlocking companies thing is clearly very open to abuse. I mean, if a company is running at a profit (which it was...) why unlock them at all?? If no player action is necessary ( and a few of us said we were't expanding to allow other players a chance, we're just waiting for 1830), then it's hardly a crime to be inactive. Some of us do have real lives, strange as it may seem... :o

Volvo, please can you PM me the password to my company, I'll try and jump on in the next couple of days to review/assess the damage. Once I've updated my simutrans to the latest etc.

Thank goodness for interest income or AP would be broke soon :)
Not entirely a coincidence :D I don't need/want vast cash reserves, once I passed $40M I decided to stop the fund growing, just build the new infrastructure I could afford to maintain.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 06, 2014, 09:23:42 PM
^some of your most profitable ships got stuck, which is why you were doing negative for a few years.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 06, 2014, 10:15:33 PM
The reason to unlock rather than simply rely on bankruptcy is that there used to be companies where people had made a small start, hardly used up any of their reserves, then abandoned things, and either the single 'bus line (etc.) that they were running was just scraping a profit, or the interest from what remained of their reserves outbalanced any tiny loss that they were making and a company slot was used up when nobody had been playing that company for (real life) months. If anyone can think of a way of addressing this problem with fewer side effects than unlocking, I should be interested in suggestions (which would apply equally to Standard, too, since the system is the same there).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 07, 2014, 02:23:14 PM
Without the free time at the moment to flip back and verify, wasn't the inactive period significantly extended to 20+ years?  We're barely moving ahead 1 game year/real life day at a time, so this is 20 real life days... which is certainly plenty of time to pop in and play for 5 minutes to check on things.  (like freeing stuck ships)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 07, 2014, 05:54:23 PM
Without the free time at the moment to flip back and verify, wasn't the inactive period significantly extended to 20+ years?  We're barely moving ahead 1 game year/real life day at a time, so this is 20 real life days... which is certainly plenty of time to pop in and play for 5 minutes to check on things.  (like freeing stuck ships)
Sounds a long time. Think maybe I was caught by the inability to connect problem (hopefully fixed now), if others were playing on? Possibly also that if you connect, browse around, but don't see anything needing doing, you don't get asked to log in.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 10, 2014, 09:29:19 AM
I think ther server has crashed again?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 10, 2014, 11:18:35 AM
probably an infinite loop caused by line 40.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 10, 2014, 11:40:32 AM
Line 40?

Edit: I had earlier restarted the server and taken the opportunity to upgrade it to the latest version of Ubuntu, but it seems to have failed again. AEO - are you referring to a particular line of code?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 10, 2014, 12:36:10 PM
To clarify, sending ships 1491 and 1492, line 40, on their way seems to result in the crash.
https://dl.dropboxusercontent.com/u/17111233/crash_14-04-10.sve

yeah, it's definitely crashing when the ship 1493 reaches its destination.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 10, 2014, 02:40:55 PM
Thank you for the information: that was very helpful. I have now found and fixed the bug on the 11.x branch.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 10, 2014, 02:43:17 PM
Thanks as always for the quick action, James :)

Squashing the bugs one by one!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 10, 2014, 09:34:40 PM
the game worked just fine if I reschedule those ships to another line, btw.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 10, 2014, 11:20:29 PM
Now restarted with version 11.24, which fixes the crash/infinite loop: you will need to upgrade to log in. Sorry about the disruption and happy playing.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 11, 2014, 02:19:55 AM
The JPS and loading optimization patch is really amazing. Before the game was struggling on 4000 convoys and now it's nearly 8000 with the only slowdowns at the beginning/end of the month.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 11, 2014, 09:53:49 AM
Splendid! Thanks to TurfIt and the Standard developers for that improvement. Is everyone finding it easier to stay connected now?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 11, 2014, 02:26:43 PM
Yes, it has been much better since those improvements.  I can stay connected for much longer.  As we've reached 7000 convoys, I have started to notice the system dragging down a bit more, but it's still much better than before at 4000 convoys.  In offline play I can reach 9-10x fast forward.

The only regular disconnects we get now are just after the start of every month, which is the checklist mismatch that we've been getting for quite some time now (you mentioned that this may have been found and repaired, so maybe this will correct itself after the fix is implemented).  It's not much of a problem, however, as it's just once a month, which gives us the better part of a real hour to stay connected.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 11, 2014, 10:05:41 PM
Thank you for the feedback - that is helpful. Glad that things are now working better.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 12, 2014, 02:51:34 PM
Am back in the game now, password protected again. Company seems profitable, so all good.

If anyone has any housekeeping items they need adjusting on my system, just let me know. :-)

1830 still seems ages away, but the scale of the game is pretty monumental now, trying to figure out all the industry flows will take some time!!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 12, 2014, 03:56:22 PM
AP, can you please open up the causeway near brickingfield?

My ships are being forced to take the long way around, when it wasn't like that before.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 12, 2014, 04:08:54 PM
Someone must have made a hole in the causeway when my account was unpassworded, so i just closed it again. It was definitely a causeway for some time. Hadn't realised it was being used.

Diagonal bridges are vastly expensive to maintain, so have adjusted the terrain somewhat to accommodate the shipping route, hope that helps.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 12, 2014, 04:15:34 PM
yeah, I put that hole in there, because it completely forced my ships to take the long way around when it was not like that previously.
It's like an extra 3hr detour to go around it.

And the diagonal elevated costs the same as bridges. The displayed cost is per tile vs. per km.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 12, 2014, 09:06:26 PM
Island Hopper: I'm not sure if you read these forums, but I was looking at your 650 ship Bone China line and it could be much more profitable and efficient for you if you changed it slightly: it's a big circuit around the map and often your goods (pax, mail, freight) are jumping on and taking the round-trip journey around the entire map to double back to its desired destination.

The trouble with circular routes in Simutrans is that you will get pax, etc, load at a station that is after the station they want to go and will travel on the ship/train/etc until it finally comes back to their desired location, making it very inefficient (high running costs for a low paying revenue distance).

Consider this route:

A ---> B
^         |
|         v
D <--- C

Suppose your ship is at station A and loads up.  Passengers for B, C and D will load at this stop and your ship will sail off to point B loaded with passengers for all 3 stations.  B and C pay well - it's the most efficient route, but D clogs up your ship and you don't get much revenue for this route because it's not very far from A.  You want to deliver your A-D passengers directly, not have them overload your ships going to B and C.  You can't achieve this with a circle route, even with reversing enabled... you have to isolate the lines.

Your other issue is that while you've set up convoy spacing, you are only loading to 1% at certain stops.  Given that your ships are always running with at least a bit of cargo taking a long route, you aren't, in effect, getting any convoy spacing... thus, if you look at the map, you are getting large masses of ships all moving in groups and then big gaps that cause station overloading.

You could probably run that line with 200 ships and make twice the profits with a few tweaks :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 12, 2014, 10:15:36 PM
And the diagonal elevated costs the same as bridges. The displayed cost is per tile vs. per km.

I could have sworn I asked that question before and got a different answer. So we are quoting bridges in one unit and elevated ways (and track?) in another?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 13, 2014, 01:49:18 AM
yeah, the costs are the same in the dat file, but the game cannot display them in the same units, for some reason.

also consider the fact that it's easier to upgrade elevated ways, where as bridges need to be torn down first.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: speedbus on April 13, 2014, 08:21:48 AM
Sarlock, thank yo very much. It's my first attempt to play experimental. Any hint is very appreciated.

The trouble with circular routes in Simutrans is that you will get pax, etc, load at a station that is after the station they want to go and will travel on the ship/train/etc until it finally comes back to their desired location, making it very inefficient (high running costs for a low paying revenue distance).

I thought the difference to standard is that trip time is taken into account for routing decisions, so I felt safe choosing the circular route layout. Anyway, I'll separate the lines.

Your other issue is that while you've set up convoy spacing, you are only loading to 1% at certain stops.  Given that your ships are always running with at least a bit of cargo taking a long route, you aren't, in effect, getting any convoy spacing... thus, if you look at the map, you are getting large masses of ships all moving in groups and then big gaps that cause station overloading. :)

You're absolutely right, up to now I didn't get the convoi spacing working properly. I probably got this feature completely wrong. Have to think about. Any hints for further reading?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 13, 2014, 04:26:52 PM
Not really a lot of written information about the systems in Experimental, a lot of it you just have to play with and gain familiarity with.  Carl did a nice write up on the scheduling system (http://forum.simutrans.com/index.php?topic=9241.0) that may be helpful.

Ultimately, your convoys, when set to load % and convoy spacing, will leave the station when either they have reached their load % or the time limit expires for spacing.  If your load % is only 1%, you won't get any spacing delay because your ships are almost always at least 1% full.  Given that your ships are running fairly full, I'd set it to 50-100%, then you will get some nice spacing between your ships and avoid the large build up of material at stations (and unhappy passengers) when the grouping in your ships causes a gap in coverage to occur (and then 20 ships arrive in an hour, followed by no ships for 4 hours).

What works well is to split your circle line in to two "L" shape lines:

A ---> B
^         |
|         v
D <--- C

Line 1: A-B-C
Line 2: C-D-A

Accomplishes the same task but now cargo will only load on the convoy going to where it wants to go, rather than circling over the entire map to get back to a point just a stop or two before it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 13, 2014, 05:23:23 PM
Alt
What works well is to split your circle line in to two "L" shape lines:

A ---> B
^         |
|         v
D <--- C

Line 1: A-B-C
Line 2: C-D-A

Accomplishes the same task but now cargo will only load on the convoy going to where it wants to go, rather than circling over the entire map to get back to a point just a stop or two before it.

Also consider running two routes, one clockwise the other anticlockwise, the traffic should (I believe) favour the route which gets it to the destination fastest, so not go the "wrong way" around.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 13, 2014, 05:38:42 PM
I think freight tends to take the path of least transfers, so making CW and CCW loop lines doesn't work the way you will intend it to work.
i.e a ship that does ABCD will still attempt to do A>D, despite there being a line that does ADCB.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 13, 2014, 05:41:44 PM
The routing of freight is based on total journey time just as with passengers, but because transshipment inherently takes longer, transfers are effectively penalised more for freight than passengers.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 13, 2014, 05:59:46 PM
Indeed, I should have rewritten that diagram to indicate that cargo would travel in both paths, not just a clockwise direction.  Then cargo from A to D will in fact take the A-D route instead of taking the long A-B-C-D path as it sometimes does now.  (take a look at some of the passengers on the Bone China route and you'll see what I mean -- there are passengers on those ships who are travelling across the entire ocean just to get to a stop that was 100km from where they loaded on to the ship)

While designing my underground network in offline play, I originally set it up with a circular route (running clockwise and counter-clockwise), but I quickly realized that passengers were loading the first convoy to reach them, even if that meant they went around the entire circle to reach the stop just before they got on.  "C" shape and grid patterns were far more effective/efficient.

I'll design an example to demonstrate.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 13, 2014, 06:09:44 PM
While designing my underground network in offline play, I originally set it up with a circular route (running clockwise and counter-clockwise), but I quickly realized that passengers were loading the first convoy to reach them, even if that meant they went around the entire circle to reach the stop just before they got on.  "C" shape and grid patterns were far more effective/efficient.

This will not happen if two separate lines are used: one for each direction, as is probably prudent for the time being for circular routes. I will have to look into improving the algorithm for passengers deciding which individual convoy to board in due course.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 14, 2014, 08:25:53 PM
De-synchronise issues has started to become more frequent these 2 days for some reason.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 14, 2014, 09:01:04 PM
Just at the ends of the months, when interacting with the world, or at any time, even when passive?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 15, 2014, 04:00:35 AM
I always get one around 5-10 minutes in to every new month... but otherwise it has been good.  I've learned to live with it (it's a good chance to get up from the office chair and stretch and do something else other than manage lines for an hour!).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 15, 2014, 04:07:06 AM
some month beginnings, 0:00 to 0:16, are super heavy, and then after that the game is pretty light.

I suspect it's because pax are rerouting, but it might also be cities trying to expand when there is no room.


---
I think the server side needs a restart so it can clear its resources. Right now the server game goes like a rollercoaster and the performance is very bad, but with a local copy, the game runs slow, but smoothly.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 15, 2014, 07:39:00 AM
There's some problem, with being able to stay connected but the server frozen (might be my computer).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 15, 2014, 11:00:36 AM
A user has reported to me by e-mail very poor performance (the client will repeatedly hang for seconds at a time and sometimes run very quickly for a short time to catch up), which I have been able to reproduce. I am restarting the server in order to see whether this will remedy the problem.

Incidentally, routes are now calculated more frequently than monthly, so specific end of month issues based mainly on route recalculation.

Edit: Restarting the server did not seem to help - yet CPU usage with a client connected is reported as only 59.8%. Can anyone let me know whether there were any noticeable changes in the game world shortly before and shortly after this performance problem set in such as might have been the cause?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: speedbus on April 15, 2014, 11:47:20 AM
Edit: Restarting the server did not seem to help - yet CPU usage with a client connected is reported as only 59.8%. Can anyone let me know whether there were any noticeable changes in the game world shortly before and shortly after this performance problem set in such as might have been the cause?

James, it's probably me responsible for the mess. My apologies for any inconvenience.

Yesterday in the evening I tried to change the routing for my Bone China Line. I must have made a mistake somewhere. The
result is a lot of ship not finding a route. Unfortunately I did not succed in removing these ships. The "Sell Now" button does not do anything, probably due to the server load.

Any saved game older than November 1818 (game time) respectively 11 pm (local time, which is UTC +2) should work as
expected.

Again my apologies.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 15, 2014, 12:00:49 PM
Ahh, interesting, this might explain it. I will have to look into this when I get a moment. Thank you for letting me know.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 15, 2014, 01:08:53 PM
Ahh, interesting, this might explain it. I will have to look into this when I get a moment. Thank you for letting me know.
It's not necessary now, after a few more connections, the re-routing procedure seems to be done and the server returned to normal now.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 15, 2014, 01:13:29 PM
Here is a save that is probably right before the slow down.
https://dl.dropboxusercontent.com/u/17111233/client2-network.sve
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 15, 2014, 01:18:37 PM
It's not necessary now, after a few more connections, the re-routing procedure seems to be done and the server returned to normal now.
Announced this for a minute, 2 clients connected lol
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 15, 2014, 01:24:04 PM
I tried it, but there are still some 100~200 ships with no route on that line.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on April 15, 2014, 01:24:19 PM
A server load of 59.2% is very likely a maxed out server, because simutrans does not distribute its CPU cycles evenly. 100% would just mean that the server cannot cope up all the time. Anything about 30% (when I tried at home) means the server lags sometimes badly (season change, start of a complicated shipping route, experimental probably at the start of a month) and then can catch up.

You can try this even without a server version. Just start a normal game and watch when the idle time drops to zero. That moment is reached well before 50% CPU. At that time there is full demand for CPU for short amount of time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 15, 2014, 01:33:12 PM
perhaps, teleporting ships back to the depot should be reinstated?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 15, 2014, 01:37:15 PM
I tried it, but there are still some 100~200 ships with no route on that line.
It was running fine, up until the point I clicked island hopper and everything is not fine...
(I persume they want to send "no route" messages and there's a lot of them)
It's so laggy that It's possibly impossible to click retire for all of them..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 15, 2014, 11:10:29 PM
AEO - thank you very much for the save. I have now reverted to November 1818 to avert these difficulties. I should like further input on the question of sending ships on open waters with no route to the depot automatically. That was disabled because people who made routing errors were losing cargo too easily which caused great problems with very long shipping lines, and ships on open water were not obstructing anything. I did not realise that the problem that eventuated when a line is edited and many ships have no route all at once would be bad enough to make the whole game completely unresponsive (even in single player mode).

Perhaps ships with no route should be sent to the depot automatically, but after a greater lapse of time than other vehicles that can block things? I should be grateful for feedback on this, especially from AP who had trouble with ships being sent to the depot before.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 15, 2014, 11:31:07 PM
Thank you for reverting the server, James, seems to be running fine now.

The biggest issue with moving stuck ships to depots on this map is that they might be sent to a depot that can't easily reconnect to the existing route -- meaning that the nearest depot may be outside of the range of route finding and when you try to put this ship back in to service on its existing line, it fails because it is too far away to refind its route.  Then you are stuck selling that ship or adding waypoints to get it back on track and then putting that convoy back on its regular line server, and losing the cargo you had on it before.  Tough to decide what is best in this case.

Either way, in 10 game years or so, most cargo will be train hauled, so it won't matter much anyhow.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 16, 2014, 12:14:06 AM
IMO, the ships serve cargo better than trains on a map with this much sea.
there are only a 3 or 4 routes where freight trains make sense.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 16, 2014, 04:27:46 AM
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.

EDIT

I am getting these multiple times per month now:

Code: [Select]
DESYNCH #1, around 5:00 in new month:

Warning: karte_t::interactive: sync_step=38160  server=[rand=148512792 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69457254] client=[rand=3955254484 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69457244]
Warning: karte_t::interactive: disconnecting due to checklist mismatch
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0

--------------
DESYNCH #2, 10 game minutes later @ 14:59

Warning: karte_t::interactive: sync_step=38640  server=[rand=2641084098 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69459539] client=[rand=2854961631 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69459537]
Warning: karte_t::interactive: disconnecting due to checklist mismatch
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0

--------------
DESYNCH #3, @ 19:17

Warning: karte_t::interactive: sync_step=38968  server=[rand=3498925062 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69461045] client=[rand=3685045178 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=16568 traffic=69461031]
Warning: karte_t::interactive: disconnecting due to checklist mismatch
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0

Seems consistently a variance in the rand and traffic figures.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 16, 2014, 07:03:38 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 16, 2014, 08:05:16 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 16, 2014, 09:52:20 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 16, 2014, 10:11:52 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 17, 2014, 09:29:47 AM
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..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 17, 2014, 01:02:19 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 17, 2014, 02:31:35 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 17, 2014, 02:39:50 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 17, 2014, 04:36:40 PM
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 :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 17, 2014, 06:21:22 PM
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  :D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 18, 2014, 03:17:25 AM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 18, 2014, 10:55:51 AM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 21, 2014, 01:44:24 PM
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. :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 21, 2014, 02:02:08 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 12:57:44 AM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 24, 2014, 05:58:38 AM
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
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 24, 2014, 08:42:26 AM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 24, 2014, 09:19:48 AM
I had the same thing (only on one ship so far...) and ended up adding extra waypoints, which seemed to cure it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 11:41:35 AM
Volvo - can you give any detailed instructions to reproduce this reliably (preferably in a specific thread)?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 24, 2014, 02:25:12 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 24, 2014, 03:05:53 PM
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?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 03:16:27 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 24, 2014, 05:32:31 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 24, 2014, 06:03:11 PM
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).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on April 24, 2014, 08:25:16 PM
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? 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 24, 2014, 08:36:21 PM
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?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 09:06:25 PM
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?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 24, 2014, 09:12:03 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on April 24, 2014, 09:35:37 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 09:40:12 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on April 24, 2014, 09:43:45 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 24, 2014, 09:48:55 PM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 25, 2014, 01:39:14 AM
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.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on April 25, 2014, 02:14:08 AM
Ta-da! 11.26 connects and works perfectly! Woohoo!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 25, 2014, 04:00:24 AM
Still getting frequent desynchs.  Almost unplayable except for those of us who are stubborn enough to keep reconnecting every few minutes.  ;D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 25, 2014, 04:03:52 AM
It might be desynching when the passengers decide to reroute, en-mass, due to backlogs.

Although, I am not entirely sure where they really want to go.

I really want to add about 500 pax ships throughout my lines, but this remains to be seen.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 25, 2014, 04:07:53 AM
Indeed, I should be adding at least that many to address growing backlogs... but afraid to add 500-1000 additional ships to the map.  Waiting for 1829-1830 trains.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 06:57:22 AM
Realistically, it's 1835 before trains are worthwhile in terms of speed (and the faster ones start becoming available in 1842).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 25, 2014, 10:15:37 AM
Can anyone confirm whether the desyncs are the checklist mismatch types under 11.26?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 10:16:52 AM
Please can players refrain from reclaiming vast tracts of coastal land unnecessarily? Whilst a large number of my "no route" ships are due to schedules jumping to inappropriate waypoints, many were due to ocean waypoints suddenly becoming inland. The large area of new land around 540,612 was particularly troublesome as it was on a junction of a lot of waterways, several routes had waypoints there.

I suggest we may need an extension request to make all in-game waypoints visible to all players, for server play?

Edit: it may take me a while to add even more waypoints to these intercontinental shipping routes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 25, 2014, 10:37:21 AM
Please can players refrain from reclaiming vast tracts of coastal land unnecessarily? Whilst a large number of my "no route" ships are due to schedules jumping to inappropriate waypoints, many were due to ocean waypoints suddenly becoming inland. The large area of new land around 540,612 was particularly troublesome as it was on a junction of a lot of waterways, several routes had waypoints there.

I suggest we may need an extension request to make all in-game waypoints visible to all players, for server play?

Edit: it may take me a while to add even more waypoints to these intercontinental shipping routes.
It also makes the server more laggy. Not only the server will overload for more ships re-routing but giving land for cities to develop for more population is also not good news.

I usually leave some tiles away from the coastal area as this happens a lot, but by the look of the land-raise it won't take long until the situation where my routes are also affected (Currently I have 2 routes with land raised waypoints).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 25, 2014, 10:39:58 AM
I should note that, with the new half-heights code and appropriate adjustment to the climate settings to match, much, much less shallow sea is available either for reclamation or long bridges: the sea becomes deeper much nearer the coast than with the current settings.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 11:35:09 AM
What is the timescale on that release James? Given the issues of map clutter (overpopulation, proliferation of ship canals blocking everything) I'm wondering how long the map is likely to be played? It's a bit of a monster having to unpick everything from the age of sail and remake it in the age of steam. (am still slightly longing for a "sell everything" button!)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 25, 2014, 12:13:51 PM
I really suggest marking out your waypoints so that they aren't accidentally paved over.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 12:17:29 PM
Marking out waypoints is a monumental task, no way I've got the time to do that. :o

As I wrote before,  there may be merit in automating the process - if others support the idea I'll start an "extension request" thread??
 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 25, 2014, 02:24:47 PM
I've had a lot of waypoints paved over... it's a hassle but I just work around them.  What I am doing now (and will do in future games in the shipping era) is put my waypoints in the 2nd level of ocean so that this cannot happen (since this level cannot be raised).

EDIT
Desynch #1 this morning:
Code: [Select]
Warning: karte_t::interactive: sync_step=3700  server=[rand=1418284383 halt=2049 line=1427 cnvy=9303 ind_dns_prop=3816 act_ind_dens=16831 traffic=75832203] client=[rand=153163709 halt=2049 line=1427 cnvy=9303 ind_dns_prop=3816 act_ind_dens=16831 traffic=75832191]
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

#2:
Code: [Select]
Warning: NWC_CHECK: time difference to server 0
Warning: karte_t::interactive: sync_step=4916  server=[rand=3252059797 halt=2049 line=1025 cnvy=9306 ind_dns_prop=3816 act_ind_dens=16831 traffic=75839057] client=[rand=920017473 halt=2049 line=1025 cnvy=9306 ind_dns_prop=3816 act_ind_dens=16831 traffic=75839065]
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
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 05:14:22 PM
I'm doing that too moving forward (but a lot are pre-existing, especially around coastal headlands etc).

---

I'm putting together a train graph (http://en.wikipedia.org/wiki/Train_path#Graphs) for my single track route so I can figure out where the passing loops need to be and plan my service.

Please could someone explain the time settings for the server game?
I know a train with max. speed 40km/h will cover 40x8 tiles in a "game hour". But how do game hours relate to game months, and game minutes?

Reading through this tutorial (http://forum.simutrans.com/index.php?topic=9241.msg86453#msg86453) I should be able to set up a "clockface timetable" but it does rely on understanding how the time system works (bits per month etc). The convoy shift spacing set to 1 gives departures every 06:24:00 (6h24min) or subdivisions thereof (not sure I understand the logic of that figure).

I'm fairly sure a single line system can be intensively operated if the loops are in the right place (since simutrans only models absolute block system). With trains of differing speeds, having the speeds an easy multiple of each other (passenger= 2x freight, say) is fairly key too.

Any help appreciated. I can break this into a parallel discussion if that helps.




Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 25, 2014, 08:41:57 PM
Your 40km/h train will cover 320 tiles per game hour, or 5 1/3 tiles per game minute.  There are 6h24m per game month, so 384 minutes per month.  Therefore the 40km/h train (while maintaining at max speed) will cover 5.333 x 384 = 2048 tiles per game month.

You have to account for slowdowns at corners, stations and climbing terrain, so your mileage will vary.

Also account for the fact that underground signals aren't available until 1863, so you won't be able to have sidings in your tunnel portions.  Also account for the steep climb out of the tunnel network which will be extremely taxing on early locomotives.  I plan to use intermittent stations in my underground systems to act as defacto signals until 1863.

If you are combining freight and pax/mail on the same line, then your average speed will likely be down around 15-20 km/h (nearly the same speed as ships, at a much higher operating and maintenance cost - you may want to just do pax/mail!), given that early freight wagons are max 30 km/h and heavy, so locomotives will struggle with a large load up those long hills out of the tunnels.

Your optimal convoy spacing will be based upon the length of your longest track section between sidings (or tunnel section with no signals/sidings), how many trains you have operating and their average speeds.  You're probably best off constructing it in offline play and finding an acceptable balance.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 25, 2014, 09:17:19 PM
Thanks Sarlock

Yeah, that's why I wanted the time data. Excel suggests the return journey is around 23h at 70km/h, plus accel/decel time.

My initial plan is 28 block sections of around 250 tiles each, so 14 trains moving in each direction with little delay. It looks possible. I really don't know how much demand there will be at this point but it could easily be multiplied up.

If it gets to needing more than 140 trains with 140 block sections of 50 tiles each, I'll double the route.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 25, 2014, 10:23:16 PM
What is the timescale on that release James? Given the issues of map clutter (overpopulation, proliferation of ship canals blocking everything) I'm wondering how long the map is likely to be played? It's a bit of a monster having to unpick everything from the age of sail and remake it in the age of steam. (am still slightly longing for a "sell everything" button!)

It is very difficult to predict how long that any given coding project will take, and there are several fairly substantial coding projects that will need to be completed before the next major release, including the particularly taxing project relating to city growth, which is still in the planning stage. I am afraid that I cannot give any sensible estimate at all, as I know of no reliable method of making such predictions.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 26, 2014, 12:53:39 AM
Well, I added my ships, which should hopefully be enough.

I still need to add some 240 ships to the four long distance lines, but I'll add them as required.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 26, 2014, 07:40:59 AM
It is very difficult to predict how long that any given coding project will take, and there are several fairly substantial coding projects that will need to be completed before the next major release.
Okay, good to know it's still worth our while investing time in this map :)


I've concluded my train-graph exercise. It is technically possible to run a mixed speed service on a single track route very smoothly, but in game it requires great precision of timetabling and waypoints which sounds like a recipe for disaster. The basic logic is that a slow train would travel one block in the same time a fast train travels two, so sometimes two 'up' trains need to overtake, other times an 'up' and a 'down' train need to cross (and sometimes both at once) which is challenging for the signalling. You also need to double the number of blocks to do it. I may play with it further some time, but not on this map.
 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 26, 2014, 08:43:03 AM
I don't know whether it's congratulations or not.. (for having 10000 convoys on the server)
(http://i218.photobucket.com/albums/cc155/kmb_68x/Untitled-1_zps50abcaad.jpg)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 26, 2014, 09:46:50 AM
I can imagine that that little ship was launched with great fanfare.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 26, 2014, 10:23:10 AM
Ships are skipping waypoints. E.g.my line "Milk1" skips from 8 ) Brentingfield to 10 ) Waypoint. I've just watched them do it, very time the ships depart Brentingfield. No wonder we're having trouble with "no route" errors  :o
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 26, 2014, 10:30:28 AM
Ships are skipping waypoints. E.g.my line "Milk1" skips from 8 ) Brentingfield to 10 ) Waypoint. I've just watched them do it, very time the ships depart Brentingfield. No wonder we're having trouble with "no route" errors  :o
I think the waypoint showing after they display no route is the last waypoint it can find between stops, after a few observations, add a few waypoints after it will sort the problem.

I can imagine that that little ship was launched with great fanfare.
Yeah... Probably because of it being one of the few named vehicles on the map. ;D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 26, 2014, 10:47:20 AM
I think the waypoint showing after they display no route is the last waypoint it can find between stops, after a few observations, add a few waypoints after it will sort the problem.

I've done so, the route is moving again, but subsequent ships still seemed to be skipping 9 ) in the schedule.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 26, 2014, 10:55:04 AM
Is 9 a waypoint? As described before, convoys automatically advance through the schedule until they reach an actual stop so that they calculate their full route to a stop straight away, rather than to the next waypoint.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 26, 2014, 08:19:12 PM
If the ship keeps going to a waypoint it can't reach, it means that there is a problem in the schedule.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 26, 2014, 09:41:39 PM
AEO, out of curiosity, I connected your Pondish Seaport to my Bigstable International Dockyards, which connected your Pondish area freight network to my entire map-wide network.  I took it offline and sped it up about 8 months and the usage has mushroomed with an intricate spider web of new connections, running both ways.

I'm not sure what the longer term permutations of such a huge connection may be (via distribution of profit and logistics), so if you'd like me to disconnect that line, I would be happy to.  It may take up to 2 years for everything to establish a new equilibrium.  We could connect your Scarden Seaport to my Dashdon dock as well, if we want to explore more interconnections, as well as others.  Combining our two freight networks would serve the majority of industrial connections spanning the entire map.

The same goes to any other player: if you want to connect to one of my many hubs, on either a supply or demand side, feel free to.  I will endeavor to keep up to demand by adding ships as necessary.  If a new player wants to earn some really quick profits, just connect any unconnected dairy or cattle farm to one of the international hubs (Farrmouth, Queensingchester, Bigstable, Dashdon, Winterton, Cogsand, Addhead, Yendermouth, Pidmead, Feathervale, Upingpike or Sandton).  Or, frankly, any unconnected industry of any type.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 26, 2014, 11:01:32 PM
Is 9 a waypoint? As described before, convoys automatically advance through the schedule until they reach an actual stop so that they calculate their full route to a stop straight away, rather than to the next waypoint.
9 and 10 are both waypoints (11 probably is too). I may be being dense, but I don't understand why it would skip 9 and not 10. In many cases my ocean lines have 20 or 30 waypoint entries between stops; I don't usually see it skipping all the way through the list 'until they reach an actual stop' which may be 5000 tiles away. Is 9 is redundant if it is being skipped (i.e. maybe it can already find a route to 10 but not to 11)?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 26, 2014, 11:04:47 PM
Waypoints are not actually skipped: the routing is calculated between each waypoint, it is just that this is done consecutively until an actual stop is reached rather than waiting until the convoy arrives at one waypoint before calculating the route to the next. If it stops finding a route at a particular waypoint and then complains that it has no route, this is because it cannot find a route from this waypoint to the next item on the schedule, probably because the distance is too long.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 26, 2014, 11:58:06 PM
9 and 10 are both waypoints (11 probably is too). I may be being dense, but I don't understand why it would skip 9 and not 10. In many cases my ocean lines have 20 or 30 waypoint entries between stops; I don't usually see it skipping all the way through the list 'until they reach an actual stop' which may be 5000 tiles away. Is 9 is redundant if it is being skipped (i.e. maybe it can already find a route to 10 but not to 11)?

The ship can't find a route between 8 and 9, so the schedule will go up to 9, but the real problem is between 8 and 9. You probably need to add a stop or two in between.
AFAIK, inside of 500~600 tiles seems to be the limit.

The schedule will highlight you the problem, by getting stuck there.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 27, 2014, 04:37:54 AM
The biggest problem I face in those instances is that when I open the schedule to inspect, the schedule will bounce ahead to the next station.  You have to make sure to set it back to the next waypoint or else the ship will get stuck.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 27, 2014, 08:43:07 AM
AEO, out of curiosity, I connected your Pondish Seaport to my Bigstable International Dockyards, which connected your Pondish area freight network to my entire map-wide network.  I took it offline and sped it up about 8 months and the usage has mushroomed with an intricate spider web of new connections, running both ways.

I'm not sure what the longer term permutations of such a huge connection may be (via distribution of profit and logistics), so if you'd like me to disconnect that line, I would be happy to.  It may take up to 2 years for everything to establish a new equilibrium.  We could connect your Scarden Seaport to my Dashdon dock as well, if we want to explore more interconnections, as well as others.  Combining our two freight networks would serve the majority of industrial connections spanning the entire map.

The same goes to any other player: if you want to connect to one of my many hubs, on either a supply or demand side, feel free to.  I will endeavor to keep up to demand by adding ships as necessary.  If a new player wants to earn some really quick profits, just connect any unconnected dairy or cattle farm to one of the international hubs (Farrmouth, Queensingchester, Bigstable, Dashdon, Winterton, Cogsand, Addhead, Yendermouth, Pidmead, Feathervale, Upingpike or Sandton).  Or, frankly, any unconnected industry of any type.

(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans/F_net_zps9821ae43.png)

My freight network looks like such, but some of those branches on the islands only feed to the hub or only carry one type of goods.
The Bulkports only export bulk and the Axingate Seaport only handles cooled goods.
The Seaports mostly handle all, except livestock.
Scarden is the hub of hubs.
I've been meaning to decommission the Axingate seaport and transfer all of the lines to the Cordish Seaport, but that's where I got lazy.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 27, 2014, 10:53:51 AM
I have just noticed that the signal really are on the wrong side of the track,
I remember when I was playing an offline savegame you can set the signal to left hand traffic one.
But I guess it's not possible to change now does it?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on April 27, 2014, 11:08:09 AM
Having the signals on the left hand side of the track is indeed a setting, but it will look very odd indeed unless the graphics are also re-drawn (especially for the semaphore signals), so I have left them at the default, right of track setting for the time being.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 28, 2014, 10:58:07 AM
Is it possible to make the server run even without clients connected?
I know I am becoming very impatient, but the server might end early anyway, so why not speed things up a bit?
Plus the server will be idle instead of shut off when no one's connected anyway.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 28, 2014, 02:28:59 PM
For my part, I prefer it this way... as we start getting in to very active years, missing a day or two can be quite impactful in the ability to manage a network.  Running only while a client is connected slows the advancement of years down a bit and helps out with the management of a large network.  1829 is only a few years away now :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 28, 2014, 03:37:13 PM
You can start pax rail at 1825/september, although the train will only go at 24~27km/h on straights and 7km/h up hills.

The engines are very cheap to run too, so they are not bad to keep around on lesser lines with very few gradient changes.


I suggest picking up another game to pass the time.
Banished or minecraft would be my top picks...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 28, 2014, 03:56:28 PM
It will only be a bit less than 2 years for one real life day to pass, plus I'm constantly connecting to it in day time now because it really is very slow..
It will only save me some reconnection maneuver when I hear my computer turns into jet mode (Lots of fan noise when de-synchronise)...
So the impact might not be as large as you think.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 28, 2014, 04:14:09 PM
by the way, those trains in 1825, if they are only ran on flat land, they can easily replace two paddle steamer ships, if you don't mind not having any mail service on them
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on April 28, 2014, 04:21:41 PM
by the way, those trains in 1825, if they are only ran on flat land, they can easily replace two paddle steamer ships, if you don't mind not having any mail service on them
I've already have a short route ready for the trains, but I would rather wait for 1829 for intercity routes
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 28, 2014, 05:07:59 PM
Sarlock, could you please open up the canals near Yercaster (5726,921) and Portosterly (5726,902)

I have not check the map since yesterday, but there was a major backlog of pax all along the west coast on the eastern island.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 28, 2014, 08:52:39 PM
Sarlock, could you please open up the canals near Yercaster (5726,921) and Portosterly (5726,902)

You bet.


Quote
I have not check the map since yesterday, but there was a major backlog of pax all along the west coast on the eastern island.

Probably.  There are tons of backlogs growing as I haven't added any pax/mail ships to overloaded lines in many years, choosing to wait for trains instead of overtaxing the server more than it already is.

By 1829-1830 that will be fixed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 28, 2014, 09:20:51 PM
thanks!

I suspect some of the backlog is caused by the road line that goes along the coast there.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 28, 2014, 10:08:22 PM
I'm sorry but these ship "no route" errors are a total pain in the backside. They take so long to figure out and fix it's not at all funny. Especially since the server spends most of its time saving/loading/static when there's >1 player connected.
 
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 29, 2014, 12:11:35 PM
1825 trains are better than expected.

Just don't make them overly long, otherwise they suffer on hills.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 29, 2014, 05:53:12 PM
1825 trains are better than expected.

Just don't make them overly long, otherwise they suffer on hills.
Surely more locomotives fixes that problem? (or fewer hills ;) )
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on April 29, 2014, 09:32:12 PM
Surely more locomotives fixes that problem? (or fewer hills ;) )

Well, you can try, if you want to, but for myself, I prefer two engines and 16 wagons.

How does everyone play on the peak hours?
I saw 3 players at one point, but most of the time the server doesn't respond because it's connecting someone.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on April 29, 2014, 10:18:53 PM
How does everyone play on the peak hours?
I saw 3 players at one point, but most of the time the server doesn't respond because it's connecting someone.

I saw it get to 4. But it was pretty painful to do anything for much of this evening. But clearly if we're all in the same time zone/working day, there isn't much we can do to avoid peak times.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on April 30, 2014, 03:48:03 AM
Indeed, I usually wait until the dead times to try and get online.  I think we're pretty spread over the globe, however, so there's almost always someone in prime player hours.  My usual playing hours are around 9pm-12am Pacific Time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 12:29:17 AM
Whatever magic wand you waved at the server made an amazing improvement to performance!  The GUI runs much smoother again, I've been connected for 2 game hours without a disconnect and the server seems better able to handle the convoy load.

Thank you!

This should see us through another 5-10 years until we load up the server with another few thousand convoys ;)

EDIT:

Desynch @ 3:00:00 Jan 1828

Code: [Select]
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 -710
Warning: karte_t::interactive: sync_step=74624  server=[rand=3046562285 halt=2884 line=1666 cnvy=12663 ind_dns_prop=3816 act_ind_dens=17748 traffic=91133423] client=[rand=1851505657 halt=2884 line=1666 cnvy=12663 ind_dns_prop=3816 act_ind_dens=17748 traffic=91133475]
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

EDIT 2:

Desynch @ 3:00:00, Feb 1828

Code: [Select]
Warning: karte_t::interactive: sync_step=99968  server=[rand=1312563863 halt=2944 line=1673 cnvy=12742 ind_dns_prop=3816 act_ind_dens=17748 traffic=91413626] client=[rand=1208293974 halt=2944 line=1673 cnvy=12742 ind_dns_prop=3816 act_ind_dens=17748 traffic=91413490]
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 rese


***
Down to about once a month, which is much, much better.  :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 02, 2014, 09:28:54 AM
I have manage to stay connected for a whole year yesterday actually.. (wow!)

As james mentioning the unrealistic gameplay think I might express some of my opinions

I think it will be much better if someone plays as a government (probably more than 1 person is good thing too)
Major infrastructures such as canals and railways should be regulated
I can see two canals running together to the same direction on the map (which is pointess)
The shallow network of railways (which is the fear of not getting any shares of the railway age..)
And to be honest even if you make plateways unavailable in the 18th century,
people can still use canals to pre-build railways :-X
If things like that have to put through a review first can prevent the situations like these..

This might make the gaming a bit more restricted, but it is realistic in real life terms.

Some more factors such as destroyed rivers and landscapes should be recovered when the infrastructure etc..
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 10:11:57 AM
Sarlock,

the "magic wand" to which you refer is my recompilation of the binary used to run the server with different compile settings, on TurfIt's suggestion: it turns out that the server had been running a debug build. It is noteworthy that you noticed a difference even without being told about it, which rules out any placebo effect. I should be interested in any other feedback on performance/frequency of desyncs that anyone else might be able to give following the recompilation.

Volvo,

I am not sure what sort of regulation that you have in mind, but regulation of any sort, especially on such a large map, is a somewhat labour intensive thing for a human player to have to do. I am rather more keen on balancing the game better to give players the incentive to play in a realistic way. Proper price balancing should ensure that it is economic suicide to build vast networks which remain unused for decades.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 02:30:49 PM
I was able to stay connected for about 2-3 months in a row last night, which is the first time I've been able to do that in many, many weeks. :)

Regarding regulation, I think that taming city growth will help quite a bit in this respect.  Part of the impetus for placing right-of-ways for future railroads is that city growth is so dramatic that all of open spaces were being consumed and the cities were merging in to giant megalopolises, making it extremely expensive to later come through these areas and bulldoze railways through (not to mention the significant loss of population which would also hurt profits by lowering potential pax/mail revenue from that area that was bulldozed).

It's pretty hard to limit these "cheats" as the players have the advantage of knowing what the next 250 years of transportation advances will bring, while the people in 1750 obviously had no clear vision.  In the late 1700's we were already claiming open tracts of land for future airports!

I also think that simply removing interest from the game will go a long way to assist in this as well, since once you build up enough cash and interest revenue, you can completely disregard profitable operations as long as you're still cash positive.  Players will be more careful about placing a large amount of early infrastructure that isn't earning profits.

I've stayed away from pre building railroads because I have something else in mind, otherwise I would have snaked a network all over the eastern island by now as well.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 02, 2014, 05:13:50 PM
yeah, the claiming of land was thanks to city growth, industry growth and excess income.

Otherwise, I wouldn't have bothered until 1825.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 05:32:25 PM
Lots of desynchs while trying to build my railway.  3 people online currently (or trying to be online).

Code: [Select]
Warning: karte_t::interactive: skipping command due to checklist mismatch : sync_step=479863 server=[rand=1125283916 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95705914] executor=[rand=1185382635 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95705914]
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset


Warning: karte_t::interactive: sync_step=481372  server=[rand=2301510979 halt=2997 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95720580] client=[rand=502712253 halt=2997 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95720556]
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


Message: network_command_t::rdwr: read packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr: rdwr id=8 client=3 plnr=2 pos=161,702,-6 wkzid=4100 defpar=17 #all down slope init=0 flags=0
Warning: network_check_activity(): received cmd id=8 nwc_tool_t from socket[532]
Message: nwc_tool_t::pre_execute: append sync_step=482034 wkz=4100 work
Warning: karte_t::interactive: skipping command due to checklist mismatch : sync_step=482006 server=[rand=3088201207 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95726182] executor=[rand=1865031780 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95726143]
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset

Warning: NWC_CHECK: time difference to server -284
Message: network_command_t::rdwr: read packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr: rdwr id=8 client=1 plnr=2 pos=159,703,-7 wkzid=4110 defpar=WoodTrestleElevatedRoad init=0 flags=0
Warning: network_check_activity(): received cmd id=8 nwc_tool_t from socket[672]
Message: nwc_tool_t::pre_execute: append sync_step=482990 wkz=4110 work
Warning: karte_t::interactive: skipping command due to checklist mismatch : sync_step=482965 server=[rand=2036190520 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95733898] executor=[rand=1686137628 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95733926]
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset

Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (convoy).
Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (line).
Warning: karte_t::interactive: skipping command due to checklist mismatch : sync_step=483848 server=[rand=3358888653 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95741574] executor=[rand=693680270 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95741604]
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0
Warning: nwc_routesearch_t::reset: all static variables are reset

Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (convoy).
Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (line).
Warning: karte_t::interactive: sync_step=485180  server=[rand=1991889874 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95753706] client=[rand=4010618520 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95753694]
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

Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (convoy).
Message: void convoi_t::laden(): Possible timetable anomaly detected. Skipping inserting journey time (line).
Warning: karte_t::interactive: sync_step=485508  server=[rand=245293848 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95756498] client=[rand=2806725383 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95756522]
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
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 05:52:15 PM
Hmm - thank you for letting me know. Does this seem to happen when you do anything in particular, and is it just you who loses synchronisation, or does everyone disconnect at the same time?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 02, 2014, 05:57:16 PM
The two times I disconnected, I was editing roads and upgrading tracks.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 06:00:30 PM
I'm online trying to determine this... at first I thought it was when I was laying track but it seems to be more broad than that: sometimes it's when I am laying a section and waiting for the server to place it, sometimes it's just when I am moving around the map.

I'll keep posting more desynch info to the same code window as I go through today, they're really frequent.  I'll post a bit of the logs before the desynch so that we know what's happening at the time.


Addition: While I was typing this, I connected in the background and was busy writing this.  I desynched without doing a single thing in-game (didn't even put in my password).  One player was on laying track at the time (according to the logs).

I think we're all desynching at different times, but all frequently.

Code: [Select]
Warning: karte_t::interactive: sync_step=486208  server=[rand=3234032248 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95762100] client=[rand=2749602838 halt=2049 line=1025 cnvy=8193 ind_dns_prop=3816 act_ind_dens=17793 traffic=95762076]
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
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 06:07:32 PM
Thank you for that information - posting a larger log extract for each desync might be very helpful.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 02, 2014, 07:42:26 PM
It's difficult to explain how can I stay connect for a game year in the afternoon and then desync every second in the evening.
I assume it's due to intensive building of infrastructures and others cannot keep up
(3 people was building things at the same time.)

For de-bug info :
Without other player connecting I managed to stay connect.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 08:11:43 PM
This is a very confusing pattern of behaviour, which, I am afraid, makes it very difficult to work out what the problem actually is. I have not previously seen a checklist mismatch type desync caused by building: all previous checklist mismatch desyncs that were found and fixed were caused by simulation differences. Building will always invoke checking of the checklist (otherwise only done every few dozen seconds), so a desync might appear to occur on building due to a problem actually occurring a number of seconds earlier, but it seems odd that players are sometimes able to connect for hours on end and sometimes are disconnected very swiftly; finding a pattern in that behaviour is likely to be the best way to begin to address the issue.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 08:25:47 PM
Indeed.  Last night I was doing building as well, but mostly canals, roads and putting extra ships in places that needed the extra capacity (just one small piece of railway) and was able to stay connected for long stretches at a time (mind you, I was the only person online at the time, too).  Today, I am building tunnels and stations.  I can't see why that would make a difference, but something dramatic has changed in the last 12 hours and switching to rail infrastructure is the only thing on the player end that would have changed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 02, 2014, 08:28:33 PM
This is a very confusing pattern of behaviour, which, I am afraid, makes it very difficult to work out what the problem actually is. I have not previously seen a checklist mismatch type desync caused by building: all previous checklist mismatch desyncs that were found and fixed were caused by simulation differences. Building will always invoke checking of the checklist (otherwise only done every few dozen seconds), so a desync might appear to occur on building due to a problem actually occurring a number of seconds earlier, but it seems odd that players are sometimes able to connect for hours on end and sometimes are disconnected very swiftly; finding a pattern in that behaviour is likely to be the best way to begin to address the issue.
Can it be like the speed of building provoke a very frequent check-list which clients' computer cannot keep up with the respond leads to the deync?
Sarlock was just building like crazy, seems like a station every second... and to add to that, the station were build tile by tile, unlike building a section of tracks.

I do not have any knowledge in gaming programming.. So excuse if the above does not make sense at all.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 02, 2014, 08:46:00 PM
Quote
Sarlock was just building like crazy, seems like a station every second... and to add to that, the station were build tile by tile, unlike building a section of tracks.

I was testing some different things to see if makes any effect, but it doesn't seem to matter much what approach I take, the desynchs happen anyways... sometimes even when I'm not doing anything.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 08:47:23 PM
No, if the server was not able to keep up with the building, there would be an "execute in the past" type desync rather than a checklist desync. A checklist desync can only, so far as I am aware, occur through an error (which might be an extremely subtle error) in the simulation code causing divergence of behaviour between server and client.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on May 02, 2014, 09:29:38 PM
Could it be that some of the way search constants (i.e. maximum number of tiles to check) are not synchronized. For building way a lot of tiles are check. If this order does not match, then you will get quick desyncs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 02, 2014, 09:38:03 PM
Hmm - interesting thought; but these are  saved/loaded in Standard, I think? I do not think that I have altered this in Experimental - unless the code that I introduced recently to cause vehicles to give up trying to find a route if they were likely to fail because the route was too long has this effect, perhaps? I cannot immediately see how this would lose synchronisation, however.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 04:09:50 AM
With the server that you're running this on, is there a maximum upload bandwidth allotment that you have?  With the number of disconnects today, we've probably collectively downloaded that 45 MB save file about 200 times (9 GB).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 03, 2014, 05:33:56 AM
The server (and sometimes client) may or may not crash when decommissioning or deleting severely overcrowded stations or stations in walking distance of those overcrowded stations.

I've had it happen occasionally, but not always, so I think that is the cause, but can't say conclusively without more testing.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 03, 2014, 09:03:31 AM
After more observations,
I can conclude that desync only occurs a lot when people are building stations
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: speedbus on May 03, 2014, 09:44:31 AM
I can conclude that desync only occurs a lot when people are building stations

Confirmed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 03, 2014, 10:03:31 AM
the server game has crashed due to a koord out of bounds bug.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 02:30:20 PM
Crash now fixed, and restarted with version 11.27; I have also modified the saved game so as to increase the maximum distance between stops for routing to make it easier for those using ships; TurfIt advises that this should be possible as a result of the new jump-point search.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 03, 2014, 04:15:17 PM
Thanks.

I also have a few more observations :

Some players such as me have an incredibly short waiting time before the game stop pausing. (usually a few seconds, sometimes immediately)
But some other players has an incredibly long waiting time. (the pausing time can extend up to 2 minutes)

What's the factor behind this?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 04:25:14 PM
Download speed - probably related to distance to server, local and server down/upload speeds, etc.  The server game is over 45MB, so it is primarily based on how long it takes to download that file from the server.  Are you located near (or in) the UK where the server is?  I'm half a planet away.  Takes between 60 and 120 seconds for me to download generally.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 03, 2014, 04:38:00 PM
Download speed - probably related to distance to server, local and server down/upload speeds, etc.  The server game is over 45MB, so it is primarily based on how long it takes to download that file from the server.  Are you located near (or in) the UK where the server is?  I'm half a planet away.  Takes between 60 and 120 seconds for me to download generally.
I'm in the UK right now,
but I'll be in Hong Kong next month,
So let's see whether distance matters.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 03, 2014, 05:58:00 PM
I am only getting 400kb/s here, so that 45mb file can take a while to transfer.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 06:07:11 PM
I'm getting about the same.  Increases a bit at night to around 600-800 kb/s, sometimes peaking over 1MB/sec at good times.  We'd be passing through the same hubs likely.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 03, 2014, 06:41:30 PM
Has the server crashed again? Or is it just slow players connecting?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 07:04:03 PM
Dunno, I've been trying to connect for a bit but having difficulties.  Just finally connecting now, not sure what's up.


Island Hopper:

I spent some time looking at your two bone china lines.  You've got two circle routes running in opposite directions, but you still have the same issue with passengers jumping on your ships to get to a station that was just behind them on the route.  What puzzles me the most is that the passengers seem okay with taking a 100 hour journey around the map even though they just want to go to a place an hour away on the schedule the opposite direction  :o  And yet you aren't being hit by giant refunds.
(http://www.ssgholdings.ca/simutrans/images/island-hopper-route.png)

If you split your service up in to two different lines (note second picture - one yellow and one orange line), one capturing the northern section and one the southern, you won't have this problem.  Have the ships go back and forth on a single line rather than connecting in a circle.  Rather than using 2000 ships, you can probably accomplish the same amount of goods moved with 500 or less - half of your goods are taking the long way around.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: speedbus on May 03, 2014, 08:34:07 PM
I spent some time looking at your two bone china lines.  You've got two circle routes running in opposite directions, but you still have the same issue with passengers jumping on your ships to get to a station that was just behind them on the route.

[...]

If you split your service up in to two different lines (note second picture - one yellow and one orange line), one capturing the northern section and one the southern, you won't have this problem.

Thank you very much for your analysis. You are absolutely right.

Splitting the lines is exactly what I tried to achieve three weeks ago. The result was a big mess, as you might recall. Several hundred ships with no route, and the server became unresponsive. So I'd prefer not to touch the routing for the time beeing.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 08:41:23 PM
The code has been updated since you tried that to make the problems that you had then much less likely. It would be useful if you could try it again and see whether you find it any easier.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on May 03, 2014, 08:55:14 PM
James, I'd suggest you look at tile 3766,1119,-13 for absolute lunacy. Seems someone has found a way other than ships with cargo holds to break the tile limit and corrupt things nicely. Even worse since there's wolke involved. I'm still not sure if exceeding the tile limit can cause desyncs, but it's still bad. Someone needs to be hauled out back and shot...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 09:08:00 PM
Are you sure about that co-ordinate? That gives me an empty ocean tile in the middle of the sea.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on May 03, 2014, 09:16:16 PM
errr 6766,1119,-13
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 09:20:21 PM
Ah yes, that's me.  I started a new line and put 50 trains in to motion all at once, queuing up to enter service as the track opened up.

Why?

Because with the desynchs it would be impossible to do it any other way unless I wanted to babysit it for a few hours and continually reconnect... or start several trains in several locations which is also an exercise in frustration and desynchs... all trains will enter service fairly quickly and the queue will disappear.

PS: I find it my duty as a play tester to try and break things deliberately ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 09:23:48 PM
Hmm - that is a workshop building in Forstone, next to Forstone Castle Keep Railway Station. I am not sure quite what I am supposed to be looking at there.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 09:25:23 PM
-13, look at the depot in the basement, 8000 feet down.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 03, 2014, 09:32:48 PM
James, you got desync(I presume the only reason you left) just when I started building things.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 10:11:33 PM
I did look underground (the normal rather than sliced underground mode) and did not see anything - did I need to zoom out? And you were able to build a depot underground...?!

Edit: I will prevent that in the next pakset release (although it might be useful to have a special underground depot at a higher price for electric vehicles only in the early 20th century - but I am not sure what the graphics for that would look like).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 10:31:15 PM
It's there at -13, perhaps you need to see it in sliced mode.  And yes, I can build depots underground.  ;)

Who knew the technology to build a 800km underground railway 8000 feet beneath the ocean's surface was available in 1830?  ;D  It's a really, really, really long elevator ride down from the surface to the underground station.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 10:41:55 PM
These antics will hopefully stop when things are properly balanced! Until then, your passengers can enjoy suffocating in the open wagons being hauled through unventilated tunnels by triple headed coal burning locomotives...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 03, 2014, 11:23:12 PM
Haha, yes, it's fairly humorous to imagine, isn't it: 2000 passengers crammed in open top carriages hurtling through the bedrock at 48 km/h being pulled by 8 smoke spewing steam locomotives.  Imagine the ventilation that would be required!  Comfort level should be about -500.

And then there would be the issue of heat down that far beneath the surface and how the passengers would fare during the 8000 foot descent and ascent from the deep sea tunnel depths.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 03, 2014, 11:31:47 PM
I think that we might have to use a spot of artistic licence apropos the height, and imagine that the scale on the Z axis is different to that on the X/Y axes...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 04, 2014, 03:18:09 AM
What's up @451,632?  Not sure how many ships are there, but it's a lot... more windows than I can open to count (>64).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 04, 2014, 08:23:21 AM
I think people also desync when other people are connecting.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 04, 2014, 12:13:49 PM
There's not a strong enough connection between that 8000ft under line at dashdon and furbury.
That 8000ft under line is also lacking a rail-rail link to the western island, so pax will pile up at Hurlstone and Astingham area.

There are various things broken on my lines too, but I won't be able to fix it until my internet is fixed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 04, 2014, 04:13:11 PM
Yeah, now that it's all set up and running, I'll have to tweak certain areas and double up areas as required.  The time it takes to perform any particular task is massive with the frequent desynchs.  Slowly picking away at it :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 04, 2014, 05:37:35 PM
Might I make a suggestion?  Until we come up with a possible fix, could we take the server down and freeze the game?  We're at such a critical time period in the game, 1830, and we are all struggling to connect and stay connected so that we can try and set up our infrastructure.  It might be a service to everyone to freeze it for a short period while we work on a few possible solutions.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 04, 2014, 05:47:52 PM
Might I make a suggestion?  Until we come up with a possible fix, could we take the server down and freeze the game?  We're at such a critical time period in the game, 1830, and we are all struggling to connect and stay connected so that we can try and set up our infrastructure.  It might be a service to everyone to freeze it for a short period while we work on a few possible solutions.
This will not be possible in my view as the game is not for long either (with new experiemental version with double sloop coming up0
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 04, 2014, 06:30:38 PM
I suspect that we're still a few months away from that being implemented, there is a lot of stuff yet to do (especially with these server issues eating up valuable programming time).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 04, 2014, 11:17:57 PM
Firstly, I am afraid that, since it has not been possible to reproduce the desyncs except on the server (for reasons that remain unclear), the only way of attempting to diagnose the problem is to continue to run the server, try painstakingly to observe patterns, make small changes to the code and run it again to see whether there is any difference.

Secondly, there are a number of significant projects that have yet to be started, let alone completed, in advance of the next major version, so that is likely to be some time away (and could be delayed very greatly if the desync issues take a long time to resolve).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 05, 2014, 05:42:45 PM
Server restarted and now running version 11.28, which should hopefully contain more debugging information to help to track down the reported loss of connexion issues.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 05, 2014, 10:23:55 PM
Perhaps I am doing something wrong, but I downloaded the new executable and it still says version 11.27 and I cannot see the server.  Tried several times.  Anyone else have luck?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 05, 2014, 11:21:57 PM
Version 11.28 does not work, so I have reverted the server to 11.27 for the time being. Apologies for the difficulties.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 07, 2014, 12:25:09 AM
Server now restarted with version 11.29, which is now available. The logging of desyncs has been updated for this version, so I should be grateful if people could post their logs when they are disconnected if at all possible. Thank you very much for all your feedback so far - it is appreciated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 07, 2014, 12:50:34 PM
Where can I find the log or what suffix am I supposed to add to the shortcut to enable it?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 07, 2014, 01:23:52 PM
Add -log to enable logging.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 07, 2014, 02:26:05 PM
Add to your parameters while running:

-debug 3 -log
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 07, 2014, 08:07:23 PM
On a balancing note, I'm astonished that a multi-track tunnel across the 6000 tiles of ocean is in any way viable. I know we were worried about my (substantially) shorter tunnels and I was considering ferries instead for at least the biggest gap. I'm not sure it's right that entire intercity rail networks can be built underground (even the London Underground is mostly above ground, in spite of the name).

At least we finally have trains :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 07, 2014, 11:35:17 PM
It cost about 100 million to build that double track system under the ocean from end to end, though I seem to be able to recover the cost of that in just a single year's profits now that it is running full bore.  This is certainly assisted by the 12 million residents we now have on the map, which creates a massive passenger demand.

The major benefit of such a system is that there are no hills and corners around terrain to contend with - just nice long straight runs, allowing trains to reach their maximum speed and maintain it.  It was more of a test than anything, I hardly expected to be making 250 million per year!!

I've only served the bottom part of the map - I'd suggest doing the same thing on the northern end instead of your above ground route.  Going in and out of the sea tunnels will make your service extremely slow and completely incapable of handling any decent amount of demand.  If you opt for rail-ship interconnections, the number of transfers required will significantly limit your potential load.

The easiest thing to implement regarding deep sea tunnels is to increase cost with the deeper it has to go: making tunnel at -13 should be very expensive to build and maintain.  That said, the technology to build the channel tunnel has existed for a very long time, it was only until recently that they actually built it... but less for technological reasons and more for political ones.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 08, 2014, 08:47:24 AM
It cost about 100 million to build that double track system under the ocean from end to end, though I seem to be able to recover the cost of that in just a single year's profits now that it is running full bore.  This is certainly assisted by the 12 million residents we now have on the map, which creates a massive passenger demand.

The major benefit of such a system is that there are no hills and corners around terrain to contend with - just nice long straight runs, allowing trains to reach their maximum speed and maintain it.  It was more of a test than anything, I hardly expected to be making 250 million per year!!

I've only served the bottom part of the map - I'd suggest doing the same thing on the northern end instead of your above ground route.  Going in and out of the sea tunnels will make your service extremely slow and completely incapable of handling any decent amount of demand.  If you opt for rail-ship interconnections, the number of transfers required will significantly limit your potential load.

The easiest thing to implement regarding deep sea tunnels is to increase cost with the deeper it has to go: making tunnel at -13 should be very expensive to build and maintain.  That said, the technology to build the channel tunnel has existed for a very long time, it was only until recently that they actually built it... but less for technological reasons and more for political ones.
It's not like "small" companies like his and mine can afford it.. 100million!
Even if we have the money to just about build it, anything wrong will then be "back to the drawing board"...

I like your push style trains by the way... (So passengers don't have to breath smoke)

The average trip time is just about 26 in game minutes, a lot shorter than i would have expected
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 08, 2014, 11:51:27 AM
You can always partner up and share the costs of the build.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 08, 2014, 02:24:33 PM
It's important to note that the eastern island's cities are much larger on average and have a higher urban density than the western island.  This is due to my early decision to constrain the cities with canals to make them denser, also to serve pax/mail early on to encourage growth.  This allows me to have heavy pax/mail demand on the underground lines.  A lot of the western island cities (more on the south half) are considerably smaller and won't generate enough demand to pay for an expensive underground system.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 08, 2014, 02:51:24 PM
Ah, but the western island has land that is easier to build above ground on.

On the eastern island, only the north west and north sections are easy to build on. The rest of it is mostly mountainous with two to four passes that are somewhat easier to build on.




P.S. There is something odd going on at 908,325
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 08, 2014, 05:52:38 PM
It's important to note that the eastern island's cities are much larger on average and have a higher urban density than the western island.  This is due to my early decision to constrain the cities with canals to make them denser, also to serve pax/mail early on to encourage growth. 
I hope that strategy will be nixed in future games by a rebalancing of the canal costs, as it's not exactly very realistic. I think the cities need a more active bridge-building code to prevent this sort of thing too. City growth should be organic unless we are going to presume a fairly prescriptive regime (rare historically) or city walls (but military installations in simutrans have been vetoed already I think).

It's not like "small" companies like his and mine can afford it.. 100million!
Even if we have the money to just about build it, anything wrong will then be "back to the drawing board"...

I also think it somewhat absurd to be able to accumulate that much capital from an undeveloped economy (let alone to get interest on it so that it grows simply because it exists). There simply isn't enough wealth creation going on for one company to have such a vast pool of liquid wealth sitting there. Interest on savings should be related to demand by others for borrowing.

I'm considering walking away from this server game because the 3/4 big companies are just too dominant in every sector, it is no longer interesting or realistic. The fact that freight "merry go rounds" are being used demonstrates that these companies aren't balancing the industry supply and demand, they are merely hoovering up everything and hoping it sorts itself out on average.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 08, 2014, 06:35:02 PM
I have discovered that combining industrial/freight operations in to one big aggregate has provided a much better supply/balance curve than matching individual industries together as I did previous.  Not only is it much easier to manage logistically, but it spreads supply and demand out much nicer and everything is producing more consistently.  We are also crossing freight over between players much more frequently as well which is benefiting both players and industries.

One thing which is irreconcilable is that supply and demand isn't matched in the game.  For the most part there is far much supply than demand, especially at the retail end, so most supply industries are running at only a fraction of their potential output.  This is mostly a pakset balancing concern.

As for realism, unless we're deciding to make it a "role play" type game where we limit ourselves to the knowledge of the time present, we are gifted by the knowledge of foresight and can anticipate future transportational needs -- much like your trans-ocean railway right-of-way built with roads and canals in the late 1700's :)  I have left that section that you service largely unaddressed, but if you aren't intending to connect it together, another player should take the initiative and jump in there.  I know I'd like to build another cross rail line through the northern bay section.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 08, 2014, 06:42:09 PM
I have left that section that you service largely unaddressed, but if you aren't intending to connect it together, another player should take the initiative and jump in there.  I know I'd like to build another cross rail line through the northern bay section.

But will there be any demand, if players are operating optimum straight-line routes beneath the sea? They will inevitably out-perform any route which follows the terrain.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 08, 2014, 06:44:50 PM
Absolutely true.  Might be better to drop your entire line under the ocean.  I know A-Train is considering plowing one across the southern side of the map.  Only a matter of time before another one comes across the north.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 08, 2014, 06:50:49 PM
Absolutely true.  Might be better to drop your entire line under the ocean.  I know A-Train is considering plowing one across the southern side of the map.  Only a matter of time before another one comes across the north.

Can't afford it. An east west route by land& sea is 'only' £4.5M.  These are engineering works demanding a whole different level of capital, man-on-the-moon (game-breaking?) levels of funding.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 08, 2014, 07:03:32 PM
I don't think it will be possible to compete with anything else, other than another underground railway line, until airplanes come about.


Personally, I was hoping to use those big ships, but I guess they are unneeded in this game.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 08, 2014, 07:13:25 PM
I don't think it will be possible to compete with anything else, other than another underground railway line, until airplanes come about.

I find myself once again wanting a "sell everything" button. :-/

If everyone is playing at level -10 then we might as well not have a terrain map...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 08, 2014, 07:56:44 PM
Can't afford it. An east west route by land& sea is 'only' £4.5M.  These are engineering works demanding a whole different level of capital, man-on-the-moon (game-breaking?) levels of funding.
It depends on whether you take the risk of partnering our companies up to build one, like AEO suggested.
I might get off-line and investigate the possibilities of that.

The plan was for each of us to build a direction, but we do need to act quickly
as both our companies are literally "dying"...

I think the next game should eliminate some of these maniac bridges and tunnel issues we have in this game, so be hold.
But quitting might not be the best choice as you can look at it the other way,
this is an interesting challenge for you to rescue a dying company and compete with ones that are 100 times larger.
You might find it satisfying after all.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on May 08, 2014, 07:57:42 PM
I've long thought maintenance and construction costs for tunnels and bridges should be exponential with length.
The only other fix I can think of would be to introduce construction time into the game. If your transcontinental tunnel takes 60 years to build...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 08, 2014, 08:04:20 PM
I've long thought maintenance and construction costs for tunnels and bridges should be exponential with length.
and/or height(for bridges) and depth(for tunnels).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 08, 2014, 08:44:42 PM
I also think that if we could control the price it will make things much more easier.
We can limit over-crowding as it will be "too expensive" for some people which in turns makes the railway more profitable.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 08, 2014, 09:13:11 PM
A full track laying from the very east end to the very west end on the north will cost about 36,000,000 simuro and the maintenance costs for the tracks alone is around 800,000 simuro per month.
I am now quite tempting to do this since I discovered I can afford it (I even have 2 years gap to get the cash rolled in before bankrupcy) But AP still have his planned IR so I will not do it for the moment.

I also think an ASwr Partnership Programme is doable. And I think AP you don't need to see this like the polish see anschluss..
What I see is more benefits for both of us in it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 08, 2014, 09:56:33 PM
Underground signals are available in 1863/11 and by then there will be the 120km/h tunnel, so there is definitely no way of competing against this with ships.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 08, 2014, 10:28:53 PM
Yeah, I made the same realization myself when looking at the future advances of ships coming.  Rail will outstrip any ship-based transport from here on in.  The luxury coast in 1878, 39km/h with 2000 passengers looked promising, but I am doubting whether it will be much use by then.

In 1848 the 120 km/h tunnels appear... which will be another 100+ million to upgrade.

Exponential tunnel/bridge costs would be interesting.  The massive elevated rail and bridge systems are nearly as outrageous as the tunnel systems.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 09, 2014, 01:26:05 AM
Are the ships still getting stuck at 908,325?

Is there a limit to how many ships can sit on one tile?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 09, 2014, 03:21:16 AM
I've noticed that with the server-side executable change today that it takes quite a bit longer for the clock to start running after a connection has been established.  It used to take about 5-10 seconds between file download/connection and being able to play in game, now it's closer to 30-60 seconds.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 10, 2014, 03:18:37 AM
Here's something fun, especially for those players who joined in later years:

This is a copy of the game as it was in Feb 1750!

Server Game - Feb 1750.sve (http://www.ssgholdings.ca/simutrans/saves/Server Game - Feb 1750.sve)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 10, 2014, 11:35:08 PM
Server restarted with new version 11.30. This reverts to a version that I have compiled myself, albeit with the same settings as TurfIt used to see whether this makes any difference to the desync problems. Please let me know how you all get on.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 11, 2014, 06:41:40 AM
I think we're getting a server crash around Dec 1837 @5:35:00.  Socket disconnections (in this case due to server crash) and reverted save game.

EDIT Third time's the charm, I guess... it sailed through the time slot and didn't crash this time.  No clue why it crashed on server end the first two times.  Not sure if server logs will have any information.


I fast forwarded local copy and it crashed twice at start of 1838, so something interesting is occuring.

EDIT And now it moved through 0:00 Jan 1838 without a problem.  Go figure!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 11, 2014, 10:37:13 AM
I didn't even desynchronise once the whole morning.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 11, 2014, 11:09:20 AM
Hmm - the crashes are rather bizarre (and unfortunate, since, on restarting, the server logs are ovewritten). A-Train has reported that he cannot stay connected longer than 30 seconds, which is also rather odd. Thank you for keeping me informed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 11, 2014, 02:29:23 PM
My apologies: the server seems to have crashed and corrupted the saved game. I have reverted to the last known good backup and restarted the server.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 11, 2014, 05:42:30 PM
Little tidbit for those of you suffering from passengers making very bizarre choices in where they queue up to load:

Just delete the station and put it back... passengers disappear, no huge refunds, all good :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 12, 2014, 04:37:41 PM
I don't think the end of choose signal is supposed to be limited to be placed underground does it?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 12, 2014, 06:29:29 PM
No - this is a bug that was fixed a while ago in the code and will be fixed in the next pakset release. Apologies for the error.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 13, 2014, 01:14:10 AM
Restarted with version 11.31 with better desync diagnostics from TurfIt and fixes to some of the issues that people had been reporting apropos the industries.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 13, 2014, 07:21:40 AM
The server is now very slow indeed...

edit : It apparently is the logged.exe problem as the normal program runs fine.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on May 13, 2014, 08:45:08 AM
Loading a game at log level 3 easily produces several MBs of logging information. The highest possible level for servers (at least not ultra high speed ones) was 2. Maybe James can tune this a little.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 13, 2014, 11:46:38 AM
Once the desyncs problem is solved, I plan to turn down the logging again. Apologies everyone for the slowness.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 13, 2014, 02:19:57 PM
The speed is tolerable... all in the name of bug squashing!  :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: TurfIt on May 13, 2014, 07:58:46 PM
The loading speed of the server appears unchanged. Many of the excessive level 3 messages that show during loading were removed.
Now the file transfer speed, that's dropped. I'm seeing a very erratic transfer with speeds frequently dropping below 2Mbps. The changes to the logging have nothing to due with this.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 13, 2014, 11:05:46 PM
There is a train attempting to go the wrong way at Burnwell and it's caused a major traffic jam and pax pileup.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 14, 2014, 12:05:13 AM
The loading speed of the server appears unchanged. Many of the excessive level 3 messages that show during loading were removed.
Now the file transfer speed, that's dropped. I'm seeing a very erratic transfer with speeds frequently dropping below 2Mbps. The changes to the logging have nothing to due with this.

That is extremely odd. I have no idea what might cause this. My provider has unlimited bandwidth, and I do not think that anything in the network code has changed that might impact on the transfer speed itself. Can anyone who knows more about the intricacies of networking than I suggest what might be happening here and how to look into dealing with it? I am rather at a loss.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 14, 2014, 04:29:43 AM
Seems okay to me right now... getting about 1.5-2.0 MB/s which is about normal for me.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 14, 2014, 07:32:36 AM
There is a train attempting to go the wrong way at Burnwell and it's caused a major traffic jam and pax pileup.
A very funny prank from the train driver there.
I didn't even have replacing vehicle schedule on the line..
No reason for it to go backwards.

edit : Put it on the next stop, still wants to go backwards, you are fired!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 15, 2014, 11:40:03 PM
I have just restarted the server with TurfIt's build of 11.31 to see whether this makes any difference to the desyncs - please report any difference in the frequency of desyncs from before the restart and any desync logs that you are able to muster.
Title: Re: How to get Simutrans-Experimental
Post by: VOLVO on May 19, 2014, 10:51:00 AM
I'm now in Hong Kong.

Very long loading time plus instant dissynchronise..

I have a 400MB Broadband here by the way.
Title: Re: Re: How to get Simutrans-Experimental
Post by: Sarlock on May 19, 2014, 06:29:02 PM
It may not be you... I just had the same experience with several checklist mismatch desynchs instantly occurring right after connection.  Check your logs to see if you are getting checklist desynchs or something else.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 19, 2014, 11:03:55 PM
I have split the last two posts from the "How to get Simutrans-Experimental" thread and added them here since they appeared to be about this server rather than about how to download and install Simutrans-Experimental.

My apologies that you are having difficulties: I do not have time to look into it to-night, but please keep me updated with how things are going. TurfIt is in the process of writing an improved system for logging that should enable us to track down the issues rather better than is possible at present. An issue has already been traced to something relating to cities (we cannot be more specific yet), and Kevin/A-Train has identified a further possible issue relating to using the forest tool, although this is probably not the main cause of the problems.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 20, 2014, 01:49:28 AM
I am hopeful that with the latest issue, you'll both be able to hone down on the core problems and address them-it seems much easier to recreate than previous intermittent issues, and hopefully a lot easier to zero in on the issue.  The desynchs were nearly instantaneous.

Thanks for moving the thread.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 20, 2014, 10:04:14 AM
What is interesting is that, having downloaded the server game locally, I cannot reproduce this with a server and client on my local system.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 20, 2014, 06:15:32 PM
It really does point towards how different systems perform the math... could this be in the rand function itself?  I don't know enough to be able to add much to the discussion and I'm sure you've both looked in many different places, but perhaps there is something in the rand function that causes the rare differential to occur and the sheer size of our map makes it statistically more likely to happen?  When running a client/server on the same machine, you're getting the same method of computation occurring which makes the mismatch not happen.

When the checklist is made and compares rand, how does it account for temporary timing differences between server and client?  ie: If the client is 1 second behind the server and perhaps a rand call that the server made 1 second ahead and has already made multiple calls later, how does the checklist reconcile this time differential?  And how frequently is the rand function being called?

I wonder if a worthwhile test would be to just run the rand function a bunch of times on different machines known to cause mismatch and see if there are any variances.

I should get myself back in to coding, I haven't really done any for close to 20 years but I'm sure I could pick up C++ fairly quickly.  (I used to do Pascal, some Perl (which has similarities to C) and some assembly).  As always, it just comes down to finding the time in a busy life to devote to it :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 21, 2014, 12:13:09 AM
The only thing I can think of is the server hardware is unstable and not calculating correctly, or the linux and windows builds calculates things differently.


---
to add, the server is currently extremely slow to send the save game over to me.
I think it is only doing about 500kb/s, which causes the transfer to take 4 minutes to complete.
---
Deep sea can still be edited in some directions, if the increase terrain height tool is used a certain level above sea level.
I think it was 3 high, then just drag left to right to increase water height.
(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans%20new/raise1_zpsb32972fc.png)(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans%20new/raise2_zps46290ed0.png)
(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans%20new/raise3_zps120b8ea7.png)(http://i199.photobucket.com/albums/aa131/AEObikes/simutrans%20new/raise4_zps0b4ef545.png)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on May 21, 2014, 06:39:49 AM
Deep sea can still be edited in some directions, if the increase terrain height tool is used a certain level above sea level.I think it was 3 high, then just drag left to right to increase water height.

This workaround has been around for a while. Expensive though :D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 21, 2014, 10:06:51 AM
Thank you for that report - I will have to fix that before the next release.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 21, 2014, 11:03:10 PM
Thank you.  For the record, if you find a bug or exploit like this, please report it on the forums to James... don't use it in the game and leave it for someone else to discover that you've used it and how it's done.  The whole purpose of this server is to identify such things.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 21, 2014, 11:11:00 PM
I am in the process of fixing this now.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 21, 2014, 11:53:14 PM
I have now restarted the server with the latest version, 11.32. I should be grateful for any feedback on how this works and the stability and prevalence or otherwise of desyncs, as well as any reports on whether the earlier reported instability of the passenger network has improved.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 22, 2014, 03:56:52 AM
Did the logs get renamed or moved?  I cannot seem to locate them in their usual spot, strangely.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 22, 2014, 07:36:46 AM
No, there was no intentional change to logging locations. Odd.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 22, 2014, 08:00:55 AM
my logs are still in the same spot.

---

is it intentional that the game makes 100MB+ log files?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 22, 2014, 08:23:55 PM
Yes - the log files are large because they contain a great deal of detail, especially with TurfIt's work on more detailed logging for the desyncs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 22, 2014, 10:32:09 PM
Error on my end, I figured it out... I had inadvertently added a random character to the -log command and didn't notice.  :o
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 24, 2014, 03:32:25 PM
Sarlock, you still have many many ships that are stuck in 'no load', possibly because they are 3 tile long schooners that you replaced with 2 tile long brigs.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 24, 2014, 03:35:20 PM
Yes, I am cycling through them sequentially and resolving them as well as several other things that I am changing with those lines (to make them better mesh with the rail lines)... so it's a slow progressive process.  Thanks for the heads up, however.  :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 24, 2014, 03:53:10 PM
Server now restarted with new version 11.33 - TurfIt is hopeful that he has found the desync issue, which I have fixed according to his instructions. I should be grateful for feedback on how this works out.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on May 25, 2014, 08:28:27 AM
For the first time in months, it works for hours at a time. Hooray!  Getting started at this late date (1850) and up against entrenched competitors is a bit of a challenge.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 25, 2014, 01:21:49 PM
I haven't desync'd thus far, so it looks like turfit nailed it.

A job well done.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 25, 2014, 02:25:30 PM
Three cheers for TurfIt!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 25, 2014, 04:01:31 PM
Indeed!  I'm late to the party as I wanted to have a few hours of evidence before I cautiously declared anything, but it is running much, much better now.  I have had one checklist mismatch desynch (and one socket disconnect) in about 6 hours of play, which is pretty amazing.

wlindley: starting with road transport is a hard way to make money in 1850.  Use ships instead and find some cargo to truck around -- start by connecting it to one of our main freight hubs for some quick profits (and a guaranteed market).  Find a couple of cattle farms and connect the milk to our networks.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on May 25, 2014, 07:31:06 PM
Sarlock: Good point.  But now I'll have to wait until the bankruptcy reaper comes along  :-[
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 25, 2014, 11:50:24 PM
I think there is a major deficiency in the western island with its north-south connection, which is possibly causing the backlog of pax there right now.
I don't know if volvo wants to work on that or not, but it is an opportunity.


I don't want to do it, because it's a hassle maintaining a massive pax network.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 26, 2014, 03:07:03 AM
Indeed, it is certainly underserved right now.  I've elected to just terminate my line in the middle (more or less) and let other players take advantage of the north-south connections.

That said, it requires more starting capital than 250,000 to build.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 26, 2014, 03:36:02 AM
Been busy for the last week, went back to the game, my network is certainly lagging behind... (in terms of technology and service quality)

It's better start off late and make time slower than to have 150 years of absolutely nothing interesting and suddenly too many things to do ;D
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on May 26, 2014, 11:02:52 AM
It's better start off late and make time slower than to have 150 years of absolutely nothing interesting and suddenly too many things to do ;D

Hopefully, once canals are properly balanced, there will be plenty to do in the first 150 years: canals are an interesting infrastructure all by themselves.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on May 26, 2014, 04:04:34 PM
Hopefully, once canals are properly balanced, there will be plenty to do in the first 150 years: canals are an interesting infrastructure all by themselves.
I think it's kind of annoying because you can never abandon infrastructures.
People upgrade rivers and then deleting the whole canal is destroying the environment.

Is it possible to let players abandoned canals and let it degrade to rivers?
Of course there must be an incentive for players to maintain a canal.
What I had in mind is faster speed for the canals than unmaintained rivers.

I also found myself in desperate need of an upgrade whole railway system button.. (I assume I'm not the first one to suggest that?)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on May 26, 2014, 04:35:24 PM
I've found the canals have continued to be a very effective way of gathering local passengers and mail to bring to the main train stations.  The iron coastal paddle ship can travel at 22km/h, holds 320 passengers, 1000 mail and doesn't get bogged down in road traffic.  It does take a bit longer to load, but the passengers in this era don't seem to mind.  You'd need dozens of road convoys (with a significantly higher operating cost) to match what one ship can do.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on May 26, 2014, 09:19:11 PM
I don't think I have anything to do until 1864, or when underground signals are available.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on June 01, 2014, 04:45:54 PM
I am getting an instant client crash after connecting to the server (once the clock starts moving)... it seems like the server is crashing as well as it takes a couple of minutes to reset itself for connection.  Anyone else experiencing this?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: ӔO on June 01, 2014, 05:14:30 PM
maybe a corrupted save game?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on June 01, 2014, 06:18:10 PM
Ahh, my apologies about this: I am afraid that I will not be able to look into this to-morrow, as I am currently away from a computer on which I can run a debugger.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on June 04, 2014, 10:32:36 PM
I have now tracked down the bug responsible for the crash and fixed it on the 11.x branch: when there was a factory with no suppliers that tried to calculate its maximum in transit percentage, this would cause a crash when the programme tried to calculate the figure based on data from the suppliers.

I am afraid that I do not have time to deploy the fix to-night, as I have been and continue to be very busy with work this week, but I hope to be able to deploy this within the week. Apologies again for the difficulties, and thank you all for your patience.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on June 05, 2014, 08:36:01 PM
No worries... been a good time to catch up on other jobs instead of spending an hour or two a day tweaking schedules :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on June 07, 2014, 11:22:24 PM
Server now restarted with 11.34, which has fixed the crash that had caused it to go down of late. Thank you all for your patience.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: speedbus on June 08, 2014, 05:39:21 AM
I've been off for two weeks and could not connect for a further week because of the known issues. After having installed 11.34 this morning, I have found that someone has taken over the Island Hopper account. Is there an option to get it back?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on June 08, 2014, 09:33:54 AM
I have reset the company's password and PMed you the new password.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on June 08, 2014, 05:09:43 PM
We put your company in to care and protection and set a password to keep anyone else from taking it over.  Everything should be in order for you to return to it :)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on June 08, 2014, 06:33:53 PM
In fact it should be in better shape than when you left. I spent hours upgrading some of your lines to cheaper tracks (they are cheaper, faster and support heavier loads!). Why? Well I wanted to see the impact it made upgrading passenger trains and clearly it has not done anything too bad last I checked (they were still making tons of money, possibly even more but it is hard to tell). My company mostly specializes in freight and I wanted to experience working passenger lines for future knowledge.

One thing I noticed was your passenger networks are often fairly irregular, you may be able to increase passenger flow with better timetabling or more trains (in some cases you only have 1 convoy on a line.

On another note there are 3 unclaimed companies online, some with pretty serious money/infrastructure. If anyone wants to get a feel of experimental drop by and you may be able to claim one.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AK on June 23, 2014, 06:37:38 PM
Hi,
Client and server crash after few minutes of playing.

Runtime Error!

Program : C:\ ....

R6025
- pure virtual function call

Im using x64 binary.
Then server is loading previous game and restart.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on June 23, 2014, 09:59:14 PM
Quote
Hi,
Client and server crash after few minutes of playing.
We are aware of this and I have spent a good part of today trying to gather information around it.

It appears that the way eye candy list, used for clouds generated from factories and trains such as starting diesels and steam locomotives is getting filled with invalid object pointers. When these are de-referenced they point to a nonsense function pointer structure which when dereferenced throws a read exception,
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on June 30, 2014, 09:41:44 PM
Server now updated to 11.35, which has fixed the crash: apologies for the disruption, and thanks to Dr. Supergood for finding the fix. Happy playing!
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on June 30, 2014, 10:33:49 PM
I already played with your test using the old version (or however it got past May/April).

Standard Simutrans does not have the awesome flow controlled factory production system so I was getting a tad bored...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on July 06, 2014, 05:54:16 PM
Seems to crash now. Crashes client as well and reverts?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on July 06, 2014, 11:09:48 PM
Hmm - is this crash occurring reliably? If so, I shall have to investigate. Apologies for the trouble.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 07, 2014, 12:18:42 AM
I let the server run through to the next month and no crash has occurred. However Sarlock's ships are now stuck in two places...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on July 07, 2014, 04:21:08 AM
Fixed again... this stacking limit per tile is a major hassle on a map of this size.

EDIT

Server crashed around 5:00:00 or so in Nov 1871, reverted back to the beginning of Nov 1871 again.  I lost about an hour of work releasing stuck ships and other projects... not sure what the issue is.  So the ships are stuck again... no point in releasing again until we resolve the crash.

On another note, I can see that we are rapidly going to run in to an issue of being unable to handle increasing industrial demand.  Freight trains are still very slow and have low capacity and won't change until well in to the 1900's, so we're stuck using ships and our lines will require many thousands of ships to handle the cargo... which runs us in to "stuck" issues with so many ships sharing the same common routes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 08, 2014, 12:03:43 AM
The server appears stable (can advance many months without crash), the crash must have something to do with what you are doing to fix the blockages.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on July 08, 2014, 09:19:24 AM
Interesting. Thank you for that.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on July 08, 2014, 04:48:18 PM
Seems fine again, I was able to "unstuck" my ships and set up a preliminary cross-map freight train route.  With a max speed of 56 km/h and 8 freight per train car, however, freight trains seem woefully inadequate on a map like this (unless I ran 10 sets of parallel track).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on July 08, 2014, 04:55:06 PM
Seems fine again, I was able to "unstuck" my ships and set up a preliminary cross-map freight train route.  With a max speed of 56 km/h and 8 freight per train car, however, freight trains seem woefully inadequate on a map like this (unless I ran 10 sets of parallel track).

Speed is not much of a problem (though the pak really needs to incorporate minimum speed signs for rail at 60 and 100 so you can force goods trains onto passing loops easily, without needing to set five hundred way points - such a pain to manage on existing routes). The capacity gets better by the 1880's. I don't think it could replace shipping entirely, though. You can easily press through some 90 trains per month with 56km/h.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 08, 2014, 05:11:58 PM
Sarlock you have done it again by Queensingchester @206,1120. It has blocked my supply ships from reaching one of the major manufacturing docks as well.

I also now have 2 lines shipping >1k cargo a month without paying my anything at all (0 revenue).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on July 08, 2014, 05:36:47 PM
Yeah, there's just too many ships all wanting to take the same routes.  It's not just my ships I have to contend with, which makes it extremely challenging.  All of the ships want to take those canals instead of the open ocean.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: AP on July 08, 2014, 06:22:17 PM
the pak really needs to incorporate minimum speed signs for rail at 60 and 100 so you can force goods trains onto passing loops easily, without needing to set five hundred way points - such a pain to manage on existing routes).

This is very true, but we've been suggesting them for a very long time for pak.britain (& pak.britain.ex) without them appearing, so it may just be wishful thinking.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 08, 2014, 08:55:28 PM
Quote
Yeah, there's just too many ships all wanting to take the same routes.  It's not just my ships I have to contend with, which makes it extremely challenging.  All of the ships want to take those canals instead of the open ocean.
This can be resolved by large ships later (that cannot take Ship Cannal/Medium River ways and only oceans). Until then it may be a good idea to place a sign where a blockage occurs so that players can be aware care is required when using that area (and so they can avoid causing one themselves).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on July 09, 2014, 07:14:00 PM
I've rerouted using waypoints as best I could to avoid the canals but I am pretty certain that we're going to see a backlog in the canal by Bidstable in short order (it may already be backed up - I haven't logged in today to check).  Widening that canal is a possibility but there are several players who would need to participate as each person has docks, rail bridges, road bridges, etc, along that route.

Part of the issue is that the long loading time for ships (2+ hours) causes a significant backlog to occur once we reach a certain level of activity in an area.  Unlike with road and rail traffic, which can use platform choose signals to distribute convoys, ships all use the exact same tile to load/unload.

The only way I can see to get around that (somewhat) is to set up multiple parallel lines using different stopping points at the docks.  Making those cross-map shipping lines takes quite a while, however, as there are dozens of waypoints in each direction.  I may not have a choice, as industrial demand is growing at a significant rate (and will grow even more shortly, as power plants come online).

What is the tile limit for ships?  Is there a different limit for loading/unloading operations and transiting through?  I assume that the total holds plays a factor in this total.  Having 1 vehicle ship convoys would certainly make it much easier.  There are no other viable ship alternatives to bulk transport via 8 hold sail ships at the moment.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 09, 2014, 11:55:48 PM
There is a theoretical limit to number of ships on a single line based on the loading time and number of ships allowed per tile.

Lets say each ship takes 3 hours to load (worst case is required) and that 50 ships can exist in a tile (some random number that seems plausible). If the months are 6 hours 25 minutes long, we can convert this into hours fraction for ease of calculation.

6:25 -> 6.4166666666666666666666666666667
6.4166666666666666666666666666667 / 3 -> 2.1388888888888888888888888888889

This means 2.1388888888888888888888888888889 ships can load and leave per month in series. The maximum you can have is 50 loading in parallel so
2.1388888888888888888888888888889 * 50 -> 106.94444444444444444444444444444

So this means about 106 ships per month on a single line assuming 50 ships per tile.

In reality this would require perfect conditions and dead long the tile. I would only use 0.8 times that so I would say at most 80 convoys per month per line.

There is also the problem with "catch-up head" that convoys loading in parallel get like ships when operating at frequencies above their loading rate. This is because ships take time slots they cannot leave at due to loading delay (time at port = max(loading time, schedule wait)) so you get {loading time / line period} convoys leaving simultaneously in a big wave. This is obviously limited to 50 (or however many) but this would block the tile and potentially block another 50 ships preventing departure in the mean time (the ships that are properly spaced arrive at the same frequency). The only way to get rid of catch-up head is to have idle convoys of head size sitting in the tile (which can leave while the head convoys finishing loading procedure so they can all leave on time). This would bring the limit down to about 50 convoys per month per tile.

It would be nice if we could get 2 improvements to the time-table system.
1. Conservative slot allocation. This could be a flag that causes the line to rather drop a time slot entirely than allocate it to a convoy that cannot leave on time due to loading. Basically this would skip enough time slots so that the arriving convoy gets the earliest time slot it can leave on time with after loading delay, with all others before then being lost (skipped). This is a major change over the existing one as it prioritizes correct spacing of at least period time between convoys rather than the existing system which prioritizes correct departure quantity per month.
2. Line statistics for number of time slots missed per month (that convoys were not able to take due to insufficient convoys being available at stops or feature 1 dropped them) and total time spent waiting for departure slots. These stats would greatly improve how easy it is to optimize a scheduled line with missed slots >0 meaning lower frequency or add more convoys and a high amount of waiting time meaning too many convoys or too low frequency.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on July 10, 2014, 10:44:19 PM
Big jam on AEO's network. Some on Arlington and South Western I think, as well, that would need to be looked at.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 10, 2014, 11:36:11 PM
A train tried to cross tracks and with incompatible signalling resulted in it blocking the line. The solution is about 15-30 seconds to apply with company access.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: prissi on July 17, 2014, 10:19:12 PM
The limit of objects on a tile is 250 (actually 255, but a little buffer for smoke etc is added). If the ships have trailer, then 125 ships on one tile.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on July 17, 2014, 10:44:48 PM
The limit was lowered to prevent exploiting 1 dock.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on July 23, 2014, 11:47:20 PM
Server seems to have crashed with a corrupt save. Not sure why that happened, but am restoring the backup and restarting now. Apologies for the difficulties.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on July 24, 2014, 03:24:37 AM
It may have been from me... I was getting a lot of checklist desynchs earlier while playing and I removed a rail signal and thought I had another desynch.  I tried to reconnect once but it failed and then I hadn't tried to connect again after that.

Thanks for restoring the server.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on July 24, 2014, 10:08:04 AM
Hmm, curious - I am not sure why removing a railway signal would cause this. Very odd.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 07, 2014, 05:05:09 AM
Progress on the server has come to a crawl because it is impossible to remain connected more than a minute or two. I can only imagine the problem is related to the rise in power on the map.

On a lesser note Sarlock has successfully managed to kill off my long distance food line due to his trains. There is no way my 20 km/h ships can compete with his 80 km/h trains so all food is being routed though him.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 07, 2014, 07:47:23 AM
Indeed... it was rather unexpected, as I did not realize that food prefers a fast route.  Bulk goods generated will happily take the next ship across the map, if it is first to arrive at the station, but food will wait for the trains and not use the ships.  This is why I have converted my freight rail line to food only instead of a mix of goods, as my food was backing up across the map, wanting to take the rail line only (it would rather build up 100,000 food at a station than take the ship going to the same destination!).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 07, 2014, 09:10:38 AM
Have we conclusively narrowed it down to electricity now, or are there still replacements going on?

Incidentally, all loads of all kinds will always prefer the fastest route.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 07, 2014, 11:48:49 AM
Quote
Have we conclusively narrowed it down to electricity now, or are there still replacements going on?
I am not even sure if my last disconnect was related to it. For some reason my connection with your server was extremely bad. What usually is a 50-100 second download took nearly 10 minutes. I have not ordered any replacements for several months as I cannot get much done before disconnecting. It is not likely the replacements as far fewer are being done than earlier when the new ship came out.

Quote
Incidentally, all loads of all kinds will always prefer the fastest route.
Which is all fine until you start trying to compete 20 km/h ships against rail 80 km/h rail. There will only be 1 winner and there goes 2M of profit per month (24M per year) for me. The fact food makes so much money might be another problem.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 07, 2014, 03:59:40 PM
We have no idea if it's the electricity or not... but it does coincide with a sudden increase in desynchs.  It's so bad now that if you can stay connected for more than 1-2 minutes, consider yourself lucky.  I haven't been on in 4-5 days.  It was May 1886 then and it is still May 1886.

re: speed.  I've watched bulk, piece, long and livestock all happily take the next ship even when there was a cross-map train route to the same destination.  The food, however, would wait until the train and never take the ship, even if it was the first to leave.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 07, 2014, 06:27:06 PM
Quote
re: speed.  I've watched bulk, piece, long and livestock all happily take the next ship even when there was a cross-map train route to the same destination.  The food, however, would wait until the train and never take the ship, even if it was the first to leave.
The logical thing for that to happen is when the waiting time would exceed the in-transit time via that route since waiting longer than the slower route for a faster route is not very logical. In any case I need to shut down my ships as there is no way I can compete with a route that is 70% faster.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 07, 2014, 07:33:59 PM
It would be helpful if somebody could confirm whether there are any pending replacements at present. If there are not, this might point to electricity being the cause.

As to the fastest route: what is happening to Dr. SuperGood is precisely what happened to the canal proprietors in the early 19th century, which is why railways dominated and canals largely went out of business except for local haulage where there was no space to fit in a railway line. In terms of Sarlock's observations, one should not confuse, on the one hand, the route taken (that is, the sequence of stops through which the goods pass, which is always based on the fastest speed) and the particular vehicle chosen to get to the next stop in the route (which in the current version depends to an extent on speed bonus, although the behaviour for this will change in the next major release to be more reliable and accurate).

Edit: I have just managed to stay connected, albeit passively, for 5-10 minutes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 08, 2014, 12:15:11 AM
Quote
As to the fastest route: what is happening to Dr. SuperGood is precisely what happened to the canal proprietors in the early 19th century, which is why railways dominated and canals largely went out of business except for local haulage where there was no space to fit in a railway line.
No as it did not involve a >300 km long under sea tunnel spanning multiple islands. Either the tunnels need to not be allowed such nonsense construction patterns (at least until a later date) or there needs to be some kind of better cost model.

Currently you are paid purely based on transport metrics such as average speed, transport type, distance etc. In real life the transport companies set the cost and they do so based on the infrastructure and running costs. Since Sarlock is running in tunnels all the distance this would translate into a much higher cost since the transport company would be expecting more to pay for the tunnels. This would result in two ways of shipping, slower cheap boat or faster expensive train. The speed against cost benefit would be weighed up and the appropriate chosen based on the value of the goods being shipped.

This is especially the case in the present where everything can be air freighted. Goods such as some food products, electronics etc are air freighted where as other goods like children toys or coal are shipped. Using your current model it would always send by air purely because you are allowed to ship at a loss, be it from actual running costs or the infrastructure. In real life shipping at a loss is not really done (is not viable) so instead goods are given certain costs of shipment which factor in the actual cost of shipping rather than simple transport metrics.

Quote
It would be helpful if somebody could confirm whether there are any pending replacements at present. If there are not, this might point to electricity being the cause.
If you run the server game a few months ahead it should almost certainly have no more convoys pending upgrade. You can also check if each slot is getting annoying error messages relating to convoy upgrades since these convoys will remain in an "upgrading" state forever. The error is along the lines "cannot insert depot into schedule, please post in forums" and I am 100% sure my company has none of them at the present.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 08, 2014, 12:49:18 AM
Ahh, the tunnel balancing needs to be fixed: tunnels such as that should, in the shorter term, be made uneconomic (but this requires full balancing on which see above), and, in the longer term, impossible (your suggestion a few months ago about ventilation is not a bad one, but would be a very large coding effort, and is a long way down a truly gargantuan queue of higher priority items, I am afraid). There is no practical way for players to set prices without the game becoming impossible to balance and/or unremittingly tedious to play, so the way of remedying this is by making (for example) air transport of coal totally uneconomic. (In fact, there are no aircraft in Pak128.Britain with bulk holds in any event).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 08, 2014, 02:13:55 PM
Sarlock, maybe we should delete all transformers and see if it improves synchronization stability? If there is a good correlation of improvement then it would prove the problem is with power.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 08, 2014, 10:06:51 PM
It's worth a try, to see what happens.

For other than milk, the undersea railroad is not economical hauling freight - it costs more to maintain than it makes in revenue (even with heavy usage rates).  For milk, however, as has been highlighted already, the revenue is much too high.  When I was hauling mixed freight on the line, it was running at a small loss per month.  It's the undersea passenger service that makes the big profits in the game.

Not that profits matter with interest income for all established players outstripping revenue by a significant margin (another thing which will be fixed in the next game).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 08, 2014, 10:27:58 PM
I should be very grateful if we could run a test removing all of the substations to see whether that affects desynchronisations: it will make a large difference to the amount of testing that I will have to do, and there is already a backlog of work for me to do as a result of spending so much of my time on matters connected with trying to move house.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 08, 2014, 10:45:49 PM
Removing them all may be difficult as there are so many power stations and so many lines. However I will try removing most of mine later. If the player who operates Orange reads this, I know you own some so please remove them as well.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 08, 2014, 10:56:37 PM
Thank you - that is very kind.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 09, 2014, 01:41:15 AM
Something is seriously wrong with your server upload at the moment.

I am only able to download from it at <100 kb/sec (usually around 50-60 kb/sec). A test of my connection downloading from youtube reports a speed of 900 kb/sec so it clearly is not my ISP or local internet connection. I also ran a trace route to your server and the ping was under 60ms which is acceptable (no major congestion).

This means it takes about 15 minutes to download the map. This clearly was not a problem before (used to download in 1 minute odd, appropriate for my network speed)  so it has started only really recently.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 09, 2014, 09:29:56 AM
Hmm - seems to be working fine for me: very quick transfer of less than 1 minute - the loading and calculating paths took longer. Has anyone else noticed this?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 09, 2014, 04:03:36 PM
I just connected to the game and it took less than 1 minute to download the file, so it may be local to you.

I disconnected within seconds of joining, so removing these transformers might take a very long time.  I wonder if it would be far faster for you to do it with a local copy, James, and then upload that save game for us to carry on with for testing purposes (and then we don't need to go and reconnect them all again).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 09, 2014, 05:08:44 PM
The download is fixed now, loaded in 2 minutes (someone else was loading network heavily at time). When it gave problems it was 4:00 AM GMT so maybe it is time dependant. As mentioned it was not my ISP as I could download from youtube and all other kinds of sites very fast (well at what I should be downloading at). I tried twice so it was not a "once off" fault.

Removing some more transformers, already removed a lot of mine. Remained connected for ~3-4 minutes.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 09, 2014, 05:55:56 PM
Very odd about the download speed: not sure what is causing that.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 10, 2014, 11:09:12 PM
I think I've been able to remove most of my transformers... hard to find them all as there is no way to reference the industry list to verify.  There are several that I noticed that belong to you, SuperGood, on both the west and east island.  Plus at least one that belongs to A-Train.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 10, 2014, 11:16:20 PM
This is very helpful, thank you. Has there been any noticeable reduction in the number of desyncs with the fewer number of substations?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 11, 2014, 12:00:43 AM
Not yet... still checklist desynched several times.  We'll see what happens after more are removed.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 13, 2014, 06:00:49 PM
I can't find any more transformers that belong to me... still a few for SuperGood.  Running much better, been connected for 2 game hours without a checklist desynch.

EDIT: Connected for 3 game months in a row.  Almost certainly related to transformers and city electrical supply.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 13, 2014, 09:56:27 PM
That is very helpful, thank you. I shall have to look into this when I have time. I suspect that this might take a long time to track down, I am afraid. In the meantime, I can only advise players to avoid using the power system until the bug is fixed; my apologies. At least it will be possible to continue the game in these circumstances.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 13, 2014, 11:33:02 PM
I will log in later to try and find more transformers I own and remove them.

I reviewed the power system a while ago to see if there were any blaring mistakes and could not notice any (the again I did not write the code) so fixing will probably not be easy.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on August 13, 2014, 11:39:45 PM
I will log in later to try and find more transformers I own and remove them.

I reviewed the power system a while ago to see if there were any blaring mistakes and could not notice any (the again I did not write the code) so fixing will probably not be easy.

Yes, I rather fear that you are right. One thing to test is whether this is reproducible on the way-improvements branch, as there have been a number of changes there (and I must confess, so many that I do not remember anything like all of them); it is probably not worth spending months of intensive work trying to fix it on the 11.x branch if it is already fixed in way-improvements.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 14, 2014, 05:50:16 AM
SuperGood, A-Train listed a bunch that he found in chat, should make it easier to find them.

James: Could this be related to another variable issue like the other problem that was causing checklist desynchs?  Knowing that it is likely related to power systems, probably something unique to Experimental, may help a lot in narrowing it down.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 14, 2014, 11:34:40 PM
Power is very unstable, with demands of stupidly large amounts appearing for the odd tick here and there (this map will never, ever use that much power, it was in the order of millions). It is possible that these silly values may be the cause.

EDIT

Once again I am downloading at a mind boggling fast speed of 50-60 kb/sec. Loading the map takes 15 minutes. This is something wrong with your server/connection with your sever since I can download at 900 kb/sec from Youtube easily.

I am very sorry poor person that must wait 15 minutes while I join. I did not expect it to take so long.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 14, 2014, 11:57:22 PM
Indeed, I've been online waiting for you to connect this past 15 minutes.  I've had to reconnect several times in the past hour and every download has been very quick, in the 1-3MB/sec range.  I haven't had any issues today.

I've also seen the odd tick of insane power consumption.  It also seems to correspond to some industries increasing production exponentially for a few moments.

EDIT: And then I got booted the moment you finished connecting.  Upon reconnecting, my download speed is great.  30 seconds tops.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on August 15, 2014, 01:19:38 AM
Takes about 1.5-2 minutes for me to load the map. I managed to stay connect earlier for about 3 hours, and was only disconnected during Volvo's joining process.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 15, 2014, 02:32:51 AM
I experience a lot of disconnections these days when someone else connects.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on August 17, 2014, 03:06:06 AM
Server is still acting painfully slow for some reason. Again it has taken me ~15 minutes to join on a connection capable of 900kb/sec. Average speed less than 100 kb/sec (more like 50 kb/sec). It never used to be this slow, I wonder why it suddenly is.

Edit after 15-20 minutes of downloading it instantly dropped me out of sync.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on August 20, 2014, 04:18:02 PM
I seem unable to see the server on the list for the past 24 hour or so... is anyone else having this issue?

EDIT  I see it now, a few hours later.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on September 19, 2014, 02:25:10 AM
The server seems to have entered an infinite loop of uploading save, running for a little while and then crashing.

What started the crashing was me restoring Blue's inter-island tunnel line to operation after something messed up during convoy upgrading.

The original mess up was that an upgrade order was issued to a convoy leaving the station before it passed the first directional signal. The result was it trying to turn around and go through the station to reach a depot using a platform in use. Obviously it caused a blockage and convoys started backing up.

The solution to the problem was to place an exit signal and block signals on the platform preventing such a deadlock from happening. However after adding the signals the server crashes approximately 1-2 minutes later. So I left the game and re-joined (so the server saved the signals) and it now crashes within 1-2 minutes of playing.

This is purely a server crash. The client simply loses connection and everything appears to run fine for a length of time afterwards. Since I cannot recreate the error on a client I cannot debug it.

EDIT: Appears fixed now.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on October 25, 2014, 08:52:19 AM
The server has now entered the days of having no respond in building things.
I suggest reverting the save or it's just basically unplayable.

EDIT : Seems to get better after a restart.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on October 25, 2014, 04:38:24 PM
I was on yesterday and it seemed okay... it's quite laggy due to the sheer number of convoys in motion, but otherwise still somewhat playable.

Things are at a bit of a standstill game-wise right now, however, as there isn't any significant incremental steam engine technologies, tunnel speeds are limited to 120km/h, air travel isn't yet available (zeppelins don't count) and ship technology has basically peaked for a long time with the Windjammer (especially in terms of capacity).

The pakset needs a lot of work to balance things out, allow for a smoother technological advancement of vehicle types (it's very choppy right now) and address the "dead zones" where there are no new technologies to advance the game.  80% of the steam engines seem superfluous and are just eye candy -- there is no application for these slower, less powerful and more expensive (!) engines.  There are periods where the best engine is one that was available 10-20 years ago and you're just patiently waiting for something that is actually superior to the old engines you're still using.  The power/traction/speed to cost ratio needs a close look.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on October 25, 2014, 05:37:20 PM
It is. I can safely conclude that I am the only player who uses more than one type of locomotive/train.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on October 25, 2014, 06:32:26 PM
It is. I can safely conclude that I am the only player who uses more than one type of locomotive/train.

I think I'm using a few... Though, mostly whichever is cheapest because the running costs are generally very high. And I haven't replaced some for a long time; it's such a pain to get on and sort it out though, with the terrible lagging.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on October 25, 2014, 10:36:09 PM
The train running costs seem to make no sense with some less powerful engines that are "more advanced" costing more per mile than older more powerful engines. I am guessing this is because the running costs are balanced for maintenance/upkeep, a feature not yet in the game.

Boats also seemed rushed. All post 1900 boats do not use the hull mechanics and hold stupidly little amounts of cargo. I am guessing this is because a balance pass never reached them but in any case they are not viable. My wooden ship can hold 3,000 units of cargo yet a dedicated metal ship only 900...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on October 26, 2014, 12:34:30 AM
The train running costs seem to make no sense with some less powerful engines that are "more advanced" costing more per mile than older more powerful engines. I am guessing this is because the running costs are balanced for maintenance/upkeep, a feature not yet in the game.

It's rather that they are not really balanced at all. Only a few modifications have been made. Most of the numbers are vague and the only touch with reality are things like, certain types known for having been costly to operate might have higher maintenance cost, etc, but the base costs are more or less randomly chosen depending on when they were added with no real coherent oversight as to the cost (certainly for railway locomotives, iirc there were some efforts to see over the 'buses and the trams).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 10, 2014, 10:50:49 PM
Thank you for all your feedback and apologies for not having noticed many of the recent posts until now. I am at a loss to explain the downloading speed issue: I have never been able to reproduce it, and I do not even know where to start looking into a possible cause.

Sadly, I have not had time to look into desync bugs lately for reasons explained elsewhere. Particularly unfortunately, desync bugs are fantastically difficult to track down: I once spent about four months doing nothing other than finding one single desync bug. The provisional plan at present is to move ahead with the next major version when my house is sorted out and re-test for the bug(s) in that version, since the changes between this and that are significant enough that a patch applied to this version may either work differently or be unnecessary in that, and may also take a lot of work to merge.

As for balance, cost balancing has not really been attempted in any significant way, so most of the cost figures are wild guesses. However, the other numbers should now be balanced. If anyone thinks that, completely aside from cost, there are some things that are significantly unbalanced in the pakset, I should be interested to know. The balancing is based on real life figures where I can find them and extrapolations from figures to fill in missing spaces.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on November 26, 2014, 05:58:45 PM
Who changed my password? Was it you supergood, if it expired? Why did you place no sign anywhere?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 26, 2014, 06:14:13 PM
Junna - do you need me to reset your password?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on November 26, 2014, 06:34:11 PM
Yes, I suppose that would be good. I assume someone changed it if it expired or something. I looked for any signs but couldn't find any.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 26, 2014, 07:01:28 PM
Done.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on November 27, 2014, 12:13:17 AM
Junna who were you again? It gets confusing who is who.

We (well A-Train and I before he left) use a common pool of passwords for large "no show" companies to prevent trolls using them to vandalise the map (or just being destroyed by nasty people). Placing them as a sign would defeat the purpose of putting a password. However we are more than happy to give anyone credible the passwords (if we are online).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on November 27, 2014, 12:57:30 PM
Well, unsurprisingly, mine was Junna Railways. I tried that password you used on AEO's before but that didn't work either. There's a chance I just forgot the password on the other hand, my memory is utterly rubbish, but as it had lapsed a good 15 years since last I logged on...
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on November 27, 2014, 10:52:37 PM
This does raise the question of what to do with these companies that people started and then stop playing for an extended period of time.  Keeping them out of the hands of new players is a good move, and maybe they shouldn't be allowed to do this at all, and just be put in stasis after 15 years and then after another bunch of years, actually disbanded and liquidated.  Otherwise the areas that that player served become locked and unaccessible to other players (unless you can somehow navigate the spaghetti of their old network and work around it, but that is very difficult, or impossible, to do).

Our solution thusfar has been to take these wayward companies and give them a new password and keep them safe until if and when the player returns, which is an acceptable strategy, but I do object to people trying to actively play them, especially when this leads to unexpected competitive behaviour towards existing players - making new lines, upgrading convoys to newer types, etc.  We're limited to one company each for a reason.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 27, 2014, 11:37:05 PM
This is actually a more complex problem than it first appears, especially given that people sometimes have limited time, go on holiday, have an especially busy period now and then, etc.. It seems difficult to formulate programmatic rules that don't cause more problems than they solve. The current community solution seems to be as good as anyone can come up with for the time being, I think.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on November 28, 2014, 02:13:42 AM
Personally the best solution would be to encourage people to work together. When I played OpenTTD people seldom played alone and there was at least 1 other player with them who helped run their company. For some reason I find players of Simutrans slightly more selfish and less willing to share companies.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on November 28, 2014, 04:16:49 AM
I wonder if it's less of a community thing and more of a nuance of Simutrans that causes this.  I haven't played OpenTTD, so I can't compare, but I wonder if the mechanics of the game lend itself to certain gameplay behaviour.  Everything is so interconnected in Simutrans that anything you do can and will affect another player, often in an unintended negative way, due to the complexity of the simulation.  If you make a journey slightly faster than another player (even if only because of the available technology at the moment, which is an upgrade to what the other player had put in place), cargo/pax/mail may choose to take that route instead.  Because you've impacted another player negatively, thing brings out a competitive edge.

You'd probably have to set out clear boundaries for operation in order to avoid this.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 28, 2014, 10:11:55 AM
This is quite an interesting discussion. Ideally, I think, what I should like to see is a mixture of co-operation and (friendly) competition. Competition was, after all (and in many places remains) an important part of the history of transport, and it would be a shame for it not to be simulated. However, there is much to be said for multiple players running single, large companies and agreeing a division of responsibilities between them: people often have insufficient time to do everything themselves, and could achieve more in concert. With such a mechanism, a company in Simutrans becomes more like a company in real life.

Players in such a situation would have to have a high level of trust in each other, however, as there is no practical way to police intra-company relations (in case of a serious dispute, all that an administrator could realistically do is reset the password and give the new password to just one of the former players, and decide to whom to give it on the basis of who founded the company, if other players were introduced later, or, if they all stated at the same time, by the toss of a coin).

Whether people will need that amount of help or will want to trust another that much remains to be seen, but there seem to be a goodly number of people here in whom it seems that such trust could be reposed (although those are often those players who seem not to need much help, too).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: wlindley on November 28, 2014, 03:10:45 PM
Is it possible for more than one person, to play in one company slot?  That would let us play as a team ("You take care of buses and trucks, I'll handle the ships. George is doing our railways.")
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 28, 2014, 03:31:06 PM
Is it possible for more than one person, to play in one company slot?  That would let us play as a team ("You take care of buses and trucks, I'll handle the ships. George is doing our railways.")

Yes, this is indeed possible, both in Standard and Experimental.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on November 28, 2014, 03:45:23 PM
When the server game first started, there was about 4-5 of us playing simultaneously.  AEO and I were the two most active players and he concentrated on the north west portion of the map and I on the eastern island coastal area.  He had more industry on that side (due to industry clumping) while I had a lot less and early on focused on a pax/mail service.  There was another player who focused on the internal area of the eastern island and the other players took up the remaining areas but were less active and created smaller networks.

While boundaries were never formally discussed, there was an implicit understanding that we each concentrated in an area and only in minor ways connected to other areas.

In the early part of the game, this was easy, as convoy speeds were slower and there was a lot of open space to expand.

Fast forward to the mid 1800's and most of the initial players went inactive and new players came on the scene to either attempt to build a new company or revive an existing one.  Not being present at the initial start and faced with a map that was highly connected with few new opportunities for expansion, some of these new players set up networks within the areas already served by existing companies.  In some cases they were complimentary services, providing local access to customers that was not otherwise present, but in same cases the services were directly competitive.  New players see the profits and success of the old, large companies, and want to have a chance to compete and match their output.  Old players want to preserve what they have and continue to service these areas.

The moment competition begins, it changes the dynamics for everyone.  Old players protect, new players expand.  And the action of both, while individually noble, ends up creating a competitive atmosphere that tries to carefully balance between friendly gamesmanship and aggressive predatory expansion.

It's an interesting case study in human economic behaviour.

Part of the dynamics in this particular game were brought about by issues in the pakset/game, that once resolved will not put pressure on players: very little new industry was created after 1850 (and now is almost entirely just coal power plants) and city expansion was rapid and covered a significant portion of the land area on the map.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on November 29, 2014, 12:12:33 AM
Personally I would have preferred to enter with a large existing company but all I had was a tiny "fail startup" company which I swung around to become the big freight company it currently is. At the time I joined all big companies were still active or password locked and later after starting up my wrought iron industry it was too late to move across.

There is no way to tell if a new player is a troll, a newbie or a serious person who wants in at managing something.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 29, 2014, 12:34:03 AM
I should be interested to know how much trolling activity that there has actually been in this server game.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on November 29, 2014, 02:50:28 AM
None, that I know of.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on November 29, 2014, 02:58:54 AM
Supergood mentioned someone having done so (some kind of sabotage), but I haven't seen any directly.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on November 29, 2014, 04:43:32 AM
There has been no purposeful trolling as far as I can tell. That said they are pretty much limited to a normal starting company so cannot troll that much (usually the people try to make profit and then quit to never return after they go bust).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on November 29, 2014, 12:15:08 PM
That is interesting, and somewhat encouraging.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on December 18, 2014, 09:36:57 PM
This seems to be failing on startup: the virtual server had run out of free space, but, even after clearing it of free space, it still seems to fail. I am afraid that I do not have time to find and fix the problem at present.

Edit: The saved game was corrupted. I have restored a backup version of the save, and it seems to be working now.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DesiroUFOSound on January 05, 2015, 10:14:57 PM
Someone has Blocked   shipping routes not me im building underground railways
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 09:47:28 AM
Which shipping routes are blocked and how?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DesiroUFOSound on January 06, 2015, 10:43:21 AM
A causeway with road on it is the problem near the middle of the map stopping ships pass  having a knock on effect for other players profits
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 11:24:04 AM
Can you give me the co-ordinates?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DesiroUFOSound on January 06, 2015, 11:50:56 AM
A block at 1179 938 another at 1129 1026 and another at 1212 913  if i see more i will post co ords
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 12:22:33 PM
Thank you for that - I think that I have got them, and also locked the account of the player who was doing this, as this was clearly intended to be malicious rather than just thoughtless.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on January 06, 2015, 06:17:44 PM
Technically DrSupergoods are partly operating my company. I understand thia is a personal thing that one just don't want to share companies, but unregulated competition only make a mess ofthings especially when some players has already been too large and the small one just struggles. It also causes extend service overlap, that's why the "chocolate express" eventually caused such a big problem London Transport Board is eventually formed to regulate bus services. Competitioms like we jave in the map just doesn't happen in real life(at least in the modern world).
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 06:46:20 PM
More or less unregulated competition prevailed for most of transport history, and modern authoritarian state regulation is really a very new thing, although it was a creeping advance through much of the 20th century.

The causeways should be impossible to build in the next version, and the one thing that we do not allow on the server is action that is malicious (that is, intended primarily or solely to harm another player's company) in nature.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on January 06, 2015, 07:42:27 PM
Frankly I haven't seen such action happening. But the fact is that competition can lead to such action. I.E. I'm a really large company and build a same route alongside the existing one simply I can afford to lose some money to some route. This action is simply to completely eliminate competition by brankrupting rival companies. Doea that count as malicious?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 08:33:01 PM
Frankly I haven't seen such action happening. But the fact is that competition can lead to such action. I.E. I'm a really large company and build a same route alongside the existing one simply I can afford to lose some money to some route. This action is simply to completely eliminate competition by brankrupting rival companies. Doea that count as malicious?

This is an edge case: this sort of thing can happen in reality in many contexts, although it is sometimes prohibited by regulation. It would be very difficult to work out whether any given loss making route is intended as a feeder route or intended to harm, I think.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DesiroUFOSound on January 06, 2015, 09:29:07 PM
My underground railway made me a massive loss so i sold it all replacing it with buses   now waiting for 1980s buses like Leyland National  ;)
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on January 06, 2015, 09:30:49 PM
The problem was no one was playing the server. As such I stopped playing to slow the advance of time. Eventually all our companies passwords were stripped and so abuse could begin when someone eventually did join. I re-locked my company yesterday but the others were left unlocked.

If we could find more players it would be great. It is pointless me playing alone as I might as well be singleplayer.

Also the pakset itself has died by this time. In a mostly water based map there are no more viable ships to come. Without such ships managing the number of goods is impossible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: VOLVO on January 06, 2015, 09:33:52 PM
Please could you do this for me please. I shall be back soon. What year is this now by the way, looks like I missed a lot.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 10:22:22 PM
Yes, there are balance issues in the current version (town growth, possible issues with ships that I will investigate) that limit the playability, which may have been responsible for the demise, but the next version is some time from being ready, so I might as well keep this going for now.

Can someone elaborate a little more on the issue with ships? I note that it has been mentioned before, but I cannot recall the details, and I cannot recall whether this has been addressed in the development version of the pakset or not.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 06, 2015, 11:26:04 PM
I still log in every few days to check on things.  With no one playing, however, the clock is barely moving forward.

The core issue for ships is that after the Windjammer, which has a storage capacity of 900 piece goods + 2450 of other cargo (3350 total) in its holds, does not have a viable upgrade after it expires.  This was discussed some time ago and if I recall it may have been addressed: the holds of the next generation of ships may have been updated already (but not in the pakset used for the server game).  I have several thousand windjammers currently plying the seas -- when I have to upgrade to the 800 hold version (though faster than the windjammer), I will have to swell my flotilla by a factor of 3 or 4 just to equal what I am currently serving.

This issue aside, the main reason the game has gone stagnant for me is that there isn't anything to do.  Every new industry is a coal power plant, and given that power supply seemed to be causing a lot of desynchs, we can't even servicing them.

Population is still slowly growing, and creates an opportunity to expand local services a bit, but other than that the map is saturated and there isn't much to do.  With the only viable cross-map pax/mail transport being underground rail, which is locked at 120 km/h max speed until new tunnels arrive in 1959 (and then, only up to 135 km/h) we're pretty much finished there too, until high speed, high volume air travel opens up in the 50's/60's.

The sheer size of the download is a negative drawback as well, especially with the odd desynch still occurring.  The transfer/load and initialization process takes a good 5 minutes, and when the game desynchs 5 minutes later, it's hard to find the desire to want to do another 5 minute transfer/load.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 06, 2015, 11:53:49 PM
Thank you - that is useful feedback. It is hard to tell, because running an experiment on this scale is not easy, but I am hoping that more restrained town growth will result in a far less intensively worked map and in consequence a smaller download/loading time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on January 07, 2015, 02:08:54 AM
I am also concerned about the viability of rail late game in maps of this scale. Where as ships can fit nice and compactly in routes over water, trains need massive amounts of rail all over the place with 50 tile long stations to perform similar routes. Where as in the water map there are massive shipping lanes, if this was a land map they would probably be 20 wide parallel railway tracks. Since double track scale is not an option I would recommend scaling down the length of trains a tad. If that 50 tile long train is just 15 tiles long things are much more manageable and the world need not be covered in rail.

As for passengers, I would recommend trying to only spawn possible journeys (no journey should be impossible with the current available transport). Early on most passengers viewed most journeys as "too slow" even if you had a pretty efficient connection set up (cross map boats). Maybe have some sort of average journey speed and journey multiplier statistic that can vary with age. When I set up some stage coach routes within towns it was at the stage where for a reasonable town I needed >50 stage coaches and still could not move enough people around. In the early 1800 there should be very few journeys made in total as people hardly travelled between towns let alone across the map.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on January 07, 2015, 05:06:39 AM
I relocked mine a week ago. Has it been opened again?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 07, 2015, 11:37:51 AM
I am also concerned about the viability of rail late game in maps of this scale. Where as ships can fit nice and compactly in routes over water, trains need massive amounts of rail all over the place with 50 tile long stations to perform similar routes. Where as in the water map there are massive shipping lanes, if this was a land map they would probably be 20 wide parallel railway tracks. Since double track scale is not an option I would recommend scaling down the length of trains a tad. If that 50 tile long train is just 15 tiles long things are much more manageable and the world need not be covered in rail.

Where does the idea of 50 tile long stations come from: what exactly would these trains be serving? The viability of rail and ship should be realistic to each era. The capacity of rail freight wagons are closely based on the capacities of real rail freight wagons, as are the capacities of ships on real ships. Industry output and demand, however, has been recalibrated in the pakset since 0.9.1, which may affect things somewhat. Other than industry demand and output, the thing that is not realistic in this map is the urban density or sprawl, which is as a result of the city growth system that needs to be fixed: what we have at present is the equivalent of the entirety of England nearly covered with one enormous, converged metropolis. This is likely to affect the viability of rail, as, at present, it is very difficult to build any rail lines anywhere.

Quote
As for passengers, I would recommend trying to only spawn possible journeys (no journey should be impossible with the current available transport). Early on most passengers viewed most journeys as "too slow" even if you had a pretty efficient connection set up (cross map boats). Maybe have some sort of average journey speed and journey multiplier statistic that can vary with age. When I set up some stage coach routes within towns it was at the stage where for a reasonable town I needed >50 stage coaches and still could not move enough people around. In the early 1800 there should be very few journeys made in total as people hardly travelled between towns let alone across the map.

The passenger generation system is redesigned for the next major release, but not in the way that you suggest, rather in a way that should be even more realistic. The reality is that far fewer people travelled in eras past, precisely because transport was slower. Many people will only make a given journey if it can be done in a short time. People who live near the seaside visit the seaside a lot more often than people who live far from it. The new model, which I believe that I have discussed in detail elsewhere, will in time be linked to a new model of city growth that will mean that successful passenger transport (which will be linked to successful freight transport by means of successful passenger trips being able to be made to consumer industries only in so far as they are provided with goods), which should drive a far greater degree of realism. The system for passenger generation that exists in 11.35 is based on distance ranges and produces quite a number of anomalies which will hopefully be eliminated in the next major version.

Junna: I cannot remember whether your company is unlocked or not.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on January 07, 2015, 04:17:11 PM
Quote
Where does the idea of 50 tile long stations come from: what exactly would these trains be serving? The viability of rail and ship should be realistic to each era. The capacity of rail freight wagons are closely based on the capacities of real rail freight wagons, as are the capacities of ships on real ships.
Their capacities are, but the lengths are not. Where as a 4 tile long ship can hold 2000 tons of cargo, a modern train needs over 18 tiles. Where as for the ship I could use a 4*4 odd station with storage buildings, the train will need 1*18tiles and possibly more if high throughput. If Food is transported raise that to 20 tiles long. On top of that only 1 train can occupy a section of the track at a time meaning that where as a single tile wide shipping lane can move near infinite amounts of goods, the trains will need multiple tracks in parallel. Sarlock shows this with his cross map underground food trains where he has large town sized stations to accept all the freight traffic.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 07, 2015, 04:23:16 PM
The town sized stations are necessitated because of the excessive demand, though, are they not? It is quite fundamental to the way that Experimental is set up that the vehicles have realistic values for all of the data that can be specified for them.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 08, 2015, 06:35:36 AM
I love these discussions  ;D

Quote
The town sized stations are necessitated because of the excessive demand, though, are they not?

Sort of.  A 24 tile station is 3km long.  A 50 car train is probably only 4 tiles (500m) long at scale... so it really only needs a 4 tile station with respect to scale.

Balancing real world statistics against a game that has adjustments to scale (size and time) makes it very difficult to reconcile.  Realistically, a 1x6 station is 750m long and 125m wide---which is probably enough room for 5-8 platforms and can handle all but the longest of trains.  Such a station in reality would be able to handle a throughput far higher than it can in the game.

One could reconcile this difference by increasing train capacities by several-fold.  But then this breaks their continuity to reality... so, somewhere, something has to give in the balancing equation.

When you consider that modern freighter ships can carry a good 50,000t or more (much more, for some of the largest ones) this gets even more complicated.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on January 08, 2015, 11:53:16 AM
The real issue seems to me to be how limited that space really is in the game. On this current game, it is far more limited than it ought to be because of excessive town growth. This should hopefully be less of a problem in future games. Any alteration of the carrying capacity of rail vehicles beyond realistic values would have never-ending adverse consequences for realism, such as a reduction in the tare weight to payload ratio, difficulty in balancing capital cost of wagons using realistic values, inaccurate track wear (and getting even more complicated if the same is applied to road where the fourth power law gives an exponential relationship between loaded weight and wear). Every decision made in the design of Experimental and this pakset is premised on the use of as near to real life figures as possible.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on January 08, 2015, 03:36:21 PM
Town growth itself isn't an issue - a well established player can easily afford to bulldoze as many city buildings as they need to make space for additional platforms and ways.  Where it gets challenging, or in some places, impossible, is where areas get hemmed in with unbulldozable objects (factories, attractions, etc) and other player's ways and stations (most of whom have long since gone inactive).

Fortunately we've been able to expand significantly underground on this map and could find the room to make these large stations.  Doing it above ground would be almost impossible.

I understand the implications of changing capacities, and wasn't necessarily advocating this change, but I was highlighting one of the issues.  We're only simulating part of the economics, so it ends up heavily skewing things to certain choices gameplay-wise.  Balancing to gameplay needs is more important that modelling reality, if we want to create a balanced game.

When we reach air travel in the game, wait until you see the monstrous sizes of airports we'll need  :o
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on February 28, 2015, 01:33:55 AM
I have been locked out of my company, either that or forgotten my password. Seems server activity is picking up again so might want to play.

I think it is time to raise the issue of "will Sarlock go broke before the end of the server"? By this I mean from overflowing his company's money counter resulting in him having an impossible debt for a while which underflows. This already is happening to the public service provider which is stuck in oscillation between impossible debt and insane wealth. The big issue is if his company will be subject to removal during the oscillation.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Sarlock on February 28, 2015, 05:48:58 AM
Interesting to find out!

I haven't been on in quite some time and seem to have been locked out of mine as well.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on March 14, 2015, 02:56:02 PM
I notice that the server had gone down owing to a mutant logfile eating up most of the hard drive space. It is back running now at the beginning of November 1942; a small amount of time progression may have been lost owing to the failure. Sorry for any trouble.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on October 21, 2016, 12:29:53 PM
I think that this has been disused for some considerable time.

However, this seems to be the pertinent thread in which to note that I have just upgraded the server to increase from 3Gb to 4Gb of RAM, and to increase from 1 core to 4 cores (which actually costs me less than the previous arrangement owing, I suppose, to advances in technology). The increase in number of cores in particular should improve loading/saving speed, which is multi-threaded and can be one of the more annoying things to have to wait for.

This is running what is technically still the current release version, but it is very out of date. I wonder whether there would be any merit in running the latest development builds for testing purposes?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Junna on October 21, 2016, 02:19:05 PM
I would say that sounds like a good idea. Certainly is why I haven't been on it for a very long time.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: DrSuperGood on October 22, 2016, 06:25:20 AM
To be honest I thought the server died about a year ago. The server listing server died so knowing it was operational was near impossible.

I would recommend using it for nightly tests. Maybe with a smaller map, maybe specific conditions that need testing.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Vladki on October 22, 2016, 06:37:36 AM
You can test stuff at server.exp.simutrans.com.
It is not updated every day though.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on October 22, 2016, 07:31:16 AM
I was hoping to test with a larger map; the other server may be better for testing specific issues. Dr. Supergood - the announce server is not run by me. If nobody else is able to host it, I could run it on my server, but I do not know how to configure it.
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: Vladki on October 22, 2016, 06:11:23 PM
I can run larger map (or even multiple servers). I don't know how to run listing server, but can try it. Is it part of simutrans sources?
Title: Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
Post by: jamespetts on October 22, 2016, 07:07:21 PM
I do not think so - I am not sure how it is set up.