Mail

[jamespetts]

Mail is a difficult topic to deal with because of its inherent complexity: in reality, it needs sorting multiple times before it is delivered, and that sorting needs people and substantial facilities to do it, and it takes a considerable amount of time. In Simutrans, none of this applies, and mail sorts itself magically as if it had its own legs and behaves as with passengers.

Also, at present, passengers have multiple destinations, but mail does not. On larger maps, this means that very little transportable mail is generated unless it can be connected to a network covering most of the map. People have commented about apparently low mail generation rates on the Bridgewater-Brunel server.

I should note at the outset that anything other than some very simple changes would be a lower priority than quite a lot of other work and may be some years off being implemented, but it is worthwhile to set out such thoughts as I have at this stage so that they may be discussed and so that they are not forgotten; and it may be that there are some intermediate things that might be done with minimal effort to improve the balance of mail.

Sorting

The relevance of this is that we have travelling post office carriages defined in the game. At present, the advantage of these is that they generate extra revenue. This is based on the system for catering for passenger vehicles. However, unlike catering in passenger vehicles, this is not how they worked in reality. In reality, the revenue was unaltered: the advantage was the increased speed of sorting.

If the revenue from mail is to be balanced accurately, it will not do to have it change depending on whether a travelling post office was used on its route. The people sending mail would not have paid more for their mail to be sorted in a railway carriage than at a post office. Balancing is a high priority task, and it will be difficult to achieve this for mail if the revenue unrealistically varies with whether a travelling post office was used. (I had originally imagined that the revenue from the travelling post offices would simulate additional fees paid by the Post Office for the use of the train, but this would not make sense without somehow simulating automatically the entire operation of the post office save for railways, ships and aircraft to which the Post Office contracted its dispatches, which would be impractical, so the player will have to act in effect as the, or rather a, post office).

Removing the revenue effect, however, would make travelling post offices redundant, which would then fail to simulate an important part of postal transport in the 19th and 20th centuries (1838-2003), which would be a major deficiency.

I have been talking to my father, who is a stamp collector and general postal aficionado, to try to understand how the postal system works and why and when sorting is necessary. So far as I now understand it, at least according to the traditional system that was used throughout most of the Post Office's history, post would generally be sorted once for each leg of its journey through the postal system; so, on arrival at a local post office, post would be sorted into "local" (i.e., addresses served by the same post office) and "non-local" (all others), and the "local" post would then be more thoroughly sorted by street, while the "non-local" post would be sorted according to which van/train that it needed to be sent to its next destination in. Then, on arriving at the next main post office, it would be sorted again, and again at the next, and so forth, until it reached its destination post office, when it would be given a final local sort into individual streets, and taken by the postman/woman to its ultimate destination.

The advantage of the travelling post office, apparently, was simply that the mail at the dispatching point could be much more approximately (and therefore quickly) sorted, as it would only need to be sorted as to which train that it was to go onto, rather than which specific destination post office to which it would go.

Simulating this fully is not likely to be feasible. The main issue is that, in Simutrans, there is no distinction between a post box and a sorting office. So, in Simutrans, but not in reality, a letter can go from a post box into a van and leave at the next post box and get directly to its destination. There is no easy means of altering the routing algorithm to prevent this - anything requiring mail to go to specific places to be sorted would require a very major rewriting of the routing code that is not likely to be feasible for very many years (unless there is some very intelligent way that I have not thought of; but any suggestions for this specific aspect would have to be from somebody who understands the routing code in detail).

However, if we allow that sorting can occur at any stop, there is a fairly simple way of simulating the time taken to sort letters, which is that, on departure from each stop, each packet of mail would be marked as unsorted; on arrival at every stop, every packet of mail marked as unsorted would be given additional transfer time at the destination stop to simulate the time that it takes to sort the mail. If, however, the mail were conveyed by a convoy containing a travelling post office, it would not be marked as unsorted on boarding the convoy, and thus would take less time in transfer at its next destination stop. It might also be that players could purchase station extension buildings to reduce the time taken to sort mails at any given stop.

