The International Simutrans Forum

      if(current_node->link != NULL && paths[category].put(current_node->halt, current_node))
      {
         // Track the path back to get the next transfer from this halt
         path* track_node = current_node;
         for(uint8 depth = 0; depth <= 255; depth ++)
         {
            if(track_node->halt.is_bound())
            {

               if(track_node->link->link == NULL)
               {
                  path* tmp = paths[category].get(current_node->halt);
                  tmp->halt = track_node->halt;
                  break;
               }
            }
            
            track_node = track_node->link;
         }
         if(!paths[category].get(current_node->halt)->halt.is_bound())
         {
            // Remove bad paths (transfer depth too great, so aborted)
            delete paths[category].remove(current_node->halt);
         }
      }
      
      INT_CHECK( "simhalt 1694" );

      if(current_node->halt == goal)
      {
         // Abort the search early if the goal stop is found.
         // Because the open list is stored on the heap, the search
         // can be resumed where it left off if another goal, as yet
         // not found, is searched for, unless the index is stale.

         if(open_list[category].empty())
         {
            search_complete[category] = true;
         }
         return;
      }   
      
      current_node = NULL;
   }

      if(current_node->link != NULL)
      {
         previous_connexion = current_node->link->halt->get_connexions(category)->get(current_node->halt);
         if(previous_connexion != NULL)
         {
            previous_best_line = previous_connexion->best_line;
            previous_best_convoy = previous_connexion->best_convoy;
         }
      }

I have noticed a significant improvement in the performance in the bi-monthly refresh of paths.

However, I have found, after testing (following a lead from Dante), that the unresponsiveness occurs primarily after updating a line. That seems to persist even after your updates. Curiously, for reasons that I have yet to fathom, it does not occur when adding a new line, or placing down new stops (or adding a new line that serves new stops, even when some of those stops are public). I am not sure whether there is anything in that - perhaps there might be some issue with the code for updating lines? It seems odd to me that the performance should be uniquely affected by updating lines.

I found only a tiny amount of unresponsiveness after updating a line on Dante's saved game, but a significant amount in "1982", so that is probably a good test platform.

I also notice, on "1982", that the amount of time before the game is responsive after it loads is a little faster with your latest fixes than it was before (even comparing a debug build with your fixes and a release build without them).

The overall speed of the game (when fast-forwarded, measured by the time multiplier) is not, however, noticably changed.

some further consideration needs to be given to the line updating issue, however.

I think that I shall have to make instant re-routing optional given that there appears still to be a potential for significant unresponsiveness (albeit only in larger maps) even with the code as efficient as we can make it.

As to the special binary, perhaps it could be called something like 3.14a to avoid confusion?