Feature: Measure vehicle capacity utilisation efficiency #7353
Conversation
|
This pull request has been automatically marked as stale because it has not had any activity in the last month. |
|
I don't think this should sink. It could be a nice goal for players and highscores / goals. It also gives increased purpose to versatile, refittable vehicles / wagons. |
|
Here's a rebase to current master for now. I think I'll take out the company rating stuff for now and just make the efficiency measurement something you can view and sort by, but not affecting the scoring. I'll rather address company ratings in a separate patch that could then also add GS custom ratings. |
That sounds actually like a good plan. It's two different things. |
|
Should penalty for waiting for load (without receiving cargo) and penalty for waiting at signals (and maybe also whatever road vehicles can wait at) be controlled by separate settings? |
|
I'm not entirely happy with the group GUI yet. The extra lines in the group statistics (lower left) makes the window sizing somewhat awkward, and the extra text in the per-vehicle statistics makes the lines very long and may often clip. |
|
I'm marking this ready for review as I believe it's feature complete and basically correct. I'm still unsure about several of the GUI changes, and there may be some balancing required on the penalty for waiting. |
nielsmh
force-pushed
the
cargotiles
branch
3 times, most recently
from
28a2c33 to
c7e772f
Compare
|
This should address all the points. I intend to clean up all the small commits later, leaving them in for now for review purposes. |
|
I'm not sure if this should be merged before 1.10 branches. My original idea with this was to also change the performance rating calculation so the (often impossible) "all vehicles have >£10k profit" item could be replaced with something like "all vehicles have >40% efficiency", but I removed the performance rating change from the branch again. The new plan is to make a GS interface for performance rating overrides instead, and I think this PR is not quite worth releasing without also having GS performance ratings. (And I haven't gone much further than ideas stage for that part.) |
|
Rebase needed |
TrueBrain
added
candidate: yes
This is calculated as the ratio of "ton-miles delivered" over "ton-miles travelled". The former is calculated as amount of cargo delivered multiplied by Manhattan-distance between pick-up and delivery station, and the latter is total cargo capacity multiplied by actual distance driven. This rating favours vehicles running at close to capacity, with more direct (less winding) routes.
TrueBrain
force-pushed
the
cargotiles
branch
from
39f357c to
1054c91
Compare
|
I found a funny issue, I think: if a vehicle takes more than a year to do a round-trip, the values get non-useful. For example, I have a train with 300% efficiency! And the next year 0%. I need some more thinking about this myself, but just wanted to leave it here. I did rebase this PR, but it was not as clean as I would like, so I had to modify some things .. hopefully I did it correct :D |
TrueBrain
added
the
work: needs more work
|
Test save attached for demo purposes. Only uses grfs from bananas. |
| @@ -493,6 +493,7 @@ struct EconomySettings { | |||
| uint16 town_noise_population[3]; ///< population to base decision on noise evaluation (@see town_council_tolerance) | |||
| bool allow_town_level_crossings; ///< towns are allowed to build level crossings | |||
| bool infrastructure_maintenance; ///< enable monthly maintenance fee for owner infrastructure | |||
| uint8 idle_loading_ct_penalty; ///< cargotiles penalty factor (in 1/4 steps) for vehicles loading and not receiving goods | |||
There was a problem hiding this comment.
What does this setting do exactly? It isn't really clear to me from the context of this PR.
In general, I would rather avoid we add settings like this, as it is more explaining to users, while they are often not in a real position to make a call on them. Maybe we should just pick for them?
| @@ -3503,6 +3517,9 @@ STR_GROUP_PROFIT_THIS_YEAR :Profit this yea | |||
| STR_GROUP_PROFIT_LAST_YEAR :Profit last year: | |||
| STR_GROUP_OCCUPANCY :Current usage: | |||
| STR_GROUP_OCCUPANCY_VALUE :{NUM}% | |||
| STR_GROUP_EFFICIENCY_THIS_YEAR :Efficiency this year: | |||
| STR_GROUP_EFFICIENCY_LAST_YEAR :Efficiency last year: | |||
There was a problem hiding this comment.
We should do better, in-game, explaining what this number actually means. Via a tooltip for example. Efficiency can be read in so many ways.
|
I was toying with this PR a bit, as I noticed I find it a bit hard to explain what "efficiency" means, in-game. So I wrote an alternative to this (it is in very rough shape, and only busses are tested. But basically, it tracks how much a vehicle is utilized, as in, if it was in a state that was productive (moving, loading, etc. Not blocked by other vehicles, in a depot, etc)): master...TrueBrain:OpenTTD:vehicle-utilization Image for context (more blue-days are better, more red-days is bad; this is a vehicle doing terrible): The choice I make here is to define utilization of the vehicle, where this PR defines it more the utilization of the line the vehicle is serving. And then it clicked why I find it hard to explain what it means. Basically, most of our vehicle statistics are about the vehicle itself. How much profit did he make. How reliable is it. How much cargo goes into it. But when we talk about utilization / efficiency etc, it becomes a bit more tricky, I think. In my approach, I basically say: as long as the vehicle is in movement, that is a good thing. Empty, full, towards the destination or not, it all doesn't matter. You are utilizing your equipment, good on you. And although there is value in such statistics, it isn't as useful as it could be. Sure, it allows you to see if your vehicles are waiting on cargo for too long, or are blocked by other vehicles / signals, etc. But it doesn't actually tell you anything about the line it is serving. And that brings me to this PR. It is telling much more how the line the vehicle is serving is doing. Which means it rightfully takes into account how much cargo fits in the vehicle, and how much cargo got delivered, etc. It also means for cargo trains it will always be < 50%, as you are going back empty. Which is perfectly fine. But that brings me to the essence of my reply: this doesn't work (I think) on a per-vehicle level. What we kinda need for this first, is line-management. #9551 collects how different games do it. But you kinda want to define a line (I want to move cargo from A to B, much like our current order dialog), and then you want to assign vehicles to the line. This PR would be a perfect statistic for the line. And my attempt would be kinda good for a single vehicle. So although I really would like to see such metric in the game, I am not sure the game is ready for it at this stage. It feels we need to do more work first, to get to a point it actually makes sense and is easily explainable to the user. I still absolutely love the idea. As for my attempt, the vehicle movement code is just way too flaky to actually make sure all transitions are encountered for. I don't think it will be a success. But maybe it sparks ideas. |
Measure the capacity utilisation efficiency of vehicles by measuring the actual distance traveled, and multiplying by capacity. When deliveries are made, accumulate the cargo-distance delivered. (Distance delivered is the Manhattan-distance between source and destination.) Dividing cargo-distance delivered over capacity-distance traveled gives a utilisation efficiency.
A vehicle traveling full everywhere, by the shortest possible route, would have (near) 100% efficiency, while a vehicle traveling empty half the time (e.g. minerals train from mine to smelter) and going by a winding route might only hit 30% efficiency.
Vehicles waiting for their turn to load cargo are also counted as wasting potential capacity.
Overall the intention of this patch is to calculate a figure that might better indicate the economic viability of a vehicle than the simple profit-last-year figure. ("Is this vehicle actually doing something useful?") Part of the intention is as an alternative to the "false" profit sharing algorithm for feeder routes, especially the large negative profits it can apply to e.g. buses making the last leg from a long-haul air route, despite the buses actually being vital.
In addition to this (and this part should probably at the very least be split into a separate commit), the patch adds a new element to the company performance rating calculation, but with a switch so the performance rating uses either lowest vehicle profit, or lowest vehicle efficiency, as a measure for the rating, but not both.
To do: