Migo portal can freeze the game

[satheon49]

Describe the bug

The game freezes when near Migo portals.

Steps To Reproduce

1. Find research facility
2. Save the game
3. Load the game
4. Approach research facility
5. Its quite random, you have a 1 in 7 chance of a portal being Migo and about a 59% change to have a freeze for each such portal. If the game does not freeze repeat from 3.

Expected behavior

The game does not freeze.

Additional context

Here is a gdb backtrace from a frozen case:

#0  0x000055b517f1c2dd in std::uniform_int_distribution<int>::operator()<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul> > (
    this=this@entry=0x55b518849a90 <rng(int, int)::rng_int_dist>, __urng=..., __param=...)
    at /usr/include/c++/9/bits/uniform_int_dist.h:82
#1  0x000055b517f1b712 in rng (lo=lo@entry=-5, hi=hi@entry=5)
    at /usr/include/c++/9/bits/uniform_int_dist.h:74
#2  0x000055b5177afbb6 in MapExtras::mx_portal_in (m=..., abs_sub=...) at src/map_extras.cpp:1800
#3  0x000055b5177b26a9 in MapExtras::apply_function (id=..., m=..., abs_sub=...)
    at src/map_extras.cpp:3139

Basically what happens is that in case of a Migo portal the logic that tries to construct resin walls will run into an endless loop in line 1800:

do {
  pos = p + point( rng( -5, 5 ), rng( -5, 5 ) );
} while( pos.x >= 1 && pos.y >= 1 && pos.x < SEEX * 2 - 1 && pos.y < SEEY * 2 - 1 );

p can roll between 5-18 (see map_extras.cpp line 1694). so basically if it is 7-17 for both x and y it will run into an endless loop.

[satheon49]

I would like to fix this issue myself though someone has to explain to me what the intention of that loop is.

Currently it tries to find a point close to the portal (within 5 squares) but the point also has to be OUTSIDE the current overmap square. If the portal is fairly centered in its own square this will cause the freeze. I assume that the actual pos should rather be INSIDE the overmap square which would allow removing the loop entirely and replace it with

pos = p + point( rng( -5, 5 ), rng( -5, 5 ) )
pos.x = std::min(std::max(1, pos.x), SEEX * 2 - 1)
pos.y = std::min(std::max(1, pos.y), SEEY * 2 - 1)

[Aivean]

Check this diff and relevant discussion there:
89dbdb4#diff-eabb0ca559c969e8378bd2f244818d171cbe4d34de383da4597754c50c45feffR1789

Inverted condition appears to be an accident. The original intention was to prevent calling map::ter_set outside of the map (it gets called from circle).