Ticket #44167

mapgen: Phase out direct references to alltemperate and single_pole

Date d'ouverture: 2022-03-23 23:06 Dernière mise à jour: 2022-03-26 21:33

Rapporteur:
Propriétaire:
Type:
État:
Atteints
Composant:
Jalon:
Priorité:
5 - moyen
Sévérité:
5 - moyen
Résolution:
Fixed
Fichier:
2

Détails

Required for #44038. This is the mapgen part of #44166 and should use the macros defined there.

Ticket History (3/9 Histories)

2022-03-23 23:06 Updated by: alienvalkyrie
  • New Ticket "mapgen: Phase out direct references to alltemperate and single_pole" created
2022-03-24 03:11 Updated by: alienvalkyrie
Commentaire

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.

2022-03-24 04:16 Updated by: alienvalkyrie
  • Résolution Update from Aucun to Accepted
Commentaire

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.

2022-03-24 04:25 Updated by: alienvalkyrie
  • Résolution Update from Accepted to Aucun
Commentaire

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

2022-03-24 06:16 Updated by: alienvalkyrie
Commentaire

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).

2022-03-25 00:37 Updated by: alienvalkyrie
  • Résolution Update from Aucun to Accepted
Commentaire

Reply To alienvalkyrie

I will however change aforementioned code either way, since scaling down ICE_BASE_LEVEL indefinitely actually doesn't sound sensible.

Done. I did consider if there were some better solutions (e.g. "only scale down the portion of the ICE_BASE_LEVEL that is greater than MIN_REAL_COLATITUDE(wld.map)), but they all felt overengineered and not worth the effort.

With the new patch, ICE_BASE_LEVEL is not scaled down further than half, which means that alltemperate maps are now equivalent to alltemperate+singlepole maps before (cf. #44174), and which means that on future partial-hemisphere maps, the poles will take up more space.

2022-03-26 21:33 Updated by: alienvalkyrie
  • État Update from Ouvert to Atteints
  • Résolution Update from Accepted to Fixed

Modifier

Please login to add comment to this ticket » Connexion