I thought that it would be useful to collect a list of balancing observations made whilst playing the new public server (http://forum.simutrans.com/index.php?topic=8969.0) so that there is a central place where I can look for this information when I have time to do something about the issues raised.
In no particular order, here are a few balancing issues that have been raised so far that I can recall:
- Tunnels cost too little to build but too much to maintain (both generally and compared particularly to bridges).
- Railway locomotives cost comparatively far more than railway track: either locomotives should cost less, or track should cost more.
- Successful railway/ship/road companies (at least, in the 1830s) are able to achieve an annual turnover on capital investment of over 100%, whereas, at least for rail, this should be not more than 10% (and probably similar for canals).
- Early steam locomotives are too slow and underpowered (at least after the Rocket - very early steam locomotives really were too slow and underpowered). This is - provisionally - fixed in the latest Pak128.Britain-Ex sources.
If anyone has any other thoughts, these would be welcome!
The passenger factor has been reported as being too high.
With regards rail, I think a fundamental question is, should one be able to build a successful railway as a first move? (I failed twice!) My impression of the pak is that railways need a large number of trains to break even, as a consequence of the slow speeds being achieved by the locomotives, otherwise most track is empty most of the time.
I think the starting budget needs reviewing, up, or down as a consequence. $250k is a very large number of horses and carriages, and quite a lot of sailing ships (wherries especially), but not very much railway or canal. And passenger railways need feeder routes, which cost further money.
I also think that the speed of the game timeline needs to be adjusted. When everything is moving around at 10km/h in 1830, it's like watching paint dry waiting for deliveries to arrive, and would be helped by having the game run at e.g. double speed, if it can be set up to vary with the date or something?
I was also suprised that I had difficulty making an industrial chain run at a profit. Coal/Ore to a steel mill, to a cannery, to a Grocer's, ought to yield a tidy reliable profit. But I had difficulty encouraging the food inputs to yield much produce (orchards giving 6 crates of apples to go with an entire trainload of steel...), and the industries seemed to lose money too. The industrial revolution was built on heavy industry moving stuff around, passengers were secondary. I also thought the map had too little heavy industry by a significant margin, although it had a nice number of towns and decent distances between.
To answer the question - yes, it should be possible to build a successful railway as one's first move (as AEO and dustNbone have in fact done) at the first instance, if one is careful: in reality, after all, most railway companies were founded from scratch, rather than branching out from existing canal companies. The long term plan for starting funds is to require players to borrow all of their starting capital from the bank for a fixed term, with interest: players who want to start small will borrow a small amount (and have a lower risk), whereas players who want to start big can borrow much more, but will have to earn a higher margin in order to make up the interest payments.
The timeline is a tricky issue - there is no provision in the code for it to be varied with time, and, if more interest/detail was added to the 1830s era (I shall have to look at adding some more locomotives to that era, I think, and I am already adding details to the carriages more generally), and things are balanced better, there will be more to do in that era. In particular, for the next pakset release, I plan on making 1830s era locomotives more powerful and faster. We must take account of the fact that players won't be able to be online all the time and the fact that, in later eras, when there is more to do, going too fast will be a problem. A persistent state online game such as this is perhaps suited to a more relaxed pace of logging on for a few hours every night rather than playing intensively as one might with a single player game.
As to industry - I certainly agree that this map has far too few: I shall have to rectify that the next time that I start a map. I am not quite sure why freight transport was not profitable - perhaps the revenues from freight are too low. The pakset does need rebalancing generally, so I shall have to look into the relative revenue of freight, I think. Does anyone have any suggestions in that regard?
Another item - not enough variety of steam locomotives in the late 1830s and early 1840s.
Edit:
Further -
* the Jenny Lind's per kilometre maintenance cost is far too low compared with other, later locomotives; and
* town growth is considerably too low.
Edit 2:
Also -
* the map roughness is too low; and
* the mountain height is too low.
some things I have noted while playing.
- Improved wrought iron track does not come early enough / LNWR Crewe type cannot be used to its full potential and meets an early demise to usefulness when Jenny Lind is introduced in 1947/6
- Freight locomotives generally have way too much power/maint./cost for the amount of freight available. Might be good to balance them against LNWR DX Goods.
- Needs a weaker and cheaper freight locomotive for early game.
- LNWR Sharp tank, somewhat of a mystery position with power/traction/cost/maint. compared to other locomotives available in 1850's. It is worse in every way compared to Jenny Lind.
- LNWR Problem / LNWR Bloomer, imbalanced against each other (possibly switch power/cost/maint. specs between the two)
- Not enough freight chains that are economically feasible
- 115km/h Brick viaduct is missing weight limit
- 200km/h Brick viaduct and Elevated Brick Viaduct, perhaps available too early
- Brick viaduct bridges need a length limit
- horse omnibus and hackney carriage could use an overcrowded capacity. Otherwise, it is very hard to notice when a horse carriage line is overloaded and can result in massive refunds that go unnoticed in the Line Management window.
- IMO, map might be better with 16:9 (or 9:16) ratio
Not a note from the online game, but it fits to what AEO said:
There is also a need for an a cheap, but not too fast engine for local trains and intra city trains as feeders. I used my planet well into the 60s (and duplicated it in depot, when i needed more)
Some companies are very difficult to play LNWR has a lot of wagons and engines, in mid 1863 there are only tank engines available for LNWR. LBSCR is very advantageous when Jenny Lind is available, but when it becomes obsolete, one is lacking an engine. Difficult are also MR which has only wagons but no engines and SDR with engines but no wagons (or was it only a freight line?). I know this is likely due to the fact that it is quite a lot of work to paint the rolling stock, i just mentioned it for completeness.
Hello
My little experience.
The PSComet (steam ship PAX+Mail) running cost should be slightly reduced .... (20 -> 17/18)?
Giuseppe
Quote from: AEO on January 27, 2012, 02:06:22 AMBrick viaduct bridges need a length limit
That one may be deliberate.
QuoteIMO, map might be better with 16:9 (or 9:16) ratio
I agree - most people have computer screens which are landscape, so having a map which can be maximised to fill it means you can see more information.
AP is right that the absence of a bridge length limit is deliberate, but they should not be able to cross deep ocean. I am planning to change the code to prevent bridges from crossing water that is more than 1 tile below sea level, and also prevent raising/lowering of land more than 1 tile below sea level, whilst increasing the cost by a factor of 5 for raising/lowering of land at sea level.
As to LNWR being a difficult company to play: first of all, the primary aim at this stage is not to enable players to play a single company, although it would be good to have that capability eventually (although it would require a very great many more vehicles), but for players to have a good selection of historical vehicles (from any company) in any given era to enable interesting and economically productive choices to be made about which vehicles to use.
A few miscellaneous points: the weight limit of the earlier bridge has been added on Github; and the hackney carriage and horse omnibus not having an overcrowded capacity is intentional, as neither of these vehicles in real life permitted standing.
The other points are noted for consideration.
Quote from: jamespetts on January 27, 2012, 09:26:07 PM
and also prevent raising/lowering of land more than 1 tile below sea level, whilst increasing the cost by a factor of 5 for raising/lowering of land at sea level
I think this is perhaps a bit harsh - unless public player is exempt from this restriction? I think it would be better with just a really excessive and prohibitive cost for it (much, much more than just 5x.)
often enough, cost doesn't matter at some point in the game. then you see those strange constructions, further tilting the game towards the player with the large advantage.
if not too difficult, excempting the public player from this restriction as suggested by Junna, would be very sensible.
Quote from: sdog on January 28, 2012, 05:13:56 AM
often enough, cost doesn't matter at some point in the game. then you see those strange constructions, further tilting the game towards the player with the large advantage
I think this is a significant balancing problem in the later game though, rather than something which should be used as a reason to price things out of reach in the early game.
What is needed is a mechanism to cause successful players with runaway bank balances to have to spend more than unsuccessful players with low bank balances. I suggested in another thread that costs of making changes to infrastructure might be proportional to the number of convoys using the tile each month, for instance - that's just one idea (and not an unrealistic one).
Junna,
as to the public player being exempt - there is a certain tension between the public player's two functions, firstly as map editor at the beginning of the game, and second as government after the game has started. As government, the public player should have just as much restriction on its physical activities as any other player, but some people prefer to use it for map editing purposes. I am beginning to wonder whether a good means of separating the two would be to disapply restrictions to the public player if freeplay mode is selected: in freeplay mode, the public player would be the map editor, and in non-freeplay mode, it would be the government. Additionally, everything would be free to the public player in freeplay mode so that the bank balance is not affected by map editing when freeplay is turned off. The idea would be that one can generate a map, turn freeplay on, edit with the public player, turn freeplay off, and then start playing. I should be interested in any thoughts on that idea.
As to balancing more generally - sdog and AP are correct to identify this as a problem. Fixing it is planned, but not easy. It was Moblet last year who explained at least part of (and possibly all of) the cause of this problem, being the insufficient utilisation based variability of costs. A number of his suggestions I plan to implement, as discussed here (http://forum.simutrans.com/index.php?topic=8172.0), but these will take time, especially as, at present, it is only me doing the coding.
AP's suggestion is an interesting one, but could easily be manipulated by a player just re-routing or stopping convoys for a month just before the change takes place to reduce the cost artificially.
Quote from: AP on January 28, 2012, 10:38:39 AM
I suggested in another thread that costs of making changes to infrastructure might be proportional to the number of convoys using the tile each month, for instance - that's just one idea (and not an unrealistic one).
Is that such a good solution, though? A player with high number of convoys is not necessarily the most stable and largest - your network for example, to use the latest online game as a basis, is far larger than mine, but I do have the most frequently travelled railway segment at around 25 convoys a month. Perhaps it would also be able to take into consideration also the general size (in terms of total income and total passengers carried)?
Quote from: jamespetts on January 28, 2012, 12:29:00 PM
I am beginning to wonder whether a good means of separating the two would be to disapply restrictions to the public player if freeplay mode is selected: in freeplay mode, the public player would be the map editor, and in non-freeplay mode, it would be the government. Additionally, everything would be free to the public player in freeplay mode so that the bank balance is not affected by map editing when freeplay is turned off. The idea would be that one can generate a map, turn freeplay on, edit with the public player, turn freeplay off, and then start playing. I should be interested in any thoughts on that idea
I do think that sounds like a fairly good compromise - is it easier or more difficult to do it that way than to exempt the public player entirely?
It is a more desirable way of doing it than exempting the public player entirely, since the public player can then be used as a government in game and have its own playing goals. I can set it to disable increasing/decreasing town size, manually adding industries and such other things, too, when not in freeplay mode.
Edit: As to balancing more generally, the better solutions are the utilisation based solutions in the thread linked above that are planned.
Hello James
In the online game "PSComet" running cost is 20, after the latest revision 3.5. Before your last change the value was 8.2, may be that you have inadvertently reduced the cost twice making it too low? (I think less then 15 is not a good choice ...).
Giuseppe
Ahh - it is indeed possible that I have reduced it twice by mistake. Try the latest commit and see whether that seems correct.
QuoteThe idea would be that one can generate a map, turn freeplay on, edit with the public player, turn freeplay off, and then start playing. I should be interested in any thoughts on that idea.
i'm not so sure if that is a good idea. the public player mostly has the function of a server admin or game-master now. And that is good i think. Turning the public player into something that could be played in it's own right is so incredibly distant from anything that could be achieved in simutrans that no effort should be spent to keep it possible to do so.
Simutrans is quite a decent network simulation, a straggling economic simulation, but simulating public sector -- seriously?
What you suggest above is i think needlessly complicated, restricts the use of the public player in game administration and doesn't really gain anything.
IMO, if exchanging money between players was implemented, all of the public sector simulations can be done.
Usually, public transport funded by the local government will set up a Commission, Bureau, Branch, Division, etc. and operate it like any other business that gets government subsidies. The subsidies can be provided by the public player on a case by case purpose.
Sdog - why do you say that it is beyond what can be achieved? Can you be more specific?
the public sector works on completely different principles than private sector.
Firstly the source of funds depends on completely other factors, it doesn't generate income in the game. Then, it's decissions are politically motivated. If the public sector wants to raise land, and build a bridge to nowhere, they can do it. (perhaps to boost construction sector, corruption, or having a hamlet with strategically important voters [or a rotten bourough in the early game], or to have a part of society participate). Thus it does not necessarily follow economic principles but sometimes solidarity.
That is for example building a bridge to allow remote vilagers to get to work and hospitals. which is so expensive the tax they pay will never cover it. Economically it would be suicide, in a wider context it might be completely reasonable. There are defense considerations too, having loyal population at a remote strategically important place might be worth quite an investment. (i won't mention the islands i have on my mind ...)
With all those factors influencing decissions, and a practically unlimited source of finances, public player decissions could be completely arbitrary. There's a different class of games that does that, starting with simcity, or tropico ending at those swedish nation simulations (europa universalis or so?). It's also quite a bit more complex than economy.
There is also much less degrees of freedom in making decissions, as a CEO of a private sector company has or rather had in the past. The public player would thus become a game "build a road from A to B using exactly the route [...]"
(just a thought that came while writing this, did you think about value of land? with economic factors influencing it? using costs for houses doesn't do the trick only very roughly [one can't sell land])
edit:
i think i should conclude: investing time to improve where simutrans experimental could be very interesting, that is an economic transport game, instead of starting another thread of development would be much wiser. More so as this would also reduce the usability of the public player that is required for moderating network games.
May I ask - what public player tools do you think are necessary for moderating a network game? So far, I have not had to do much other than build/delete roads on the bridgewater-brunel server.
As to the economic considerations - planned for the future (although not a priority) is to allow the public service player to generate income by raising tax (on players, partly, and also on cities, which would reduce their population growth). The public service player would act as the Simunation's ministry of transport, rather than government generally, and thus have available to it a rather limited budget (for these purposes, the revenue from the tax on transport operators, plus a small proportion of whatever tax is levied on the general population). Its aim in game terms would simply be to maximise growth using the tools available to it (which is why we need to restrict the increase/decrease population buttons, or else increasing growth would be a somewhat trivial task). That would need only relatively minor changes to the code.
if you are thinking about taxes, I would recommend a progressive tax rate.
That's an interesting idea, although could complicate things somewhat.
without getting too political, just by looking at what the players have in their bank, say 10% out of Lindley would be quite bad, while 10% out of mine doesn't hurt at all.
There may be something to be said for that - but implementation is the key!
"So far, I have not had to do much other than build/delete roads on the bridgewater-brunel server."
most of that work seems -- an impression from reading this thread -- to stem from your decission not to allow players to delete public roads.
Sometimes the need arises to fix the havoc an abusive player causes. There is also the possibility of a player acting as game master in a more controlled game. Here you could ask moblet, he has a rather interesting set of rules and moderated game on one of Timothy's servers. (I've never joined it, but, as an example there are public motorways)
The public player sometimes needs to remove infrastructure of a player, who abandoned the game, but has a company still running.
It might also be necessary to make larger changes to level the playing field for players who joined later. Eg, if there is a narrow isthmus between two continents, but the area is completely used by old players, widening the isthmus may be such an operation. Building a public way another, or even replacing player owned infrastructure with public infrastructure. Same for making larger cities more accessible for competitors.
It is not so much a question here if you would do it yourself, but that a game-master/admin could do it (can't be sued for it after all :-)
Imaginable would be a setting similar to the scenarios Severous builds.
In the course of a single player game, i use the public player also frequently. For all sorts of operations. This is sometimes building and linking of factories (to make a game more interesting). Beautifying cities, or improving their growth. In early game overcomming obstacles i consider unfair, but to expensive to fix as player. (eg. having dug too deeply, by accident; using workarounds for things that can't be achieved easily in-game, but would not be excruciatingly expensive in real life.)
Quite often i use public player to straighten out diagonal roads close to cities (they don't grow well with those) and fix silly inter-city roads.
also frequent is fixing river sections i accidentally deleted.
(should this and my previous post perhaps be cut-off and put in a different thread, i'm really far off-topic now)
Hello James
Quote from: jamespetts on January 28, 2012, 05:57:35 PM
Ahh - it is indeed possible that I have reduced it twice by mistake. Try the latest commit and see whether that seems correct.
The ship, completely full, has an income per km (estimated) of 8.3 € / km. In my opinion a good parity between costs and revenues can be found with filling equal to 75%, so at a cost of about 6.2 € / km (the last commit cost is 4.1 € / km).
Giuseppe
Quote from: AP on January 28, 2012, 10:38:39 AM
What is needed is a mechanism to cause successful players with runaway bank balances to have to spend more than unsuccessful players with low bank balances. I suggested in another thread that costs of making changes to infrastructure might be proportional to the number of convoys using the tile each month, for instance - that's just one idea (and not an unrealistic one).
You could have the government institute a graduated tax rate: the higher your profits the more money the government wants to skim off the top, whereas if you are losing money, there's nothing to tax, and the government may decide it is in the public interest to grant low-interest loans or an outright subsidy in the interests of economic development.
If you really wanted to go down this road, a smart government would try to tie incentives with deliverables, or as we call them in video games, scenarios. "The government will grant you $300k grant in order to build a network connecting 12 cities. If you have not completed this obligation in three years time, you'll owe the money back plus hefty interest. Do you accept?"
I also note a tension between the public player acting as a would-be government and the public player being a would-be God mode. I'd say make it configurable, and then down the road make the existing public player "God mode" and make a "government player" that can do stuff based on taxes. In a multi-player game, the government player could possibly be elected at regular intervals, maybe favoring a player who has gone out of business: the government then has to balance tax policies with delivering infrastructure needs in a fair manner in order to get re-elected. This political aspect would encourage players to cooperate nicely with each other, though in some games you'd have a tit-for-tat bloodbath.
My existing practice is the public player is used for infrastructure projects within or between cities that might typically be undertaken by the government, and, for example, to clean up after in-game bugs. :)
-d
- LBSCR A1 terrier, maintenance too cheap when compared to GWR 517
- Midland 700, maintenance too expensive when compared to LNWR 17in
- LNWR Precedent, maintenance too expensive when compared to Midland 156 and GNR Stirling Single
Narrow gauge ways should cost significantly less to build (a little more than half), and slightly less to maintain, than regular gauge track. For the 100km/h narrow track, I imagine a cost of 100.00 (150.00 now) and a maintenance of 10.00 (comparable standard track maintenance 14.40). Am really hoping the narrow gauge bridge makes it into the next release.
Quote from: wlindley on February 03, 2012, 11:35:52 PM
Narrow gauge ways should cost significantly less to build (a little more than half), and slightly less to maintain, than regular gauge track.
May I ask - what is the basis of these figures?
Just a quick note: If the idea of having a 'government' player takes off, I would recommend splitting 'public service' into "Server Administrator" and the Government player.
And this sounds really interesting to me.
I frankly get more fun out of building freeways than I do playing the game. On my list of things I want to do is to run a server where I build freeways and public rail and such... :)
If you like building roads, have a look at this (http://forum.simutrans.com/index.php?topic=8172.0) thread under the title, "traffic simulation". Not currently a high priority, but I'd love to do it one day...
- Freight should possibly pay out 2 to 3x what it currently does.
- Minimum maintenance for locomotives should probably be 100kW/$1 (300kW=$3) or some form of power/weight ratio. (300kW/40t)/2=$3.75. Obviously, for faster locomotives, there should be modifiers that make it cost more maintenance, but for the weaker and slower ones, I think this should be fairly good as the baseline.
AEO,
interestingly, I am in the process of planning something similar, although not quite the same thing. I am in the process of implementing and testing my "fare stages" module (on an eponymous Github branch) which allows a different per kilometre fare to be implemented depending on the distance (usually, reducing the per kilometre fare the longer that the goods/passengers have travelled). Using historical figures for passengers and freight, I have found that the freight costs are far too low compared to the passenger costs. My current testing goods128.pak file for the branch looks like this:
#-------------------------------------------------------------------------------
#
# Dat file for simutrans goods types
# created by: Hj. Malthaner
# 16-Nov-02
# updated:
# 22-Feb-2003 (T. Kubes)
# 09-Sep-2003 Added food chain good (T. K.)
# 17-Nov-2003 Added beer, milk, table of units
# 19-Nov-2003 Adjusted prices and added bonuses
#
--------------------------------------------------------------------------------
#
# categories:
# 0 = type defined (unique)
# 1 = piece good (i.e. crates of XY)
# 2 = bulk good (i.e. ore, sand, coal)
# 3 = oil type fluid
# 4 = piece good refrigerated (i.e. cooled crates of XY)
# 5 = liquid food
# 6 = long goods (planks, steel (any flat-bed))
# 7 = fabric (or any lightweight packed goods - crates, sacks)
#
# units:
# = none (no units displayed)
# sack = bags
# tonnen = t
# paletten = crates
# m3 = m^3
#
#-------------------------------------------------------------------------------
#
# See W. M. Ackworth, "The Elements of Railway Economics" p. 107 for historical records
# of relative charges for passengers and different types of goods on the Liverpool &
# Manchester Railway and previous pages for similar rates for canals (freight only).
#
# Generally speaking, per ton per mile:
# Low value bulk: 1d
# Medium value bulk (incl. coal) 1 1/2d
# High value bulk (incl. clay) 2d
# Perishables and semi-manufactured (incl. flour, timber and finished metals) 2 1/2d
# Manufactured goods: 3d
# Passengers (per passenger): -
# 1.8d (first 10 miles)
# 1.5d (next 20 miles)
# 1.4d (thereafter)
#
# Cattle (per head)
# 2d (first 15 miles)
# 1.4d (thereafter)
# Note that the LMR was only 35 miles long.
#
# See ibid pp. 111 and onwards for the later RCH classification system, as follows:
# A: Coal, coke, irone ore, furnace slag
# B: Clay, sand, manure, limestone, chalk, salt, unfinished stone, zinc ore, copper ore, bricks, paving stones, pig iron
# C: Hay, straw, grain, flour, seeds, fertiliser, chemicals, lead ore, part-finished iron goods
# I: Iron/steel hoops, pipes, sheets, plates, common fruit and vegetables, paper, cotton, beer in casks, oil in caks, tin ore
# II: Beer in bottles, wine in casks, bacon, biscuits, brass, china in casks or crates, coconut matting, nickel ore
# III: Cotton and linen goods, cured bacon, blankets, books, boots in casks, cases or boxes, china in hampers, woollen cloth, tea, silver ore
# IV: Pineapples, fresh cured meats, china in boxes or cases, woollen cloth in boxes, cases parcels or hampers.
# V: Amber, dyes, peaches and apricots, bonnet boxes, basketwork, bismouth, clocks, hats, artificial flowers, silk
#
# 1844 Act - 1d/mile for "parliamentary" vehicles for passengers.
#
# Ackworth, p. 145 has a table of maximum charges for each class for the GER, which was similar to that for other railway companies.
# This dates from around the 1890s as far as can be ascertained. (See for example:
# http://digital.slv.vic.gov.au/view/action/nmets.do?DOCCHOICE=771636.xml&dvs=1327967822965~470&locale=en_GB&search_terms=&adjacency=&usePid1=true&usePid2=true )
#
# Figures are all per ton per mile
#
# Class First 20 miles Next 30 miles Next 50 miles Remainder
# A 1.15d 0.90d 0.45d 0.40d
# B 1.40d 1.05d 0.80d 0.55d
# C 1.80d 1.50d 1.20d 0.70d
# I 2.20d 1.85d 1.40d 1.00d
# II 2.65d 2.30d 1.80d 1.50d
# III 3.10d 2.65d 2.00d 1.80d
# IV 3.60d 3.15d 2.50d 2.20d
# V 4.30d 3.70d 3.25d 2.50d
#
# Note that, for the time being, the original values are retained for backwards compatibility. They are over-written by the new system
# on the fare-stages branch.
### UNIQUE GOODS TYPES ###
# Passengers
# Class: passengers
obj=good
name=Passagiere
mapcolor=79
metric=
catg=0
#
#value=42
value=50
#
value[0]=60
to_distance[0]=16
value[1]=50
to_distance[1]=32
value[2]=47
to_distance[2]=0
speed_bonus=18
weight_per_unit=70
-----------------------
# Mail
# Class: mail
obj=good
name=Post
metric= bags
catg=0
#
#value=48
value=57
#
value[0]=69
to_distance[0]=16
value[1]=57
to_distance[1]=32
value[2]=54
to_distance[2]=0
speed_bonus=15
weight_per_unit=50
-----------------------
# Livestock
# Class: Livestock trated as class of own.
obj=good
name=livestock
metric=head
catg=0
#
#value=35
value=56
#
value[0]=67
to_distance[0]=16
value[1]=56
to_distance[1]=32
value[2]=52
to_distance[2]=0
speed_bonus=18
speed_bonus=2
weight_per_unit=120
------------------------------------------
# None
obj=good
name=None
metric=
catg=0
value=0
weight_per_unit=1
-----------------------
# Cars
# Class: not given, but treat as IV
obj=good
name=Autos
metric=cars
catg=0
#
#value=225
value=284
#
value[0]=324
to_distance[0]=32
value[1]=284
to_distance[1]=48
value[2]=225
to_distance[2]=80
value[3]=198
to_distance[3]=0
speed_bonus=15
weight_per_unit=1800
-----------------------
# Fish
# Class: not given, but treat as III
obj=good
name=FreshFish
metric=paletten
catg=0
#
value=133
#
value[0]=155
to_distance[0]=32
value[1]=133
to_distance[1]=48
value[2]=100
to_distance[2]=80
value[3]=90
to_distance[3]=0
speed_bonus=15
weight_per_unit=1000
metric=tonnen
-----------------------
### BULK GOODS ###
# Coal
# Class: A
obj=good
name=Kohle
metric=tonnen
catg=2
#
#value=35
value=45
#
value[0]=58
to_distance[0]=32
value[1]=45
to_distance[1]=48
value[2]=23
to_distance[2]=80
value[3]=20
to_distance[3]=240
value[4]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Iron Ore
# Class: A
obj=good
name=Eisenerz
metric=tonnen
catg=2
#
#value=35
value=45
#
value[0]=58
to_distance[0]=32
value[1]=45
to_distance[1]=48
value[2]=23
to_distance[2]=80
value[3]=20
to_distance[3]=240
value[4]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Wood Chip
# Class: not given, but treat as B
obj=good
name=woodchip
metric=tonnen
catg=2
#
#value=35
value=53
#
value[0]=70
to_distance[0]=32
value[1]=53
to_distance[1]=48
value[2]=40
to_distance[2]=80
value[3]=28
to_distance[3]=240
value[4]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Stone
# Class: B
obj=good
name=Stone
metric=tonnen
catg=2
#
#value=35
value=53
#
value[0]=70
to_distance[0]=32
value[1]=53
to_distance[1]=48
value[2]=40
to_distance[2]=80
value[3]=28
to_distance[3]=240
value[4]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Clay
# Class: B
obj=good
name=clay
metric=tonnen
catg=2
#
#value=35
value=53
#
value[0]=70
to_distance[0]=32
value[1]=53
to_distance[1]=48
value[2]=40
to_distance[2]=80
value[3]=28
to_distance[3]=240
value[4]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Cement
# Not given, but treat as C
obj=good
name=Cement
metric=tonnen
catg=2
#
#value=35
value=75
#
value[0]=90
to_distance[0]=32
value[1]=75
to_distance[1]=48
value[2]=60
to_distance[2]=80
value[3]=35
to_distance[3]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
obj=good
# Class: C
name=grain
metric=tonnen
catg=2
#
#value=35
value=75
#
value[0]=90
to_distance[0]=32
value[1]=75
to_distance[1]=48
value[2]=60
to_distance[2]=80
value[3]=35
to_distance[3]=0
speed_bonus=1
weight_per_unit=1000
-----------------------
### PIECE GOODS ###
# Subcategory - High Speedbonus
# Books
# Class: III
obj=good
name=Bucher
metric=paletten
catg=1
#
#value=51
value=133
#
value[0]=155
to_distance[0]=32
value[1]=133
to_distance[1]=48
value[2]=100
to_distance[2]=80
value[3]=90
to_distance[3]=0
speed_bonus=10
weight_per_unit=810
-----------------------
# Fruit
# Class: I
obj=good
name=fruit
metric=paletten
catg=1
#
#value=51
value=68
#
value[0]=80
to_distance[0]=32
value[1]=68
to_distance[1]=48
value[2]=51
to_distance[2]=80
value[3]=37
to_distance[3]=0
speed_bonus=10
weight_per_unit=730
-----------------------
# Vegetables
# Class: I
obj=good
name=vegetables
metric=paletten
catg=1
#
#value=51
value=65
#
value[0]=77
to_distance[0]=32
value[1]=65
to_distance[1]=48
value[2]=49
to_distance[2]=80
value[3]=35
to_distance[3]=0
speed_bonus=15
weight_per_unit=700
-----------------------
# Newspaper
# Class: not given, but treat as III
obj=good
name=newspaper
metric=paletten
catg=1
#
#value=51
value=105
#
value[0]=122
to_distance[0]=32
value[1]=105
to_distance[1]=48
value[2]=79
to_distance[2]=80
value[3]=71
to_distance[3]=0
speed_bonus=10
weight_per_unit=790
------------------------------------------
# Subcategory - Low Speedbonus
# Hardware
# Class: I
obj=good
name=hardware
metric=paletten
catg=1
#
#value=35
value=69
#
value[0]=83
to_distance[0]=32
value[1]=69
to_distance[1]=48
value[2]=53
to_distance[2]=80
value[3]=38
to_distance[3]=0
speed_bonus=3
weight_per_unit=750
-----------------------
# Furniture
# Class: not given, but treat as III
obj=good
name=Moebel
metric=paletten
catg=1
#
#value=50
value=53
#
value[0]=62
to_distance[0]=32
value[1]=53
to_distance[1]=48
value[2]=40
to_distance[2]=80
value[3]=36
to_distance[3]=0
speed_bonus=3
weight_per_unit=400
-----------------------
# Textiles
# Class: III
obj=good
name=textile
metric=paletten
catg=1
#
#value=35
value=57
#
value[0]=67
to_distance[0]=32
value[1]=57
to_distance[1]=48
value[2]=43
to_distance[2]=80
value[3]=39
to_distance[3]=0
speed_bonus=3
weight_per_unit=430
-----------------------
# Flour
# Class: C
obj=good
name=flour
metric=paletten
catg=1
#
#value=35
value=63
#
value[0]=76
to_distance[0]=32
value[1]=63
to_distance[1]=48
value[2]=
to_distance[2]=80
value[3]=
to_distance[3]=0
speed_bonus=3
weight_per_unit=840
-----------------------
# Beer
# Class: I
obj=good
name=beer
metric=barrels
catg=1
#
#value=35
value=74
#
value[0]=88
to_distance[0]=32
value[1]=74
to_distance[1]=48
value[2]=56
to_distance[2]=80
value[3]=40
to_distance[3]=0
speed_bonus=3
weight_per_unit=800
-----------------------
# Cider
# Class: not given, but treat as I
obj=good
name=cider
metric=barrels
catg=1
#
#value=35
value=73
#
value[0]=86
to_distance[0]=32
value[1]=73
to_distance[1]=48
value[2]=55
to_distance[2]=80
value[3]=39
to_distance[3]=0
speed_bonus=3
weight_per_unit=780
-----------------------
# Pharmaceuticals
# Class: not given, but treat as IV
obj=good
name=pharmaceuticals
metric=paletten
catg=1
#
#value=35
value=91
#
value[0]=104
to_distance[0]=32
value[1]=91
to_distance[1]=48
value[2]=73
to_distance[2]=80
value[3]=64
to_distance[3]=0
speed_bonus=3
weight_per_unit=580
-----------------------
# Plastic
# Class: not given, but treat as C
obj=good
name=Plastik
metric=paletten
catg=1
#
#value=35
value=38
#
value[0]=45
to_distance[0]=32
value[1]=38
to_distance[1]=48
value[2]=30
to_distance[2]=80
value[3]=18
to_distance[3]=0
speed_bonus=3
weight_per_unit=500
-----------------------
# Paper
# Class: I
obj=good
name=Papier
metric=paletten
catg=1
#
#value=35
value=74
#
value[0]=88
to_distance[0]=32
value[1]=74
to_distance[1]=48
value[2]=56
to_distance[2]=80
value[3]=40
to_distance[3]=0
speed_bonus=3
weight_per_unit=800
-----------------------
# Wool
# Class: not given, but treat as C
obj=good
name=wool
metric=sack
catg=1
#
#value=35
value=29
#
value[0]=34
to_distance[0]=32
value[1]=29
to_distance[1]=48
value[2]=23
to_distance[2]=80
value[3]=13
to_distance[3]=0
speed_bonus=3
weight_per_unit=380
-------------------------
# China
# Class: II
obj=good
name=china
metric=paletten
catg=1
#
#value=35
value=52
#
value[0]=60
to_distance[0]=32
value[1]=52
to_distance[1]=48
value[2]=41
to_distance[2]=80
value[3]=34
to_distance[3]=0
speed_bonus=3
weight_per_unit=450
------------------------------------------
# Bricks
# Class: B
obj=good
name=bricks
metric=paletten
catg=1
#
#value=35
value=43
#
value[0]=57
to_distance[0]=32
value[1]=43
to_distance[1]=48
value[2]=33
to_distance[2]=80
value[3]=23
to_distance[3]=0
speed_bonus=3
weight_per_unit=820
---------------------------------------
# Canned Food
Class: not given, but treat as IV
obj=good
name=canned_food
metric=paletten
catg=1
#
#value=35
value=129
#
value[0]=148
to_distance[0]=32
value[1]=129
to_distance[1]=48
value[2]=103
to_distance[2]=80
value[3]=90
to_distance[3]=0
speed_bonus=3
weight_per_unit=820
---------------------------------------
### LONG GOODS ###
# Steel
# Class C
obj=good
name=Stahl
metric=tonnen
catg=6
#
#value=35
value=75
#
value[0]=90
to_distance[0]=32
value[1]=75
to_distance[1]=48
value[2]=60
to_distance[2]=80
value[3]=35
to_distance[3]=0
speed_bonus=2
weight_per_unit=1000
-----------------------
# Planks
# Class: not given, but treat as I
obj=good
name=Bretter
metric=tonnen
catg=6
#
#value=35
value=93
#
value[0]=110
to_distance[0]=32
value[1]=93
to_distance[1]=48
value[2]=70
to_distance[2]=80
value[3]=50
to_distance[3]=0
speed_bonus=2
weight_per_unit=1000
-----------------------
### BULK LIQUIDS ###
#Crude Oil
# Class: I
obj=good
name=Oel
metric=m3
catg=3
#
#value=35
value=83
#
value[0]=99
to_distance[0]=32
value[1]=83
to_distance[1]=48
value[2]=63
to_distance[2]=80
value[3]=45
to_distance[3]=0
speed_bonus=0
weight_per_unit=900
-----------------------
# Petrol
# Class: I
obj=good
name=Gasoline
metric=m3
catg=3
#
#value=35
value=70
#
value[0]=83
to_distance[0]=32
value[1]=70
to_distance[1]=48
value[2]=53
to_distance[2]=80
value[3]=38
to_distance[3]=0
speed_bonus=0
weight_per_unit=750
-----------------------
# Fuel Oil
# Class: I
obj=good
name=FuelOil
metric=m3
catg=3
#
#value=35
value=93
#
value[0]=110
to_distance[0]=32
value[1]=93
to_distance[1]=48
value[2]=70
to_distance[2]=80
value[3]=50
to_distance[3]=0
speed_bonus=0
weight_per_unit=1000
-----------------------
# Chemicals
# Class: C
obj=good
name=Chemicals
metric=m3
catg=3
#
#value=35
value=66
#
value[0]=77
to_distance[0]=32
value[1]=66
to_distance[1]=48
value[2]=53
to_distance[2]=80
value[3]=31
to_distance[3]=0
speed_bonus=0
weight_per_unit=860
-----------------------
### COOLED GOODS ###
# Meat
# Class: II
obj=good
name=meat
metric=paletten
catg=4
#
#value=69
value=47
#
value[0]=54
to_distance[0]=32
value[1]=47
to_distance[1]=48
value[2]=37
to_distance[2]=80
value[3]=31
to_distance[3]=0
speed_bonus=15
weight_per_unit=410
-----------------------
# Fish
# Class: not given, but treat as II
obj=good
name=fish
metric=paletten
catg=4
#
#value=69
value=47
#
value[0]=54
to_distance[0]=32
value[1]=47
to_distance[1]=48
value[2]=37
to_distance[2]=80
value[3]=31
to_distance[3]=0
speed_bonus=15
speed_bonus=15
weight_per_unit=410
-----------------------
# Milk
# Class: not given, but treat as I
obj=good
name=milk
metric=paletten
catg=4
#
#value=69
value=89
#
value[0]=106
to_distance[0]=32
value[1]=89
to_distance[1]=48
value[2]=67
to_distance[2]=80
value[3]=48
to_distance[3]=0
speed_bonus=15
weight_per_unit=960
-----------------------
#===============================================================================
#
# EOF - goods-128.dat
#
#===============================================================================
I have not got this to work quite yet, as there has been a bug in the makeobj that goes with this, but it will be interesting to see this in practice.
As to the running costs of steam locomotives, it seems that these should indeed be based on the power: see this (http://forum.simutrans.com/index.php?topic=6521.msg63787#msg63787), this (http://forum.simutrans.com/index.php?topic=6521.msg63652#msg63652) and this (http://forum.simutrans.com/index.php?topic=6521.msg85675#msg85675).
Earlier locomotives will, of course, be less efficient, especially before the advent of superheating and the use of coal instead of coke. I shall at some point have to produce a spreadsheet or other similar means of creating a formula to give the ratios of power to cost (taking into account fuel and repair costs, and the proportion of each) to get a sensible amount of balancing; but that task might well take some time.
The chief reason narrow gauge railways were built was their low cost; the inconveniences of having to transfer freight would otherwise have been too great a disincentive. Here is just one quote:
"The Toledo, Delphos, and Indianapolis narrow gauge (three feet width) was estimated to cost $8,000 per mile, built and equipped, versus a standard gauge, (four feet, eight and one half inches width) at least three times that amount." (source (http://www.delphos-ohio.com/Holdgreve/narrowgauge_railroad.htm))
I'm sure we could find some additional info...
Aha, excellent! Thank you. I knew that narrow gauge was built for its low cost: the question is exactly how much lower that the cost should be. One complication is that the narrow gauge in Pak128.Britain-Ex is actually based on Welsh practice, where most of the narrow gauge is about 2ft width, rather than the 3ft width used in the railway that you quoted (and also in the Isle of Man), so perhaps the cost should be lower still (1/3.5 of standard gauge, at a guess?).
the cost reduction of narrow gauge mostly come from reduced earthworks?
Quotethe cost reduction of narrow gauge mostly come from reduced earthworks?
That's my understanding, so yes one would expect 2' NG to cost less than 3' NG. Tighter corners mean it can more easily follow difficult terrain, so fewer bridges, tunnels, and excavations, but since in Simutrans NG track takes up 1 tile, same as SG track, that advantage of space is lost, and can only be represented in terms of reduced capital expense.
I suspect operating costs must also be lower - look at how the early preservation movements had a much easier time with NG than SG lines. Possibly cost per ton of cargo moved at a given speed may be higher than SG(?), but clearly an NG freight train moves much less than a SG one.
- Aside - is there any way to code a train which costs less to run downhill than uphill? Am thinking ffestiniog gravity slate trains - operation cost £0 in the downhill direction!
Yes, reduced earthworks as well as needing sleepers ("ties" to us Yanks) that are only half as long. Narrow gauge was often laid with rather lightweight rail as well.
In terms of gameplay, I suggest two levels of n.g. in comparison to standard:
- 1870s Standard Gauge WSSR(light) is 75km/h, 62tonnes, cost 160.00c, maint 14.40c.
- 1870s Narrow Gauge (light): suggest 40km/h, 30tonnes, cost 65.00c, maint 10.00c.
- 1870s Narrow Gauge (heavy): suggest 75km/h, 62tonnes, cost 100c, maint 12.00c.
The reasoning is to have a cheap light n.g. a little below the rated speed of the Fairlie loco and only just capable of its weight; the heavy n.g. at a comparable speed and capacity to standard but at a mildly lower price. If someone would care to draw early n.g. goods carriages, or perhaps a late diesel loco, we can pick similar values for those periods.
AP: Hmm, Now you have me thinking about cable-drawn railways...
Quote from: wlindley on February 04, 2012, 05:53:12 PM
AP: Hmm, Now you have me thinking about cable-drawn railways...
I would love an incline-plane in-game, both for freight (e.g. Portreath Harbour incline) or passengers (e.g. Lynton-Lynmouth cliff railway, which is powered by water), hilly maps are fun to play but the changes in levels are a real pain. Something like the San-Francisco cable-railway for passengers would be great too, being completely indifferent to gradients.
:-D
Hmm - the balancing of way costs more generally needs to be considered before we can set specific prices for narrow gauge. And what about track from the 1850s?
100km/h narrow gauge track would be quite the over-technology in 1850, IMO.
the 1067mm cape gauge has trouble getting over 130km/h for passenger trains without tilting and very high quality track..
What were the speeds/timelines for foreign narrow gauge? UK terrain didn't always call for the most interesting solutions, but some mapsettings might. Obviously British engineers were involved in building railways around the globe, so if (say) they were building faster narrow gauge in India, Norway, or South America than in the UK, because of a quirk of history or geography, suggest we shouldn't unduly restrict the options our players have, since they may choose a different approach for their company.
There was narrow gauge in the UK in the 1850s, albeit perhaps rather more speed limited - 70km/h?
I have to add, however, that narrow gauge is not currently a priority.
the costs for leveling terrain on a slope (perpendiular to the gradient) does increase faster than linearly with the width of the leveled area. You have to dig deeper on the mountain side and embark higher on the valley side, the wider it gets.
Further notes:
- Undersea tunnels need to cost much more than under-land tunnels - any suggestions as to by how much?
- Tunnels generally are probably too cheap
- Underground stations really do need to be restricted as planned
- We need if possible to encourage the building of city buildings near stations: see here (http://forum.simutrans.com/index.php?topic=9176.new#new) for discussion
- Railway station platforms need to have a much lower passenger capacity (and probably concomitantly lower cost) to encourage the realistic use of extension buildings
- To go with the above, there need to be some new, smaller extension buildings (wooden ones, perhaps)
- Elevated ways need to cost the same as bridges of the equivalent type (which now makes sense, since both types can be built only over shallow water)
Quote from: jamespetts on February 05, 2012, 02:08:03 PMUndersea tunnels need to cost much more than under-land tunnels - any suggestions as to by how much?
The original Severn tunnel might be the precedent to look at.
Canal wharfs/harbours need to handle mail - currently either freight-only or passenger only. In either case, leaving a mailsack for the boat to collect should not require extra facilities. Passenger Dock (ocean type) already handles mail.
Re elevated ways - I mentioned it elsewhere also, but to enable taller curved viaducts, a "pier only" stackable elevated way would be advantageous - and indeed already exists in pak.japan I understand.
Hmm - the latter suggestion seems to me equally apt for Standard - might I suggest that you post a note in the Standard board repeating the request? I shall look into the cost of the original Severn Tunnel - good thought on that.
what you could do about tunnels, is divide the existing ones into light/hvy usage as well as give them differing costs, like what the bridges have currently.
- Need one way signal, as opposed to signals set to one direction only, because regular signals allow junctions to be blocked.
I'm not sure that I follow about tunnels - the actual cost of building the tunnel does not have much to do with the weight of vehicles that can traverse it - that is very different in principle to a bridge, in which the quality of the engineering is related to the weight that it can bear.
As to the signal issue, can you elaborate? I am not sure that I follow.
I think there might be a case for Narrow Gauge tunnels to be significantly cheaper than Standard Gauge ones - less material to excavate. In many real-life cases, the associations with slate mines etc also meant the tunnelling expertise was on-hand. The speed limits and capacity limits on NG would prevent the cheap tunnels being abused.
I have split the section about one-way markers into this (http://forum.simutrans.com/index.php?topic=9179) topic in order to focus here on balancing
AP - there may well be something to be said for that indeed. The capacity and speed limits inherent to narrow gauge (not to mention the incompatibility with standard gauge) would be as effective in Simutrans as in reality at disincentivising their use.
Do you have any idea as to how much cheaper that they should be?
I suspect it crudely correlates with the amount of material needing excavation (ie how many navvies for how long). If we assume a rectangular tunnel:
Ffestiniog loading gauge
height: 1715mm width 2082mm = 3.57cubic metres of spoil per metre of tunnel
UK Standard loading gauge
height: 3911mm width 2743mm = 10.73 cubic metres of spoil per meter of tunnel
ie NG tunnels should cost 1/3 of SG ones. (dimensions from interweb, slight variation possible)
Hmm - I suspect that it doesn't scale linearly, though, does it, as there are lots of costs (surveying, setting up systems for removing spoil, accommodating workers, bringing in materials, laying the tracks inside the tunnels, etc.) that will not vary in this way. It would be better to have real world examples if possible (even if not British). It rather reminds me of the old joke about how long it would take somebody to dig half a hole...
the most important factor for costs we can't include, geologic composition of the underground. There's quite a difference if you can build in granite or chalk or even sediments. Depth below daylight is also quite important. However here we can have at most about 100 m on the map, that's not a range where it really should come to bear (due to plasticity of the mountain).
Transfering to the game, it should be much more expensive to build a tunnel in flat land, where soft materials sedimented than in mountains. the steeper the mountains the cheaper tunnels should be. The slate mentioned by AP is especially difficult, WP says a 0.4 m width tunnel would hold 2 minutes before caving in (only things like shale are worse) This makes it extremely tedious to build, the excavating goes fast, but you can go forward only a few cm, have to stabilize then excavate the enclosed by the stabilization. You also need shields to hold the tunnel front back from just bursting into the cavity. Modern tunnel drilling machines get allong with this, but are slow in soft rock. In hard rock only a layer of chotcrete is needed
The load gauge of a tunnel does not just increase the volume of material to be removed, but it also requires the internal stabilization of the tunnel to be more difficult to do. (the german word is Verbau, couldn't find a translation)
There should be two massive cost drops in tunnel building, introduction of dynamite (uk patent 7 may 1867) and more recent prefabricated tubbings (about 100 years ago) and automated drill machines (mid 1960s)
I have split the continuation of the tunnel discussion to a separate thread (here (http://forum.simutrans.com/index.php?topic=9185.msg85834#msg85834)) to allow this thread to continue to focus on general balancing notes.
I am getting the impression that time is passing too fast in the game, such that I might need to increase the bits_per_month settings for future games - we are now in 1894, which means that time is passing at the rate of something approaching a decade a day, which seems to me too fast for people who are not able to play for many hours each day to make full use of the technology of any one era.
As we know, increasing the "bits_per_month" setting by 1 doubles the amount of real time that it takes an in-game year to pass. I am thinking of increasing it by either 1 or 2 for the next release - any thoughts?
- LBSCR bogie compartment and non-corridor lavatory are unattractive to use when they become available. They are slightly lighter, but pale when comparing maintenance and comfort to the clerestory sets. Generally, the clerestory sets have enough capacity for local lines too, so the higher capacity of the LBSCR sets are not as useful.
- GWR clerestory brake missing overcrowded capacity.
- DC overhead centenary available before electric depot or any electric trains (not trams) in general.
In general, I think we are lacking some good competitive main lines for the better LBSCR carriages to be used to their full effect.
The express lines are having quite a nice speed match.
LBSCR non-corridor lavatory
min_loading_time=20
max_loading_time=50
choc-cream-clerestory
min_loading_time=20
max_loading_time=50
perhaps having distinctively different load times for both sets? those clerestory have doors for each set of opposing benches? Thus loading works in parallel. However the (well paying) long distance pax will likely not be rushed as much when alighting as urban commuters would.
first class with more comfort but more importantly without overcrowd capacity would also be interesting for the clerestory carriages
a bit early, but GER S46 Claud Hamilton tender is only 4t
GWR bulldog, LNWR Precursor, GER S46, GNR C1, Midland 1000 and GWR 2900 saint should be better balanced against each other. Currently, GER S46 is outstandingly good, while the midland 1000 and GNR C1 are fairly close and the GWRs don't even come close.
- midland 1632 and 2441, are presumably the same engine, different batch, but they are both available at the same time, starting from 1908.
as for the game speed, I don't think it is too bad right now, but I wouldn't mind trying longer.
AEO,
thank you for those notes - very helpful. The 1632/2441 thing is intended - the 2441 is the push/pull version. I shall make this clearer in the next release.
I have also noticed that the Metropolitan E-class, LBSCR E4 and LNWR M7 do not appear to be well balanced against each other, with the M7 being obviously best for nearly everything of the three, despite all being closely contemporaneous.
As to the carriages, they are under general review in any event.
I see the GWR 517 has an upgrade for the autocoach in 1905, but the 517 itself is not available for purchase in 1905. It is a bit hard to have some foresight to store or keep using the GWR 517 for this purpose when it was available between 1865-1885.
perhaps some sort of marker, like (upgradeable) could be added?
on a related note, it doesn't seem possible to upgrade the LBSCR A1 to A1X.
AEO,
thank you for the notes. The dates are based on the actual lives of these locomotives; the idea is that players really would have older locomotives like that in use for economic reasons. The priority there is making the economy such as would incentivise such behaviour.
There should, however, be contemporaneous push-pull vehicles that can be built from new - the next pakset should involve an LBSCR push-pull carriage. As to the GWR - there are later locomotives that can operate the auto trailers that can be built new.
Thank you for the A1 A1X bug report - that should be fixed for the next version.
Midland 1000 tender goes out of production before the locomotive (and therefore you cannot use the replacer with it after this has happened).
I think it might be worth looking at axle load again.
LBSCR I3, hard to use. Overall, it's decent, but you have to pay for track upgrades, because it's just over the 69t limit. If one were to upgrade to heavy track, it would just be better to use GWR 3150, because it's better in every way.
same problem with LNWR Precursor Tank.
The Claud Hamilton seems too favourable compared to other locomotives of the time.
for the Claud Hamilton, GNR C69 and midland 1000, I think they can all be around $20.00/km in maintenance and still be profitable.
If the GNR stirling single is any indication of profitability.
6-PAN rear motor car has the wrong power.
even if the number was correct, it's very awkward to use. It's main problem is sluggishness, but putting that aside, it's just not very good when you can use SR V class on the same set of tracks.
8 car set of 4-LAV is much better in just about every aspect. It fits in 6 tile stations (6-PAN takes up 5), has more power, has better acceleration and more capacity.
there's no pantry car with the 4-LAV, but the 6-PAN is not good for long haul anyways.
There needs to be another road mail van, other than the austin 7. Either that or it should be able to hold more.
more bugs
SR bulleid corridor set, catering missing from dining car
LMS open set, also missing catering from dining car
balance
SR V class, LMS 5XP, maintenance too cheap compared to power and speed. They are so good, in fact, that you sort of have to wonder why you would use GWR King and LMS 7P
GWR King at somewhat of a disadvantage compared to LMS 7P. Same tractive effort, but more power in 7P while you still have to pay for the 150t tracks for both.
AEO,
thank you for your report. I have now corrected the 6-PAN rear motor unit's power. When things are balanced properly, it should be more economical to run by a good margin than any steam train. As to the 4-Lav, don't forget that it has lower comfort.
Can you elaborate in respect of the mail van - why does there need to be another one?
I fixed the missing catering levels, and made interim adjustments to the running costs of the SR Schools class and the LMS Black 5, but a full rebalance will be necessary before these values are properly in line.
the capacity of the austin 7 mail van is inadequate for the amount of mail generated.
it is the same problem encountered with early steam train to horse carriage transfers.
it is not as pronounced, but still leaves a bit to be desired.
the morris 8 that comes after becomes the mainstay, but it can barely keep up with the demand.
Hmm - the problem might be that the demand is too high, not that the capacity is too low. I am planning on reducing the passenger factor for the next version, so it might be that the van then becomes adequate.
LMS mail carriages are slightly shorter than the LNER, SR and GWR carriages, yet have the same capacity. This gives them a slightly unfair capacity advantage
also 4-wheel and 6-wheel brake mail carriages have an overcrowded capacity, which probably shouldn't be there.
Morris eight van and Morris Minor van could possibly use a touch more traction. like 1 or 2kN more each.
BR Mk.1 coaches have inconsistent speeds between set.
- Mk.1 restaurant buffet, 175km/h
- Mk.1 TPO, 175km/h
- rest, 160km/h
BR Mk.1 and Mk.2 coaches are really confusing to use. possibly because their next/previous is not set correctly.
for example:
Mk.1 mail gangwayed brake cannot be last. - therefore you cannot make a mail only convoy out of Mk.1 coaches.
Mk.1 GUV allows anything else after, not just mk.1/2 coaches
Mk.2 must end with brake coach, but not start with it. - aren't there different batches of these? some that work with Mk.1 and some that don't?
Mk.2D, two different versions exist with the same name
AEO,
thank you for your feedback. May I ask you to elaborate on the last point - what do you mean by confusing to use?
@james
with the mk.1/2 coaches, the way you can assemble them is just bizarre, to say the least. With timeline on, it's not too bad, but try assembling them with timeline off (or if you have a lot of rolling stock left over in the depot) and it becomes very difficult to try and assemble two convoys that with the exact same sequence of cars. This is because the next coach possible selection moves around so much and because you can only add some cars after some other cars which also relies on some other car being there first.
Can you be more specific about this part:
Quote
This is because the next coach possible selection moves around so much and because you can only add some cars after some other cars which also relies on some other car being there first.
I should also note that this pakset is intended to be played with the timeline on; however, it is also intended that Experimental have the ability to buy/sell second-hand vehicles, so this needs some consideration.
okay, well, if you start off with...
- mk.2d buffet. There is a nice selection to choose from.
then you select...
- mk.2 standard open. Now where did the carriages go?
then you select
- mk.2 tourist open. Oh, there they are again.
next
- mk.1 brake open. I can still see the other mk.1/2 carriages, but wait, why did the mk.1 restaurant buffet disappear and in its place I now have mk.1 gangwayed corridor brake?
next
- mk.2 brake open. Okay, now I can select nearly everything else that has existed in the past.
next
- mk.1 gangwayed brake. now I can't add any mail carriages after it.
next
- mk.1 GUV. now I can add anything from the past, and even the mk3/4 carriages
and well, if you play around with it, you will see that the selections move around a lot too.
Ahh, I see. Will have to regularise this...
some of the bridges in 1960 have cheaper maintenance than the equivalent speed and weight ground level track.
example:
concrete supported rail bridge (225km/h, 150t). $837.50/km to build, $20.00 maintenance
vs.
concrete sleeper heavy (200km/h, 150t). $720.00/km to build, $39.60 maintenance
same problem with road bridges.
---
BR class 71 is too cheap in maintenance and cost compared to class 73, which has less power.
the airplanes are quite horrid to use.
they are fast, so they get a lot of pax flow, but they are low capacity, so you need a lot of them. The problem with using a lot of them, is that they have poor turn around times, which jam the airport. Compounding the problem, they only like using one runway because there's no one way signal in the pak to route the airplanes to use specific runways.
this usually results in a lot of pax that get dumped and decide to use the trains. However, there is usually around 8000~12000pax that get dumped at once, so the trains can't handle it.
also, stopovers are hard to replicate. Currently, it's like a forced layover every time the airplane lands.
Hello AEO
Quote from: ӔO on March 01, 2012, 06:44:41 AM
the airplanes are quite horrid to use.
they are fast, so they get a lot of pax flow, but they are low capacity, so you need a lot of them.
I'm working on the development of the aircraft, I am currently trying to have aircraft available at any age but are not yet able to give more variety. The number of passengers of the planes that I have done is aligned to the number of passengers that the aircraft had in reality. I still have to draw all the larger aircraft, such as the 747, the Airbus 330 and 340, the latter are characterized by 300/400 people on board. These innovations should reduce, but not zero, the problem that you're exposing.
Giuseppe
@milko
I should have added "in the 1960~1970" range.
there are only the BAC 1-11-200 and comet in this era.
---
309/1 and 309/2, when used as 4+2+4 has more power, more capacity, faster turnaround and is cheaper to run than a class 86 with mk1/2 coaches with similar length. The only thing that the 309 is disadvantaged in is comfort, but not by much.
As Giuseppe said, the aircraft capacities are based on reality. The capacity problems in game come about through the passenger factor being far too high, I think. I was looking at the railway lines in Thurmouth last night, and noticed fully loaded express trains departing every two or three game minutes from just one of the many, many lines coming out of that town. That is far too much, and will produce unrealistic results as you have found with aircraft. Larger aircraft, such as 747s, are intended for long haul (thousands of kilometres); the short haul aircraft should suffice for what are in the game in essence short haul routes.
Couldn't there be some kind of penalty factor for plane travel, such as for example an enforced waiting time at the airport before being able to board a plane. That would make plane travelling less likely.
More importantly, however, I think there should be some more variation in the routing of individual passengers. Instead of everybody going from A to D only going via B, some percentage might instead choose to go via C. In that case, plane travel could make more sense.
omikron
Quote from: omikron on March 01, 2012, 10:12:09 AM
Couldn't there be some kind of penalty factor for plane travel, such as for example an enforced waiting time at the airport before being able to board a plane. That would make plane travelling less likely.
There already is - see the "min_wait_airport" setting in simuconf.tab.
QuoteMore importantly, however, I think there should be some more variation in the routing of individual passengers. Instead of everybody going from A to D only going via B, some percentage might instead choose to go via C. In that case, plane travel could make more sense.
This would not, unfortunately, be possible without a massive overhaul of the routing system, which is not currently feasible, and would in any event likely make the routing system too computationally intensive. If one day in the distant future one were to have divergent routes, however, it would not make any sense for the divergences to be entirely random: there would have to be some realistic economic basis for the divergence.
Hello
Quote from: omikron on March 01, 2012, 10:12:09 AM
More importantly, however, I think there should be some more variation in the routing of individual passengers. Instead of everybody going from A to D only going via B, some percentage might instead choose to go via C. In that case, plane travel could make more sense.
There was a thread already open about where you can find some more information.
http://forum.simutrans.com/index.php?topic=6227.msg60003#msg60003
Giuseppe
IRL, medium-sized planes were enough in the 60s. Therefore, they should be enough in the game at the same era.
Maybe it' a question of planning? Air companies are using hub, up to a certain point, yet there are also many lines that do not go through non-hubs. I can fly from Paris to Katowice or Wroclaw, without changing in Warsaw/Munich/whatever big airport. I'll have less planes to choose from(2 per week for the Paris-Beauvais/Wroclaw line), but I'll have.
It is possible that passenger factor is too high, but even in that case, it should be up to the player to adapt : many metropolis today have 2, even 3 airports. If one airport, as big as it may be, is not enough, build another one at the other side of the town. Be also sure to make more "direct lines" to reduce pressure upon your main lines, by transferring it upon secondary hubs.
It is very tempting to have only a few hubs & giant lines between them, but there comes a time when it's no more enough. Then, you have to manage an increasing complexity. IMHO, it's realistic. Atlanta is the main hub in USA, yet I can take direct flights to other US towns. That's the joy of simutrans : you're always looking for a good line balance, yet, town size increases makes the right balance always shift.
Lyon is not the biggest french airport. By far(though it's a big town). Yet, it already links to many different towns (http://www.lyonaeroports.com/fre/Accueil/Formalites-Informations-Pratiques/Infos-vols-en-temps-reel), including a lot of non-hubs.
I was poking around at the journey times on the server map, and many of the journey times (with waiting times included) aren't that much quicker than the train journeys in many cases. Combined with the fact that the airplane journey will probably end much further from the actual destination than the train will, there is definite overlap in which is the "better" service. I think some way to make pax that choose air travel tolerate longer waiting times before rerouting would help.
Once the map gets to the point where it is now, those multi thousand passenger bounces really make a mess elsewhere on the network, sometimes taking a very long time to correct themselves.
Can I ask -- by 'bounce', do you mean the rerouting of passengers?
Am I right in thinking that this only happens when the route they have chosen is no longer the fastest in the database? Unless I'm mistaken, I don't think that passengers reroute just because they have been waiting a long time. Either they will board any convoy to their next immediate destination, or they will be discarded (if max_wait_time is exceeded).
Yes, Carl is correct...
So one way you'd get passengers ditching the plane for another mode of transport (though not the only way) is if there were an alternative direct service (e.g. a train) between the two airports.
One way to avoid this ever happening is to have your airports as separate stations which are nevertheless within walking distance (an on-foot connection) to your airport-train or your airport-bus stations.
This way, once passengers arrive at the airport they are committed to travelling by air unless (a) they are discarded through waiting too long or (b) a reroute occurs because the air route is no longer the fastest route.
I've ditched the airlines for major routes and put them into service as branch service that was previously the job of ferries. (because I accidentally replaced the ferries and now there are no longer any ocean going ferries to use). I've estimated that I need about 60~100 airplanes for each line to operate smoothly.
- class 313 and 507 seem to have an unusually low comfort level compared to any of the previous commuter EMU trains, despite similar seating and overcrowded capacity. 3-sub, 4-sub, 414 and 415 all have around 70~80, but the 313 and 507 have 60. It's also unusually cheap to run.
If you'd ever travelled on a class 313/507 (the interiors are the same) you'd know why I set the comfort as I did! A picture of the interior can be found here (http://www.flickr.com/photos/seadipper/224009013/).
I'd agree. But not as bad as a pacer!
ah, it's one of those "we don't have money, so we'll just use parts from buses" type trains. gotcha :)
Morris LD mail van (1952) is the best for quite a while. It basically takes the best of Austin Morris EA (capacity 34) and low load time of Leyland DAF 200 (0:30-3:20)
The other road mail vehicles are not very interesting to use due to various issues.
- Morris Marina Van -- not enough capacity for the loading time and low on power.
- Leyland Sherpa Van -- less power compared to DAF 200, yet same running costs.
- Austin Morris EA Van -- loading time is horrid compared to Morris LD Van
- Morris FG -- loading time is horrid compared to load it can carry, just 2 more than vans, but at least it's cheaper
- Leyland G -- poor power to weight, but might be interesting to use inside cities.
There seems to be a few previous/next lines missing for the BR class 221 super voyager set. You cannot add a middle car before or after a buffet car. Quite sure this is limited to experimental, because the 221 set doesn't exist in standard.
could use a 300km/h elevated railway. maybe with somewhere around 70t weight limit.
I'm thinking maglev can use an overall reduction in capacity by around 33% and also have a maintenance cost increase by at least 50%. The 560km/h track can also use a maintenance cost increase by around 50%.
It's extremely spacious and profitable in its current state.
and I do realize I'm the one who thought up the capacity. :p
Should be 3+2 (1st class) or 3+3 (2nd class) seats per row, instead of 3+4 in a 24~25m car.
I mean, it's supposed to be wider than your regular BR stock, but not that much wider.
AEO,
thank you for that report. This probably applies to Standard, too - perhaps you could mention this on the Standard Pak128.Britain forum?
It would be nice to have something that runs on AC electric and is placed between the 225km/h EMU and 160km/h EMUs in the late game.
The 225km/h sets are $40~60 for 8 cars
395 - javelin is costly to operate and weak in corners and has poor comfort. It's only slightly cheaper than 373 in terms of maintenance, despite having half the power.
390 - pendolino is not bad, but slightly short on power due to improper configuration, leaving it short one motor car.
The 160km/h sets are roughly $10 for 8 cars
357 - best power to weight, but comfort is not as good as 375/6
375/6 - second best option in terms of power/weight/comfort
444 - best comfort, but terrible power to weight ratio
450 - same power to weight as 375/6, but clearly not as good in comfort
The only thing in between are the 200km/h diesel sets, which are pretty good in their own right, but don't have an electrical counterpart. Something that costs around $20~30 in maintenance with around 175~200km/h would be nice to have.
New class 350 sets are on order and existing ones are being trialled to run at 110mph (say 175km/h) so could be introduced around 2012/3 time.
I am reading this post on a 350...
Heh, yes I know they are around already, some existing ones are being modified (but not most/all) and new ones are being ordered - same class different top speeds for different subclasses :p
hmm, if it is really 1500kW total, then that would be the same as 375 and 450, which require two sets in experimental to hit their top speed. I guess they are going to use a different gear ratio, which would hurt acceleration.
Is there any other BR EMU with around 1700~1900kW power per 4 car set? class 357 is just barely under 1700kW, which gives it a pretty good edge in acceleration and top speed.
It might be better to have tilting for the maglev sets and lower their traction by about 10~25%.
Their current corner penalty, no matter how wide, is 220km/h, which is pretty significant.
On the other hand, their acceleration is really outstanding.
Hmm - do real life maglevs tilt? I think that they just have straighter tracks, don't they?
yeah, they don't tilt, but their tracks have quite an extreme banking in the corners, so it's pretty much the same as tilting.
On the flip side, higher banking disallows slower and heavier trains to use the tracks. This is why you normally cannot use freight trains or slower trains on high speed tracks.
Quote from: ӔO on April 24, 2012, 02:50:38 PM
The only thing in between are the 200km/h diesel sets, which are pretty good in their own right, but don't have an electrical counterpart. Something that costs around $20~30 in maintenance with around 175~200km/h would be nice to have.
There is of course the e-Voyager project which may well see pantograph cars inserted into Voyager units to give them dual-mode capability. We could easily add a pantograph car option in Simutrans to allow an electric Voyager to fill the gap. Although this project will probably only happen 2015ish (because of energy concerns and increasing electrification in the UK), technologically there's nothing that would have prevented an electric Voyager in 2000...
e-Voyager is a bit of a minefield as it becomes an electro-diesel which isn't really simulated well in simutrans...
Quote from: ӔO on April 25, 2012, 01:41:53 PM
yeah, they don't tilt, but their tracks have quite an extreme banking in the corners, so it's pretty much the same as tilting.
On the flip side, higher banking disallows slower and heavier trains to use the tracks. This is why you normally cannot use freight trains or slower trains on high speed tracks.
You can do it with interlaced track (rails, not maglev) - you have 4 rails, and incline each pair at a different angle according to the speed of the train that will use it. I read an article on it once, I don't know if it's in use anywhere though.
Quote from: kierongreen on April 25, 2012, 06:36:36 PM
e-Voyager is a bit of a minefield as it becomes an electro-diesel which isn't really simulated well in simutrans...
I take your point, but in simple terms it's not too unrealistic to imagine a voyager entirely electric powered, which is what would be simulated in game...
Right - I have (on my local copy for now - changes will be pushed in due course) reduced the passenger/mail maglev capacity by 1/3rd, increased the cost of the 560km/h track and tunnels by 50% and reduced the cornering penalties in simuconf.tab (which I thought was better than making them tilting). I hope that this will help the balance on the next occasion. Thank you for the feedback on this!
Quote from: AP on January 24, 2012, 04:12:38 PM
I also think that the speed of the game timeline needs to be adjusted. When everything is moving around at 10km/h in 1830, it's like watching paint dry waiting for deliveries to arrive, and would be helped by having the game run at e.g. double speed, if it can be set up to vary with the date or something?
Hah! This is the how-many-hours-in-a-month issue. I was working on disentangling that so that it could be adjusted in a straightforward fashion. In current simutrans code it's a mess, but if I ever finish straightening out the "units problem" it should be easy to change. You've just given me more motivation to do so.
Quote
I was also suprised that I had difficulty making an industrial chain run at a profit. Coal/Ore to a steel mill, to a cannery, to a Grocer's, ought to yield a tidy reliable profit. But I had difficulty encouraging the food inputs to yield much produce (orchards giving 6 crates of apples to go with an entire trainload of steel...), and the industries seemed to lose money too. The industrial revolution was built on heavy industry moving stuff around, passengers were secondary. I also thought the map had too little heavy industry by a significant margin, although it had a nice number of towns and decent distances between.
I also noticed a while back that the food industries produced too-low production, particularly early on.
Quote from: ӔO on March 01, 2012, 06:44:41 AM
the airplanes are quite horrid to use.
they are fast, so they get a lot of pax flow, but they are low capacity, so you need a lot of them. The problem with using a lot of them, is that they have poor turn around times, which jam the airport. Compounding the problem, they only like using one runway because there's no one way signal in the pak to route the airplanes to use specific runways.
this usually results in a lot of pax that get dumped and decide to use the trains. However, there is usually around 8000~12000pax that get dumped at once, so the trains can't handle it.
These problems show up consistently in standard as well; the modelling of air traffic control in the simutrans engine is poor. If I cared about airplanes, I'd fix that to get the airplanes to use multiple runways properly; this would be a nice engine improvement. But I don't care much about planes so I won't be the one doing that...
Quote from: neroden on May 06, 2012, 05:28:42 PM
I also noticed a while back that the food industries produced too-low production, particularly early on.
The idea was realistically to reproduce the relative production levels of early farms, having a very large number of farms each producing a small amount of output, which the player would have to gather together, as in reality.
Quote from: jamespetts on May 06, 2012, 07:09:27 PM
The idea was realistically to reproduce the relative production levels of early farms, having a very large number of farms each producing a small amount of output, which the player would have to gather together, as in reality.
It's a good idea, but the minimum levels per farm have to be at least high enough so that the deliveries pay for the construction and maintenance of the dirt roads to the farms and the stops at the farm end; that's a problem for a spreadsheet. Also, the demand end (the Market, etc.) also needs to have high enough numbers, so that you can get economies of scale at that end.
Quote from: neroden on May 06, 2012, 05:31:34 PM
These problems show up consistently in standard as well; the modelling of air traffic control in the simutrans engine is poor. If I cared about airplanes, I'd fix that to get the airplanes to use multiple runways properly; this would be a nice engine improvement. But I don't care much about planes so I won't be the one doing that...
Sorry for necroposting here, but I am looking into airports/aircraft at present, so a comment here is in order, I think. There's something to be said for improving air traffic control (and, for that matter, forcing every airport to have a control tower before anything can land there, although how this would be presented to players in the UI is a tricky issue).
However, in the meantime, a fairly realistic workaround is to have different terminals represented as different stations ("Bimblebridge Airport Terminal 1" and "Bimblebridge Airport Terminal 2", etc.), and have each terminal have its own runway. There can be a land connexion (e.g., 'bus, maglev, monorail, underground train) between the terminals, as there often is in reality.
The excess of passengers seeking to use airports in the server game was probably caused by a combination of an excessive passenger factor with an excessive proportion of the passengers being prepared to make long-distance journeys. It is also possible that the journey distances were just too short for aircraft to be suitable, with the result that they were only marginally faster than rail, such that when actual rather than initially estimated (and very low) waiting time was factored in, they suddenly worked out as less fast than railways.
One thing I would like to suggest.
For 3rd rail electrification, could the max speed be brought up to 200km/h?
Due to the way speed restriction works, all trains going over the tracks are limited to 160km/h, which means one would need a separate set of tracks to run 200km/h diesel trains
No routes in Britain with third rail electrification have a speed limit of over 160km/h even for diesel trains.
But that's not to say they couldn't. There's no technical restriction (that I know of), why non-3rd-rail powered trains couldn't run faster than 160 cm/h on track that happens to have a 3rd rail adjacent to it.
The absence of a precedent is perhaps more to do with uk geography than anything else (3rd rail electrification being mostly south of london, where there is less need for high speed rail, because you hit the coast rather quickly...). If the restriction is to do with the shoe/contact technology, then the locomotive max speed would cover that without placing the restriction on the track also, would it not?