Well, I know exactly what goes wrong and what the game is doing, but it's very complicated to explain what is happening.
The problem is in a piece of code that produces a certain type of cargo around a house or office building (that is, everything that is not an industry) so it happens with mail too.
So, for the REALLY curious people out there, I'm going to explain what's going on. I'll take that challenge
Can get a bit technical, though, so be warned.
The function that is responsible for the production of cargo around, say, a house, is called with the following arguments: the coordinates of the house, its dimensions (usually 1x1 or 2x2), and the type of cargo that must be spawned around that. For multi-tile buildings, the coordinates given should be that of the tile with the lowest coördinates (which is the northernmost tile).
The first thing the game does, is step 4 tiles back in either direction and change the dimensions to be 8 tiles wider in both directions. That's what we could call the "inverse catchment area" or so. The building is going to catch the stations around it. So, for a 1x1 tile building, the dimensions are 9x9 now.
Then, the game enters what programmers will know to be a "nested loop": the game steps through the tiles one by one, one line at a time. For this, at the start a copy is made of the coordinates and the dimension values.
In the nested loop, the tile at the current coordinates is searched for stations, the "width" value is decreased (9x9 becomes 9x8) and the X-coordinate is moved forward by one tile. This is done repeatedly until the "width" value becomes 0; so at that point the game has searched 9 sequential tiles for stations. Then, the Y-coordinate is moved forward by one tile, the "length" value is decreased, and the X-coordinate and the "width" value are reset to what they were when we created a copy of them (so, dimensions are now to 8x9: we've finished the first line).
Another line of 9 tiles is searched for stations; after that, the "length" value is decreased to 7 and so on, until it reaches zero. At that point, the game should have searched the full 9x9 tiles around the building for stations.
After this loop, a certain amount of the specified cargo is spawned at each of the stations it found.
Now that's what the function *should* be doing. Instead, as we all know, it derails completely and dumps cargo at seemingly random stations.
What happens is this: the game builds up a list of (at most 15) station numbers (which range from 0 to 1023). The list always ends in a -1 value. These numbers are stored in memory as two-byte values; the upper byte ranges from 0 to 3 depending on the station number: <255 = 0; 256 to 511 = 1; 512 to 767 = 2, 768 to 1023 = 3. The -1 value is stored as two bytes with value 255 (this is the most technical part -- google "signed vs unsigned" or something like that).
Now, when the game finds a certain station, it starts walking through the list it has built up so far and it reads out the values until it reaches either the station it has just found on the map (in which case it has already seen that station on another tile and does nothing) or the -1 value (in which case it adds this station's number to the list and moves the -1 value one slot further). The point is: when reading a value from the list, the game
overwrites the dimension values it used to keep track of how many tiles it still had to check for stations!
So follow this...
The game hasn't found any stations around the building yet (so this list starts with the -1 value). As soon as it finds one (say, number #0001), it reads out this -1 value, which results in the dimensions to be set to 255x255. The game will start looking on the next 255 tiles in a row unless it finds another staton! Let's say it doesn't find one there, so at some point the dimension values reach 255x0 and the game shifts to the next line.
As the dimensions were stored before entering the nested loop, they are restored to "sane" values (i.e. 8x9). Somewhere in this line of 9 tiles, the game finds another station (with a different number than the first one, let's say this station is #0540). It again starts reading the list again, overwriting the dimension values. It first sees the other station in the list, setting the dimensions to 1x0, and then the -1 list terminator, setting the dimensions again to 255x255. So the game scans another 255 tiles from here.
Then, we end up on the third line (dimensions are now 7x9). Let's say the game finds another platform of station #0540 here. It starts reading its list again; first finding station #0001 which sets the dimensions to 1x0, then station #0540 which sets the dimensions to 28x2. Because it finds the same station again, the game immediately stops traversing the list and continues scanning tiles. As the "width" value is now 2, it will only search one more tile before it reaches 0 and jumps to the next line again. So, in this case, the game actually scans
too little tiles. Thus: it won't produce cargo on any other stations in this line of tiles. That's why it doesn't happen
all the time. In fact, it may even end up
not producing cargo on a station that is well within the "reverse cachment area" of the building!
Now you see that it actually took me little effort to get a 100% working way to reproduce this: just build two stations in the same tile line, where one catches the building. Because of this bug, the other will get picked up while scanning tiles anyway. Now it's up to you to use this information to build a station that
doesn't get any cargo from the office blocks that are standing
right next to it!
I hope this was somewhere near understandable
Greetings,
Jerry
Now lets get some crazy stuff done 
)
Either way, thanks a lot 