Activity.cs is searching for the location of triggers in the trackdatabase each timestep. For this is uses Traveller.DistanceTo. Some issues were found where this distanceTo can go into infinite loops. Some of these issues have been fixed. But Rob indicated that instead of fixing the DistanceTo or all locations in activity.cs, it is probably better to make sure activity.cs uses features from the new signalling system and a path-based triggering system. This is much faster because the track database does not have to be searched each time.
All of Rob's arguments are in https://bugs.launchpad.net/or/+bug/1448772. A related bug is https://bugs.launchpad.net/or/+bug/1447222. The initial discussion and report is in http://www.elvastower.com/forums/index.php?/topic/24176-orts-simply-freezes-up-no-error-message-sound-keeps-running. These bugs have been fixed with temporary solutions.
This ticket is here to make sure the activity.cs part is not forgotten (as suggested in the last entry on 2015-04-30 in ticket 1448772.) Not for 1.0.
Jeroen.
Using any Traveller functions every time step, especially the distance ones, is just a bad idea even without loops. :)
I'll put this down for 1.1 but it may take a fair bit of work, depending how the code depends on distances and such like.