Ticket #44594

TECH_UPKEEP_DEBUGGING messing research->techs_researched when future techs involved

Open Date: 2022-05-14 22:13 Last Update: 2022-06-26 19:44

Reporter:
Owner:
Type:
Status:
Closed
Component:
MileStone:
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
Fixed
File:
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
Comment

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
Comment

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
Comment

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
Comment

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
Comment

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
Comment

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
  • Owner Update from (None) to cazfi
  • Resolution Update from None to Accepted
2022-06-26 19:44 Updated by: cazfi
  • Status Update from Open to Closed
  • Resolution Update from Accepted to Fixed

Edit

Please login to add comment to this ticket » Login