Feature: Make large UFO destination a bit more random

[Eddi-z]

Motivation / Problem

When a large UFO appears, it picks a random tile, and looks for the next rail tile. on usual networks, this often results in the same rail tile being picked, as some rail tiles "stick out" more than others, and there is a heavy bias towards those tiles

Description

With this PR, a random number of rail tiles is skipped after the first one, hopefully evening out some of these biases

Limitations

I haven't actually had time to run a test playthrough with disasters enabled

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, gs_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

[PeterN]

The main issue is the way it picks a random tile and then moves from there. This means that unless the rail networks are spread over the whole map (like might be found on a 256x256 map), it's somewhat biased to find the lowest index tile.

[James103]

Ideally, what should happen is that when a UFO spawns, it picks a random tile, tests to see if it is a track tile (that is owned by a non-AI company), and, if the test fails, picks another random tile, repeating up to X times, where X can be some number such as 64 or 255.

This should remove the bias that picking a random tile then walking forward causes, while also making UFOs affect the player slightly more frequently as their railway network expands.

[glx22]

Even when trying 255 times, it's highly probable to not find a human owned rail tile.

[Eddi-z]

The main issue is the way it picks a random tile and then moves from there. This means that unless the rail networks are spread over the whole map (like might be found on a 256x256 map), it's somewhat biased to find the lowest index tile.

you could fix that by wrapping around and stopping at the original tile instead of the end of the map

EDIT: actually, i think it already does this

[PeterN]

Yes, it does that, which doesn't help the bias. It could iterate in a random direction (chosen before the loop, unlikely to be effective), or use a (probaby expensive) RunTileLoop() style iteration.

[Eddi-z]

If you want to get a true even distribution you need to know the number of rail tiles on the map and then loop the whole map until you counted a random number from 0 to total number, which is potentially a slow operation. could be debatable if that actually matters in a rare operation such as this.

this change doesn't fully resolve the bias, but it should make it much less pronounced

[nielsmh]

Instead of using a linear tile search, would using a circular (spiral) search perhaps be more evenly distributed?

[Eddi-z]

no, as the problem is large swaths of unused land, where all tiles within that area will result in the same rail tile being chosen, a circular search doesn't really solve that

[Eddi-z]

What maybe could help would be a non-localized search pattern, so when the rail network only covers a small section of the map, the search pattern scatters those tiles around

[PikkaBird]

Ok, how's this for outside the box:

Pick a train, and target the tile it's currently on? :)

[PeterN]

Pick a train, and target the tile it's currently on? :)

Ease of implementation bonus: this is how the small UFO works for RVs.