News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Way maintenance multiplier

Started by gfurst, February 13, 2014, 08:30:18 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gfurst

I would like to suggest a new setting for the simuconf file, way maintenance multiplier, relevant to paks.
This could accept a integer of the range 0-200, 100 equals 100%. This is to be able to set the costs according to the desired difficulty.
Similar to the building maintenance option, it seems only logical that other infrastructure parts should also be subject to user option.
# Maintenance costs of buildings
maintenance_building = 1000

Of course this would be a main multiplier, not needing pak maintainers to alter every single pak file but only include it in its simuconf file.
Optionally, it could also have different multipliers for different types of way, track, road, canal, etc...

My reasoning for this:
Paks can be, within reason, not well balanced. Sometimes making it very hard for players to turn a profit while attempting better infrastructure( looking at you pak128).
This of course is a difficulty setting that should tune in to the player's needs.
The per type based cost, would suit also to balancing the game , for example, I think roads cost way more that they should compared to tracks and others.
Plus, I tend to use the public player to build the majority of ways and stations, so players can use and share the network, and this could potentially give the public player a chance to break even.

Please tell what do you think of it. I could help implement it, though my coding skills are pretty much obsolete.

Ters

Although it would work as part of a difficulty modifier, it does not really solve the problem of badly balanced pak sets. A pak set is likely too difficult in some (in-game) years, but too easy in others. pak64 certainly changes between being a money maker and an uncurable money drain. (Fortunately, they come in that order, so in my experience you can afford the later losses.)

gfurst

Quote from: Ters on February 13, 2014, 09:05:51 PM
Although it would work as part of a difficulty modifier, it does not really solve the problem of badly balanced pak sets. A pak set is likely too difficult in some (in-game) years, but too easy in others. pak64 certainly changes between being a money maker and an uncurable money drain. (Fortunately, they come in that order, so in my experience you can afford the later losses.)
True, pak64 reaps incredible fortunes in early game, well, not actually. The period between 40 and 80 I've to guess, never played a single game too long too know.
Before the 40s its very hard too due to the lack of options in transport.
On the other hand pak128 its hard to turn a profit, even with a big network and convoys close to full.

I had a game where I manually created all the cities and industry, the public player built all the rail and road network. Had seven companies together working on the supply chain on the very profitable food industry, also the very stable coal power plant. Buses running around the clock and still the combined profit of the companies could barely pay for the public player's upkeep.
The Public player came very close to breaking even from electric revenue and road tolls, but the cost for the companies were so much they couldn't keep up.

Ters

Quote from: gfurst on February 13, 2014, 09:24:15 PM
True, pak64 reaps incredible fortunes in early game, well, not actually. The period between 40 and 80 I've to guess, never played a single game too long too know.
Before the 40s its very hard too due to the lack of options in transport.

I've played one game from somewhere around 1850, perhaps as early as 1830, to 2030. I made huge amounts of cash up to somewhere in the late 1900s. Even when losing millions per year after 2000, I have no worries about going bankrupt for centuries. Pak64 has however been rebalanced since I started that game. I've currently started a new game from 1850, and by 1865 I was making a steady profit and no longer have to worry about construction cost or going bankrupt over wasting money on something that didn't turn out to be profitable. (My main problem is moving all the passengers, as well as some other goods, within a city without clogging up the streets with horsedrawn carriages.)

gfurst

Yeah, it would normally need to much carriages to move enough passengers around, within the urban are I've mean.
Why is it so hard to make a profit on the late part of the game? Speed bonus I suppose?

Anyway, what do you say about the extension it self, the global maintenance multiplier defined within pak's text files.

kierongreen

Just recompile the pak with value you think are appropriate - or use freeplay.

gfurst

Quote from: kierongreen on February 16, 2014, 07:56:33 PM
Just recompile the pak with value you think are appropriate - or use freeplay.
This is not an answer, changing each relevant pak file and repacking them is simply to much work, plus the source of pak files is updated and only usable with the latest source of the game itself, not always the best choice for players.
Of course freeplay can be used here, but this is not the point, the point is to enable the user to easily tweak his game. As a difficulty setting, like the "building maintenance" setting already exists, its only logical to also have way cost maintenance setting.

kierongreen

Building maintenance isn't a multiplier of pak file values though - until recently buildings couldn't have a value for maintenance in pak files so the config file option was the only way to set this.

If you have the skills to open up a config file you should be able compile a pakset from source - and you can choose the revision number to be compatible with the release version you are using. Compiling from source means you can set all kinds of values.

Ters

Quote from: kierongreen on February 17, 2014, 04:50:34 AM
you can choose the revision number to be compatible with the release version you are using.

I guess the problem is that the release version one uses changes. I can understand that gfurst wants to change this once and for all. If one checks out the pak sources with subversion (or git, or whatever the particular pak set uses), any changes one has done should automatically be merged over when syncing up to a newer revision, but that tends to break down for anything but the most trivial changes. Manual merging can be a daunting task even for experienced developers. One also has to keep an eye out for new items that must be fixed.

I do however suspect that tuning such a value is rather difficult. If it was easy, pak sets would likely be tuned already. I wonder if the difficulty of setting up a balanced economy, is that everything in Simutrans scales linearly. There is as far as I know no administrative overhead that makes operating twice as many vehciles more than twice as costly. But on the other hand, the focus in Simutrans is transportation, not economy.