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

[jamespetts]

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



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

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

Notes:

• Remember to set a password: do this by going to the "players" dialogue and clicking the little green box
• Please set a meaningful and realistic company name
• Please do not run more than 1 company simultaneously, to allow others to join in (players may start new companies if their old ones become bankrupt, even before the bankrupt companies are deleted completely).
• Please replace any roads deleted (if you wish in a different place) so that anything that was connected before you deleted any roads remains connected.
• Please allow access to other players if you build over a public road or canalise a river.
• Roads between towns are not owned by the public player and may be deleted (and then replaced in a different configuration - see above) to allow for level crossings
• Players are encouraged to build their own inter-city roads for all to use - tolls will be payable for using other players' roads.
• Towns start either not connected at all or connected only with roads that wheeled vehicles cannot traverse
• Anyone whose company is unused after 10 years will have their password automatically reset
• Anyone whose company has never built anything will have their password automatically reset after 2 years
• This is likely to be the last Simutrans-Experimental online game started before double/half heights are introduced.
• This online game might be stopped short when the next major release of Simutrans-Experimental (with double/half heights) is ready
• Pak128.Britain-Ex is not yet fully balanced.
• Please report any bugs with the game or pakset on the appropriate boards, not in this thread
• As the game develops, it will become more demanding on computational resources. Slower computers might not be able to keep up.

Happy playing!

[ӔO]

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?

[Sarlock]

Wow, new pakset, new Experimental release, new server... you were busy today, James!

Now to carefully consider the design of my initial network...

[jamespetts]

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.

[AP]

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.

[jamespetts]

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.

[Sarlock]

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.

[jamespetts]

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.

[Sarlock]

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.

[ӔO]

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.

[AP]

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.

[jamespetts]

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.

[ӔO]

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.

[Sarlock]

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.

[jamespetts]

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?

[ӔO]

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

[Sarlock]

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.

[AP]

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... :-(

[ӔO]

for me, the server side crashes in march and reverts to febuary.

[AP]

Ditto. Annoyingly it reverts to after I made my costly mistake with the terrain editor  .

[ӔO]

I do have this save from just before.

https://dl.dropboxusercontent.com/u/17111233/client3-network.sve

[Sarlock]

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.

[AP]

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

[Sarlock]

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.

[AP]

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.

[ӔO]

cow farm - dairy should be easily profitable too.

wooden planks - builder yard are probably the most profitable

[asaphxiix]

game is effectively down it seems - see here for report

[jamespetts]

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!

[Sarlock]

Thanks for looking in to it... seems fine now, no clue as to why it decided to hiccup at that same spot every time.

[ӔO]

the server seems to be doing the endless loop again for the beginning of june.

[Sarlock]

Indeed; another endless loop.  I wonder what's causing it.

[jamespetts]

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.

[Sarlock]

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.

[prissi]

Could it be that the threaded season change is to blame for this? Or is the server compiled explicitely without threads?

[TurfIt]

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