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

Change cargo age to have more effect on cargo payment. #9002

wants to merge 3 commits into
base: master
Choose a base branch


Copy link

@michicc michicc commented Apr 10, 2021

Or: Make transfer networks suck.
Or: How to break cargo ageing and cargodist in one go.

Motivation / Problem

There's lot of talk about cargo ageing, profitability and strange cargo curves. We should try our hardest to make sure routes fail to be profitable.

Cargo profit depends on distance and time taken until delivery. There's a hard limit for the time taken, which means each cargo has a point from which on time (and thus vehicle speed) don't matter anymore. Further away means more profit then, not matter if horse or Concorde. Cargo also doesn't care about being stored for hundreds of years in transfer stations before delivery.


Increase age range of cargo packets. Age in-transit cargo at stations. Add a fourth time range to profit calculations that asymptotically approaches zero.

Cargo that is in-transit (i.e. has an age > 0) will be aged in stations. Default ticks before ageing is 740, except pax/mail which are aged every 370 ticks. A NewGRF cargo prop is provided to modify the rate.

On profit calculation, if the time factor was previously clamped to 31, it will now continue with a scaled 1/(x+1) function asymptotically to zero with 4 bits of fixed point precision.



Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

@michicc michicc changed the title How to break cargo ageing and cargodist in one go. Change cargo age to have more effect on cargo payment. Apr 10, 2021
@michicc michicc force-pushed the pr/crackpot_cargo_age branch from eff2ddc to ac58f2d Compare Apr 10, 2021
src/cargotype.cpp Outdated Show resolved Hide resolved
@michicc michicc added candidate: needs considering preview labels Apr 10, 2021
@DorpsGek DorpsGek temporarily deployed to preview-pr-9002 Apr 10, 2021 Inactive
Copy link

@ldpl ldpl commented Apr 10, 2021

Is this a troll or are you actually serious? If it's the latter can you please state what's the actual problem and how is this all suposed to solve it and how does it change the established game economy? I wasn't able to follow chat last week and so far it looks to me like "let's break the game for no fucking reason" PR.

Copy link
Member Author

@michicc michicc commented Apr 10, 2021

The agreed wisdom seems to be that after some point, transport time doesn't matter anymore for cargo profit. Whether this is a problem or not is very much open to debate, but at least for this PR I'm treating it as one.

And it is semi-serious. I didn't add any setting because then most players would never see it, but at the same time it would probably seriously mess up any existing cargodist/transfer game.

@michicc michicc force-pushed the pr/crackpot_cargo_age branch from ac58f2d to 998c998 Compare Apr 10, 2021
@DorpsGek DorpsGek temporarily deployed to preview-pr-9002 Apr 10, 2021 Inactive
Copy link

@JGRennison JGRennison commented Apr 10, 2021

This looks like two separate features really:

  • Ageing cargo in stations
  • Raising the limit on cargo age + profit calculation changes

The former is quite a significant gameplay change and is likely to have a non-trivial impact when cargodist is used (i.e. big pax/mail networks). (This is not an objection, just to be clear).
If we're going to add this penalty for cargo waiting in stations, can we ditch something else to compensate? The mysterious vanishing cargo syndrome or much of the silliness around station ratings just to get cargo into the station in the first place, perhaps? ;)

I notice that passengers and mail age more quickly in stations than other cargoes. Passengers and mail don't age more quickly in actual vehicles though. It seems odd to do one but not the other.
Also, why not valuables/diamonds? Why not make coal age extra slowly, etc. etc.

Presumably the actual per-cargo curve time constants should encapsulate the difference between cargoes?

Copy link
Member Author

@michicc michicc commented Apr 10, 2021

There's a reason its marked as draft, so don't take this as gospel.

I only gave pax and mail a different value than the default one because those two are most likely™️ not redefined by NewGRFs. Proper backwards compatibility would be to default to 0 (no ageing), but I dislike doing work 98% of the players will never get to see.

I do think the station ageing only makes sense with the first change, as otherwise it just means average cargo payment will tend to be even more stuck at the "time doesn't matter anymore" end. This would make even stronger incentive to completely ignore travel time.

Copy link

@andythenorth andythenorth commented Apr 10, 2021

I only gave pax and mail a different value than the default one because those two are most likely™️ not redefined by NewGRFs.

I have news on this front 😉

For some reason FIRS has been redefining pax and mail payments and curves since maybe 2012 or older (I'm not sure how different the curve really is).

I discovered (re-discovered?) this fact recently, it gives rise to some 'interesting' vehicle set balancing problems👻

EDIT: probably not relevant here :)

Copy link
Member Author

@michicc michicc commented Apr 10, 2021

NewGRF configurable max and min time factors, you can do stuff like this with it (axes are payment over time):


Copy link

@2TallTyler 2TallTyler commented Apr 11, 2021

I suspect many industry sets define passengers and mail simply to follow FIRS. I know mine does, simply copying payment rates and even graph colours.

Copy link
Member Author

@michicc michicc commented Apr 11, 2021

I suspect many industry sets define passengers and mail simply to follow FIRS.

