News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

[0.8.1] A slight suggestion/tweak for simuconf.tab and stations

Started by ӔO, September 28, 2011, 06:02:39 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ӔO

I have a few suggestions for the configuration settings.

The first bit is just some display settings that I think don't need to be on, as it can be a bit of a hassle trying to query what you want.
Pedestrians, cars, trees and ground info aren't really necessary and are a bit of an annoyance when you accidentally click on them, because you need to close their info window. Townhall info is left on. Only single info is turned off, because now the game allows you to build and stack convoys at the depot. If you built, say 40 convoys and wanted a bit more, but closed the depot window, it can be a lot of clicks before you can get to the depot window again.
pedes_and_car_info = 0
tree_info = 0
townhall_info = 1
ground_info = 0
only_single_info = 0



The second regards passenger generation.

 The default setting is "passenger_factor=15", but I've played with "passenger_factor=8" and I think this is a bit more realistic. If only the townhalls are connected by rail, the line won't generate a lot of passengers, but once the cities is connected with buses and trams, it causes quite a large influx of passengers to use the rail. When set to "passenger_factor=15", there's no need to connect anything, but the townhalls, because doing so will cause overcrowding of the line.

I think somewhere between 7 and 10 should be ideal for game play.
passenger_factor=8


The last one is in regard to station capacities and costs. The current capacities of stations are overbuilt for their purpose and it's too easy to expand the station size.

 I've noticed that the key to keeping passengers happy and generating a large network relies heavily on frequent service, rather than speed or capacity of the vehicles used. I've also noted that as a result, stations are overbuilt for their purpose and only the level 1 platform is required. This causes level 2 and 3 station buildings to become quite redundant and mainly decorative in nature. The only reason to expand the station is to fit more trains or allow longer trains to fit.

 The stations are too easy to expand in both length and width. In real life there are problems such as procuring land to expand and many railways struggle to build new stations or expand current ones to meet capacity demands. As it is now, the costs to build the stations don't reflect inflation and it ends up being cheaper to build stations in the modern age, compared to the golden era. To encourage building up, rather than expansion, I would suggest reducing cap and changing costs.

The idea is that cost, maint. and cap do not scale linearly with each other and the costs of newer buildings are higher than their older counterparts. It should be cheaper to build higher level buildings rather than expanding the platforms.

QuoteWooden platform: Cost: 150.00c, Maint.: 18.00c, Cap: 24
Wooden  w/ roof: Cost: 225.00c, Maint.: 30.00c, Cap: 48

Brick platform: Cost: 300.00c, Maint.: 27.00c, Cap: 24
Brick w/ build: Cost: Cap: 400.00c, Maint.: 36.00c, Cap: 36
Brick w/ roof: Cost: 450.00c, Maint.: 45.00c, Cap: 48

Concrete platform: 600.00c, Maint.: 36.00c, Cap: 24
Concrete w/ build: Cost: Cap: 800.00c, Maint.: 48.00c, Cap: 36
Concrete w/ roof: Cost: 900.00c, Maint.: 60.00c, Cap: 48

I'm unsure if this should be applied to bus/tram stops.
I'm unsure how station buildings should fit, but I would guess higher capacity, but the same cost as platforms.
These should not be applied to freight.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

AEO,

thank you for those suggestions. I have implemented the suggestion in relation to the station capacities on my Github repository (with a few tweaks), but I am not so sure about the others. The information about cars is quite useful, as, in Experimental, their origins and destinations are given. The ground and tree information is significant, as one can tell to which city that a land tile belongs, which is important for electrifying cities. The multiple information thing is more marginal: it can be rather annoying to click a square and have a large number of windows appear when one only wanted one; I should be interested in others' views on this subject.

The passenger factor issue is a particularly complicated one. May I ask - what size map were you using to test? The smaller the map, the larger the number of passengers that can be transported at the beginning of the game, there will be a higher chance that any given destination is the destination that the passengers wish to serve. Thus, larger maps need higher passenger factors (the exponential increase in the number of passengers in the later game in large maps is controlled in Experimental by the journey time tolerance). The size of towns is also a relevant factor: larger towns need a lower passenger factor, but one must factor in town growth over the course of an entire game, which might be hundreds of years.

Thank you for your research and suggestions!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

currently I'm testing with the New Zealand North map.
http://dl.dropbox.com/u/17111233/Ageage%2010.0.sve

I know from past games, that as soon as bus lines are connected to the mainline, they will cause a large influx in passengers.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

How many towns do you have in that map? That's the important thing for the passenger level.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

134 cities
1,190,000 population

currently the population is not spread out too much due to the nature of the map.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

sdog

Quote
The second regards passenger generation.

  The default setting is "passenger_factor=15", but I've played with "passenger_factor=8" and I think this is a bit more realistic. If only the townhalls are connected by rail, the line won't generate a lot of passengers, but once the cities is connected with buses and trams, it causes quite a large influx of passengers to use the rail. When set to "passenger_factor=15", there's no need to connect anything, but the townhalls, because doing so will cause overcrowding of the line.

