Maximum Income Distance Patch

[wleader]

So, wleader, are you making this patch in the hope of improving the economic model, or do you just want to be rid of the excessively long routes in multiplayer?

Either is fine by me, but I suddenly realise that I'm not helping by throwing ideas around if I dont know what the patch is working towards!

What I am trying to do is to make excessive profits more difficult to obtain. In a multi-player game where one player already has a huge amount of cash, the game for that player is no longer challenging. For all the other players its a hopeless effort to catch up. Competition in the game is reduced to who builds that long coal route network first. There is almost no reason to join a game thats been running for 10 years, because as much as you like you can't compete with that except by building a similar network that connects more stations. I am a pretty fast builder and I can compete in this way, but its not as much fun for me as building more interesting networks. Personally I just don't find simple long haul networks fun, and I suspect I'm not the only one.

In short I am trying to make multi-player more fun. I do realize that fun can be pretty subjective. I think I would enjoy multi-player more if the balancing rewarded efficient networks instead of just long networks. I do realize you can build an long network that is also efficient.

To that end I see the time penalty cap an exploit in the code that unbalances things. The time cap was never meant to be used on large maps.

[Elvish Magi]

So yes, I am working the time penalty now. The problem I am seeing is that the time cap code isn't completely clear to me yet. One thing I have seen is that if a cargo takes a long time but doesn't travel very far that a negative profit could happen. Stop a train for a couple of years before starting it again to see what I mean. So If I remove the time penalty cap, I probably ought to add code to prevent the prevent the profit from being negative. At worst the most you ought to be able to loose is the vehicle running cost.

I've had a (very!) quick look at economy.cpp and it seems that the problem is:

Code: Select all

01272   if (time_factor < MIN_TIME_FACTOR) time_factor = MIN_TIME_FACTOR;

A little earlier MIN_TIME_FACTOR is defined:

Code: Select all

01246   static const int MIN_TIME_FACTOR = 31;

It would be illogical to have cargos arriving that are worth a negative value, but not illogical that they might have no value what so ever (for example, a product that degrades would have no value if it had turned to a pile a mouldy mush!)

Therefore, the first thing to do seems to be to change MIN_TIME_FACTOR to 0. Test playing with that and see if the change is too harsh or desired, and then if needed either tweak the value used (could it be set by the user in some way?) or look for some mechanism to degrade it depending on certain conditions.

[Lupin III]

There already are many threads that talk about different economic modells (and some of the developers are already annoyed by it). In my opinion the assumption that distance and time make the profit is wrong to begin with. It should simply be the destination that sets the profit. If there is a powerplant and no coal mine around it would pay more per ton, no matter where the coal comes from. Another powerplant with a coal mine some 50 tiles away wouldn't pay more for coal shipped over the whole map. Or you can see it the other way round: the farther away from a coal mine, the more expensive the coal gets. For the price at at given point, always the nearest mine is taken into account.

But I think this would be a completly different patch, so just take it as an idea.

[Bilbo]

Even better, if you want to be "realistic", tak demand and offer into accound. If industry is not supplied, it will raise it offer for good and price would rise. If the industry is supplied too well, it may drop the payouts. But that would be probably quite complicated, both for coding and for players to understand and use effectively.

[athanasios]

For the price at at given point, always the nearest mine is taken into account.

So if a coal mine is next to a power station you may get negative profit. There should be a minumum fee, regardless of distance. And this should apply especially to local passengers.

[el koeno]

There already are many threads that talk about different economic modells (and some of the developers are already annoyed by it). In my opinion the assumption that distance and time make the profit is wrong to begin with. It should simply be the destination that sets the profit. If there is a powerplant and no coal mine around it would pay more per ton, no matter where the coal comes from. Another powerplant with a coal mine some 50 tiles away wouldn't pay more for coal shipped over the whole map. Or you can see it the other way round: the farther away from a coal mine, the more expensive the coal gets. For the price at at given point, always the nearest mine is taken into account.

But I think this would be a completly different patch, so just take it as an idea.

This sounds like the Railroad Tycoon 3 economic model.

Perhaps this all goes a bit too deep into the heart of the game. I never play multiplayer, so I have the option to design my networks the way I want to, and thus I'm not bothered by long lines being too profitable. But I wouldn't mind a patch setting that simply sets the maximum time penalty.

[Lupin III]

So if a coal mine is next to a power station you may get negative profit. There should be a minumum fee, regardless of distance. And this should apply especially to local passengers.

Passengers and mail would be excluded of course. They are no "supply and demand" cargo.

You wouldn't make negative profit from the cargo (only from the running costs), because you don't buy and sell the coal. You just transport it. But the power plant wouldn't pay extra for your long haul, if you could get them the coal from a mine much closer. It's like some hidden local competition, that transports goods if you don't.

Btw. time should still play a roll in transporting, a least for goods that can go bad. If you can't deliver fruits within 100 days they are worth nothing.

This sounds like the Railroad Tycoon 3 economic model.

Yes, and I really liked that, because it prevented the build-the-longest-line-possible-strategy very effectively. But I really missed the "network"-building and many other features in RT3. So I try to spread the imho good ideas of RT3

[el koeno]

This sounds like the Railroad Tycoon 3 economic model.

Yes, and I really liked that, because it prevented the build-the-longest-line-possible-strategy very effectively. But I really missed the "network"-building and many other features in RT3. So I try to spread the imho good ideas of RT3

What I'm afraid of is that it would really drastically alter the nature of the game. Right now if I build a network, I build the trains and I can pretty much leave it all alone. But if the economy get too dynamic, some trains might end up operating unprofitable lines. If you have only a few trains this is no problem, but checking dozens or hundreds of trains to see whether they serve good lines requires huge amounts of micro management. Unless of course you go all the way with the RT3 idea. I would like it (even though it would change the basic nature of the game a bit too much), but it's probably going to be a huge effort to code.

So I think the OP is on the right track. It might be best to include it somewhere in the option screens, where you can select by just how much you want to discourage long lines.

