Many passengers now seems to be stuck at "Transfers" on the stations, and does not get inside the station or on any ship, I think this is a bug?
This is happening on all saves since the most recent build. I suspect it's because of the large merged pull request that fixed many compiler warnings.
Transfer times for all stops are all at 1193046:28:10 which totals 4294967290 seconds which is just under the maximum size for a uint32. Therefore this likely has something to do with the recent changes to signed/unsigned integer conversions.
I have now submitted a pull request that fixes the problem.
Reverting commit 65192df78 seems to fix the issue. The bug seems to be a side effect of removing using namespace std from float32e8_t.h and the compiler silently changing std::max/std::min for max/min. The results of these differ for large unsigned integers because std::max/std::min make an unsigned comparison and max/min make a signed comparison (see simtypes.h).
Thank you for the report - I have now reverted the commit to which ceeac refers. I should be grateful if people could confirm whether this is fixed with to-morrow's nightly build.
I've just built the latest master and can confirm transfer times work again, that means newly generated passengers will arrive at the stop again.
However, passengers that already are in transfer will remain in transfer for a long time, so an emergency mechanism might be required when loading such games, otherwise there will be passengers in transfer for roughly the next 15 milleniums...
Due to that very huge number, it should be fine to simply detect any transfer times greater than 2^31 seconds and reset these to a reasonable low value.
Quote from: Freahk on May 20, 2020, 12:02:54 PMI've just built the latest master and can confirm transfer times work again, that means newly generated passengers will arrive at the stop again. However, passengers that already are in transfer will remain in transfer for a long time, so an emergency mechanism might be required when loading such games, otherwise there will be passengers in transfer for roughly the next 15 milleniums... Due to that very huge number, it should be fine to simply detect any transfer times greater than 2^31 seconds and reset these to a reasonable low value.
Thank you for that suggestion. I have added the following code, which I hope will suffice:
if (tc.ready_time > current_time + UINT32_MAX_VALUE)
{
// HACK: Fix after-effects of bug from 20 May 2020 causing extremely high transnfer times.
// This can be removed shortly afterwards.
transferring_cargoes[i].remove(tc);
tc.ready_time = current_time + 10000;
transferring_cargoes[i].append(tc);
}
Fixed by https://github.com/jamespetts/simutrans-extended/commit/ca1f2d7fa4799dea65ad4b4b1ba038fc01b2ac20 ; move to solved
I have reviewed that change. I don't think the logic is correct.
Current time is in tick unit, which is real-world miliseconds.
Mentioned 2^32 transfer times were related to ingame seconds, not to ticks.
2^32 ingame seconds is something bewteeen 2^39 and 2^40 ticks at pak128.britain-ex' default settings.
That means wour fix won't work.
Anyways, I have prepared a different approach to hotfix this, when loading the save.
It will properly take care of seconds to ticks conversation and ignores any transfer times where more than 2^31 seconds are remaining, simply setting their arrival time to "now".
I have pushed these changes to my github. It can be found here:
https://github.com/jamespetts/simutrans-extended/pull/174
The PR is based on a version before your hotfix and does not undo it. You'll need to do this in addition.
Thank you - now incorporated.
I have merged the two topics as these refer to the same issue. Thanks to Freddy for the fix to this and apologies that this was duplicated.