Cargo payment graph - fixed speed instead of fixed distance.

[ebik]

I tried to get know what is the optimal distance for maximizing profit for cargo. So I modified graph of transfer payment rates, to show prices for days of delivery AT FIXED SPEED. -> The peak of the curve gives optimum days of delivery - optimum distance is that the goods is transported exactly the optimal number of days.

Here are screenshots and patch.

Btw. there is overflow "bug" in prototype of GetTransportedGoodsIncome, as number of days can be bigger than 255*5/3 which is about year and half. (You can have slow trains on big map, that are delivering cargo for that time...).

[hertogjan]

Are you sure that the graphs are equivalent for any speed? I mean, you draw the graph for 20 squares per day, but if you draw the graph for a different speed (e.g. 5 sq/day or 50 sq/day) will the graphs be the same?

[ebik]

Are you sure that the graphs are equivalent for any speed? I mean, you draw the graph for 20 squares per day, but if you draw the graph for a different speed (e.g. 5 sq/day or 50 sq/day) will the graphs be the same?

Yes I am, I read the code. But is also intuitive: on original graph is payment for 20 squares and 10 units of cargo. This get MULTIPLIED if either distance or number of units are multiplied. (I.e. twice more units - twice more mony, but also twice more squares - twice more money!)

[MeusH]

This must be 3D rendered or done other way to show clearly relations between distance, time and money.

Here is a quick mock-up of a pseudo 3D graph. Treat colour as the third dimension, as the 3D graph rendering software is still downloading.

[ebik]

So the current equation is:
income = time_coeficient * distance * units.

but distance = time * speed, then you have

income = time_coeficient * time * speed * units

But speed of train is always same - it does not depend on time, (units as well), so the speed * units part of equation is dependent only on your vehicle (not on time), so it has no influence on the shape of graph.

On the other hand time_coeficient * time is the function that depends ONLY on time, so it gives the same shape of the curve for different speeds and different numbers of units. (note that distance is not constant, but it is calculated from speed and time)

This holds provided that you deliver cargo at fixed speed. I.e., you should be able to deliver cargo at double distance when you have double time. This is not exactly true (waiting times at stations) but for 120 days it is near.

[Patchman]

However, the time_coefficient also depends on time, and therefore on the speed you choose. For 100 squares at 20 sq/day (fast aircraft) you'd get the 5-day coefficient, at 5 sq/day (train) the 20-day coefficient and at 1 sq/day (ship) the 100-day coefficient.

Instead of "income = time_coefficient * time * speed * units"

income = time_coefficient[distance/speed] * time * speed * units

So just saying "at constant speed" isn't enough, the relative shape of the curves also changes depending on which constant speed you choose.

(Also please don't use the yellow colour, it's all but unreadable in the subsilver theme.)

[ebik]

However, the time_coefficient also depends on time, and therefore on the speed you choose. For 100 squares at 20 sq/day (fast aircraft) you'd get the 5-day coefficient, at 5 sq/day (train) the 20-day coefficient and at 1 sq/day (ship) the 100-day coefficient.

Instead of "income = time_coeficient * time * speed * units"

income = time_coeficient[distance/speed] * time * speed * units

So just saying "at constant speed" isn't enough, the relative shape of the curves also changes depending on which constant speed you choose.

(Also please don't use the yellow colour, it's all but unreadable in the subsilver theme.)

NO! The thing you are missing is that distance IS NOT constant in the second graph! For 10 days and 20sq/day I get 200 squares for aircraft and for 5sq/day I get 50 squares for train. ([EDIT] And it is not surprising, that this distance will give 10 days for both.)

The distance is the thing that you should calculate so the delivery time will be optimal.

[Born Acorn]

Can you please refrain from using yellow? It is very hard to read on subsilver.

[ebik]

Ok, once again, to make it clear. time_coeficient of course depends on time, but in second graph we have fixed speed, we have time on x-axis and distance is calculated as [time*speed]. So whenever there is distance in our equations we should substitute it with the [time*speed] term. This is the way how I use "constant speed".