Note that there is a passenger destination patch for passengers (included in Gonozal's patch pack). I love it, and it solves most of the problems I had with passenger transport, although it might need some tweaking.

[Bilbo]

What I'm afraid of is that it would really drastically alter the nature of the game. Right now if I build a network, I build the trains and I can pretty much leave it all alone. But if the economy get too dynamic, some trains might end up operating unprofitable lines.

With high competition from other players you can end up with unprofitable line even with current way the things work (others build track to same factory that you are serving, they will take 80% of the goods, leaving you only 20% and your line could get unprofitable).

[wleader]

Alright I've had some time to work on this, and what I ended up doing is spending the time looking at GetTransportedGoodsIncome in economy.cpp, specifically this code:

Code: Select all

int time_factor;
if (days_over_days1 <= 0) {
	time_factor = MAX_TIME_FACTOR;
} else if (days_over_days1 <= days2) {
	time_factor = MAX_TIME_FACTOR - days_over_days1;
} else {
	time_factor = MAX_TIME_FACTOR - 2 * days_over_days1 + days2;
}

if (time_factor < MIN_TIME_FACTOR) time_factor = MIN_TIME_FACTOR;

To help me better understand what was happening here, I created a spreadsheet the models this code. (You'll find the spreadsheet attached to this message.) Basically I first tried to figure out what the time factor would be at different times.

The time factor that this code produces is a horizontal line at 255, for the first few days, then slopes downward in a straight line until it reaches 31, and then becomes a horizontal line again. I tried looking at this line for various cargo types, and its pretty much the same basic shape. So that by itself wasn't very interesting. It wasn't until I included a calculation for estimated distance traveled, and made a graph of that that I found something interesting.

Now these graphs just show the income curve. The actual numbers aren't correct because they don't consider cargo payment rates or inflation, but those aren't important because they are the same over time. Time factor and distance change over time so they are the only values used in creating these graphs. I've also used the value 5.6 tiles per day at 100kph. This allows us to calculate the time factor for a number of days, and the distance for a number of days, Those values are then multiplied to get a profit value. I ran the same calculations for Coal and Passengers to compare because their Day1 and Day2 values are very different.

The top graph shows the current behavior of OTTD. The next graph shows what happens when you set the minimum time factor to 0 as Elvish Magi suggested. The result was that if a cargo took too long to get there, its profit could become zero. However it seemed that as long as the cargo was delivered before Max time factor was reached, a hefty profit could be obtained, especially if the ideal travel time of half the max time factor was reached. So just to experiment a third graph was made with a max time factor of 128. The reason why there are two lines to show the effect that vehicle speed has. The blue line represents 64 Kph, and the pink line 128 kph.


So setting the minimum to zero close the infinite time exploit, and causes the ideal round trip time to be 255 days (wow, the same as the Max time factor) This means that the ideal distance is dependent on the speed of available vehicles. What this means is that there is no point in running a longer route until you have faster vehicles. However, even at 128 KPH (Ginzu) you could run a route ~900 tiles (opposite corners on a 512x512 ) away and make fantastic profits with the current max time factor of 255. The realization is that the profits happen way before the minimum time factor is ever reached. This means that If I want to control huge profits, then the maximum time factor must be reduced as well.

Lets just look at some various route lengths based on a 128 kph ginzu. Assuming 100Kph, = 5.6 tiles per day, then 128 kph = 7.15 tiles per day. If the ideal trip time is half the max time, then the ideal one way is half the max. So if the max time is 255, half that is 127. In 127 days, 910 tiles can be covered.
Max Time 255, Ideal Route 910 tiles. Max Time 127, Ideal route 450 tiles. Max Time 64, Ideal Route 221 Tiles. Max Time 31 days, Ideal route 107 tiles.

So, First the minimum time factor must be changed to zero. Second the maximum time factor must be reduced, however what the ideal value is I am not sure. So I will probably in the next day or so make a patch that exposes these two constants so that they can be tweaked until I can find a value that works well.

I'll post again when I know more.

[MagicBuzz]

I already did an old patch, and I think the new cargo feature should introduce a "perishable" value.

I mean when you look at real life, you see :
- Many good are made in asia, and delivered everywhere in the world. Transportation time, by ship, are like 3 months for europe (10 weeks average for France by exemple).
- Some goods like raw material often do a very long trip, like petrol. Those trips can take many months.
- A passenger that stay in a vehicule for more than 2 days will just become mad.
- Many perishable goods can't be iced, then the travel time must be very fast in order to keep it sellable.

Then when I designed my older patch, I had to enter some arbitrary perishable flags to the different basic cargos. By exemple, iron, coal, oil or wood were not perishable, while food, passengers, mail or fruits were perishable.
Then the income value was just 0 when the perishable flag was true and the travel was longer than the maximum payment cargo rate time, while the no perishable goods were just paid using the same time_factor than the maximum payment rate (the patch just thought the payment became constant).

With the new cargo feature, we can't hardcode this perishable flag, then this kind of patch seems to me absolutely useless until the GRF can't say which cargos can be transported for more than 180 and which ones can't.

[DaleStan]

With the new cargo feature, we can't hardcode this perishable flag, then this kind of patch seems to me absolutely useless until the GRF can say which cargos can be transported for more than 180 and which ones can't.

But the GRF can say. It's called "Callbacks", and through the magic of that callback the issue that patch is trying to solve goes *poof*. Possibly the issue that this one wants to solve too.

[athanasios]

{
[quote="MagicBuzz"]- A passenger that stay in a vehicule for more than 2 days will just become mad.[/quote]
When I was a child I travelled by ship for one month and I didn't get mad. On the contrary, I really enjoyed it!
}

[Tekky]

I also think that the payment calculation is the wrong way to solve the problem. The problem isn't that long lines are more profitable than short ones IMO. The problem is that you can choose to build long ones instead of short ones. Why would a coal mine send its coal halfway across the map if there's a powerplant around the corner? The coal mine should decide were its coal goes, not the player.

I don't think the coal mine should decide which power plants the player should deliver the coal to. The player should make this decision. For example, the player should be able to decide which power plant to deliver the coal to based on his existing infrastructure. However, I do agree that longer routes shouldn't necessarily be more profitable than shorter routes.

The basic question is the following:

When there are two coal power plants on the map and one coal mine, which player behavior should be the most profitable? Should the player deliver most of the coal to the power plant which is closer to the coal mine? Or should the player deliver most of the coal to the further away power plant, in order to be paid more due to the additional travelling distance?

I personally think it would make more sense if the player would first deliver the coal to the closer power plant. Only when the closer power plant is oversupplied and the further away power plant is undersupplied, should it be meaningful for the player to also deliver coal to the further away power plant.

This is my personal opinion. I think industries should not care how far the goods were hauled. The industries should only pay according to their current demand. Therefore, a player's revenue(=income not taking expense into account) is maximized if he delivers to all power plants equally. However, since it costs a player more to deliver to further-away industries, a players profit(=income minus expense) should be maximized if he delivers about 70% of the cargo to the closer industry and 30% of the cargo to the further-away industry.

I have described this solution with mathematical background in this thread. Please note that I am not referring to the first post of the thread, as the person who started the thread is someone else.

This solution is also ideal for multiplayer, because it allows for price wars between competing players, as I have described later in the linked thread.

[MagicBuzz]

IMO, the cargos should have a destination, and that would solve the problem of needlessly long routes.

I might be interresting to merge in the paxdest patch (and not another new patch) a cargodest patch. rules for cargo should be slightly different than the passengers, but similar :
For raw materials (ie. producing industry doesn't accept any cargo), they should be sent with a rule like this : 50% to the nearest accepting industry, 25% to the second, 12% to the third, etc. with an arbitraty minimum of 50 units per month.
For refined materials (producing industry accepts some cargos, and accepting industry produces some cargo), it should be sent 10% to each of the 10 nearest industries.
And finished materials (producing industry accepts some cargo and accepting industry does not produce cargo or is a city) should be sent to any accepting industry/city on the map with a proportional rate according the population in the owner town.

By this way, the player can choose to enable or not the patch, and must build a coherent network in order to feeds industries according some realist pattern. This should have different impacts : trucks become profitable (when 50 units of goods per month need to be delivered to a station, you won't build a train), you will need to share some trains in order to grab different materials from many places, etc.

[wleader]

Ok, I've made the small changes required to make the time factors used in calculating income adjustable. I've been playing around with it for a while, and I have found that changing these values creates a huge difference in difficulty.

I've been playing with the max set to 60, and the minimum set to 0. The difficulty comes in finding the ideal place to deliver a given cargo. Just for an example, I was playing on 1 512x512 map, and when I delivered coal to the nearest power station, it paid 6K, and when it went to a power station half way across the map it paid 22K, but when I sent the train to the far corner of the map it only paid 12K.

With this patch installed its possible to have the original behavior by using the default values of 31 for the minimum and 255 for the maximum, or these values can be adjusted for lots of interesting effects on payment rates.

I'm very curious to get a multi-player game going with this patch running.

[wleader]

To follow up on this, I've been playing with this patch enabled and found out a few things about its effects on game play.

It has had the desired affect on coal mining, in that delivering cargo to a nearer power station can be more profitable than a distant power station. However Slower trains have become practically worthless. The game is near impossible to play before diesels start to appear. Passenger traffic has also become to sensitive to travel time that its near impossible to make a profitable passenger network. Basically the best opportunities for income remain the same. Time insensitive cargo such as coal, ore, oil, and wood are still the best bets, but produce less income.

So I think removing the minimum time factor is still a good thing and I intend to keep that. Reducing the maximum time factor had unexpected side effects and really is not what I would consider a good way to improve game play. So now its time for me to consider alternatives. I think it would make sense to start a new thread for that.

[Tekky]

So now its time for me to consider alternatives. I think it would make sense to start a new thread for that.

As I have already pointed out, such a thread already exists.

By the way, using my proposed system, supplying an industry will always be profitable. The only question is how much you can haul on this route while still staying profitable. However, my proposal doesn't take perishable cargo into account. But I think this is not the most important issue. As I said before, the most important question should be:

When there are two coal power plants on the map and one coal mine, which player behavior should be the most profitable? Should the player deliver most of the coal to the power plant which is closer to the coal mine? Or should the player deliver most of the coal to the further away power plant, in order to be paid more due to the additional travelling distance?

[Jim Starluck]

I've been running this as part of the Russian Community patchpack and it doesn't seem to interact very well with the Daylength Patch.

I started off with the Minimum Time set to 31 and Max Time at 255, which was the apparent default, and a Daylength factor of 10x. I also had it so that the Daylength factor would also affect both running costs and delivery prices, which would in theory adjust the costs and profits so that it wasn't possible to get huge profits for traveilng a great distance at a very "fast" speed.

I quickly found it very hard to turn anything remotely resembling a profit. A coal train carrying 720 tons and traveling a distance of little over a 100 in 6 days earned little more than $15,000. Setting the Daylength to 20 and leaving everything else the same resulted in half the profit, whereas setting Daylength to 1 and leaving everything else the same got me $150,000. For the same amount of coal hauled the same amount of distance.

I know from past experience that the Daylength patch, when both running costs and delivery prices are set to be affected, scales the time factor for payment with the Daylength. If Daylength is set to 10 and you travel 100 tiles, it reduces the time bonus by 1/10th, so that you earn the same amount of cash despite completing the trip in fewer game days.

I'm not entirely sure how the two patches interact, but right now it seems like the game is unplayable with Daylength enabled--profits are too low to get anywhere.



Edit: Fiddling around a bit. With a Daylength factor of 10... reducing the minimum time factor to zero has no apparent effect. Reducing the max time factor to 1 results in a payment of $0. Increasing min time factor results in time playing absolutely no role in the payment, but it only goes up to $20,000.

With no Daylength factor and a min time factor of 255, the profit for the run goes above $200,000.



Edit again: Nevermind, it seems to be a purely Daylength issue. >.<

[Savormix]

If memory serves right, in original TT (only one type of map — 256x256) after I built a huge line (diagonally) from one corner of the map (forest) to another corner of the map (sawmill) using monorail (best&fastest possible in TT) and after it arrived, I got... a huge payoff instead of any income.