One complexity is how this would work in the routing system. There is no reasonable way of modifying the routing system (without rewriting it completely, which is not feasible in the foreseeable future) to work on the basis of a differential transfer/transshipment time for different cargo arriving at the same stop, so far as I am aware at present (I did try to alter it to this effect once to allow for different transfer times for passengers depending on how far that they had to walk within the stop, but this proved to be impossible). One option might be to ignore this in routing, but that would then prevent the savings of time procured by a travelling post office from affecting mail routing, which might be significant where there is competition. Another possibility is to record the average actual time taken by mail arriving at the stop in question, and use this, but this would then fail to distinguish between mail arriving from a travelling post office and mail not so arriving, and also consume extra memory (and large games are already approaching 4Gb).

Adding the simple version of this feature without modifying the routing time would be very straightforward, especially if Ves were able to help with the GUI element of things, so I should be interested in people's views on how doing this would be likely to work in practice.

Alternative destinations

As noted above, currently, mail does not have alternative destinations. That means that, if mail can only reach a small fraction of the possible places on the map from its point of generation, it is very unlikely indeed to want to go to any of them. This effect is amplified exponentially with the size of the map (measured in terms of the total number of buildings that generate/accept mail).

For passengers, it is different: passengers have alternative destinations, and the number of alternative destinations automatically increases with the size of the map (again, measured in the number of buildings). So, passengers will much more readily travel even though many destinations are unreachable.

Mail does not have a journey time tolerance, unlike passengers, so mail will be transportable to a greater number of destinations - once everywhere is connected to everywhere else by mail. Until then, in the early game, it is often useless for players to try to connect anything with mail. This means that there may well be a negative feedback loop preventing players from ever building the infrastructure needed for mail, although that does not appear to be occurring on the Bridgewater-Brunel server, where there is extensive mail infrastructure.

It would be quite straightforward to add configurable alternative destinations to mail. This would mean that mail would be more likely to go to local destinations in an era when it cannot go further because there is no network for it to go further yet.

The question remains, however, as to whether this is desirable. For passengers, it simulates reality: if a person cannot go to the best butcher in the country because it would take too long to get there, he/she will go to the reasonably good local butcher instead. Likewise, if one cannot get within a sensible time to watch a particular play at a particular theatre, one might instead decide to travel to a local cinema.

Does this hold for mail? Does it make sense that, if one cannot write to one's long-lost brother who has moved to the other side of the country to find work, one would instead write a letter to one's cousin in the next town (but would not write to one's cousin in the next town if one could write to one's brother)? It makes some sense, perhaps, for business correspondence: one might write to a local business rather than a business far away if one can only transact with the local business.

It might be, then, that mail should have some alternative destinations, but a small fraction of those that passengers have; but how to calibrate it?

[AP]

Can we distinguish between business mail and personal mail?


I can imagine that being worthwhile since they behave very differently. I imagine in the "days of empire" a considerable amount of business administration was done by mail.

[jamespetts]

Can we distinguish between business mail and personal mail.

Possibly, but that would be a major feature, and thus take a lot of time to implement, as it would require code for treating it differently at every place where it needs to be treated differently. It would require a significant change in the way in which passenger/mail generation is handled. It is not clear how this would actually work: in what precise respects do you imagine this being different?

Such a thing would add a great deal of work, but it is not clear what problems that it would solve.

[AP]

Fair enough.  We seem to currently have normal and priority mail,  is that adding to things?

[jamespetts]

Fair enough.  We seem to currently have normal and priority mail,  is that adding to things?

What do you mean by "adding to things" here?

[AP]

I mean,  is it bringing a meaningful benefit to the simulation.  If not,  you could for example rename one of the existing classes to business mail.

[jamespetts]

I mean,  is it bringing a meaningful benefit to the simulation.  If not,  you could for example rename one of the existing classes to business mail.

