News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Sorting of mail and realism thereof

Started by Spenk009, February 09, 2017, 06:36:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Spenk009

I've been playing in the late 19th century, trying to develop a mail network. I encountered the issue due to the availability of buildings that are mail enabled.

It is in theory possible to built an entire network made of mail stops and no post offices, as mail is transported via any node in the network and with enough storage in convoys little is needed on the stop/station. This is not impossible in real life, but improbable. There is very little incentive to build expensive post offices and maintain them (large volumes excepted). Mail vehicles can't dump their goods on the side of the road (e.g. a staging post) and disappear knowing that the next connection will find the correct mail items it needs and immediately be able to leave with them. This also disregards the possibility of theft. I have two suggestions to help realism and necessitate post offices. The first is an easy fix, the second slightly less obvious in terms of benefits.

1. Integrate an only only_route_via_transfer variable, that only allows a changeover between lines/vehicles at stops that have a building that is enabled to sort the mail. It's in a similar vein to no_rounting_via_overcrowded. This would at least require transfers to have offices to redirect the items. I'm not sure whether this could build an array with all stops that can sort and store their respective direct connections in a list for quick lookup (look for stops first, then search other transfers and their stops).

2. Mail is created in "unsorted" form and once it has been in a stop that can sort the mail, the destination is discovered/shown and can then be routed to the appropriate stop. This is for realism, as the player has to wait until the mail is sorted before they can see destinations. Most players do not get close to their vehicle capacities unless they are connecting transfers by small convoys. This may induce unintended behavior if convoys unload at the first opportunity presented to them (if larger transfer stops further along schedules are intended to be used).

I have spent a few hours looking through the code in the project, but find it difficult to see where the mail routing system is initialized and run since it seems to borrow its operation directly from the passenger code albeit with different parameters.

jamespetts

Mail sorting could do with being added as a feature; the trouble is my very limited time and the very long list of other things, each of which will take an entirely unpredictable amount of time to finish. Of course, if anyone else were to implement a workable mail sorting algorithm, I should be happy for that to be integrated whenever it is ready, providing that pakset support were not a problem.

As to your two proposed solutions, no. 2 seems more sensible to me, and this is actually quite an interesting idea: having to take the mail to a sorting station to reveal its destination is probably a better idea than the (so far very sketchy) idea that I had previously had of mail being generated as "unsorted mail" and having to be converted to "sorted mail" (a different type of goods) before being delivered.

However, this second solution has much more complexity than is at first apparent because of the way in which mail generation and routing currently works. At present, all packets of "ware_t" (goods/passengers/mail) are generated with a destination. They all route themselves to try to reach that destination. The routing system does not distinguish between the type of thing being routed (i.e. mail, passengers, goods). The logic is simple: whenever a ware_t packet arrives at any stop, it looks up a table to see what its next transfer should be. It then boards the next vehicle bound for that transfer (unless it calculates that waiting for a subsequent one will get it there sooner). It keeps doing this until it arrives at its destination stop.

The actual calculation of these tables is a very computationally intensive process and is done periodically, now multi-threaded in the path_explorer class. This class was written by a very skilled coder whose nickname on this board was Knightly, and who has now sadly retired from Simutrans development. It is highly optimised and it is difficult to alter it too much without disrupting that optimisation (I have altered it in places on occasions, but only in fairly peripheral ways).

So, the idea of mail that does not reveal its destination until it is sorted contradicts some quite fundamental assumptions of the current way in which mail generation and routing works. Quite how to overcome this and integrate a solution into the code would require very careful and detailed thought.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

In reality there are more differences, especially in the first and last hop. Usually one postman is only picking up mail from postboxes and brings them to the post office. Another postman does the delivery. Sorting mail during transfer is possible only if you have special post office carriage on the train (or special post office bus). Yeah that is very complicated. It would be nice, but I agree with James that there are more important features that need finishing.

Sent from my ONEPLUS A3003 using Tapatalk