question about mail transport

[Mariculous]

Hey there,
after a while I found some time to play Simurans again. As ingame time passed by, I have to replace many of my trains now.
So far, I used combined mail and passenger transport on most of my lines. Now it seems that most trains can't be equipped with mail cars, which is perfectly realistic (or at least I guess it is)
I will need to setup a seperated mail network now but to setup a proper mail network, I need to know how mail routing works.

For passengers I know travel times are pretty important, so I need to setup multiple stops with overlapping catchment area, otherwise walking time will quickly lead to passengers not travelling at all or taking private cars due to too long journey times.

Are travel times also important for mail or doesn't it matter?
As mail generation is much lower than passenger generation, I can't (profitably) just send mail trains on the same lines as my passengers. These trains would be either nearly empty or extremely short, wich would both be pretty inprofitable. Mail cars already were'nt full when I only attached a single mail car to my passenger trains.
If travel times don't matter, I assume that it is fine to have just as many mail stops to cover the whole city with mail catchment areas, is this correct?
Also, schedule frequency does not matter (as long as stations don't get "overmailed" for sure), I can just set it as low as required to have fairly full trains.

Is this correct or is there some kind of waiting/travel time limitation for mail services?

[Spenk009]

According to the FAQs, mail has a maximum waiting time. There is only a preference for faster service, not an additional maximum transit time.

[Mariculous]

Could not find any information about mail being affected by journey time or not.
I guess at some time, I have read something about mail not being affected by journey times but I was not sure and coudln't find it when searching for it.

I just found information about max waitiing time and routing itself (mail will also use the fastest path)

Thank you for clearly pointing out that there is no maximum journey time for mail.

I would also like to know how long mail will wait.
FAQ states

If passengers, mail and goods with a non-zero speed bonus have waited at a single stop more than a fixed period of time (this is a value set in simuconf.tab), they will leave the station and claim a refund based on the estimated amount that they have paid so far to reach the stop in question.

In the paksets simuconf.tab ob Pak128.Britain-Ex I could find a passenger_max_wait of 19440. From the description I assume it is 18 hours or ~3 months, which is very high, so it doesn't matter in most cases.

However, I could not find any mail equivalent to this parameter. Is the same time used for mail?

[Spenk009]

We've gone through the same motions here.

I don't know enough about programming to look into whether the game picks up the value in simuconf.tab, maybe the reading of max_wait_time for pax isn't far from mail (and goods).

[Mariculous]

Well, so I'll just did some code research. I was hoping someone knew how it was implemented, so I don't need to dig through the code.

My reasearch came up with the answer and some additional maybe interessting implementation details:
At first, the quick answer is "passenger_max_wait" is simply bad named. Maybe historically it was limited to passengers only.
Any ware/good(class ware_t in the code, type=good in the dat) that has a speedbonus defined will also have a maximum waiting time. The actual waiting time is not the same as passenger_max_wait but depends on the speed bonus of a ware.

So we got a new question: Which wares have a speedbonus defined?
For pak128.Britain-Ex this is any good except Coal, Iron ore, Wood chip, Stone, Clay, Cement, Wroght iron, Crude oil, Petrol, Fuel oil and Chemicals. These will wait infinitely.

That were the important points. You can stop reading if you don't care about the details.


The relevant part of the code implementing max waiting time is in haltestelle_t::step

Code Select Expand


const uint32 max_wait = welt->get_settings().get_passenger_max_wait();
const uint32 max_wait_minutes = max_wait / tmp.get_desc()->get_speed_bonus(); // (*)
uint32 max_wait_tenths = max_wait_minutes * 10u;
if(waiting_tenths > max_wait_tenths){
bool passengers_walked = false;
if(tmp.is_passenger()){... /* (1) */}
if(!passengers_walked && tmp.get_origin().is_bound() && get_owner()->get_finance()->get_account_balance() > 0){... /* (2) */}
(3)
}
if(waiting_tenths > 2 * get_average_waiting_time(tmp.get_zwischenziel(), tmp.get_desc()->get_catg_index(), tmp.get_class())){... /* (4) */}

(1) is for passsengers only. It will try to let passengers walk to their next destination or their next transfer. Such passengers will still be unhappy with that station ( calling add_pax_too_waiting) but you won't have to pay a refund (see (2) for this)
Btw. What does pax mean in this case?

(*) We can see that the actual maximumum waiting time of a ware is NOT the same as passenger_max_wait and not the same for all wares.
passenger_max_wait is divided by the speed bonus value of the ware to get the actual maximum waiting time of that specific ware.

In (2) a refund has to be paid if the ware did not walk (anything else than passengers can't walk), the origin is known (wasn't deleted meanwhile) and the players account balance is positive. So no refunds for negative account balance!

(3) Increase stops waiting times, remove ware from the stop, and remove "disappearing" cargo from industries intransit counters. Not pretty interessting though.

(4) waiting times will increase additionally if the ware was waiting much longer than stations waiting times. I don't really understand this, as I don't know how often haltestelle_t::step is called and I don't want to dig on for this now.

[Phystam]

Speedbonus is obsoleted; it is removed when we have developed the passenger/mail class feature.

[Mariculous]

Speedbonus itself is indeed obsolete.

However, it's existence for a good is still important for the max wating time. If speed bonus for a good is 0, there won't be a max waiting time for that good at all.

https://github.com/jamespetts/simutrans-extended/blob/59f9d9d7de60c2bdd66610be8d194a82d6f319bd/simhalt.cc#L1337

The value of the speedbonus also matters as actual waiting time of a good is defined as max_wait/speed_bonus
This can be seen in the code snippet posted above but I forgot to explicitly mention this important behavior, so I've edited my post above.

[freddyhayward]

Maybe then it should be renamed to something like wait_time_tolerance, or wait_time_factor?

[Mariculous]

If we do so, we should also consider renaming passenger_max_wait to something like max_wait_base.

I guess renaming those in the code is fine
Renaming these in the dat would involve all pak authors to change their simuconf and ware dat files.

Aditionally, renaming the speedbonus parameter in the dat file is yet another standard to extended incompatibility on the pak level.
On the other hand it is indeed a different feature so not being compatible in that point may be fine.

However, I guess pakset authors, especially those maintaining a standard and extended version should decide this imho, as renaming the parameter should in the first place support pakset authors.

If we don't change the names, I kindly want to ask pakset authors to add a comment to the passenger_max_wait parameter mentioning that it is despite its name not only used for passengers but any ware that has a speedbonus defined. Additionally a comment in the ware dat would be nice mentioning that in extended this value will be used to calculate maximum waiting times.

I nearly forgot: please modify the Dat file reference for: Factories and Goods

(Should this "Speed bonus" section be removed:)
speed_bonus:{S} This specifies in percent how much revenue is increased if you use fast convoys. Usefull for time sensitive good like passengers and fresh food etc.
speed_bonus=

[wlindley]

Better names would be a definite improvement for new and updated paks. It's easy enough to add an alias in makeobj.  "Harbor" and "Harbour" are already aliases, for example.

[Mariculous]

So we should rename both and alias them with the old name. It will be much better readable.

[Ranran(retired)]

Until I saw this thread, I thought it was a bug that mail was sometimes discarded from the station.
Do we need too-waiting count stats in mails as well as passengers if mails that exceed the waiting time are discarded?