Ticket #44594

TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved

Eröffnet am: 2022-05-14 22:13 Letztes Update: 2022-06-26 19:44

Auswertung:
Verantwortlicher:
Typ:
Status:
Geschlossen
Komponente:
Meilenstein:
Priorität:
5 - Mittel
Schweregrad:
5 - Mittel
Lösung:
Gefixt
Datei:
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-Verlauf (3/10 Historien)

2022-05-14 22:13 Aktualisiert von: cazfi
  • New Ticket "TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved" created
2022-05-14 22:27 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
Kommentar

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 Aktualisiert von: cazfi
  • Verantwortlicher Update from (Keine) to cazfi
  • Lösung Update from Keine to Accepted
2022-06-26 19:44 Aktualisiert von: cazfi
  • Status Update from Offen to Geschlossen
  • Lösung Update from Accepted to Gefixt

Bearbeiten

Please login to add comment to this ticket » Anmelden