Freeciv

Minor obstacle / place where a decision needs to be made: In temperature_map.c:create_tmap(), adjust_int_map() is called to more evenly distribute temperatures on non-alltemperate maps. Two things:

(A) adjust_int_map() always produces zero-based output, so it can only be used when the actual poles are within the map's latitude range. I don't think this is a blocking issue, since not calling adjust isn't a world-ending problem (probably – I haven't checked).

(B) Even once A is solved, we still won't want to call adjust on alltemperate maps, since it would erase the variation introduced by height and coastal climate. The same probably applies to maps with a nonzero, but still very small (co-)latitude range; the question is where the cutoff should be. Possible considerations:

• The maximum amount a tile can be colder than its latitude dictates is by 0.405 * MAX_COLATITUDE (equatorial coastal mountains on a frigid planet)
• The maximum amount a tile can be warmer than its latitude dictates is by 0.0375 * MAX_COLATITUDE (middle latitude coastal floodplains on a desert planet)

Hard limits to maintain old behavior:

• When (co-)latitude range is zero (alltemperate), never call adjust
• When colatitude range is maximal, always call adjust, irrespective of whether latitude range is also maximal (regular map), only half that (singlepole), or inbetween

The simplest solution (to both problems) would be to only call adjust when colatitude range is maximal; that way, no additional variation is squished down – at the cost of maps that don't include a full hemisphere potentially having uneven temperature distribution. The slightly less simple solution would be to have a cutoff point (say, 1/2 or 2/5 or 1/3 of MAX_COLATITUDE) and call adjust iff the colatitude range is at least that. This would cause some anomalies where being slightly below the cutoff might allow more extreme outliers than being slightly above the cutoff, but I'd consider those acceptable – it's probably best to use a simpler solution now, and then maybe change it once #44038 is done and testing is easier.

Reply To alienvalkyrie

The slightly less simple solution would be to have a cutoff point (say, 1/2 or 2/5 or 1/3 of MAX_COLATITUDE) and call adjust iff the colatitude range is at least that.

Went with that; cutoff is MAX_COLATITUDE * 2 / 5, mainly based on the maximum amount a tile's temperature can differ from its colatitude.

I've also raised #44173 for the problem (A) above.

Regression test failed with multiplayer ruleset; presumably the patch has some unintended impact on alltemperate maps.

Reply To alienvalkyrie

Regression test failed with multiplayer ruleset; presumably the patch has some unintended impact on alltemperate maps.

Found the issue: The generalization of the code that used to halve the ICE_BASE_LEVEL on singlepole maps now scales it to the latitude range, which means it becomes zero on alltemperate maps. While that shouldn't, conceptually speaking, make a difference (since no tile's actual latitude is remotely close to it), the ICE_BASE_LEVEL is used in mapgen.c:adjust_terrain_param() to affect various terrain percentages.

This also reveals an underlying issue, namely that (prior to this change) singlepole affects alltemperate maps ~> #44174

I don't think it's worth adding special cases just to avoid this change; I will however change aforementioned code either way, since scaling down ICE_BASE_LEVEL indefinitely actually doesn't sound sensible (particularly for future maps covering less than an entire hemisphere – players might want larger polar areas there).