I think somewhere between 7 and 10 should be ideal for game play.
This is exactly what i came for to this forum section, to suggest.

I'm making good money in a not very denseley populated map* around 1835 at pax factor 10. Higher values make any line to cash cows, network effect is not really necessary. A while ago you had pax factor at 8, this used to be challenging but possible. (short max travel time made it almost impossible though)

(1280*640, 180 towns, largest 4k, average 800)


Along the lines of network effect this also goes:


# Some passengers who are not able to find a route will be content
# to go to an alternative destination. Set the maximum number here.
# (Note: whether any given passenger is content to go to an alternative
# destination, and, if so, the number, will be random. For each
# possible number of alternative destinations, the chances will be even.
# For example, if the number is set at 2, there will be an equal chance
# of passengers having 0, 1 or 2 alternative destinations).

max_alternative_destinations = 6

This i think is way too high. It almost cancels the network effect. Values between 1 and 3 might be more desirable.

If you increased it to have less decrease of difficulty with longer running games, perhaps you can make max travel time tighter, this is the real challenge for large and complex networks.

jamespetts

AEO,

one thing that I've noticed about that map is that the towns are very large and very close together: more than I might normally expect. Might I ask - in what year did you start that game? If you scaled the proportion of the urban area of your map with the tile scale, you would probably find that it is more dense than would be realistic in 1924.

Even so, although the network is very heavy, much of it is lightly used, with only a smattering of passengers. I recall when I had the passenger factor set to 8, the usage would be too low to be realistic: there would be so few passengers that only a single track railway would be justified between even large towns. What we really need is a factor at which there are challenges at both ends of the scale within the parameters of an organically generated map at default parameters: in small villages, the passenger numbers should be low enough to be challenging (although bearing in mind that even most small villages had sufficient passenger traffic to justify a railway line before the advent of the  motor car), and in large towns and cities, the passenger factor should be high enough to justify trams, underground railways, urban rail lines, etc., and still leave overcrowding problems if these are not implemented efficiently enough.

Also, the map configuration is rather unusual: you have a very large and dense cluster of cities in one part of the map, and the rest of the map is blank, but you have extensive rail networks (without stations) extending into barren countryside. May I ask - do you play by adding towns as you go along? Doing this will mean that a high proportion of towns are always connected, greatly reducing the potential for network effect as described above. Simutrans-Experimental and Pak128.Britain-Ex are designed for a network to be built over many years on a map of towns that is complete when the player starts.

As for the maximum alternative destinations: I don't think that, on a map with many hundreds of towns, it will eliminate the network effect for passengers to be able to choose between 1 and 7 total destinations (any number of which might be in the same town as any other); remember, they do not all have 6 alternative destinations - the number of alternative destinations is chosen at random up to the maximum. The overall proportion of chosen destinations to actual possible places remains low. On a small map, this might better be adjusted downwards, but I have balanced Pak128.Britain-Ex for large maps.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

the NZN map was more of an experiment to see how large of a network interest funds could support, to see how playable each company of the big four was and to eventually emulate competition between lines. I would ignore the timeline, because it was meant to be an emulation of at least 1970.

this game is from 9.12, with 0.8 settings, but it still generates a lot of money on the main line in 10.1. This one was started in 1750 and played normally.
http://dl.dropbox.com/u/17111233/Epona%20ex9.12.sve
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Returning to this topic after somewhat of a pause, I have looked briefly at your saved game. What I notice is that, although you are making a lot of money, most of the lines have a very high free capacity to transported ratio (look at the two graphs simultaneously in the line management window). This means that you have more capacity on your lines than you really need - your trains are too long, mostly. You also double-head a lot of trains, even with smaller locomotives (may I ask - what is the advantage of doing this over using a single, more powerful locomotive?).

The issue thus does not appear to be with the overall number of passengers (as can be corrected by changing the passenger level), but rather with overall profitability. Reducing the passenger level would make an efficient network too sparse.

I am currently working on a feature, in my fare-stages branch on Github, which reduces the per kilometre cost paid by passengers and goods after their journey has exceeded a certain distance (e.g., 1.00c/km for the first 50km, 0.80c/km for the next 100km and 0.50c/km thereafter). This would reduce what often appears to be excessive profitability for longer routes without making it too difficult to make a profit on local routes or early in the game.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

if you are talking about the NZN save, then the locomotive choices are because it was an attempt to see where the gaps were in each of the big four and how profitable each company was. I think I was intent on making a vast network for 4 or 5 companies, but most of it was not finished.

For the epona save I think the choices were as such, because the replace feature was broken and the trains were left with what they started with.

for the double headers and overcapacity, I think that was done because one engine would never hit top speed, even if it was not pulling much.

It's been a while since I've played those saves, so I don't remember all the details of why I did that.
The epona save is the one that has been played normally.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart: