The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.
The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.
The feeder share setting applies in the existing way.
'date -u' returns the time in UTC. 'git log' uses local time. In
result, when a machine is on for example +0100, it would generate
the changelog of 7 days 1 hour, instead of 7 days. This is a silly
oversight.
SDL_GetVideoDriver(0) returns name of first video driver included in
the library, not the driver currently used.
SDL_GetCurrentVideoDriver() does what we want here.
* Feature: GS method to allow company to use an engine before its introduction date
* Feature: GS method to retire an engine early for a specific company
If the game was started loading a savegame or scenario, auto-restart will load a new random map.
This is inconsistent with the case in which a heightmap was loaded, as in that case the heightmap is kept as a basis for a new game.
This proposal solves this heterogeneity be considering the originally loaded resource shall be kept, hence savegames & scenarios shall be reloaded
MCF Dijkstra iterations are executed for all source nodes in a round-robin order.
Source nodes typically require different numbers of MCF Dijkstra iterations
to satisfy all of their demand.
This change is to avoid performing MCF Dijkstra iterations on source nodes which
have already been fully satisfied.
In the case where multiple industries have the same name, sorting
in the industry directory window is non-deterministic.
This results in the order changing on each re-sort, and is noticeable
when the industries have different production or transported values.
