bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.0

[jamespetts]

I am also getting desynchs, but am able to get a little editing done between each.
EDIT: No - desynchs are quite bad. :-(

Hmm - I am wondering whether the problem is the one discussed here, which is a specific long-standing problem only just fixed in Standard that applies to Linux servers. It might be worth pushing out another new version just to fix this, or at least see whether it fixes this.

It's still there at 1389,1475. Dark brown road is public but built on alignment I engineered, was previously player-owned. Have drawn track either side. Possibly it was fixed but got lost in a resave?

Are you sure? By dark brown, do you mean MacAdam rather than unsurfaced? The tile that you gave was a railway tile in your ownership. I have removed a few more road tiles from the East of that area. I am not sure where it is that you want to build here. What other tiles need removing?

Am also becoming concerned at the financial side of the game - not sure what settings we're using, but because there's no pause in a server game, it's impossible to make changes without bleeding out a fortune in lost revenue. I think the money side of the game needs slowing down - income and expenditure, by maybe a factor of 10. This would also greatly reduce the stress/ urgency of online play- the need to check in twice daily to see if you've gone bankrupt yet.

In single player-games, large scale re-engineering is possible (essential), but it seems in the server games, not to be. My company has gone from £27M to £7m because of the time the work has taken (some of that was expected losses, but I'm nowhere close to finishing, and may well go bankrupt). Mainly it's because other players, inevitably, run the clock on substantially whilst any given player is not online. The only way I can see around this, apart from a server pause function (which would be nightmarish to manage) is to reduce the flow of money in/out.

This issue, and the subsequent discussions, are most interesting and need careful consideration. One thing to consider is that the high turnovers per unit of time are necessitated by the high number of passengers/mail, which are slated for substantial calibration. What I don't know is whether a game in which the number of travelling passengers was more realistic would still exhibit this issue. If it did, the question is what exactly could be made slower? The only way of achieving this, I think, would be to increase the bits per month setting, which would double (or quadruple, or multiply by eight, etc. in factors of two) the time that it takes for each game month to pass, and concomitantly change the relationship between capital costs and monthly costs and per trip/km costs/revenues. Simply decreasing revenues and running costs by the same amount would do nothing useful, as the proportion between them would be the same. I should be interested in any views on the most effective way of addressing this. Is there something to be said for increasing the bits per month setting to 22? This would mean that it really would take a long time for years to pass, I think about 1 every day, assuming that somebody is constantly connected. We perhaps need to assess how things work when the passenger generation is recalibrated, however; or do people think that the issue of the time that it takes to build infrastructure is cause enough to increase this number by itself?

As to the other discussion - station maintenance has been recalibrated completely already in preparation for the release of 0.9.0, and it is right in economic, historical and game-play terms that massive over-expansion (especially by building railway tracks just to save space long before any trains are ready to run on them) ought be financially ruinous. Early railways were built as local affairs and only slowly expanded into large trans-national networks: this should be how it is necessary to build railways in Simutrans-Experimental, too. On refunds, note that 10.16 introduced a new feature whereby a player who is already overdrawn will not be charged any refunds, which should stop players becoming bankrupt by the action of refunds.

As to "marking" routes in advance, the idea of putting down a shadow route then clicking "build" is an idea that has been mooted many times in the past. It would be a massive change to the code and require an enormous amount of work to implement. It has been rejected for Standard for now, and I do not see the coding resources being available to implement it in Experimental any time soon. The way that this would have to work, though, to avoid players just grabbing land for the sake of it or to block competition (this would not have been allowed in reality) is that players would mark their route only for their own convenience: a marking of a route would not stop somebody else from building on it first. This would, unfortunately, reduce substantially the utility of doing so, but there is no way around this. However, there is in some respects much to be said for the current situation: there is a strong disincentive (unrealistically) to "mark" routes for future use because of the maintenance liabilities that doing so will engender. Players ought only to build routes that they are about to use in the near future.

Any other thoughts on this topic would be most welcome!

[ӔO]

It would be nice if unused stops were deleted.

There are a bunch of them littered about and it makes it doesn't make sense that a railway has to navigate around them.

[AP]

Financially, I think the cost of building stuff is "about right" (with a few exceptions e.g. bridges). Presumabli increasing the bits-per-month would keep that the same, we'd just be able to build stuff less often. In which case that sounds right. It's quite possible that the "default for server play" needs to be very different than the default for single player games.

Are you sure

I checked again after posting - my mistake. Tile was visibly the same but unowned now. Somewhat moot, of course now.

As to "marking" routes in advance, the idea of putting down a shadow route then clicking "build" is an idea that has been mooted many times in the past. It would be a massive change to the code and require an enormous amount of work to implement. It has been rejected for Standard for now, and I do not see the coding resources being available to implement it in Experimental any time soon. The way that this would have to work, though, to avoid players just grabbing land for the sake of it or to block competition (this would not have been allowed in reality) is that players would mark their route only for their own convenience: a marking of a route would not stop somebody else from building on it first. This would, unfortunately, reduce substantially the utility of doing so, but there is no way around this. However, there is in some respects much to be said for the current situation: there is a strong disincentive (unrealistically) to "mark" routes for future use because of the maintenance liabilities that doing so will engender. Players ought only to build routes that they are about to use in the near future.

An interesting aside is how players build routes. I was very surprised to see all the other players in game building railways up and over hills, vast viaducts and such. If one is prepared to do that, clearly no planning or survey ahead is necessary. I took the view (and usually do) that trains dislike hills, so make my railways (and in this game, roads too) dead flat, following contours and such, so that trains will never slow to a crawl going over a hill (which I assume should lose money once the game is balanced).  This is, I suggest, the more realistic approach. However, it relies on terrain at a given contour being available all the way across the map - which is why I "marked out" the route using a road first.

I agree pre-building vast amounts of network should be financially ruinous, unless the gameplay is such that it's the only way to build it - a few elements at a time. There are certainly precedents for canals being replaced by railways on the same alignment (re-using the engineering as I was doing), but it's inherently slow.

[Junna]

An interesting aside is how players build routes. I was very surprised to see all the other players in game building railways up and over hills, vast viaducts and such. If one is prepared to do that, clearly no planning or survey ahead is necessary. I took the view (and usually do) that trains dislike hills, so make my railways (and in this game, roads too) dead flat, following contours and such, so that trains will never slow to a crawl going over a hill (which I assume should lose money once the game is balanced).  This is, I suggest, the more realistic approach. However, it relies on terrain at a given contour being available all the way across the map - which is why I "marked out" the route using a road first.

I agree pre-building vast amounts of network should be financially ruinous, unless the gameplay is such that it's the only way to build it - a few elements at a time. There are certainly precedents for canals being replaced by railways on the same alignment (re-using the engineering as I was doing), but it's inherently slow.

I believe this is a product of some of our players being a bit new to experimental, and play in the manner of standard - and from what I've seen in standard save-game from multiplayer, players often build very many unsightly viaducts and bridges all over the place, as well as the prevalent sharp turns (I'd call them amateurish, but it's a perfectly sensible approach in standard, apart from being terribly ugly). I think that this is the reason for these odd play-styles!

[greenling]

Hello on all
I think that a Tool that reserved plots for later to building Road and Rail a very useful tool it.
I self have alive, that the build from new Road and rails in later games get some problem to finance
and problem to find a good route.
With a tool that reserved plots can you save very many money.

[jamespetts]

Interesting discussion!

Greenling - actually, there is such a tool: the marker sign. This can be used without any sign text, and acts (whether sign text is used or not) as a tool for purchasing plots of land. It can only be done one tile at a time, however, not dragged.

Junna raises an interesting point that people may well need to adapt their play style for Experimental. As AP points out, if the Standard play style is financially workable in Experimental, the pakset isn't balanced properly. That is not surprising - much work needs to go into pakset balancing, and substantial work on the code is necessary before balancing is possible.

AEO - what do you mean by unused stops here? One can't just go around deleting any stop that doesn't have a service, as the player who owns it might need it for later, and/or the cessation might be temporary. Indeed, service might not have commenced yet.

[greenling]

Interesting discussion!
Greenling - actually, there is such a tool: the marker sign. This can be used without any sign text, and acts (whether sign text is used or not) as a tool for purchasing plots of land. It can only be done one tile at a time, however, not dragged.

Yes, I have that marker sign seen but there is when the use this marker sign a lot of problems.
Are the problems that makes it:
It is useless for the reservation of large surfaces.
Because it flooded when it is inserted the marker sign menu in bulk list which can lead to problems.
Also the purchase price and the price of the maintenance is not quite true.
These are the reasons why I do not like to use because marker sign.

[AP]

Greenling - actually, there is such a tool: the marker sign. This can be used without any sign text, and acts (whether sign text is used or not) as a tool for purchasing plots of land. It can only be done one tile at a time, however, not dragged.

A dragged tool would have the key advantage of being able to be upgrade-to-track end to end with just two clicks. Would greatly assist in the building of a route over many evenings etc without ruinous costs.

Can a player-owned item be deletable by other players (just this one type of way, not anything else?) - to prevent land-grabbing?

[greenling]

Hello to all
If you want to then I design a new country reservation tool that taken over by road, railway, Canal, maglev train can.

[rsdworker]

Hello to all
If you want to then I design a new country reservation tool that taken over by road, railway, Canal, maglev train can.

sounds good

[ӔO]

AEO - what do you mean by unused stops here? One can't just go around deleting any stop that doesn't have a service, as the player who owns it might need it for later, and/or the cessation might be temporary. Indeed, service might not have commenced yet.

After a year of being unused, it ought to be removed, because sometimes those stops become forgotten.

[wlindley]

After a year of being unused, it ought to be removed, because sometimes those stops become forgotten.

((scrolling bulletin))  Citizens of Tarrot Downs have removed three of your bus shelters as eyesores.

[greenling]

After a year of being unused, it ought to be removed, because sometimes those stops become forgotten.

Sometimes I build stations, train stations, loading dock, post boxes and other things as a preliminary planning for a line to be built later.

[ӔO]

just bus and truck stops.
one year ought to be enough time to add a line that will use it, no?

[AP]

just bus and truck stops.
one year ought to be enough time to add a line that will use it, no?

Not on the basis of current construction times. Took me 6 game years to get a rail route put together, during which time various associated road routes were being re-worked entirely. Also in the server game another player cut off two of my stops entirely, what happens in that case? Also, re durations, can things be coded in real-life time? E.g. unused infrastructure on public road (only) gets deleted after 2 RL weeks of inactivity, irrespective of how much game time passes?

[ӔO]

yeah, I don't mean stations. only bus and truck stops on public roads

[asaphxiix]

Not on the basis of current construction times. Took me 6 game years to get a rail route put together, during which time various associated road routes were being re-worked entirely. Also in the server game another player cut off two of my stops entirely, what happens in that case? Also, re durations, can things be coded in real-life time? E.g. unused infrastructure on public road (only) gets deleted after 2 RL weeks of inactivity, irrespective of how much game time passes?

you shouldn't be reserving so much track that takes 6 years to build. This shouldn't happen in an online game.

[Vonjo]

yeah, I don't mean stations. only bus and truck stops on public roads

But what if when you work in a city on a network game, electricity in your house goes down, and when it turn back on, those stops have disappeared. Even worse, someone else can take that city.

But yes, sometimes some stops can be carelessly forgotten.

[AP]

you shouldn't be reserving so much track that takes 6 years to build. This shouldn't happen in an online game.

"reserving"? I was replacing my own player-owned roads with rail, over heavily engineered routes my company had paid to terraform. I don't think that's unreasonable. There's a lot of editing to setting up feeder routes - you can't set the main routes going without the feeder routes being adjusted. That it took 6 game years was also down to the other players "running the clock on" (legitimately) whilst I was away from the computer. I don't think it's at all reasonable to expect people to work at a server game for 8 hours straight, it's done over the course of several/many evenings, which can easily be an in-game decade. This goes back to the discussion of how many bits per year though, rather than how to edit /plan routes.

Also, you can't balance the spacing of vehicles on a route without the entire length of the route available; you'd end up re-doing it each time you extend it (which when vehicles are slow, is very tedious).

[asaphxiix]

perhaps, since not all players can play currently, the server could be suspended till the new version with the bugfix?

[ӔO]

I don't seem to be able to make a profit anymore.

Maintenance is bad, but so are running costs.

The cause seems to be a myriad of things.
1. high volume resulting in long and heavy trains
2. locomotives are not powerful enough to climb a single hill
3a. adding enough locomotives to climb the hill causes high running costs, which cannot be paid
3b. not adding locomotives causes severe backups and degraded line capacity
4. demand cannot be met, therefore refunds are issued and passengers wander around the lines, further clogging an already bad situation

[AP]

2. locomotives are not powerful enough to climb a single hill
3a. adding enough locomotives to climb the hill causes high running costs, which cannot be paid
3b. not adding locomotives causes severe backups and degraded line capacity

These 3 are related and realistic. Hence all my lines (before their untimely demise due to financial mismanagement...) were perfectly flat across the entire map, at great engineering cost (and long construction time), and I had 3 incline planes (as did the Liverpool-Manchester Railway, Canterbury Whitstable railway, and others of the time) where altitude gain was concentrated until it could not be avoided, and 3/4/5/6 tiles climbed at once. Anything else simply does not work. I don't think this should be changed in-game.

1. high volume resulting in long and heavy trains
4. demand cannot be met, therefore refunds are issued and passengers wander around the lines, further clogging an already bad situation

This is the balancing issue. High demand is okay until it results in massive refunds, which was what I found happened to me when I tried passenger trains.

[asaphxiix]

good point there. seems that they would run trains with cables through one incline on the S&DR line, but the line was otherwise flat. Guess we'll have to wait till 1847, if we make it till then

[jamespetts]

Of interest, on the question of calibration of the passenger factor, I have done a considerable amount of calculation here, which I urge players of this server to read and comment on, particularly the discussion about urban population densities and whether journeys of under 1 mile (1.6km) should be excluded from the figures when calculating the total number of trips that passengers make per year.

[AP]

Of interest, on the question of calibration of the passenger factor, I have done a considerable amount of calculation here, which I urge players of this server to read and comment on, particularly the discussion about urban population densities and whether journeys of under 1 mile (1.6km) should be excluded from the figures when calculating the total number of trips that passengers make per year.

Reading ... understanding may take longer! In particular I can't immediately find definitions for bev, arb, and won, which may be buried earlier in that thread...
I certainly think that far too many passengers on the server are undertaking far too many uncomfortably long journeys (by sea and stagecoach), so will support efforts to curb that prior to the introduction of suitable first class rail travel etc.

[prissi]

Standard has an exponential falling distance factor, if enabled. This cust passengers travelling probability much stronger than the three parameter modell of experimental (although I am not sure if this still in used). Instead you have now a age dependent parameter which gives a probability for a travel, the lesser the longer (and earlier in time).

[jamespetts]

The server has been restarted with the latest releast, 10.18. Apart from fixing a few bugs, this incorporates a recent fix from Standard which should help to reduce the number of desyncs. I should be grateful for any feedback on how stable that this version is. Happy playing!

Prissi - this is very interesting. Was this introduced recently? How has this worked out in practice; in other words - how has it affected the way in which the games actually play out?

[wlindley]

With 10.18 on Linux 64-bit, the desyncs (knock on wood) are much reduced and the game is far more fluid and playable.  On top of which, specifying fps=15 on the client which is just a bit faster than fps=14 on the server, might be part of what's helping.  Huzzah!  Thanks to everyone! And to all a good night... (ignore the light at the end of the hall)

[asaphxiix]

how do you define fps on client? simuconf.tab?

[TurfIt]

You don't. Server controls FPS in network games.

[wlindley]

Does specifying -fps on the command line have no effect?

[asaphxiix]

sadly, right now I cannot join at all - I enter the game rather quickly, and lose sync immediately.

[asaphxiix]

also a funny anecdote, that since South Empire was bankrupt, my losses have diminished to virtually nothing (pretty even now).

I guess those severe jams near coatsand (which I requested several times to resolve) were much more devastating than I thought. I think this shows how important proper moderation is in online play.

[AP]

I guess those severe jams near coatsand (which I requested several times to resolve) were much more devastating than I thought

Sorry about those, but I had tried several things to resolve them, they started moving each time. I think when adding a second route to a city that already has one, care is needed to avoid crossing and re-crossing the two lines, otherwise you get frequent gridlock (where all 4 sides of the city block are jammed so nothing can move). That seems to have been the root of most trouble, and it's quite tricky to resolve retrospectively (without traffic lights!), since one player can never delete the vehicles of another, so altering city roads to remove junctions is almost impossible.

I was also test-running a long-distance Rail Passenger service from Clacingford to Edby , which will have competed with other players, so I could get some stats about their (un) profitability. With my liquidation, that competition will have been removed.

I did notice that when railways appeared, a number of instances of players bisecting cities without checking which roads were in use by other players, and thus cutting off one or two stops on a route from the rest (e.g. near Clacingford dock). This is particularly devastating in an online game, because the vehicles with "no route" get auto-sent to depot, so if the game is run-on by other players, an entire route can be depopulated without the player knowing, which can really mess up network balance. I think building embankments and altering roads is fine, but cutting off through routes being relied upon by others, without provision of a *public* alternative, should be avoided.

[jamespetts]

sadly, right now I cannot join at all - I enter the game rather quickly, and lose sync immediately.

Hmm - are you still having this difficulty? Have you made sure to update to 10.18? It's odd that you should be getting this when others are not.

I did notice that when railways appeared, a number of instances of players bisecting cities without checking which roads were in use by other players, and thus cutting off one or two stops on a route from the rest (e.g. near Clacingford dock). This is particularly devastating in an online game, because the vehicles with "no route" get auto-sent to depot, so if the game is run-on by other players, an entire route can be depopulated without the player knowing, which can really mess up network balance. I think building embankments and altering roads is fine, but cutting off through routes being relied upon by others, without provision of a *public* alternative, should be avoided.

Hmm - can you give me some examples of where that's occurred? I did introduce new code in 10.17 aimed at stopping players from demolishing roads in cities that were the last piece of road connecting any given city building to anything else, but perhaps code alone won't suffice for these purposes: perhaps we need some server rules? I should appreciate any thoughts on that question.