It does bring something meaningful to the simulation, in that it simulates that different people are willing to spend different amounts to send mail. The way that it works is just that all mail generated is randomised as between normal and priority. This would not suffice for a simulation of business as opposed to personal mail, which, to be done properly, would have to be generated in realistically differing quantities, and only from and/or to a business address (otherwise, business mail would be generated originating and bound for residences with the same frequency as personal mail, and likewise personal mail generated to/from businesses), and altering the code to address these issues would be a huge amount of work; it is hard to see what corresponding benefit that the simulation would gain from this work.

[zook2]

"However, if we allow that sorting can occur at any stop, there is a fairly simple way of simulating the time taken to sort letters, which is that, on departure from each stop, each packet of mail would be marked as unsorted; on arrival at every stop, every packet of mail marked as unsorted would be given additional transfer time at the destination stop to simulate the time that it takes to sort the mail. If, however, the mail were conveyed by a convoy containing a travelling post office, it would not be marked as unsorted on boarding the convoy, and thus would take less time in transfer at its next destination stop. It might also be that players could purchase station extension buildings to reduce the time taken to sort mails at any given stop."

Call me a bit slow, but what difference does it make whether the mail spends a few extra game minutes being sorted, if it takes a game month or two to reach its destination? Would it have a major effect on revenue?

Anyway, an idea (probably useless because I don't know the routing code) might be to generate only mail that is addressed to an actual post office the player has built (or public ones that were generated by the city builder. Or use the Town Hall instead). And for each mail packet that reaches a post office, generate a new mail packet at that post office and address it to an actual house or business in the same town. At least that's more or less the way it works in real life.

[jamespetts]

Travelling post offices were used in reality to save time, so the saving of time must have been significant; remember, you are using two inconsistent scales when you refer to "a few extra game minutes" and "a game month or two": a "game month" is 6.4 hours; a saving of half an hour is a significant proportion of that.

The significance of saving time might well be that, when I rework town growth, the time that it takes to send and receive mail from a particular area might well make a difference to how desirable that building in one place rather than another is, and thus affect the pattern of town growth.

As to your different idea, that would require a major rewrite. It would also be very difficult to make work well - precisely how local would a post office have to be to be local enough? What happens when there are multiple post offices that are local enough? What would a TPO do? This would also not really simulate sorting, as sorting has to be done at every step of the way, not just at the final post office, so it would be a lot of extra work for a very limited benefit, and would not give TPOs any economic significance.

[wlindley]

Given game mechanics: If the time that mail spends in a TPO,  were counted at half of the actual recorded time, would that be suitable?

[DrSuperGood]

I like your TPO mechanic suggestion. Transfer time penalty if unsorted. Possibly post related buildings lowering it is also good.

As for alternative destinations, why not use a mixture? 2/3 of post is random destination while the other 1/3 is given multiple destinations. This simulates people using mail to keep in contact with people they can keep in contact with rather than trying to keep in contact with someone they cannot. This means players will get some reward for small mail infrastructure, but will get even more for larger.

Could we get a penalty for mail overcrowding at a transfer? On the server someone set up an inefficient delivery route for mail and is causing back logs (which I have to pay to store). I would imagine forcing the line manager to "refund" some of the mail for the lines that are causing the back log would suffice. Like with passengers, if mail is left too long at an overcrowded stop it becomes "lost" so some financial penalty must be paid. The victim mail chosen to be lost is selected by grouping mail into immediate destination or lines and sorting by quantity and taking the largest 50%. In the case of the server game example, this would mean that I, the stop operation, and my efficient lines would not get a refund penalty but the person who has over 900 mail waiting at my stop to be delivered would.

[jamespetts]

W. Lindley - I am not sure that I understand your suggestion, I am afraid; can you elaborate? In particular, what exactly do you mean when you refer to "counted at half of the actual recorded time"?

Dr. Supergood - I had been thinking a similar thing in relation to mail and alternative destinations. In particular, I had thought that mail that originates at and is bound for residential buildings would not have alternative destinations, whereas mail to and/or from non-residential buildings would have alternative destinations.

As for mail overcrowding at a transfer, I do not think that automatically losing mail after a certain period of time makes any sense, but there is already a mechanic to increase the transfer time in the case of overcrowding.