Average comfort for lines is computed wrong....

[jamespetts]

Inkelyad,

the time for the purposes of journey calculation is indeed independent of bits_per_month, and this is intentional, since both distance and speed in km/h remain the same at any given number of bits_per_month, as does the distance scale and the number of tiles per real second that any given in-game km/h setting represents. Given that GUI minutes can be represented in many different ways depending on the local user's preferences, it does not seem as though synchronising that would work effectively.

Update: I have now taken up Dwachs' suggestion and used the halts' Quickstone IDs instead of co-ordinates for storage.

[inkelyad]

Given that GUI minutes can be represented in many different ways depending on the local user's preferences, it does not seem as though synchronising that would work effectively.

Well, I will try.

Update: I have now taken up Dwachs' suggestion and used the halts' Quickstone IDs instead of co-ordinates for storage.

You should do same for haltestelle_t:: waiting_times

And you need clean-up code. When station is deleted, all records about it still be present in average_journey_times.

[jamespetts]

Inkelyad,

see the latest commits to the point-to-point-average-speeds branch for an implementation of those most recent suggestions.

[inkelyad]

Is this code in path_explorer.cc is clean-up code for average_journey_times?

Code Select Expand


if(!halt_list[i].is_bound() || ! halt_list[(i+1)%entry_count].is_bound())
{
   current_linkage.line->average_journey_times->remove(pair);
   continue;
}
<And some code just later>

Can it be moved to convoi_t::unregister_stops and simline_t::unregister_stops?

And(maybe) blank journey_times can be filled in convoi_t::register_stops and simline_t:register_stops.
It (maybe) allow skip existence checking in path_explorer.

Edit: using average_tpl::reset in path_explorer seems too excessive. Something like this:

Code Select Expand


if (count > 1) {
    count /=2;
    total /=2;
}

should provide fade-out effect for old data.

[jamespetts]

Inkelyad,

thank you for your thoughts. The unregister stops methods, however, appear to be invoked only when a schedule changes such as to cause the present convoy or line no longer to call at those particular stops. This does not occur when a halt is deleted, as the convoys that stop there will continue to have the entry in their schedules, but as a waypoint instead of a halt. This cannot, therefore, account for deleting halts.

As to the fading of data: this does not seem optimum to me, as the remnants of very old data would linger for a long time, being ever reduced but never eliminated; this would be significant in cases of large discrepancies between the data (as where a convoy gets stuck on one occasion, for example). At present, it is designed to ensure that each set of data is used exactly once in the calculations. Additionally, a divide operation would be more computationally expensive than an assignment operation.

[inkelyad]

This does not occur when a halt is deleted, as the convoys that stop there will continue to have the entry in their schedules, but as a waypoint instead of a halt. This cannot, therefore, account for deleting halts.

That can't be right.
1) We have line through multi-tile stop
2) Remove said tile from stop
3) It became waypoint in schedule.
4) Line should be unregistered from stop and stop must be excluded from path-finding for that line somewhere. (In haltestelle_t::add_grund/haltestelle_t::rem_grund? registered_lines  used/changed here, but no calls to register/unregister functions.)