The thing that is most interresting for player is, for given speed what is the best distance. But shape of curves in such graph will be dependent on speed. I think that this will be complicated, as the user should choose the speed somewhere to get correct graph. So I choosed to draw graph that depends on time instead of distance. Then the shapes of curves are same for different speeds, only the scale will depend on capacity and speed of the vehicle. But now for different vehicles the same time value means different distance. But user can easily try how far his vehicle, which he choosed before, goes in let's say 120 days (which is like optimal for passengers, livestock, etc.).

And now more game economy theory:

The number [capacity*real_speed/yrly_cost] gives profitablility of vehicle. You should ever choose vehicle with this number as large as possible.

(real_speed is in squares per day, not in km/h! (300km/h aircraft is much slower real_speed than 300km/h train in openttd))

You choose always this vehicle (it may be different vehicle for different cargo type). Then you design route, so the cargo will be delivered for the optimal number of days (peak in the second graph), this includes finding (or building) industry that accepts considered cargo at distance that optimizes the delivery time (I don't know if distance is counted by route of vehicle or by distance by air). Then you will look at monthly production and buy [production/vehicle_capacity*optimal_time_in_months] vehicles and then you cannot profit on this particular industry more.

The only exeption is if your industry generates to few units, so your vehicle waits too long in your loading station. You should choose vehicle that will wait for production only a short time, so let's say a half of month for passengers, livestock etc, or one month for coal, oil, etc. If your vehicle waits more, then its running cost must be much lower than of vehicles of same capacity that wait shorter time, because its income will be lowered for the delay.

[ebik]

Can you please refrain from using yellow? It is very hard to read on subsilver.

Okay, I'll edit it.
[EDIT] Done.

[dev|ant]

ebik, I like what you've done so far. To finish it off though, I think you need to make the speed that is used to generate the graph adjustable by the user. That way, after putting in the speed of the vehicle that the user wants to use to transport a particular cargo, they can see the optimal distance they need to cover to maximise profit.

If people can't be bothered counting how many squares a vehicle travels in a particular time period, they can enter the speed in km/h (or whatever their local unit of distance is), and then select whether the vehicle is a train, plane, ship, etc. Then you've got all the data necessary to construct the graph for that particular vehicle.

[ebik]

ebik, I like what you've done so far. To finish it off though, I think you need to make the speed that is used to generate the graph adjustable by the user. That way, after putting in the speed of the vehicle that the user wants to use to transport a particular cargo, they can see the optimal distance they need to cover to maximise profit.

If people can't be bothered counting how many squares a vehicle travels in a particular time period, they can enter the speed in km/h (or whatever their local unit of distance is), and then select whether the vehicle is a train, plane, ship, etc. Then you've got all the data necessary to construct the graph for that particular vehicle.

Yes, but I'm lazy to write the GUI for entering such data.... (And now I can easily check route optimality by watching one train). So I will not do this.

[hertogjan]

However, the time_coefficient also depends on time, and therefore on the speed you choose. For 100 squares at 20 sq/day (fast aircraft) you'd get the 5-day coefficient, at 5 sq/day (train) the 20-day coefficient and at 1 sq/day (ship) the 100-day coefficient.

Instead of "income = time_coefficient * time * speed * units"

income = time_coefficient[distance/speed] * time * speed * units

So just saying "at constant speed" isn't enough, the relative shape of the curves also changes depending on which constant speed you choose.

(Also please don't use the yellow colour, it's all but unreadable in the subsilver theme.)

It seems that the shape of the curves doesn't change when changing the speed.
The function that is used is as follows:

Code: Select all

income = distance * f[time] * units * unitprice

Here f[time] is a time dependent multiplication factor. For times small enough (cargotype dependent), f is linearly decreasing in time. For large times, it is constant.
The horizontal axis of the graph is the time in the cargo is in transit. The original graph shows the income for 10 units over a distance of 20 squares. In formula form:

Code: Select all

income[time] = 20 * f[time] * 10 * unitprice

The patch shows it as follows:

Code: Select all

income[time] = (speed * time) * f[time] * 10 * unitprice

This function is linear in speed, hence the shape of the graph does not depend on speed.

If you would have squares travelled on the x-axis, it will be more complicated:

Code: Select all

income[distance] = distance * f[distance/speed] * 10 * unitprice

This is not linear in speed. So the shape of this graph would depend on the speed.
However, assuming that f[time] is linearly decreasing in time (f[time] = b - a * time), the optimal distance x_opt and optimal time t_opt are given (and related) by

Code: Select all

x_opt = b * speed / 2a
t_opt = b * speed / (2a * speed)
x_opt = speed * t_opt

Hence, you don't need the distance-dependent function to know where the optimal distance is. Just find the optimal transit time and multiply it by the speed.

This was the reason I asked whether the shown graphs are well-defined. The one from the patch surely is, but if you change the x-axis to a different parameter it isn't. At least, the time dependent multiplication factor makes the problem nontrivial.

[csuke]

all this seems rather pointless when what the graph needs to show is train speed vs optimal distance, so that you can look at the bottom of the graph, find the point on the left and so you know how long the ditance for the train to travel is

[ebik]

all this seems rather pointless when what the graph needs to show is train speed vs optimal distance, so that you can look at the bottom of the graph, find the point on the left and so you know how long the ditance for the train to travel is

That is GOOD idea, I will think about it and may be I'll implement this. It will show ONLY the optimal distance curve depending on speed for each cargo type. The only problem will be that speed coeficients (km/h to tiles/day) differ for different vehicle types. But there are not so many vehicle types (I think there are exactly four: road, rail, planes, ships). So the coeficients can be written in legend or number on x-axis will change as user will click on buttons...

But this means not I'll throw away my graph, because from my graph you can read how much you can be off compared to optimal route.

P.S. for csuke: I like what you designed in #openttdcoop-sandbox, and now this idea..., I think you are clever man.

[csuke]

i didnt design that station, merely copied it, all credit goes to xahodo

[ebik]

i didnt design that station, merely copied it, all credit goes to xahodo

Yes, but there is also your 'load balancer', at south edge. I know you need AND presignals there, but they can be emulated (It will cost lot of space, but it will work, and the 'choice tracks' will be short as they are in your design. That is good I think...)

[Syranide]

This should really be added to the OpenTTD release, I have never really understood the point of the default cargo payment graph as it is next to impossible to interpret and you get no sense for how long things should be freighted.

Having a clear time to payment rate is really superb, the time for vehicles to get there can be handcalculated, estimated or just taken from intuition, but at least now you can see what's going to happen. Additionally it does not alter functionality, only extend.

[bulb]

There is one thing to remember about these graphs, though. They show the return for given amount of cargo being in transport given number of days. However the vehicle transporting it also has a running cost and you have to subtract it to get the profit.

The running cost is a linear function of time, so it will eventually outgrow the return. This makes the optimal distnace shorter. I would take some calculation to estimate how significantly, but I suspect quite a lot.

[ebik]

There is one thing to remember about these graphs, though. They show the return for given amount of cargo being in transport given number of days. However the vehicle transporting it also has a running cost and you have to subtract it to get the profit.

The running cost is a linear function of time, so it will eventually outgrow the return. This makes the optimal distnace shorter. I would take some calculation to estimate how significantly, but I suspect quite a lot.

Yes but you have to divide running cost of vehicle by its capacity.
Typical no. of cars in train differ, e.g. I use 6 cars for one Lev4 engine,
so it has reasonable acceleration.

And there is also other problem, I did not try to estimate the influence of
staying in station for load. In fact, this may add few days to delivery time,
making the average increasing with the time. This will make the optimal
distance slightly larger.