I didn't mean just changing some cargo parameters, I meant reusing the cargo slot for something else, because I don't want any older NewGRF to suddenly inherit some strange ageing factor from a predefined cargo. Assuming that pax/mail are not redefined in another slot is probably a sane assumption.

Copy link

@andythenorth andythenorth commented Apr 11, 2021

Assuming that pax/mail are not redefined in another slot is probably a sane assumption.


Not doing so breaks houses quite unpleasantly 😉

I do have a semi-serious suggestion to remove pax from FIRS and do industry-only gameplay, but I don't think it's viable.

Copy link

@LC-Zorg LC-Zorg commented Apr 13, 2021

Make transfer networks suck.

I don't see anything good in this PR. I could repeat what Idpl wrote in the first sentence and that wouldn't be a question. I also find the last sentence quite velvety. But ok, let's say there's a problem with the transfer.

So I did a test to present the effects of such a solution (in ordinary OTTD 1.11.0).


  • Three different methods of making the same connection (average time of travel is 120 days on the main intercity route)
  • Company A (green): A-B direct link
  • Company B (yellow): connection with transfer at both ends (intercity line + public transport)
  • Company C (red): same as company B, but at stations cargoes are aging (additional connection)
  • the length of the additional connection can control the aging of cargoes at the station
  • FIRS 1 used due to constant station rating.
  • For simplicity, the connection is unidirectional

Transfer   Cargo ageing on station graph

Station Cargo Ageing


  • Direct connections have always been the most profitable (green vs. yellow)
  • With the addition of cargo aging at stations, the primitive A-B connections gained an even greater advantage
  • Building extensive and complex passenger transport networks never made economic sense - players who intuitively tried to build realistic extensive networks that should increase their income, only lost. Their incomes have always been much lower than those of who used flawed game mechanics to build primitive and meaningless A-B connections.
  • After adding cargo aging at stations, building extensive networks will be even more unprofitable. The more extensive the network is, the worse the results will be.
  • In simulation, the transfer is in a favorable direction. If it were otherwise, as sometimes required by the map layout, the differences would be even greater. Obviously in favor of the primitive A-B connections.
  • If a player allows for free, unguided flow of passengers, fewer of them will travel in the most favorable direction - again the advantage of primitivism grows.

In brief:

  • This PR destroys the sense of building extensive and complex transport networks
  • A-B flights will be even more OP
  • Big maps will be even more pointless
  • The game will reward those players who can do nothing and punish those who are trying to build something interesting.

There are three problems that this PR refers:

  1. Multiple vehicle negative income when transfer / cargodist is used
  2. Unprofitability of building complex communication networks - the more connections a company offers, the worse its earnings
  3. Lack of economic sense to build long connections on large maps

This PR does not solve any of these problems. Its only magnifies them.

Copy link

@LEB0VSKI LEB0VSKI commented Oct 23, 2021

what about the passengers?

Copy link

@odisseus odisseus commented Nov 10, 2021

I agree that the delivery rewards can't and shouldn't be realistic, and that the players shouldn't be penalized for building complex networks. However, clamping the cargo age doesn't reward such networks — it only rewards length.

AFAIK the cargo age clamp was implemented back in the day when maps used to be rather small by today's measure, and any vehicle could almost certainly cross any map in less than 255 days. Removing the clamp would not break transfer networks; it would just bring back the original intent behind the reward calculation.

Copy link

@2TallTyler 2TallTyler commented Nov 13, 2021

Can the station aging rate be disabled entirely by NewGRF by some special value? The easy way to add this without breaking savegames would be for vanilla cargos to not age in stations, but allow NewGRF authors to use the new feature. I would certainly experiment with it!

Copy link

@ldpl ldpl commented Nov 14, 2021

I guess now that PR looks semi-decent it can be discussed semi-seriously.

First of all, I see 3 completely unrelated commits that should be separated into 3 PRs and discussed separately IMO. But since it is what it is I'll just go over each of them here.

  1. Unclamping the minimal time factor. First of all, you seem to have completely missed the case where it hits the minimum between days1 and days1+days2, so that needs to be handled (with a slightly different transition function to smooth it out). Second, that clamping is clearly intentional so it would be nice to figure out the reason why it was added in the first place before throwing it out. My guess is that it was added to make big mistakes like traffic jams and lost trains less punishing (especially with breakdowns). And to encourage players to actually solve those and get trains to their destination rather than selling everything in place. It can also help new players that just built their first train and spent an eternity getting it to the destination to not get out of business immediately. So while it's irrelevant for experienced players it may be important for new players. Though it clearly needs to be adjusted by the map size if it is to stay. Anyway, it's been a long time since I was a new player so I don't find that reason particularly important and would like to see the clamping gone. Also, I added the new formula (with fixes) to the profit calculator if anyone wants to see its effect on the economy:
    Screenshot from 2021-11-14 03-55-32

  2. Ageing on stations. Very bad change IMO. There is already a dedicated cargo decaying mechanic for stations so adding this would make it a double decay which makes no sense from neither realism nor gameplay perspective. It also specifically penalizes complex networks with transfers that already lose to point-to-point routes and definitely don't need any further nerfing. It's so bad that I don't even think it deserves to be included as a newgrf option with all the incurred maintenance costs. Anyone who still wants to experiment with station aging can do that with this PR.

  3. Exposing mix/max time factors to newgrfs. Absolutely useless change, especially so after the effective elimination of min factor cap in (1). Scaling of prices can already be achieved by base payment rate and slightly expanding the available range for moving payment chart points is hardly useful as it's good enough already and, if anything, should depend on the map size and game goal rather than being a static property of the cargo.


