Passenger changes from 9.004(ish) to 9.006

[Junna]

I noticed a tremendous decline in passenger traffic, down by about 65%, from 2.7 million per month to just around one. To counteract this very steep and severe decline, I increased the passenger factor from 8 to 10, but I found that the only things getting crowded were local city buses. Traffic elsewhere remained low, increasing by perhaps 10%. The increase on city bus lines was at least three times the original amount. This seems odd to me, is this intended?

Also James, are you going to go along with Neroden's good suggestion and simply abolish the separate goods station reach - I think this would be the wisest way to proceed. Has the "Unknown" destinations for most goods yet been sorted?

[Carl]

The decrease in passenger traffic was planned, I think, and it was intended that passenger factor would have to be risen in order to maintain current levels of traffic. The further point about buses does sound concerning, and possibly speaks to a change in the routing mechanism--maybe related to walking?

[Junna]

The decrease in passenger traffic was planned, I think, and it was intended that passenger factor would have to be risen in order to maintain current levels of traffic. The further point about buses does sound concerning, and possibly speaks to a change in the routing mechanism--maybe related to walking?

Indeed, I understand the passenger total numbers were going to go down - they were clearly quite excessive (which was why I lowered the passenger factor). But the changes to routing resulted in almost all stops served by city buses being overcrowded, and hardly any traffic on inter-city lines (or even suburban services)... Now, I assume this wasn't quite the change intended?

[Carl]

No, indeed, and this could be an artifact of something not working right with the new passenger generation settings. James will likely know more!

[kierongreen]

Intention was to nuke long distance traffic as I understand to make things more 'realistic'.

[jamespetts]

There has indeed been a reduction in overall passenger traffic since earlier versions, to make the number of passengers generated consistent with real world data about the number of trips that any given number of people actually tend to make. To get a realistic amount, I suggest increasing the passenger factor again to 15 or 16 - 15 is the level that will be used by the next version of Pak128.Britain-Ex.

There has for some time been a deliberate tendency to favour local over long-distance traffic, as, in reality, most traffic is local rather than long-distance. In addition, there is a journey time tolerance, which is greater for midrange and long-distance passengers than it is for local passengers. In earlier versions (10.x) this tolerance was not working properly, in that it was ignored for return journeys, which caused an excess of passengers overall.

In the long-term, it is planned to replace the explicit distance ranges with a more sophisticated implementation of multiple destinations and journey time tolerances, which should provide a more even and realistic distribution of passengers to various destinations.

As to the goods stations; there have been a number of fixes to this feature on the development branch, which should be incorporated into the next version.

Thank you for your feedback; it is much appreciated.

[neroden]

I have almost got the goods station distance thing working.  I think.  There may be further bugs in it.

I'm beginning to work my way around to the hardest part of the journey time code.  The estimated and recorded journey times currently take walking (or "manual" freight haulage at 1 km/h) into account.  However.  The passengers and freight don't actually delay for the appropriate amount of time when transferring between halts or between halt and factory (this is a "cheat", you might say -- the passengers or freight think it took time, but it actually didn't take game time).

Fixing this will probably require some serious rework of the journey routing code.   But before I do that I want to fix the handling of attractions.

[jamespetts]

Thank you very much. Do you really think that it is necessary for passengers/frieght actually to wait for the relevant amount of time, so long as relative journey times and the journey time tolerance is calculated correctly? If it requires major reworking, this might not be an efficient use of coding time, unless it creates significant in-game anomalies.

[neroden]

Yes, it's significant and it creates serious anomalies.  However, it's no worse than the situation in standard, so I wouldn't feel that you have to fix it *immediately*.

The problem relates to factory production rates (it should apply to passenger and mail produciton rates too but it's more obvious with factories).  You can supply a factory using a number of convoys *as if* the transshipment time did not exist -- fewer convoys than you should need to use.

The correct way to do this is rather complex, but elegant. 
* When a city or a factory generates a packet, or when a halt routes a packet by walking to another halt, after finding a suitable route, it should put the packet into a "walking-to-halt envelope" associated with the halt, which waits until the relevant time has passed, and then drops the packet into the halt.  The halt will keep a list of people and freight walking towards it, with "go_on_ticks" numbers, basically.
* When a halt is ready to route a packet to its final destination, it should put the packet into a "walking-to-destination" envelope associated with the city or factory, which waits until the relevant time has passed, and then drops the packet into the destination factory (or credits it to the destination city).  The city and factory will keep a list of the people and freight walking towards it, with "go_on_ticks" numbers, basically.
* When a halt is deleted, the "walking-to-halt" packets should be dropped back on the halt they came from, or the factory they came from, or (if they were generated by a city) declared undeliverable and thrown out.
* When a factory or city is deleted, the "walking-to-factory" or "walking to city" packets should be declared undeliverable and thrown out.


----
Unfortunately, I found yet another set of bugs in the "freight coverage" code.  I attempted to fix those....
...and now I have disappearing freight again.  This time it's disappearing at a transfer stop!

The "freight coverage radius" code is nothing but trouble.  Really, I would love to rip it out entirely.  Transshipment times *ought* to substitute for it, except that the transshipment times aren't real yet (as noted above).  Sigh.

[jamespetts]

I see the point about the freight, and your solution is a sensible one (albeit for after the next release). I don't think that it affects passengers or mail, though, does it?

We should probably make a list somewhere of cleaning up/recoding/refactoring things that need to be done or might need to be done so that we can organise them, prioritise them, and assign them.

Thank you for all your bug-squashing work. This is not a good time to be a bug in Experimental, I think...

[neroden]

I guess it doesn't really affect passengers or mail *except for passengers walking between halts*.

As I'm going through the code, I'm seeing where one would implement the delays.

[jamespetts]

Ahh, I see the point: relating to the number/frequency of convoys again.