Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Measure vehicle capacity utilisation efficiency #7353

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Mar 9, 2019

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.

image

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:

  • Calculate cargo distance delivered on unload
  • Calculate tiles traveled as vehicles move
  • Add penalty tiles traveled when vehicles are idle loading
  • Add penalty tiles traveled when vehicles are waiting at signals/other
  • Show total efficiency per vehicle group
  • Make data available to GS and AI

@stale
Copy link

stale bot commented Apr 10, 2019

This pull request has been automatically marked as stale because it has not had any activity in the last month.
Please feel free to give a status update now, ping for review, or re-open when it's ready.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Apr 10, 2019
@planetmaker
Copy link
Contributor

planetmaker commented Apr 10, 2019

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.

@stale stale bot removed the stale Stale issues label Apr 10, 2019
@nielsmh
Copy link
Contributor Author

nielsmh commented Apr 10, 2019

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.

@planetmaker
Copy link
Contributor

planetmaker commented Apr 10, 2019

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.

src/lang/english.txt Show resolved Hide resolved
src/saveload/afterload.cpp Outdated Show resolved Hide resolved
src/vehicle_base.h Outdated Show resolved Hide resolved
@nielsmh
Copy link
Contributor Author

nielsmh commented Apr 11, 2019

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?

@nielsmh
Copy link
Contributor Author

nielsmh commented Apr 27, 2019

I'm not entirely happy with the group GUI yet.

image

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.

@nielsmh
Copy link
Contributor Author

nielsmh commented Jul 14, 2019

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.
The commit history also needs some squashing.

src/group_gui.cpp Outdated Show resolved Hide resolved
src/economy.cpp Show resolved Hide resolved
src/saveload/afterload.cpp Outdated Show resolved Hide resolved
src/script/api/script_group.cpp Outdated Show resolved Hide resolved
src/script/api/script_group.cpp Outdated Show resolved Hide resolved
src/vehicle_base.h Show resolved Hide resolved
src/vehicle.cpp Outdated Show resolved Hide resolved
src/vehicle.cpp Outdated Show resolved Hide resolved
src/vehicle_base.h Outdated Show resolved Hide resolved
src/vehicle.cpp Outdated Show resolved Hide resolved
@nielsmh
Copy link
Contributor Author

nielsmh commented Nov 30, 2019

This should address all the points. I intend to clean up all the small commits later, leaving them in for now for review purposes.

@nielsmh nielsmh dismissed LordAro’s stale review December 23, 2019 12:18

All points addressed

LordAro
LordAro previously approved these changes Dec 23, 2019
@nielsmh
Copy link
Contributor Author

nielsmh commented Dec 23, 2019

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.)

@LordAro LordAro added this to the 1.11.0 milestone Dec 23, 2019
@LordAro LordAro added the stale Stale issues label Sep 24, 2020
@LordAro
Copy link
Member

LordAro commented Sep 24, 2020

Rebase needed

@TrueBrain TrueBrain added candidate: yes This Pull Request is a candidate for being merged size: large This Pull Request is large in size; review will take a while and removed stale Stale issues labels Dec 14, 2020
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
Copy link
Member

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%.
This made me wonder, shouldn't this be a sliding window instead, or something? As measuring efficiency per year .. 1st of January it is now always zero for all vehicles. This feels counter-intuitive.

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 TrueBrain added the preview This PR is receiving preview builds label Dec 22, 2020
@DorpsGek DorpsGek temporarily deployed to preview-pr-7353 December 22, 2020 16:16 Inactive
@TrueBrain TrueBrain added the work: needs more work This Pull Request needs more work before it can be accepted label Dec 22, 2020
@andythenorth
Copy link
Contributor

Test save attached for demo purposes. Only uses grfs from bananas.

7353 Transport.sav.zip

@TrueBrain TrueBrain removed this from the 1.11.0 milestone Jan 5, 2021
@TrueBrain TrueBrain removed the preview This PR is receiving preview builds label Jul 8, 2023
@@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@TrueBrain
Copy link
Member

TrueBrain commented Sep 14, 2023

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):
image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
candidate: yes This Pull Request is a candidate for being merged size: large This Pull Request is large in size; review will take a while work: needs more work This Pull Request needs more work before it can be accepted
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants