News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Refund statistics

Started by zook2, January 14, 2023, 12:03:17 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zook2

I have a flourishing transport company on the BB server, but a while ago I noticed that profits were not what they were supposed to be. Not that money matters except for ego, but I found that I was paying enough refunds to buy Charles III. twelve new colonies in the New World. Or something on that scale. Just because some love letters were taking a year or two longer than promised to reach their destination.

Anyway, would it be possible to get refunds as a category in the Finance window? It can add up to a significant amount, but I don't even know where it's currently hidden.

By the way, the "Other" category in the Fin.Win. has Infrast. Maint. costs that are getting pretty huge for me. What's that?

Mariculous

There is actually no "refunds" section in the financial window. I'm not sure why. It might just have been forgotten.

Most expansion buildings are accounted as "Other"
Though for some reason the Staging Inn expansion building is not accounted as any of the categories available in the stats, but still accounted in "all"

Ranran(retired)

#2
company's refund is included in the revenue.

EDIT:
I checked a bit of code for this. Refunds may occur at stations and this is recorded as a negative profit, for which there is no chart. Therefore, players cannot currently see all refunds from the chart.

Station refunds always bring negative benefits only to the station owner. Wondering if this is really fair. The convoy that has already received the profit may be another player, and the station owner gets the access charge from another player's convoy who uses the station, but it is the station owner who makes the refund.
// no line or convoy found -> charge the stop owner
owner->book_revenue(-refund_amount, get_basis_pos(), ignore_wt, ATV_REVENUE_PASSENGER);
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Mariculous

The code you cite might imply this but it's only telling part of the truth.
Refunds are definitely assigned to lines, as you can see in the attached image.
Unbenannt.JPG
Maybe the stat doesn't represent reality, in which case this is clearly bugged.

In any case, charging refunds from the station owner is weird.

Ranran(retired)

#4
EDIT:
This refund system looks very weird to me.
The refund amount is for the entire journey, but the negative revenue is recorded for the line/convoy to the previous stopover.
This is only true if the starting point and the station where the journey is interrupted are connected by a single line/convoy.
For example, you traveled from the starting point with player A's convoy, and used player B's convoy at the next station, but the journey was interrupted. In this case, the profits of player A and player B should be subtracted.
However, it will try to take all profit and loss from the owner of the previous convoy/line. Cargo will refund from the convoy/line to the next destination. That is, Player B takes full responsibility.

And this convoy/line search could also be wrong.
// Find the line the pasenger was *trying to go on* -- make it pay the refund
linehandle_t account_line = get_preferred_line(tmp.get_zwischenziel(), tmp.get_desc()->get_catg_index(), tmp.get_class());
This is because it searches for the preferred route of the station used last time to get there from the station where the journey was interrupted. So we have to find the reverse route. For example, if this is a circular route, the reverse route is the line actually taken.
And as pointed out in the previous post, if it does a reverse route search and no route is found, the station owner will give them a refund. This is more likely to happen because the current line/convoy search is unfavorable.

Also, if multiple players are operating the same route, they may accidentally reap profits from another player.

And if it's traveling long distances, it's possible the last player won't get much benefit.
For example, for certain cargo, if it is already beyond a certain distance from the origin, no further fare can be obtained. Despite this, that player is unfairly required to only issue a refund. In other words, profitability is low and transportation risk is high.

EDIT2:
German in the code confuses me sometimes. I had some misunderstandings.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Mariculous

#5
Yes, I think that's the kind of refund Zook is talking about. At least it's the kind of refund I had in mind.

As usual, I will describe the situation for passengers, but it is quite similar for any other kind of freight (given they have a speedbonus defined)

First, about the code (at least how I understand it)
If a refund occurs, there are two relevant things to consider:
1. How much is refunded
2. Who is charged these costs.

The charged fare is documented an approximation, because we don't know how much was actually paid on the route so far.
It is based purely on the distance between the "ultimate origin" of the passenger and the station where the journey is discared. This distance is doubled and multiplied by the fare per kilometer.
That's all and I think as an approximation, this is not too bad, but surely we might consider recording the actual cost being paid yet on the route and then refund that actual cost.

So who is charged?
It is the owner of the preferred line from the current station (where the journey was discared) to the next hop.
I don't think this is quite weird if there is only one such line, but it is not quite fair if there are many different lines on that route.
Especially if these lines share more-or-less the same journey time between these two stops.



Real-world thoughts:
In the real-world, those passenger rights I know of basically ensure the following:
- The passenger will arrive.
- If the passenger does not arrive "in time", he will be paid an additional compensation.

That means, if for some reasons he cannot arrive in reasonable time, "someone" will pay them the cost of using a different means of transport (e.g. a long-distance train or a taxi, when the passenger has originally purchased a local transport ticket)
Additionally, he will get a (partial) refund on his ticket price depending on how late he arrived.

So who is that "someone" paying these compenstations?
Usually it's the company that has caused the situation. And that's where it gets complicated.

In the code, only a very specific situation is handled:
Passengers being stuck at a station because nobody is picking them up there.

Edit:
Quote from: [C] Ranran on January 21, 2023, 08:18:28 AMFor example, for certain cargo, if it is already beyond a certain distance from the origin, no further fare can be obtained.
If this is actually how the distance based fare calculation works, then that system is indeed not fair and might require some re-consideration, but I don't think this issue is quite much related to "who should pay the refunds".
It's still usually the fault of the company that was meant to pick these passengers up.

Mariculous

Thanks for looking into this Ranran!
I totally understand that the code might be difficult to read for the vast majority of people, i.e. everyone who doesn't speak German...
Simutrans code is difficult to read in any case, even if you understand this mixture of German and English...

I also had another look at this and I think that I have identified two issues:
1. On the user finance level, refunds are always considered "passenger" refunds. This is correct in pak128.britain-ex, but generelly, refunds can be paid for any kind of freight.
2. Refunds actually are not recorded on the company finance level (finance.h/finance.cc) So we cannot simply add this stat to the finance window. There simply is no such stat recorded.
I am not sure which category should store these.
Revenue is attached to the accounting type vehicle, which is recorded for each transport type seperately.

We might pick the transport type of the line whose owner is charged the refunds, but I am not sure if that makes any sense.