Immediately pay transfer

[Ferrarius]

Hello everyone,

I developped a little patch that makes sure every leg of the route is paid directly to the transporter and only for the part over which the packet was actually transported. This allows players who use infrastructure sharing to properly get all the payments.

[planetmaker]

So I can send goods half-way, deliver them to a station where they decay and still get money for it? Sounds perfect

"where's my goods?"
"they're in Munich."
"In Munich?! I wanted them transported from Hamburg to Rome!"
"Yeah. But I have them there in an old shed. It's approx. half way. Thus may I have 50% of the contracted delivery price please? You can pick them up there whenever you want. But you'll need to buy a loading license and right-of-way for the road to the sheds"
"..."

[Ferrarius]

Yes, exactly, I didn't write this patch to be overly realistic but from what I gathered transfers were always paid to the last transporter which isn't very realistic either.

[Eddi]

That is also a problem i had a while ago, and i had a similar "fix".

it's probably fine for personal use, when you have enough self-restraint to use it the way it's intended, but due to the abuse potential it should probably not be used in a public environment.

@planetmaker see it like this:
passenger pays bus service in town A to get to the main station, pays train to go from town A main station to town B main station, and then pays bus service in town B. each of these are separate payments.

[bokkie]

Yet Another Advanced Option? For games with Cargodist, this is more of a problem since there are more vehicles making a (virtual) loss on which f.i. your rating depends and which gives a lot of annoying messages. This leads to a lot of noise in a sense, vehicles making a 'real' loss get overlooked more often because I just close all messages. (Which can already be turned off ofcourse).

[Eddi]

there is already an option to tweak the virtual loss. (feeder share)

[Alberth]

So I can send goods half-way, deliver them to a station where they decay and still get money for it? Sounds perfect

Nah, way too complicated, just bring them to some place, unload (get paid), load, bring them back, unload (get paid), load, bring them some place, ...

Always full load in both directions, infinite amounts of money \o/


Seriously, the reason why the payment is done at the end, is because only at the end you know the total amount of payment that should be done. All the intermediate steps are just estimated guesses, which can be hopelessly wrong (it's easy to construct such cases). Thus if you want a fair intermediate payment system, you have to keep track of what you paid to who in the past, and adjust payments for everybody involved.

[Ferrarius]

I know, but that would require far more significant changes and still isn't completely fair as the last transporter could easily get very negative income. Besides, especially in PAX it is more realistic to pay per part transported as this is how it is done in real life (at least, over here in the Netherlands). When transferring from bus to train one still must pay the bus transporter and not the train transporter.

[Alberth]

I know, but that would require far more significant changes and still isn't completely fair as the last transporter could easily get very negative income.

Depending on how you interpret "adjust payments for everybody involved", this need not be true.

Besides, especially in PAX it is more realistic to pay per part transported as this is how it is done in real life (at least, over here in the Netherlands). When transferring from bus to train one still must pay the bus transporter and not the train transporter.

Realism is not a design goal for OpennTTD, the main goal is "fun to play" if that contradicts with reality, so what?
Most often, reality is way too boring to copy into the game anyway.

[Ferrarius]

In that case, I don't like the previous way transfers were handled and this increases the fun for me. I'll make it into a settable option soon.

[michael blunck]

Realism is not a design goal for OpennTTD, the main goal is "fun to play" if that contradicts with reality, so what?

Somebody not me should get gradually sick about that ineluctable blabber about a claimed antagonism between "realism" and "fun to play" in the context of TTD.

Because everyone with a background in development from TTD to TTDPatch to OTTD does know to what extent we have been using suggestions derived from real life to raise this game onto higher levels of fun.

regards
Michael

[kamnet]

To me, this seems like something that will take too much work from the developers to deliver too little fun OR practical use to end players.

[Eddi]

"realism" is neither a reason for nor against a feature.

the reason for a feature like this is the income distribution amongst multiple companies, which is a very long standing shortcoming, and reproduceable in trunk.
the reason against this particular implementation of the feature is the easy abuse potential.

it's that simple.

[adf88]

What's current behaviour? Do these estimations of partial profit (yellow floating prices) are permanent, or maybe everything is recalculated after cargo arrives? AFAIK there is no recalculation so perhaps that's the right solution?

[Eddi]

not entirely sure what you're asking.

yes, the (yellow) estimates are "fixed", as in once they're recorded, they won't change anymore.

and changing them afterwards is tricky at best, because in every cargo packet you'd have to record a list of vehicles the packet used, and from where to where it was transported. and what if vehicles are sold before the packet is delivered, and a new vehicle is bought reusing the same ID? it's both computationally and memory heavy, so "right" solution is a bit overly optimistic.

[Eddi]

an idea that i came up with, that might not be (much) less computationally heavy, but might more easily fit the current design better:

the cargo packet's size should stay constant, so instead of recording the travel history in the cargo packet, the vehicle which transferred the cargo will store a reference to the packet. when the packet is delivered, and the reference count is not 0, the package is kept alive, and in some (daily?) vehicle loop, the referenced transfer packets are checked whether they were delivered. if so, the transfer share is evaluated, and the final price is recorded. if the reference count then reaches 0, the cargo packet is destroyed.

asymptotically, you could end up with O((number of vehicles)*(number of cargo packets)) checks every loop. in a heavy transfer network (e.g. Cargodist with passengers/mail)

[adf88]

Sorry, I didn't clarify what I mean exactly

To overcome this:

So I can send goods half-way, deliver them to a station where they decay and still get money for it? Sounds perfect

we have to give proper amount of money to companies when cargo reaches it's destination. So there must be some information which couples cargo packets with companies and stores total time and distance travelled per each such couple. Basically it's many-to-many relation between cargo packets and companies.

Somehow automatically I started thinking about another problem - inexact partial cost calculation. If we would like to have exact results then we would have to do the same but per vehicle instead of per company. These two problems are similar.