This comment has been minimized.


This comment was marked as disruptive content.

Copy link

@2TallTyler 2TallTyler commented Nov 15, 2021

I think station cargo aging would make a lot more sense if we had true CargoDest where a larger network (almost certainly with transfers) allowed a company to capture more cargo. But with CargoDist, this discourages a true network to incentivize point-to-point routes, as Rau and others correctly pointed out.

Copy link

@odisseus odisseus commented Nov 16, 2021

My guess is that [cargo age clamping] was added to make big mistakes like traffic jams and lost trains less punishing (especially with breakdowns). And to encourage players to actually solve those and get trains to their destination rather than selling everything in place.

That's a good point, though I'm not sure it outweighs the opportunity for abusing the reward system. Any system that accounts for distance in a linear fashion but ignores time after some point can be gamed by building a sufficiently long route. With the current system, this happens at about 2000–3000 tiles for slow vehicles and perishable cargoes, which definitely fits into modern maps.


This comment was marked as disruptive content.

Copy link

@LC-Zorg LC-Zorg commented Nov 19, 2021

I believe that considering any change requires looking not only to see if it is true to reality, but also to consider how it will affect gameplay. Yes, you could say that this proposition is logical and it follows what is happening in reality. The problem is that this solution will not work at all in this game. Sometimes it is even so that seemingly contradictory solutions give the best and... the most realistic results. An example of such a seemingly pointless solution can be the setting used on the Polish map server, where electric trains are much more expensive to maintain than diesel ones. When looked at in point, it probably has nothing to do with the facts and is a contradiction of reality. However, looking at it more broadly and covering the entire economy of this game, the end result is very close to reality. Previously, before this change the construction of an electric railroad was the only sensible solution and if someone built a diesel railway, it was only for sentimental reasons or because he doesn't know the economy of the game. Raising the costs of building traction or buying electric locomotives did not make sense, because for most players these prices ceased to be of any importance over time. A change in the infrastructure maintenance costs would also not have an appropriate effect, because paradoxically it would turn out that electification would be most profitable on short, side routes, and on the main ones it is better to leave the diesel rail, which is completely opposite to the reality, where the main ones are mostly improved. Meanwhile, the increased maintenance costs of the electric locomotives themselves mean that the player avoids using them on short routes, where costs are the most important, but already on main routes, where the power of the locomotives plays a large role in maintaining traffic flow, there electric locomotives are most used. Thus, something theoretically illogical can actually be the solution for this game, giving the most realistic and playable effects at the same time.

The same is true of FIRS, where, after delivering 100 tons of all the necessary raw materials, factories can produce up to 300 tons of the product. It seemingly makes no sense, but thanks to this, the player has the motivation to build and develop really interesting supply networks. This "lack of logic" makes this set so good and addictive.

Just when considering any change, it's necessary to look at what the actual end result will be. In the case of this proposal, it would be unequivocally bad or even more than bad.

With CargoDest, the aging of cargo at stations would be even more burdensome and discouraging. Building a network would be even more economically pointless and players would focus on building the simplest possible connections. Over time, bored with the lack of sense in building anything bigger and complex, they would simply quit the game.

The only thing worth noting here is the extension of the period of decline in rates, but certainly not in the way it was presented. The rates cannot drop to zero or almost zero, because this will mean that transport over longer distances, and especially in games starting in the 19th century, will only generate losses. The problem is also that the player does not see what is happening with the rates after the 200th day - he will not know that the transport can not take too long. Even if he did, he wouldn't always be able to judge how long the road would actually take. Even experienced players often cannot do that.
So if this decline in rates in the final period were to be extended, then this shift should be a plus, not a minus. Then long-distance transports and large maps will still make sense, and at the same time it will still be profitable to buy better, faster vehicles on these routes - probably that's what PR is all about, right?

Copy link

@odisseus odisseus commented Nov 30, 2021

The simplest possible connections always have been the most efficient from an economical point of view. This follows from the fact that the delivery reward grows with distance. Given the same distance and time, it is always better to build a simpler connection and save on maintenance costs.

(The Industries of the Caribbean add-on is an interesting subversion of this rule. It features a socialist planned economy, in which payment rates are negative for all cargoes except the export goods.)

Yes, tweaking the payment rates in the proposed way would mean that slow transport over longer distances will only generate losses. I think that's a good thing, and coincidentally this is also realistic: e. g. international travel had been a luxury for the most part of 19th century.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
candidate: needs considering preview
None yet

Successfully merging this pull request may close these issues.

None yet