Fix #10511: Delay 'go to nearest depot' orders

[SamuXarick]

Motivation / Problem

#10511

A lone Road Vehicle with a "go to nearest depot" order on a large road network and no depot nearby causes constant calls to the pathfinder every tick, hindering game performance.

This is happening in ProcessOrders and not in IndividualRoadVehicleController as it's been in the previous reported cases with similar symptoms. I think that the ideal solution here would be to call the pathfinder upon reaching the end of a segment, as that would in theory limit the number of calls significantly. But in this case, it really wants to know what's the destination of the order before handling it over to the IndividualRoadVehicleController.

I don't know how to do that, so I thought of a different approach.

Description

Delay the nearest depot order search for a day if the destination has been set to zero, which happens when it has already attempted to do so and failed to find a valid destination.

Closes #10511.

Limitations

It may break other "legitimate" uses for v->dest_tile == 0

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, game_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[glx22]

Squash required, but final diff looks good to me.

Seems default penalty is actually too small

[SamuXarick]

A better savegame with 74 vehicles going to nearest depot.
go to nearest road vehicle depot x74.zip

[2TallTyler]

@SamuXarick This looks fine to me, but can you test your demo savegame and verify it still works, and I haven't given you some wrong code? 😉

[SamuXarick]

@SamuXarick This looks fine to me, but can you test your demo savegame and verify it still works, and I haven't given you some wrong code? 😉

TimerGameCalendar::date_fract worked the same as if it was TimerGameTick::counter % Ticks::DAY_TICKS.
One starts from 0 and goes up to 73. On the 74th, it becomes 0 again. The values I'm interested are in the range 0-73.
The other starts from 0 and goes to infinity. Using % 74 assures I am also getting the desired values in the range 0-73.

If there's some other functionality I'm not aware that could skew this check, then I must be aware.

[glx22]

Suggested change

	if (v->dest_tile != 0 || TimerGameCalendar::date_fract == (v->index % Ticks::DAY_TICKS)) {
	if (v->dest_tile == 0 && TimerGameCalendar::date_fract != (v->index % Ticks::DAY_TICKS)) break;

should work too without needing to touch indentation.
(Maybe return false instead of break, but I didn't analyse all the function)

[PeterN]

What happens to the road vehicle in this state? Does it just carry on driving randomly?

[glx22]

Yes for at most a day, it's usually a user error if the vehicle can't determine what is the nearest depot, and the change is just so it has less impact on gameloop.
Before the change the search would happen every tick.