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

(Re)consider subsidies should work under cargo-dist #5766

Closed
DorpsGek opened this issue Sep 26, 2013 · 14 comments
Closed

(Re)consider subsidies should work under cargo-dist #5766

DorpsGek opened this issue Sep 26, 2013 · 14 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

Milsa opened the ticket and wrote:

I have passengers from Rimavska Sobota in train 87. Subsidies list contains "Passengers from Rimavska Sobota to Kremnica". Train 87 is just transfering passengers from Rimavska Sobota to Kremnica. Passengers from Rimavska Sobota in train haven't destination in Kremnica. Any passengers will get off in Kremnnica and they will wait to another train. I will not receive subsidy. I think that it is bug.

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/5766
@DorpsGek
Copy link
Member Author

Alberth wrote:

No it's not; the authorities only pay for passengers that have the city as final destination.
People passing through are not paid for (neither for people that pass through while staying in a train, nor for people that have to switch trains).

The fact that they have to switch trains is basically a property of your train network, not something that the town authorities control or want.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12641

@DorpsGek
Copy link
Member Author

Milsa wrote:

If I want subsidy I must isolate stations. It is against cargo destination. Ok, how to get subsidies?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12642

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 2, 2013

fonsinchen wrote:

A solution could be to priorize subsidized lines against others in DemandHandler and McfFirstPass. This, however, would somewhat defeat the purpose of subsidies. While the line is subsidized traffic on that line would be artificially increased. As soon as it's not subsidized anymore traffic would drop again, in extreme cases as the one shown above, to 0. Whoever gives the subsidy should feel cheated then.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12646

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 2, 2013

fonsinchen wrote:

Or we could pay the bonus (but not the original delivery income) if the cargo is only transferred, not actually delivered. That might work. The problem with the above savegame is not that there are no passengers travelling along that line. The problem is that only a very small fraction of them are delivered to the subsidized destination.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12647

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 2, 2013

fonsinchen wrote:

However, paying the subsidy on transfer has two problems:

  1. Cargo could stay in the vehicle and not be transferred at all. Then it should still be subsidized.
  2. Cargo could first be transferred and then delivered to the same town. It would get two subsidies.

Maybe we need a "subsidized" flag in CargoPacket which would be set whenever the packet travels along a subsidized route and which would trigger the extra payment at the final delivery.

On the other hand, maybe we want to scrap subsidies altogether and make people use GameScripts instead. I guess something similar to subsidies can be implemented as GameScript already.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12649

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

fonsinchen wrote:

There isn't really a safe way to priorize links in the link graph. As soon as you have multiple subsidies involving the same towns or industries you'll get the same problem again. All of them would then be priorized and steal cargo from each other. As no one seems to like the idea of paying the subsidy not only on deliver but also on transfer or passing through the only sane thing to do may be disabling subsidies for automatically distributed cargo.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12660

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

Milsa wrote:

What problem is about transfer?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12663

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

Milsa wrote:

This is solution for transfer subidies. Look at the image.

ABC - real way of train for AC
AC - computed way of train for AC
AC2 - computed profit for subsidy AB
AB2 - vector for compute subsidy transfer profit for AC (rotation angle is angle between AB and AC)

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12665

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

fonsinchen wrote:

I don't really get that picture. The root cause of the issue is that cargodist routes cargo independently of subsidies. So if you build a route suitable to fulfill a subsidy offer, cargodist might not send any cargo along that route which means you don't get the subsidy. In your case cargodist does send some cargo along that route, but that cargo only passes through and isn't delivered at the subsidized destination which also means you don't get the subsidy. That letter problem could be solved by granting the subsidy not only for delivered cargo, but also for cargo passing through. However, as that significantly changes the semantics of subsidies, people might not like it. It's less controversial to just switch subsidies off for automatically distributed cargo as cargodist is a new feature we can easily change without making anyone angry.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12666

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

Milsa wrote:

Ok.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12667

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2013

Zuu wrote:

Regarding subsidies and Game Scripts: GS can announce extra subsidies to players (by telling OpenTTD the source + dest) but they can currently not disable the default subsidies created by OpenTTD. It has been suggested that the default subsidies in OpenTTD could be converted to a default GS that is used when no custom GS is selected. This however do not cover detecting when a subsidy should be awarded nor bonus payment.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12668

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

Just preventing the default subsidies from spawning for automatically distributed cargo is easy. See ulfhermann/openttd@9baa232 . however, considering how hackish that piece of code already is, it might be better to redesign the subsidies after all.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766#comment12687

@DorpsGek
Copy link
Member Author

fonsinchen closed the ticket.

Reason for closing: Fixed

In r25882


This comment was imported from FlySpray: https://bugs.openttd.org/task/5766

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Cargodist labels Apr 7, 2018
@PeterN
Copy link
Member

PeterN commented Feb 18, 2019

I'm disappointed that I've only just noticed that subsidies are disabled when cargodist in use. I'd really like this to be reconsidered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

2 participants