Incidencia #44594

TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved

Abrir Fecha: 2022-05-14 22:13 Última actualización: 2022-06-26 19:44

Informador:
Propietario:
Tipo:
Estado:
Cerrado
Componente:
Hito:
Prioridad:
5 - Medium
Gravedad:
5 - Medium
Resolución:
Fixed
Fichero:
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
Comentario

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
Comentario

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
Comentario

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
Comentario

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
Comentario

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
Comentario

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
  • Propietario Update from (Ninguno) to cazfi
  • Resolución Update from Ninguno to Accepted
2022-06-26 19:44 Updated by: cazfi
  • Estado Update from Open to Cerrado
  • Resolución Update from Accepted to Fixed

Editar

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Entrar