Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrepancies between meter effects and related sitreps and accounting #1927

Open
Dilvish-fo opened this issue Dec 23, 2017 · 2 comments
Open
Labels
category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:internal The Issue/PR deals with any project component that has no explicit `component` label. component:UI The Issue/PR deals with the game user interface, graphical or other.

Comments

@Dilvish-fo
Copy link
Member

#1623 notes certain discrepancies between damage repair sitreps and the actual damage repair,
#1894 notes that the accounting info for industry/research doesn't take into account that turns growth so wrongly has 'unknown' entries.
There is also some forum discussion on visibility that I think could wind up related (or at least potential developments there could also implicate these issues).

I think that both of these have related causes, due to our extra round of meter effects. Post combat we have the single primary round of effect processing, which includes (preliminary) meter updates and related accounting info generation, and also includes all scripted sitrep generation.

Later, after supply propagation is updated, and planet population growth is calculated, there is another round of superseding only-meter-effect processing, but this one does not currently include accounting info generation nor would any sitreps be generated at that point, thus allowing discrepancies to appear in both respects.

The accounting info aspect seems the simplest to me, it seems that we should have the accounting info update occur with the second round of meter effect processing instead of during the first (which for meters is really just a preliminary round).

As far as the scripted sitreps go, it is seeming to me that the best solution would be to allow SetMeter effects to have a SitRep subclause that would be conditionally executed (i.e., only at the second, meter-only round of effects processing); we would use these subclauses for meter-related scripted sitreps instead of having the independent GenerateSitRep effects like we do currently.

@Dilvish-fo Dilvish-fo added category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:internal The Issue/PR deals with any project component that has no explicit `component` label. component:UI The Issue/PR deals with the game user interface, graphical or other. labels Dec 23, 2017
@Dilvish-fo Dilvish-fo added this to the v0.4.8 (optional) milestone Dec 23, 2017
@geoffthemedio
Copy link
Member

Might be resolved by recent move of meter growth into effects and related changes...

@Dilvish-fo
Copy link
Member Author

It does seem likely that the recent changes resolved the issues in 1894, but the changes I'm aware of don't strike me as likely to have fixed the occasional sitrep/repair mismatch noted in 1623. I'll try to keep my eyes open for it, though.

@Vezzra Vezzra modified the milestones: v0.4.8 (optional), post 0.4.8 Aug 31, 2018
@Vezzra Vezzra removed this from the Next Release milestone Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:internal The Issue/PR deals with any project component that has no explicit `component` label. component:UI The Issue/PR deals with the game user interface, graphical or other.
Projects
None yet
Development

No branches or pull requests

3 participants