Tíquete #44594

TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved

: 2022-05-14 22:13 Última Atualização: 2022-06-26 19:44

Relator:
Dono:
Tipo:
Estado:
Fechado
Componente:
Marcos:
Prioridade:
5 - Medium
Gravidade:
5 - Medium
Resolução:
Fixed
Arquivo:
1

Details

init_tech() recalculates research->techs_researched when TECH_UPKEEP_DEBUGGING is defined. That recalculation does not consider future techs.

This is one candidate for the cause of various assert failures I'm getting in testing #44419. When number of lost (i.e. ones subtracted from the counter) future techs is same as number of real techs, the counter goes to zero despite player knowing a lot of techs.

Ticket History (3/10 Histories)

2022-05-14 22:13 Updated by: cazfi
  • New Ticket "TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved" created
2022-05-14 22:27 Updated by: cazfi
Comentário

That counter is resetted later, so isn't the cause of the asserts.

server/techtools.c::593: assertion 'research->future_tech == 0' failed.
ai/default/daidiplomacy.c::349: assertion 'player_tech_upkeep(pplayer) == 0' failed.

2022-05-14 23:22 Updated by: cazfi
Comentário

The savegame seems to have correct techs_researched vaues, so the error is not coming from there either. Regardless, opened #44595 for sanity checking savegame in this respect.

2022-05-15 01:40 Updated by: cazfi
Comentário

Reply To cazfi

The savegame seems to have correct techs_researched values

No, it doesn't. I made the initial check wrong way. The count in the savegame is correct for none of the players - most of them have a negative count!

2022-05-15 12:33 Updated by: cazfi
Comentário

We still don't know why the counters have ended wrong in the savegame. One bug messing the counters is #44593, but it's unlikely to explain so drastically wrong values as in the savegame in question.

In any case we should add also sanitycheck.c check for these counters. It will help in detecting and debugging such problems in the future - maybe even the very case we are facing here.

2022-05-27 18:17 Updated by: cazfi
Comentário

Reply To cazfi

In any case we should add also sanitycheck.c check for these counters. It will help in detecting and debugging such problems in the future - maybe even the very case we are facing here.

That's what this ticket is about, now.

2022-05-29 03:55 Updated by: cazfi
Comentário

Maybe it's not a very good idea to introduce that sanity check to an active release branch. While it could help us to find the problems, we don't want it to start constantly failing on people as a regression compared to earlier 3.0 releases.

People who want to test S3_0 for this problem, can use such sanity check locally.

2022-06-18 12:41 Updated by: cazfi
  • Dono Update from (Nenhum) to cazfi
  • Resolução Update from Nenhum to Accepted
2022-06-26 19:44 Updated by: cazfi
  • Estado Update from Aberto to Fechado
  • Resolução Update from Accepted to Fixed

Editar

Please login to add comment to this ticket » Login