News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Upgrading tracks same cost as building new - balanced ?

Started by missingpiece, January 22, 2012, 02:58:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

missingpiece

Hi !

I am just realizing that upgrading tracks costs the same as laying the tracks new. Is that intended or determined ? Or everyone's fine with that ? Or is it determined by program logic and cannot be changed ?

Well, I can afford it. But I would be happier if it was a little cheaper.  :P

Thanks for commenting.


missingpiece

Zeno

I'd say it's determined by program logic, as long as there's no option for track upgrade; I guess it's replacing the old track with the new one instead of updating it.
Anyway, should it be cheaper? Maybe it could be even more expensive, because you would probably have to remove the existing track in order to place the new one (two jobs); anyway all the laying bed job would already be done, so that part could be saved... well, it's difficult to say for me; I'm not a track expert, but here you have some thoughts! :)

Fabio

Its definitely determined by the program although I always had your feeling that it should be cheaper. Saying that the ways are in pristine conditions due to regular maintenance costs the player pays and in real life not all maintainers do, often increasing speedlimit in real life just implies working on bends and aloe gradient, with less work for straight stretches and so on. And obviously upgrading a 70 km/h road to 90 km/h is much cheaper than updating a 30 km/h dirt track to 90 km/h road. So imho a fair upgrade price should be min(new_road_price, (new_road_price-old_road_price)*k) where k=1.25 or so.
But this should indeed go to extension requests, although denied in the past...

merry

Well, I'd have to agree: a large part of building new rail is buying the land, preparing the base & drainage, etc. The rail costs money as well, but certainly there is a base cost to having a stable bed upon which to build. And of course, signalling, stations, etc are not directly affected by track upgrades (unless you want to...)
The recovered value of used track has to exceed the cost of lifting the track, otherwise it would be left to rot in place and Mr. Beeching would not have recommended lifting all the lines closed in the 1960s in the UK! (as an aside, it's interesting to note in some cases track is not lifted, but simply becomes overgrown - where this is not a 'strategic decision' to retain routes for the future, it would seem related to steel scrap value and new costs, and the difficulty in getting the track to scrap/re-use.)
Ergo, the cost of upgrade should be less than new track: the lifted rail etc is almost always re-used in sidings, depots, etc, or even sold for scrap - all of which recoups some of the residual value. 
Now for the difficult bit - (a) programming the upgrade in place feature, and (b) setting the upgrade costs. I quite like Fabio's suggestion, scaling factor to be decided of course.
It does also suggest to me that a previously proposed option to 'abandon' track but not lift it (thus saving dismantling costs) may have value, if a consistent approach is to be taken. it allows routes to be retained but 'mothballed' (could one also do this with stations, depots, etc?)
This most definitely sits well with the Experimental approach, prissi might consider the complexity too great for Standard.

it will be interesting to see the response.

missingpiece

Thanks for commenting. As I understand Fabio, there has been similar feature requests in the past. Maybe, Fabio knows whether this has been hinted to james in the past for the Experimental branch, as merry suggests ?

prissi

It was different before. But then you could get money by overbuilding cityroads ... Thus it was decided to have the current behaviour.

Fabio

So, did I understand that this could actually be changed now?
It would be really great!
I'm moving this to Extension Requests...

prissi

If changed, you could easily end up that downgrading a way (or overbuilding city roads) gives you money. It can be changed again, but needs more discussion.

wlindley

min(new_road_price, abs(new_road_price-old_road_price)*k)

would never result in a negative number -- you will always pay at least the absolute value of the difference between the way types.

For railroads, paksets could define "graded right-of-way only" so you could survey and lay down ballast without any actual tracks.  The maintenance cost on that would be low, but not zero  (you have to prevent wash-outs and trees from growing)... which would fulfill the "mothball" request.

prissi

Just use a way with cost zero and you can do this today ...

missingpiece

I think the request can be formed as : "it appears worthwhile considering a different approach to calculating the cost of building ways where a way has been built before; overall resulting in less than the flat new cost per tile calculated solely off the new way tile's price, but by taking into account the way type and its pakset price that is already present on the same tile."

Of course, the calculation should offer as little exploit by the user ( user = the one playing ) as possible. Changing pakset values, or using a pakset having values that specifically try to "game" the new calculation scheme do not constitute an exploit.

Fabio

Wlindley's formula seems sound enough imho.

We could also think of increasing the upgrade/downgrade cost according to the fact whether the old way belongs to the same player, to another player or to nobody.

For upgrading/downgrading own way factor is k as defined in simuconf.tab
For upgrading other players' ways factor is 2*k
For downgrading other ways, factor is 10*k



EDIT: I propose here another improved formula:

upgrading_cost=min(max(new_road_price,old_road_price),abs(new_road_price-old_road_price)*k)

This would make much more expensive downgrading e.g. a 130 km/h motorway to 30 km/h dirt road (previously it would take the cheaper price of dirt  road).

For taking into consideration also ownership, we could have:
upgrading_cost=min(max(new_road_price,old_road_price),abs(new_road_price-old_road_price)*k)+penalty_factor*old_road_price

where penalty_factor would be
0 for same ownership
0.1 to 1 for different ownership (upgrading)
>1 for different ownership (downgrading)

prissi

You are not allowed to cahng eroads that do belong to somebody else. And why should downgrading be more expensive?

How about max( Price_new-(Price_old/2), min( Price_old, price_new) )?

(It is anyway happening very rarely.)

Combuijs

Quote from: prissi on January 24, 2012, 02:48:23 PM
You are not allowed to cahng eroads that do belong to somebody else. And why should downgrading be more expensive?

How about max( Price_new-(Price_old/2), min( Price_old, price_new) )?

(It is anyway happening very rarely.)


Hmm, that gives 3 cases, assuming all costs > 0:

Price_old > Price_new (downsizing): Price = Price_new  (new-old/2 will always be less than new)
Price_old < 1.5 * Price_new (serious upsizing): Price = Price_new - 0.5*Price_old
Price_old < Price_new (a little upsizing): Price = Price_old

Sounds good to me, Price to pay function is continuous, no strange gaps. And in the upsizing case you pay now less. Only for downsizing you still pay the full amount, which seems a bit strange to me. In upsizing you get something back for the old road, but not when downsizing.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Ters

Though the old track already has a base and the ground has been bought, this might not be as beneficial as one could believe. Newer tracks typically means faster tracks, and faster tracks have to be straighter both vertically and horizontally. What this means in Simutrans depends on how one interprets its representation of the world. Is a straight track really straight, or are there small bends and hills that just isn't visible because they are smaller than a tile?

Fabio

But consider this case: you upgrade a cheap 30 km/h dirt trail into a 130 kk/ motorway: you pay the full cost of a motorway. But then you have also a 110 km/h expressway and you upgrade it too to motorway standard. With current behaviour you pay as much as in the first case (the dirt trail) and this seems pretty illogical. This second case needs to be way cheaper than the first one.

missingpiece

I'm already happy with an approach that breathes some life into upgrade prices, makes them less static.  :)

AP

I think upgrades should take accounts of how many convoys pass over a given tile.

To upgrade a lightly used road or railway is simple (ie close it for a few days whilst work is done). To upgrade a heavily used section of infrastructure however is very expensive indeed, since it has to be done overnight or without disrupting the traffic. Just look at the current upgrade works for Crossrail in London, they're costing a fortune!

missingpiece

Quote from: AP on January 24, 2012, 06:07:13 PMI think upgrades should take accounts of how many convoys pass over a given tile.
First I thought, oh Lord, someone's getting greedy. But then I remembered, some statistics is there already : how many convoys passed over a tile the past month. That is a start. But certainly not the whole deal for this feature complexity. Yet, I like the idea.

The map data model would have to be changed for this, though, allowing an extra counter to be stored per tile which sums up all by-passes over the lifetime of a way-tile since the tile was last constructed. And that, I fear, will break compatibility of old maps with a new client unless compatibility code was added. And convincing a voluntary dev to do all that ... ?! Also a lot broader consensus would probably be required of the community. Maybe features are in the pipeline which break map compatibility anyway with the release 112 ? I admit, I am so new to the game that I do not even know how map compatibility was handled pre 111.

AP

Quote from: missingpiece on January 24, 2012, 07:40:18 PMBut then I remembered, some statistics is there already : how many convoys passed over a tile the past month.
Indeed. Wasn't trying to be greedy, suggested it precisely because the data already exists, and I actually thought it was sufficient. :-)

I mean, it doesn't in reality cost more to upgrade a quiet route that historically was busy, than one that has always been quiet, it only depends on current traffic levels, so I'm not sure I understand the need to count the whole-lifetime traffic?

EDIT: The other reason I liked the idea - it penalises success (put crudely). Simutrans has a tendancy towards runaway bank balances, once a network is up and running and profitable, so something that could act to limit that, maintaining competitiveness between players etc, might be useful. I recall that in certain computer game circles this is termed a "gold sink" - depending on how it is weighted of course.

prissi

But if a most used road is upgraded, then we are back at the full price of the road. Mosr than that would not make sense.

AP

Quote from: prissi on January 24, 2012, 09:07:21 PMMore than that would not make sense.
I think it would. To build a new road in a field is quick, cheap, and a good base cost.

But in London recently, they've taken over a year to replace railway bridges on the A40 (link), a major arterial road. It took much longer than normal, and therefore cost much more than normal, because they had to to keep the road and railway open throughout for the large numbers of vehicles which use the key commuter routes. Even then, they had to work with 50% capacity reductions at times.

jamespetts

Addressing this issue is already planned for Experimental: see here for details.
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.